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

151–160 of 169 posts

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

#151

Post by hinkley »

moondev wrote: post #149
hinkley wrote: post #143

Earlier quoted context omitted.

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

And how do you solve all of the security problems and over-large layer issues that the Docker team has been punting on for the last 2 years?

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

#152

Post by moondev »

hinkley wrote: post #151
moondev wrote: post #149

Earlier quoted context omitted.

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

And how do you solve all of the security problems and over-large layer issues that the Docker team has been punting on for the last 2 years?

Which security problems are you referring to? Our containers run web applications, we aren't giving users shell access and asking them to try and break out.

Over large layers: Don't run bloated images with all your build tools. Run lightweight base images like alpine with only your deployment artifact. You also shouldn't be writing to the filesystem, they are designed to be stateless.

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

#153

Post by amazingman »

justincormack wrote: post #82
amazingman wrote: post #59

Earlier quoted context omitted.

Not to mention the lack of host:container socket sharing and the fact that the Moby VM time drifts due to system sleep. I love Docker for Mac, I use it every day, and it's definitely still beta quality.

How much does your time drift? We changed the mechanism so that it should sync from the OSX ntp server now, which seems to be giving good results. If you are having problems can you create an issue and we can look into it. Host container socket sharing will come, but it is complex as sockets only exist with in a single operating system, so we have to bridge them across two. We are using this for the docker socket, an…

Actually GA may have fixed this. I was able to reproduce it, but may have checked too quickly. I opened https://github.com/docker/for-mac/issues/17 against it, and may end up closing it.

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

#154

Post by hinkley »

moondev wrote: post #152
hinkley wrote: post #151

Earlier quoted context omitted.

And how do you solve all of the security problems and over-large layer issues that the Docker team has been punting on for the last 2 years?

Which security problems are you referring to? Our containers run web applications, we aren't giving users shell access and asking them to try and break out. Over large layers: Don't run bloated images with all your build tools. Run lightweight base images like alpine with only your deployment artifact. You also shouldn't be writing to the filesystem, they are designed to be stateless.

Credentials capture in layers. Environment variable oversharing between peer containers (depending on tool).

And the fact that nobody involved in Docker is old enough to remember that half of the exploits against CGI involved exposing environment variables, not modifying them.

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

#155

Post by ben_jones »

justinhj wrote: post #123
ben_jones wrote: post #43

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.

So if I have an application that utilizes networking or the file system it will have to use separate dockerfiles depending on platform?

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

#156

Post by moondev »

hinkley wrote: post #154
moondev wrote: post #152

Earlier quoted context omitted.

Which security problems are you referring to? Our containers run web applications, we aren't giving users shell access and asking them to try and break out. Over large layers: Don't run bloated images with all your build tools. Run lightweight base images like alpine with only your deployment artifact. You also shouldn't be writing to the filesystem, they are designed to be stateless.

Credentials capture in layers. Environment variable oversharing between peer containers (depending on tool). And the fact that nobody involved in Docker is old enough to remember that half of the exploits against CGI involved exposing environment variables, not modifying them.

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?

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

#157

Post by friism »

ZenoArrow wrote: post #89
HerpDerpLerp wrote: post #80

"This version of Docker requires Windows 10 Pro, Enterprise or Education edition with a minimum build number of 10586. Please use Docker Toolbox." :(

That'll be because Windows 10 is the first desktop Windows OS with support for Hyper-V. If you didn't want to use Windows 10, perhaps you might have some more luck with a Windows Server OS. Does anyone know if the latest version of Docker will work on Windows Server 2012?

Client Hyper-V actually showed up in Windows 8 [1], but only recent versions of Windows 10 have Hyper-V with all the features needed by Docker for Windows.

[1]: http://www.howtogeek.com/196158/how-to-create-and-run-virtua...

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

#158

Post by lewisl9029 »

amq wrote: post #99

I've been trying to switch from VirtualBox to Hyper-V twice to use Docker for Windows, but always hit the same wall when using a desktop Linux guest: no 3D acceleration, no resolution scaling, no shared clipboard.

Yes, Hyper-V's Desktop UX for VMs is still in a really sad state compared to the competition, even for Windows guests, let alone Linux ones. I have it enabled to use Docker for Windows by default, but very often still need to reboot to disable it and use VMware Workstation for any serious work inside VMs, for all the reasons you listed, plus the awesome multi-monitor support in Workstation.

Microsoft really needs to get its act together.

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

#159

Post by justinhj »

ben_jones wrote: post #155
justinhj wrote: post #123

Earlier quoted context omitted.

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.

So if I have an application that utilizes networking or the file system it will have to use separate dockerfiles depending on platform?

Usually you have a Dockerfile to build an image then you would deploy it to servers with different run parameters.

You could also have dockerfiles that take a base image and then add some environment specific configuration

IMHO it's better to keep the images identical across environments, and pass runtime configuration when deploying

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

#160

Post by hinkley »

moondev wrote: post #156
hinkley wrote: post #154

Earlier quoted context omitted.

Credentials capture in layers. Environment variable oversharing between peer containers (depending on tool). And the fact that nobody involved in Docker is old enough to remember that half of the exploits against CGI involved exposing environment variables, not modifying them.

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're basically screwed.

If you only had to deal with production issues there are a few obvious ways to fix this, like changing the order of your image builds to do more work prior to building your image (eg, in your project's build scripts), but then you have a situation where your build-compile-deploy-test cycle is terrible.

Which would also be pretty easy to fix if Docker weren't so opinionated about symbolic links and volumes. So at the end of the day you have security-minded folks closing tickets to fix these problems one way, and you have a different set that won't provide security concessions in the name of repeatability (which might be understandable if one of their own hadn't so famously asserted the opposite http://nathanleclaire.com/blog/2014/09/29/the-dockerfile-is-... )

I like Docker, but I now understand why the CoreOS guys split off and started building their own tools, like rkt. It's too bad their stuff is such an ergonomics disaster. Feature bingo isn't why Docker is popular. It's because it's stupid simple to start using it.

Post reply on HN