Thu Jun 16, 2016
Docker for Mac is a great product, but here’s a list of some gotchas and where possible the workarounds to them.
8/11/2016 - Docker for Mac Time drift issue
Noticed today (8/11/2016) that the zim docker container was stuck on 8/8/2016.
To fix: restart Docker for Mac from the Moby system tray or see below….
Apprantly there are two threads in the Docker Forums: https://forums.docker.com/t/syncing-clock-with-host/10432/10 https://forums.docker.com/t/time-in-container-is-out-of-sync/16566/7
Seems like it’s also an issue on Docker for Windows.
Github issue: https://github.com/docker/for-mac/issues/17
Time drift in Moby VM and containers caused by system sleep #17
+* If system does not have access to an NTP server then after a hibernate the time seen by Docker for Mac may be considerably out of sync with the host. Furthermore the time may slowly drift out of sync during use. The time can be manually reset after hibernation by running: + + docker run --rm --privileged alpine hwclock -s + + Or alternatively to resolve both issues you may like to add the local clock as a low priority (high stratum) fallback NTP time source for the host by editing the host's `/etc/ntp-restrict.conf` to add: + + server 127.127.1.1 # LCL, local clock + fudge 127.127.1.1 stratum 12 # increase stratum + + And then restarting the NTP service with: + + sudo launchctl unload /System/Library/LaunchDaemons/org.ntp.ntpd.plist + sudo launchctl load /System/Library/LaunchDaemons/org.ntp.ntpd.plist
Alternative Work Around
docker run -it --rm --privileged --pid=host debian nsenter -t 1 -m -u -n -i date -u $(date -u +%m%d%H%M%Y) Make it as alias command and run it when time drift.
9/28/2016 Docker for Mac - disk consumption of 64GB maximum
This blog post talks about Docker for Mac and how its disk consumption continuously grows over time.
This Github issue tracks the disk consumption issue.
The .qcow2 is exposed to the VM as a block device with a maximum size of 64GiB. As new files are created in the filesystem by containers, new sectors are written to the block device. These new sectors are appended to the .qcow2 file causing it to grow in size, until it eventually becomes fully allocated. It stops growing when it hits this maximum size.
Unfortunately when files are deleted from the filesystem, the block device doesn’t find out, because the connection protocol we currently use virtio-blk doesn’t support a “TRIM” or “DISCARD” operation. The block device keeps filling up with junk. A similar problem manifests on real hardware in SSDs – they start slowing down as they fill up, unless TRIM is enabled in the OS and drivers.
We’re hoping to fix this in several stages: (note this is still at the planning / design stage, but I hope it gives you an idea)
we’ll switch to a connection protocol which supports TRIM, and implement free-block tracking in a metadata file next to the qcow2. We’ll create a compaction tool which can be run offline to shrink the disk (a bit like the qemu-img convert but without the dd if=/dev/zero and it should be fast because it will already know where the empty space is)
we’ll automate running of the compaction tool over VM reboots, assuming it’s quick enough
we’ll switch to an online compactor (which is a bit like a GC in a programming language)
We’re also looking at making the maximum size of the .qcow2 configurable. Perhaps 64GiB is too large for some environments and a smaller cap would help?
Let me know what you think! Thanks for your patience.
Check the current size of your qcow2 file
$ du -sh ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2
The Nuclear Option
You can simply reset your Docker for Mac installation to stock and your qcow file will regenerate. This
WILL DELETE all of your images and containers however, so proceed with caution.
Repeat WARNING! This will DELETE ALL of your images and containers.
The Hard Way
Follow the steps in this blog post which involves installing the qemu utility via home brew to re-compress our qcow2 disk.
Oct 9, 2016 Docker-Compose and Docker network limitations
Docker-compose and docker network limitations - see this other blog post on how to clean up your local docker network definitions and deal with the possiblity that these RFC1918 ranges might overlap/conflict with the network you’re on.