Live data from Hacker News

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

blog.docker.com

121–130 of 169 posts

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

#121

Earlier quoted context omitted.

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 still using VirtualBox. Could you elaborate why Docker is better?

When I used VirtualBox for Docker (using Docker machine/toolbox), I would run out of VM space, have to start and stop the VM, and it was just clunky all around.

Docker.app has a very nice tray menu, I don't know or care anything about the VM it's running on, and generally is just better integrated to OS X. For instance, when I run a container, the port mapping will be on localhost rather than on some internal IP that I would always forget.

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

#122
post #74

Earlier quoted context omitted.

I think it makes sense to depend on the "native" virtualization solutions for each operating system (Hyper-V and xhyve). We have been using Vagrant and VirtualBox heavily and the new Docker for Windows/Mac is making us reconsider that since you can't easily use more than one hypervisor on the same dev machine without some hassle. We might be building our Vagrant boxes for these other hypervisors soon. VirtualBox stil…

It's sad that Vagrant is so married to VirtualBox in practice. VirtualBox on Linux is especially bad (crashy kernel drivers). (Yes, I know there theoretically exist different Vagrant backends, but Vagrantfiles and public images are married to specific backend so all the reasons to use Vagrant tie it to VB)

Have you tried using vagrant-libvirt on Linux? You can convert public images to run on it using vagrant-mutate.

https://github.com/vagrant-libvirt/vagrant-libvirt

https://github.com/sciurus/vagrant-mutate

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

#123

Can I expect a dockerfile that 100% works on Linux to 100% on Mac and Windows?

Dockerfiles describe how to build an image. You can build the image on any docker host and it will be identical. The differences occur only when you run the image and it becomes a container. The way networking and file systems behave can vary depending on the host and run command options.

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

#124
post #2

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-... (2) pinata was removed, so it can't be configured from CLI scripts https://forums.docker.com/t/pinata-missing-in-latest-mac-bet... (3) it's not possible to establish an ip-level route from the…

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.

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

#125
post #48
post #47

Earlier quoted context omitted.

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).

I wouldn't consider pegging a CPU until restart to be 'stable'.

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

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

#126
My biggest issue with it is that there seems to be no easy way to provide more space to the VM docker runs inside. While it seems trivial it can be useful if you happen to have really large images (yes, for valid reasons). If you run too many containers you just run out of space.

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

#127

Earlier quoted context omitted.

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

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.

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.

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

#128

Earlier quoted context omitted.

So misinformed. Docker for mac and docker for windows are not targeting production. They are designed for local dev envs

So why call it "production ready"?

Well, it was beta before.

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

#129

Earlier quoted context omitted.

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 still using VirtualBox. Could you elaborate why Docker is better?

I don't think he was comparing Docker to VirtualBox.

In Docker 1.11 they used VirtualBox to host a Linux Docker Image to run containers. In 1.12 they switched to Microsoft's Hyper-V.

Post reply on HN