8 ms·

I've been tracking the beta for a while. I'm confused about this announcement. These issues still seem unresolved? (1) docker can peg the CPU until it's restar

by senex 10y ago

I've been tracking the beta for a while. I'm confused about this announcement. These issues still seem unresolved? (1) docker can peg the CPU until it's restarted https://forums.docker.com/t/com-docker-xhyve-and-com-docker-osxfs-cpu-usage/10537/32 https://forums.docker.com/t/com-docker-xhyve-and-com-docker-... (2) pinata was removed, so it can't be configured from CLI scripts https://forums.docker.com/t/pinata-missing-in-latest-mac-beta-1-11-2-beta15/15541 https://forums.docker.com/t/pinata-missing-in-latest-mac-bet... (3) it's not possible to establish an ip-level route from the host to a container, which many dev environments depend on https://forums.docker.com/t/ip-routing-to-container/8424/14 https://forums.docker.com/t/ip-routing-to-container/8424/14 (4) filesystem can be slow https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/168 https://forums.docker.com/t/file-access-in-mounted-volumes-e... Are these fixed in stable? I'm personally stuck transitioning from docker-machine and (from the comments) it seems like other folks are as well...

hijinks 10y ago
I was an early user of the mac beta and the 100% cpu would happen 2-3 times daily. Now it maybe happens once every 2 weeks. Not sure about the others but the CPU isn't much an issue anymore. Maybe its just me being use to how bad it was.
- 010a 10y ago
  I've been heavily using it since what must have been early closed beta, and cannot recall ever having this issue. Might be something that isn't quite so widespread.
  - DigitalJack 10y ago
    It's about weekly for me on mac.
  - justincormack 10y ago
    It only happens with a few users, and not at all to the majority. It seems to happen more on older OSX versions, but beyond that there has not been anything identifiable in common about the systems it happens on unfortunately.
jmspring 10y ago
Sadly, the state of things, be it the Docker ecosystem or others, "ready for production" means something much different than it did years ago. For me, the definition of ready for production, Debian is a good example of the opposite end of Docker.
- gtirloni 10y ago
  Exactly. "Ready for production" and "industrial" are constantly abused. All these tools are awesome and we use them, but PROPERLY deploying and supporting them in production is far from painless (or easy).
- rhinoceraptor 10y ago
  I think by 'production', they mean 'ready for general use on developer laptops'. No one in their right mind is deploying actual production software on Docker, on OS X/Windows. I've been using it on my laptop daily for a month or two now, and it's been great. Certainly much better than the old Virtualbox setup.
  - mherrmann 10y ago
    I'm still using VirtualBox. Could you elaborate why Docker is better?
    - numbsafari 10y ago
      Leaving containers vs VMs aside, docker for Mac leverages a custom hypervisor rather than VirtualBox. My overall experience with it is that it is more performant (generally), plays better with the system clock and power management, and is otherwise less cumbersome than VirtualBox. They are just getting started, but getting rid of VirtualBox is the big winner for me.
      - mherrmann 10y ago
        Thanks!
      - 10y ago
girvo 10y ago
The filesystem is still not as fast as I would like, but it's incredibly improved over the last couple months. One thing I found, was to be a little more cautious about what host volumes you mount into a container: for a Symfony project, mounting `src` instead of the whole folder sped up the project considerably, as Symfony's caching thrashes the file-system by default.
jonesetc 10y ago
I have also yet to see a reasonable solution for connecting out of a container back to the host with Docker.app. On linux and OSX with docker-machine this is easy with: docker run --add-host host:ip.for.docker.interface foo But there is no equivalent to the docker0 interface or the vboxnet interface for Docker.app. EDIT: I don't use this for any production environments, but it is very useful for debugging and testing.
- colordrops 10y ago
  What about getting the gateway address from inside the container: HOST_IP=$(/sbin/ip route | awk '/default/ { print $3 }')
  - divideby0 10y ago
    That works for some use cases, but for others (Elasticsearch, Zookeeper, Kafka, etc) the service inside the container needs to bind to an interface associated with an IP that's also addressable by the host. Even in host networking mode, eth0 inside a DFM-powered container will bound something like 192.168.x.y but that 192.168.x.0 subnet is completely inaccessible from the host.
- justincormack 10y ago
  The best solution is to add a new stable, unconflicting IP address to the loopback interface on the Mac and connect to that.
  - jonesetc 10y ago
    Still not as friendly, as it requires system changes on the host, but not totally unreasonable. I'll give it a try if I evaluate Docker.app again.
- moondev 10y ago
  why not just bind a port with -p
thejosh 10y ago
Fixing the file system is going to be a very hard/impossible task.
- jaequery 10y ago
  They should just go with nfs mounts it is at least 10 times faster than what they have now
qubit23 10y ago
This is another issue that's been preventing my adoption of Docker for Mac: https://forums.docker.com/t/docker-pull-not-using-correct-dns-server-when-private-registry-on-vpn/11117/20 https://forums.docker.com/t/docker-pull-not-using-correct-dn.... The fact that DNS resolution over a VPN still doesn't work correctly makes me wonder how production-worthy this release is. It's a pretty common thing people want to do in my experience.
- turnip1979 10y ago
  Sigh .. I need to disconnect from VPN to use it. I think u can reconnect after creation.
- djs55 10y ago
  If you have the time, could you make a report on the issue tracker https://github.com/docker/for-mac/issues https://github.com/docker/for-mac/issues and include the contents of /etc/resolv.conf and "scutil --dns" when you connect and disconnect to your VPN? Ideally also include an example resolution of a name by the host with something like "dig @server internalname". I suspect the problem is caused by a DNS server in the "scutil" list being missing from /etc/resolv.conf. We're planning on watching the "scutil --dns" list for changes, but it's not implemented completely yet.
  - qubit23 10y ago
    Okay, will do. Resolution of internal hostnames by their FQDN works fine if I set my VPN client (Tunnelblick) to rewrite /etc/resolv.conf. That said, the search domain is not carried into the VM, so name resolution by hostname does not work. Also, Tunnelblick has a name resolution mode that does split DNS (i.e. preserves DHCP-set DNS servers and only forwards DNS requests for the internal domain to the VPN DNS servers). This mode doesn't work at all. Would it be possible to allow forwarding of DNS requests to the host machine like with Virtualbox (VBoxManage modifyvm "VM name" --natdnshostresolver1 on)? I feel like that would simplify things greatly.
dcosson 10y ago
I had a similar experience trying to switch to docker-machine as it sounds like you've had with the new apps, and ended up giving up. It's super simple through Vagrant though, just vagrant up and set DOCKER_HOST to the static IP. Plus there are vagrant plugins that let you sync a directory to the vm in a way that gives you inotify events so live build/update tools can run in your containers (which btw is huge, I can't believe the official apps haven't even attempted to address that, as far as I've seen).
- RussianCow 10y ago
  > Plus there are vagrant plugins that let you sync a directory to the vm in a way that gives you inotify events so live build/update tools can run in your containers (which btw is huge, I can't believe the official apps haven't even attempted to address that, as far as I've seen). If you don't mind, what are these plugins? This is one thing that's sorely missed when I do development with Vagrant. I did a small amount of searching and trial and error, but couldn't find a solution that worked for me.
  - maccam94 10y ago
    There used to be a separate vagrant plugin for rsync but it's now built-in. There is also built-in support for NFS and virtualbox/vmware synced folders. These all work reasonably well until you start having fairly large numbers of files/directories. Also if you use a native Linux host with LXC or Docker there is no overhead for sharing directories with the container, it's just a bind mount.
    - RussianCow 10y ago
      I don't believe NFS supports inotify events? At least, that's what I'm using, and I'm forced to use polling for any file change detection. And rsync is one-way IIRC. But yes, LXC on Linux works great when it's feasible; I've just been looking for something that supports file change detection on other platforms.
- zwily 10y ago
  The official apps do do that. It's one reason their shared fs performance is abysmal so far.
slidese 10y ago
I always thought of production ready to be stable, of all things. Feature complete is not a part of it. Basically, if you can live with the shortcomings a release has (bugs, performance, lack of features) you can use it in production as long as it's stable (and secure).
- hueving 10y ago
  I wouldn't consider pegging a CPU until restart to be 'stable'.
  - slidese 10y ago
    True. So that gives us one issue then?
    - jacalata 10y ago
      "Aside from that Mrs Lincoln, how was the play?"
  - slidese 10y ago
    But this release aside, I was more commenting on the whole concept of production ready.
  - avsm 10y ago
    This bug's been driving us mad because we can't reliably repro it on our machines at Docker, and it only happens to a small subset of users, but is very annoying when it goes trigger. It seems to be related to the OSX version involved, but there's not enough bug reports to reliably hone in on it. The other aspect that it may be is a long-running Docker.app -- since as developers we are frequently killing and restarting the application, it could happen after a period of time. I've now got two laptops that I work on, and one of them has no Homebrew or developer tools installed outside of containers, and runs the stable version of Docker.app that's just been released. If this can trigger the bug, we will hunt it down and fix it :-) In the meanwhile, if anyone can trigger it and get a backtrace of the com.docker process, that would be most helpful. Bug reports can go on https://github.com/docker/for-mac/issues https://github.com/docker/for-mac/issues
jaequery 10y ago
I wish they just adopt what dinghy did, xhyce with nfs mounts and dns server
amazingman 10y ago
Not to mention the lack of host:container socket sharing and the fact that the Moby VM time drifts due to system sleep. I love Docker for Mac, I use it every day, and it's definitely still beta quality.
- justincormack 10y ago
  How much does your time drift? We changed the mechanism so that it should sync from the OSX ntp server now, which seems to be giving good results. If you are having problems can you create an issue and we can look into it. Host container socket sharing will come, but it is complex as sockets only exist with in a single operating system, so we have to bridge them across two. We are using this for the docker socket, and debugging the issues across Mac and Windows, so it is in the roadmap.
  - amazingman 10y ago
    Actually GA may have fixed this. I was able to reproduce it, but may have checked too quickly. I opened https://github.com/docker/for-mac/issues/17 https://github.com/docker/for-mac/issues/17 against it, and may end up closing it.
mpermar 10y ago
Number (3) is specially painful. The fact that their documentation makes it very explicit that the host is bridged by default and containers are "pingable" aggravates it a little bit further as it seems as a very basic pre-requisite for the tool to be usable.
coleca 10y ago
For #3 that is an issue for remote debugging with things like XDebug for PHP. I have been using this command: sudo ifconfig lo0 alias 10.254.254.254 And setting the remote host to 10.254.254.254 instead of localhost inside the container to work around that issue. It's been working pretty well. I've been using the Beta version of Docker for Mac for many months and haven't had many issues with it at all. The biggest issue I've seen was the QCow file not releasing space and growing to 60+GB, but deleting it and restarting Docker did the trick (although I had to rebuild or repull any containers).
aleem 10y ago
I can't get it to work on OSX without the CPU staying at 100%. Still not fixed: > There are several other threads on this topic already. Setups that docker build an image and rely on in-Docker storage work well; setups that rely heavily on bind-mounting host directories do not. A complex npm install in a bind-mounted directory breaks Docker entirely, according to at least one thread here. https://forums.docker.com/t/just-switched-over-from-dlite-cpu-usage-through-the-roof-beta-is-unusable/12809/2 https://forums.docker.com/t/just-switched-over-from-dlite-cp...
kentt 10y ago
The last one, in my experience, is basically a deal breaker. Simple commands (eg rake routes, npm install, etc) take 100x longer. I'm don't have a firm opinion on what is or isn't 'production ready', but if there are major bugs, then there should be some way of disseminating that information instead of everyone rediscovering the same issues.
jokoon 10y ago
I wonder, is microsoft helping to solve those issues? If they are, it shouldn't take too long.
eugenmayer 10y ago
for 4) you can use http://docker-sync.io http://docker-sync.io - its compatible with docker for mac and others, supports rsync/unison/unison+unox and will have NFS support in the near future. With unison+unox you have full transparent sync while having native performance (no performance loss at all). This is far better the osxfs or nfs.

by senex 10y ago

hijinks 10y ago

I was an early user of the mac beta and the 100% cpu would happen 2-3 times daily. Now it maybe happens once every 2 weeks. Not sure about the others but the CPU isn't much an issue anymore. Maybe its just me being use to how bad it was.

010a 10y ago
I've been heavily using it since what must have been early closed beta, and cannot recall ever having this issue. Might be something that isn't quite so widespread.
- DigitalJack 10y ago
  It's about weekly for me on mac.
- justincormack 10y ago
  It only happens with a few users, and not at all to the majority. It seems to happen more on older OSX versions, but beyond that there has not been anything identifiable in common about the systems it happens on unfortunately.

jmspring 10y ago

Sadly, the state of things, be it the Docker ecosystem or others, "ready for production" means something much different than it did years ago. For me, the definition of ready for production, Debian is a good example of the opposite end of Docker.

gtirloni 10y ago
Exactly. "Ready for production" and "industrial" are constantly abused. All these tools are awesome and we use them, but PROPERLY deploying and supporting them in production is far from painless (or easy).
rhinoceraptor 10y ago
I think by 'production', they mean 'ready for general use on developer laptops'. No one in their right mind is deploying actual production software on Docker, on OS X/Windows. I've been using it on my laptop daily for a month or two now, and it's been great. Certainly much better than the old Virtualbox setup.
- mherrmann 10y ago
  I'm still using VirtualBox. Could you elaborate why Docker is better?
  - numbsafari 10y ago
    Leaving containers vs VMs aside, docker for Mac leverages a custom hypervisor rather than VirtualBox. My overall experience with it is that it is more performant (generally), plays better with the system clock and power management, and is otherwise less cumbersome than VirtualBox. They are just getting started, but getting rid of VirtualBox is the big winner for me.
    - mherrmann 10y ago
      Thanks!
    - 10y ago

girvo 10y ago

The filesystem is still not as fast as I would like, but it's incredibly improved over the last couple months. One thing I found, was to be a little more cautious about what host volumes you mount into a container: for a Symfony project, mounting `src` instead of the whole folder sped up the project considerably, as Symfony's caching thrashes the file-system by default.

jonesetc 10y ago

I have also yet to see a reasonable solution for connecting out of a container back to the host with Docker.app. On linux and OSX with docker-machine this is easy with: docker run --add-host host:ip.for.docker.interface foo But there is no equivalent to the docker0 interface or the vboxnet interface for Docker.app. EDIT: I don't use this for any production environments, but it is very useful for debugging and testing.

colordrops 10y ago
What about getting the gateway address from inside the container: HOST_IP=$(/sbin/ip route | awk '/default/ { print $3 }')
- divideby0 10y ago
  That works for some use cases, but for others (Elasticsearch, Zookeeper, Kafka, etc) the service inside the container needs to bind to an interface associated with an IP that's also addressable by the host. Even in host networking mode, eth0 inside a DFM-powered container will bound something like 192.168.x.y but that 192.168.x.0 subnet is completely inaccessible from the host.
justincormack 10y ago
The best solution is to add a new stable, unconflicting IP address to the loopback interface on the Mac and connect to that.
- jonesetc 10y ago
  Still not as friendly, as it requires system changes on the host, but not totally unreasonable. I'll give it a try if I evaluate Docker.app again.
moondev 10y ago
why not just bind a port with -p

thejosh 10y ago

Fixing the file system is going to be a very hard/impossible task.

jaequery 10y ago
They should just go with nfs mounts it is at least 10 times faster than what they have now

qubit23 10y ago

This is another issue that's been preventing my adoption of Docker for Mac: https://forums.docker.com/t/docker-pull-not-using-correct-dns-server-when-private-registry-on-vpn/11117/20 https://forums.docker.com/t/docker-pull-not-using-correct-dn.... The fact that DNS resolution over a VPN still doesn't work correctly makes me wonder how production-worthy this release is. It's a pretty common thing people want to do in my experience.

turnip1979 10y ago
Sigh .. I need to disconnect from VPN to use it. I think u can reconnect after creation.
djs55 10y ago
If you have the time, could you make a report on the issue tracker https://github.com/docker/for-mac/issues https://github.com/docker/for-mac/issues and include the contents of /etc/resolv.conf and "scutil --dns" when you connect and disconnect to your VPN? Ideally also include an example resolution of a name by the host with something like "dig @server internalname". I suspect the problem is caused by a DNS server in the "scutil" list being missing from /etc/resolv.conf. We're planning on watching the "scutil --dns" list for changes, but it's not implemented completely yet.
- qubit23 10y ago
  Okay, will do. Resolution of internal hostnames by their FQDN works fine if I set my VPN client (Tunnelblick) to rewrite /etc/resolv.conf. That said, the search domain is not carried into the VM, so name resolution by hostname does not work. Also, Tunnelblick has a name resolution mode that does split DNS (i.e. preserves DHCP-set DNS servers and only forwards DNS requests for the internal domain to the VPN DNS servers). This mode doesn't work at all. Would it be possible to allow forwarding of DNS requests to the host machine like with Virtualbox (VBoxManage modifyvm "VM name" --natdnshostresolver1 on)? I feel like that would simplify things greatly.

dcosson 10y ago

I had a similar experience trying to switch to docker-machine as it sounds like you've had with the new apps, and ended up giving up. It's super simple through Vagrant though, just vagrant up and set DOCKER_HOST to the static IP. Plus there are vagrant plugins that let you sync a directory to the vm in a way that gives you inotify events so live build/update tools can run in your containers (which btw is huge, I can't believe the official apps haven't even attempted to address that, as far as I've seen).

RussianCow 10y ago
> Plus there are vagrant plugins that let you sync a directory to the vm in a way that gives you inotify events so live build/update tools can run in your containers (which btw is huge, I can't believe the official apps haven't even attempted to address that, as far as I've seen). If you don't mind, what are these plugins? This is one thing that's sorely missed when I do development with Vagrant. I did a small amount of searching and trial and error, but couldn't find a solution that worked for me.
- maccam94 10y ago
  There used to be a separate vagrant plugin for rsync but it's now built-in. There is also built-in support for NFS and virtualbox/vmware synced folders. These all work reasonably well until you start having fairly large numbers of files/directories. Also if you use a native Linux host with LXC or Docker there is no overhead for sharing directories with the container, it's just a bind mount.
  - RussianCow 10y ago
    I don't believe NFS supports inotify events? At least, that's what I'm using, and I'm forced to use polling for any file change detection. And rsync is one-way IIRC. But yes, LXC on Linux works great when it's feasible; I've just been looking for something that supports file change detection on other platforms.
zwily 10y ago
The official apps do do that. It's one reason their shared fs performance is abysmal so far.

slidese 10y ago

I always thought of production ready to be stable, of all things. Feature complete is not a part of it. Basically, if you can live with the shortcomings a release has (bugs, performance, lack of features) you can use it in production as long as it's stable (and secure).

hueving 10y ago
I wouldn't consider pegging a CPU until restart to be 'stable'.
- slidese 10y ago
  True. So that gives us one issue then?
  - jacalata 10y ago
    "Aside from that Mrs Lincoln, how was the play?"
- slidese 10y ago
  But this release aside, I was more commenting on the whole concept of production ready.
- avsm 10y ago
  This bug's been driving us mad because we can't reliably repro it on our machines at Docker, and it only happens to a small subset of users, but is very annoying when it goes trigger. It seems to be related to the OSX version involved, but there's not enough bug reports to reliably hone in on it. The other aspect that it may be is a long-running Docker.app -- since as developers we are frequently killing and restarting the application, it could happen after a period of time. I've now got two laptops that I work on, and one of them has no Homebrew or developer tools installed outside of containers, and runs the stable version of Docker.app that's just been released. If this can trigger the bug, we will hunt it down and fix it :-) In the meanwhile, if anyone can trigger it and get a backtrace of the com.docker process, that would be most helpful. Bug reports can go on https://github.com/docker/for-mac/issues https://github.com/docker/for-mac/issues

jaequery 10y ago

I wish they just adopt what dinghy did, xhyce with nfs mounts and dns server

amazingman 10y ago

Not to mention the lack of host:container socket sharing and the fact that the Moby VM time drifts due to system sleep. I love Docker for Mac, I use it every day, and it's definitely still beta quality.

justincormack 10y ago
How much does your time drift? We changed the mechanism so that it should sync from the OSX ntp server now, which seems to be giving good results. If you are having problems can you create an issue and we can look into it. Host container socket sharing will come, but it is complex as sockets only exist with in a single operating system, so we have to bridge them across two. We are using this for the docker socket, and debugging the issues across Mac and Windows, so it is in the roadmap.
- amazingman 10y ago
  Actually GA may have fixed this. I was able to reproduce it, but may have checked too quickly. I opened https://github.com/docker/for-mac/issues/17 https://github.com/docker/for-mac/issues/17 against it, and may end up closing it.

mpermar 10y ago

Number (3) is specially painful. The fact that their documentation makes it very explicit that the host is bridged by default and containers are "pingable" aggravates it a little bit further as it seems as a very basic pre-requisite for the tool to be usable.

coleca 10y ago

For #3 that is an issue for remote debugging with things like XDebug for PHP. I have been using this command: sudo ifconfig lo0 alias 10.254.254.254 And setting the remote host to 10.254.254.254 instead of localhost inside the container to work around that issue. It's been working pretty well. I've been using the Beta version of Docker for Mac for many months and haven't had many issues with it at all. The biggest issue I've seen was the QCow file not releasing space and growing to 60+GB, but deleting it and restarting Docker did the trick (although I had to rebuild or repull any containers).

aleem 10y ago

I can't get it to work on OSX without the CPU staying at 100%. Still not fixed: > There are several other threads on this topic already. Setups that docker build an image and rely on in-Docker storage work well; setups that rely heavily on bind-mounting host directories do not. A complex npm install in a bind-mounted directory breaks Docker entirely, according to at least one thread here. https://forums.docker.com/t/just-switched-over-from-dlite-cpu-usage-through-the-roof-beta-is-unusable/12809/2 https://forums.docker.com/t/just-switched-over-from-dlite-cp...

kentt 10y ago

The last one, in my experience, is basically a deal breaker. Simple commands (eg rake routes, npm install, etc) take 100x longer. I'm don't have a firm opinion on what is or isn't 'production ready', but if there are major bugs, then there should be some way of disseminating that information instead of everyone rediscovering the same issues.

jokoon 10y ago

I wonder, is microsoft helping to solve those issues? If they are, it shouldn't take too long.

eugenmayer 10y ago

for 4) you can use http://docker-sync.io http://docker-sync.io - its compatible with docker for mac and others, supports rsync/unison/unison+unox and will have NFS support in the near future. With unison+unox you have full transparent sync while having native performance (no performance loss at all). This is far better the osxfs or nfs.