Live data from Hacker News

Docker for Mac and Windows Is Now Generally Available and Ready for Production

blog.docker.com

141–150 of 169 posts

Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production

#141
post #5

Earlier quoted context omitted.

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.

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.

I'm pretty sure they don't mean that, or they would have said that it was still in Beta.

Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production

#142
post #49
post #41

Earlier quoted context omitted.

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'…

The company claimed back in March [0] that Docker for Mac addresses the filesystem events. I observed that it works. While Docker for Mac has improved somewhat over the beta, unfortunately it's still quite rough. For example, it was only last week that they pushed a fix for the DNS timeout issue [1] (I think maybe it was fixed? I can't check because Docker for Mac is not open source). [0] https://blog.docker.com/2016…

The DNS resolving code in Docker for Mac is in the VPNkit project which is open-source: https://github.com/docker/vpnkit. A DNS timeout is a fairly general symptom and it's hard to diagnose fully without a packet capture, but there's one issue that I'm aware of: if the primary server is down then the UDP DNS queries and responses will use the host's second server. However if a response is large and requires TCP then unfortunately we will still forward it to the primary server, which obviously won't work :( I've filed this issue about it: https://github.com/docker/vpnkit/issues/96. We hope to improve DNS, VPN and general proxy support for 1.13 -- please do file issues for any other bugs you find!

Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production

#143
post #17

Earlier quoted context omitted.

It's amazing to me that a tool I use to prove that our stuff is ready for production is having such a hard time achieving the same thing.

Do you run your containers in production with "docker run" ??

Only for a tiny pet project.

The sales pitch I usually give people is that any ops person can read a Dockerfile, but most devs can't figure out or help with vagrant or chef scripts.

But it's a hell of a lot easier to get and keep repeatable builds and integration tests working if the devs and the build system are using docker images.

Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production

#144
post #115

Earlier quoted context omitted.

This seems to work fine for me: docker run -it -v /private/etc/passwd:/etc/passwd alpine sh (not recommended for any actual use obviously) Is there a particular case in which this failed for you? We'd appreciate a bug report on https://github.com/docker/for-mac/issues (or from the Docker for Mac GUI, just click on "Diagnose and Feedback") so we can chase down whatever issue you're having.

Yes, this use case, it happens on Windows and on Mac as well. C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: oci runtime error: rootfs_linux.go:53: mounting "/var/lib/docker/aufs/mn t/90d24356afdeb7b9ddad4b3b6903be92063151c33bf34f3d63ede464437060c6/cryptoservice/broker-config.yml" to rootfs "/var/lib/docker/aufs/mnt/90d24356afdeb7b9ddad4 b3b6903be92063151c33bf34f3d63ede464437060c…

The error message specifically says "not a directory" and afaik you can't mount single files, only directories. I at least have never even thought of trying to mount individual files since the bind mounting functionality in Docker seems to always and everywhere have been described in a way that suggests that it's for mounting directories, not individual files.

Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production

#145

Basically echoing senex's comment, but this announcement seems bizarre in light of https://forums.docker.com/t/file-access-in-mounted-volumes-e... . In particular, a Docker employee responds with a status update in https://forums.docker.com/t/file-access-in-mounted-volumes-e... , saying this isn't resolved for stable Docker for Mac. It's totally unusable for Rails development right now.

The 'convox start' dev environment enables Rails dev on Docker for Mac with a custom file sync strategy. This is another case of simple solutions win... You can effectively rsync code changes without all the low level file system madness. https://convox.com/blog/bidirectional-sync/

Thanks. There are some workarounds posted in the thread I linked, too. Frustrating that Docker for Mac doesn't just work for the main use case (local development), though.

Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production

#146

Earlier quoted context omitted.

I'm still using VirtualBox. Could you elaborate why Docker is better?

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.

It's based on the OS X sandbox and xhyve which is in turn is based on bhyve https://blog.docker.com/2016/03/docker-for-mac-windows-beta/

Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production

#147

I'm finding it really funny how even Docker users can't really explain easily what Docker is.

Docker is a process launcher that makes it fast and simple to start processes with a unique network/filesystem/process/user space (via cgroups and namespaces).

Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production

#148
post #87
post #64

Earlier quoted context omitted.

I doubt the problems mentioned happen on Linux or CoreOS, which is likely what a production environment will run on.

> Linux or CoreOS Well, now I'm confused

Sorry, CoreOS is Linux as well, but in my mind it's enough of a hyper-specialised immutable auto-updatable container-specific version of Linux that it warrants a separate category when talking about Docker.

Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production

#149

Earlier quoted context omitted.

Do you run your containers in production with "docker run" ??

Only for a tiny pet project. The sales pitch I usually give people is that any ops person can read a Dockerfile, but most devs can't figure out or help with vagrant or chef scripts. But it's a hell of a lot easier to get and keep repeatable builds and integration tests working if the devs and the build system are using docker images.

You are doing it wrong then. People run containers in production using orchestration platforms, like ECS, kubernetes, mesos etc. The docker for mac/windows are not designed to serve containers in production environments.

They help you build and run containers locally, but when it comes time to deploy you send the container image to those other platforms.

Using docker like that is like running a production rails app with "rails s"

Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production

#150
post #8

I don't use Docker much now, but in my experience the reliance on Virtualbox (on Mac) was a little clunky and annoying, and I really wished for native support without Virtualbox. I'm super happy to see that's here!

I switched to VirtualBox from Parallels, and I agree that it's clunky in comparison (got tired of having to put in a purchase request every time they upgraded). I have to run IIS and MSSQL, unfortunately, and until I can use those with Docker, I think I'm stuck.

I think when Windows Nano Server is available I'll give it a try, my Win7 image is almost 70GB...

Post reply on HN