Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.docker.com

Post reply on HN
Print view View original

161–169 of 169 posts

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

#161

Post by qubit23 »

djs55 wrote: post #119
qubit23 wrote: post #23

Earlier quoted context omitted.

This is another issue that's been preventing my adoption of Docker for Mac: 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.

If you have the time, could you make a report on the issue tracker 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 /e…

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.

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

#162

Post by smarterclayton »

hinkley wrote: post #160
moondev wrote: post #156

Earlier quoted context omitted.

With kubernetes, putting credentials in env vars is an anti pattern. You create a secret and then that secret can be mounted as a volume when the container runs, it never gets captured in a layer. Also CGI exploits exposing env vars would work just as well on a normal non-container instance would they not?

Two separate issues. Yes, you can capture runtime secrets in your layers, but it's pretty obvious to everyone when you're doing that and usually people clue in pretty quickly that this isn't going to work. Build time secrets are a whole other kettle of fish and a big unsolved problem that the Docker team doesn't seem to want to own. If you have a proxy or a module repository (eg, Artifactory) with authentication you'…

Regarding secrets in builds, I think a long term goal would be to grow the number of ways of building Docker images (beyond just Docker build), and to make image builds more composable and more flexible.

One example is the work we've experimented with in OpenShift to implement Dockerfile build outside of the Docker daemon with https://github.com/openshift/imagebuilder. That uses a single container and Docker API invocations to execute an entire Dockerfile in a container, and also implements a secret-mount function. Eventually, we'd like to support runC execution directly, or other systems like rkt or chroot.

I think many solutions like this are percolating out there, but it has taken time for people to have a direct enough need to invest.

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

#163

Post by jokoon »

senex wrote: 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…

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

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

#164

Post by JustinAiken »

geekbri wrote: post #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.

> While it seems trivial it can be useful if you happen to have really large images (yes, for valid reasons).

I'm curious what some of these valid reasons are - why would you have a large image instead of a minimal image with all the data linked out?

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

#165

Post by statictype »

gecko wrote: post #101
statictype wrote: post #95

Earlier quoted context omitted.

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.

I am almost positive that is completely incorrect. Can you give any example of Docker being used to isolate Windows software?

You're right. I was wrong about this

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

#166

Post by eugenmayer »

senex wrote: 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…

for 4) you can use 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.

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

#167

Post by amorphid »

sigjuice wrote: post #86
amorphid wrote: post #36

Earlier quoted context omitted.

I believe xhyve works fine with recent versions of VirtualBox, since xhyve is a pure userland app (aka no kernel extensions). Check out the issues section in the xhyve readme... https://github.com/mist64/xhyve/blob/master/README.md

xhyve needs to interact with all kinds of low-level things so there has to be kernel code involved. xhyve does not install kernel extensions of its own like VirtualBox or VMWare Fusion. xhyve uses the kernel extensions provided by Apple (com.apple.driver.AppleHV and possibly others).

Ah, that makes sense. It doesn't install anything extensions of it's own, only using the kernel bits provided by Hypervisor.framework.

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

#168

Post by AlexC04 »

numo16 wrote: post #138
AlexC04 wrote: post #102

Earlier quoted context omitted.

I don't think so. That's what Jeffery Snover is working on in Server 2016 with Windows nano server. 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…

Docker images still aren't generally available, but you can now run Windows Container Images based on the NanoServer docker image (and WindowsServerCore image if you replace nanoserver with windowsservercore in their image URL in the docs below) on Windows 10 (insiders build)[0]. [0]: https://msdn.microsoft.com/en-us/virtualization/windowsconta...

I went wide-eyed about three or four times while reading those instructions!

Super exciting! Thanks for the comment.

Post reply on HN