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.
Docker for Mac and Windows Is Now Generally Available and Ready for Production
141–150 of 169 posts
Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production
#142Earlier 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…
Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production
#143Earlier 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" ??
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
#144Earlier 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…
Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production
#145Basically 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/
Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production
#146Earlier 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.
Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production
#147I'm finding it really funny how even Docker users can't really explain easily what Docker is.
Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production
#148Earlier 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
Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production
#149Earlier 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.
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
#150I 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 think when Windows Nano Server is available I'll give it a try, my Win7 image is almost 70GB...