Earlier quoted context omitted.
I doubt the problems mentioned happen on Linux or CoreOS, which is likely what a production environment will run on.
Docker for Windows is to isolate Windows software. It's not a tool to test Linux containers on Windows. The deployment target for Docker containers for Windows will be a Windows OS.
Docker for Mac and Windows Is Now Generally Available and Ready for Production
101–110 of 169 posts
Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production
#102Earlier quoted context omitted.
I doubt the problems mentioned happen on Linux or CoreOS, which is likely what a production environment will run on.
Docker for Windows is to isolate Windows software. It's not a tool to test Linux containers on Windows. The deployment target for Docker containers for Windows will be a Windows OS.
Unless something has changed since the last time I checked, The WindowsServerCore docker image was not generally available yet and requires server2016 (I think it was TP6 the last time I checked)
Docker, to my knowledge, is still exclusively Linux flavors. (Though I'm happy to be corrected if someone knows more than me)
Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production
#103Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production
#104An interesting fact I think is worth mentioning is that Docker for Mac uses a forked and currently closed version of xhyve, and not the same xhyve that we can find on Github. The last commit to open source xhyve was May 27. With that said Docker has plans to open source it, I wonder if that will happen soon as they declare Docker for Mac ready for production. That would imply that the xhyve port also should be ready…
https://github.com/docker/hyperkit
Source: https://blog.docker.com/2016/05/docker-unikernels-open-sourc...
Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production
#105Earlier 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.
>No one in their right mind is deploying actual production software on Docker, on OS X/Windows. Since the whole point of Docker would be to deploy these in production and not just for development, I don't see how the term 'ready for production' can be used. Isn't this just a beta?
Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production
#106I just installed D4W a few days ago for the first time. It's been great. It's a seamless experience on W10 Pro with Hyper-V. I've used VirtualBox a lot and I like it but I always have to fuss with the network bridge and such. With this, it's hard to tell I'm even using a VM. Their network port mapping is seamless. FYI, I was using rc4 and I didn't see any information on how to upgrade (should I uninstall first?). I r…
Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production
#107I'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…
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).
Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production
#108Earlier 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.
This isn't a product that's "ready for production"; it's a product company declaring that it is. This means what it's always meant: that the company believes the sum they'll make by convincing people it's "production ready" is greater than the sum they'll lose from people realizing it isn't. Keep in mind the optimal state of affairs for Docker Inc. is one where everyone is using Docker and everyone requires an enterp…
Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production
#109Earlier 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.
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.
Re: Docker for Mac and Windows Is Now Generally Available and Ready for Production
#110I'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…
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…