This data is exported by container and machine-wide. Specifically, for each container it keeps resource isolation parameters, historical resource usage, and histograms of complete historical resource usage. It is a running daemon that collects, aggregates, processes, and exports information about running containers.
![]() Docker Unstable Mac Will NotSeptember 2020 Update: Alas, Docker for Mac will not be getting built-in Mutagen support at this time. Docker -version Docker version 1.10.3, build f476348/1.10.3 docker info Containers: 3 Running: 0 Paused: 0 Stopped: 3 Images: 42 Server Version: 1.10.3 Storage Driver: devicemapper Pool Name: dockervg-docker-pool Pool Blocksize: 524.3 kB Base Device Size: 107.4 GB Backing Filesystem: xfs Data file: Metadata file: Data Space Used: 17.69 GB Data Space Total: 73.67 GB Data Space Available. Hopefully that feature makes it to the standard Docker for Mac version soon. You can test them by getting the YAML files from the repository and changing latest.July 2020 Update: Docker for Mac may soon offer built-in Mutagen sync via the :delegated sync option, and I did some benchmarking here.The database is stored on a separate Docker volume, and not shared, so it is plenty fast on its own (and doesn't affect the results).The second benchmark loads the home page ( /) immediately after the installation this page load is entirely uncached, so Drupal again reads all the thousands of files from the filesystem and loads them into PHP's opcache, then finishes its operations.Both benchmarks were run four times, and nothing else was open on my 2016 MacBook Pro while running the benchmarks. The operation requires loading thousands of code files from the shared volume, writes a number of files back to the filesystem (code, generated templates, and some media assets), and does a decent amount of database work. Since then, the File system performance improvements issue has been a common place to gripe about the lack of improvements to the underlying osxfs filesystem.Since around 2016, support has been around (albeit barely documented) for NFS volumes in Docker (see Docker local volume driver-specific options).As part of my site migration project, I've been testing different local development environments, and as a subset of that testing, I decided to test different volume/sync options for Docker to see what's the fastest—and easiest—to configure and maintain.Before I drone on any further, here are some benchmarks:The first benchmark installs Drupal, using the JeffGeerling.com codebase. It was painfully slow, and the community finally got a cached mode that offered a 20-30x speedup for common disk access patterns around 2017.Docker-sync.ioDocker-sync is a Ruby gem (installed via gem install docker-sync) which requires an additional configuration file ( docker-sync.yml) alongside your docker-compose.yml file, which then requires you to start docker-sync prior to starting your docker-compose setup. But at least on macOS, everything is built-in, and you don't have to install anything extra, or run any extra containers to be able to get the performance benefit. For older macOS versions you would use /Users instead, and for locations outside of your home directory, you have to grant 'Full Disk Access' in the privacy system preference pane to nfsd.Some of this info I picked up from this gist and it's comments, especially the comment from egobude about the changes required for Catalina.So, for NFS, there are a few annoying steps, like having to manually add an entry to your /etc/exports, modify the NFS configuration, and restart NFS. For my Drupal site, since there are almost 40,000 files (I know. Docker bg-syncBg-sync is a container that syncs files between two directories. Not sure the reason, but might have to do with the way unison sync works. Too often is it overlooked that a developer's efficiency can be partially (or largely) impacted by the Operating System they work in. For Linux, since normal bind mounts offer native performance already (Docker for Linux doesn't use a slow translation layer like osxfs on macOS), I have a separate docker-compose.override.yml file which configures a standard shared volume.And in production, I bake my complete Docker image (with the codebase inside the image)—I don't use a shared volume at all."Note that even if a task takes twice as long, if it's not the major barrier to finishing a project (even if repeated a thousand times), then the tool or platform's raw performance might not be the most important measure."I agree with this. What about Linux?I'm glad you asked! I use the exact same Docker Compose config for Linux—all the NFS configuration is stored in a docker-compose.override.yml file I use for my Mac. SummaryI wanted to write this post after spending a few hours testing all these different volume mount and sync tools, because so many of the guides I've found online are either written for older macOS versions or are otherwise unreliable.In the end, I've decided to stick to using an NFS volume for my personal project, because it offers nearly native performance (certainly a major improvement over the Docker for Mac osxfs filesystem), is not difficult to configure, and doesn't require any extra utilities or major configuration changes in my project. The configuration is a little clunky (IMO), and requires some differences between Compose v2 and v3 formats, but it felt a little cleaner to manage than docker-sync, because I didn't have to install a rubygem and start a separate process—instead, all the configuration is managed inside my docker-compose.yml file.Bg-sync offered around the same performance as docker-sync (they both use the same unison-based sync method, so that's not a surprise), though for some reason, the initial sync took closer to three minutes, which was a bit annoying. Where are archive folder for email accounts in outlook for macOur team has always struggled with the volume mounts setup & performance, so was excited to test out your NFS solution.Unfortunately I haven't seen the same improvements in my own benchmarks. Something Mac OS CAN do, but largely only with unofficial ports of software installedReally interesting write-up, and some solid testing!I've worked on a Drupal 8 site using Docker on macOS for about two years now. Especially since those OSes are built with Tooling specifically suited for Docker/Cloud development. Unless the performance difference impairs work progress, it should not be a reason to NOT use Mac OS for development.In contrast, it should also NOT be a reason to forcing developers into using Mac OS over Windows or Linux. It could also degrade their work performance due to frustration, dislike, or unfamiliarity with the OS "forced" on them. (all tests run a few times, times averaged) NFS is a bit faster for some operations but a bit slower for others.Here are my test results. Particularly nuking & reinstalling all of our dependencies, although extreme, is something we end up doing a lot of, as we switch between branches with various module & core versions. root dir mounted with delegated: 1 min 52 sec yarn install with a completely empty node_modules directory: root dir mounted with NFS: 4 min 18 sec root dir mounted with delegated: 5 min 01 sec root dir mounted with NFS: 1.137 sec (!!)I compared the NFS mount to a default delegated mount so that I was testing in a similar way to how you were, and because a delegated mount is a pretty standard way to get a project set up.But that's actually not what we've been working with for the past few months. root dir mounted with delegated: 770 msec root dir mounted with delegated: 16.564 sec
0 Comments
Leave a Reply. |
AuthorMusa ArchivesCategories |