News for hackers. Stuff that matters.

A comment on Docker 1.0. Parent comment

Re:Docker 1.0 by sigil on Monday June 09, 2014 @02:16PM (#7869653)
Normally you would have two choices: ship the source with a bunch of readme's and let the recipient figure out how to install your software and all dependencies and to resolve any conflicts with other software already on the machine (aka version hell). Or you could ship a VM image.

Option 3: use a package manager.

Now, I realize this doesn't solve the existing software conflict problem you mention. Nor is it mutually exclusive with shipping an image: you could always construct an image by installing packages into it.

I've always been a little wary of the "ship a golden image" idea. How do Docker images get updated? What if there's a security issue with software in the Docker image -- can my package manager automatically apply security updates? How do I push other upgrades to the client once they have a Docker instance -- do they need a whole new image from me? Package managers have solved these problems, and I hope we're not reinventing those solutions in the Docker world.

If you're familiar with Docker, please enlighten me on these points.

[ Parent | on HN ]
Re:Docker 1.0 by grosskur on Monday June 09, 2014 @05:07PM (#7870503)
My understanding: If you provide an image then, yes, you're supposed to build a new image every time there's an OS security update. Users of docker containers aren't supposed to run 'apt-get upgrade' themselves inside containers. In fact, people build who build app images on top of base images aren't even supposed to run 'apt-get upgrade' in their Dockerfile---it's the responsibility of the base image to be up-to-date. See:

http://crosbymichael.com/dockerfile-best-practices-take-2.ht...

This does seem to get a bit cumbersome. I'm at DockerCon today and Fabio Kung mentioned in his talk that this is one difference from Heroku's container platform---they provide the base image and can update it without requiring you to rebuild your application slug. He said there's been some discussion of a possible "docker rebase" command that would produce new images by replacing lower-level layers while keeping higher-level layers the same.

[ Parent | on HN ]
Re:Docker 1.0 by voltagex_ on Tuesday June 10, 2014 @01:44AM (#7871992)
docker rebase sounds like an awesome idea. Is there a mailing list thread or GitHub issue?
[ Parent | on HN ]
Re:Docker 1.0 by justincormack on Monday June 09, 2014 @02:29PM (#7869717)
If your container has a whole OS image in it, then you can run the package manager for that OS to update it.

If you just have the application running in the container then you just replace it with an updated container.

[ Parent | on HN ]
Re:Docker 1.0 by tacticus on Monday June 09, 2014 @08:23PM (#7871269)
> How do Docker images get updated?

I rebuild the image. At the moment with the giant stupid image that we use for rhell land it takes about 5 minutes (builds a vmware, virtualbox, aws, qemu, and docker image (packer.io is kinda cool))

Then redeploy

[ Parent | on HN ]
Re:Docker 1.0 by aidenn0 on Monday June 09, 2014 @03:21PM (#7869988)
In many cases, package managers are insufficient to solve the problem. A lot of times they don't handle "Service A must use dependency version X.* but Service B must use version Y.*"
[ Parent | on HN ]
Re:Docker 1.0 by vertex-four on Monday June 09, 2014 @03:24PM (#7870004)
I'll point out that Nix, which is used by NixOS but also runs perfectly on other distros, does handle this wonderfully.
[ Parent | on HN ]
Re:Docker 1.0 by vezzy-fnord on Monday June 09, 2014 @04:08PM (#7870205)
Option 4: Statically link your binaries.

By the way, I do have a basic idea of what Docker is, as well as some inclination with OS-level virtualization (FreeBSD jails and LXC), but OP's example wasn't particularly inspiring.

[ Parent | on HN ]
Re:Docker 1.0 by heavenlyhash on Tuesday June 10, 2014 @09:51AM (#7872436)
This. Or, similarly, just put all your dependencies in a path relative to your executable. Problem solved.

I'm an enormous fan of docker for solving linux sysad woes (stacking up magic numbers in /etc/passwd, etc), and it's also great as an asylum for badly designed or badly packaged applications, but let's not forget the utter magic of paths beginning in "./".

[ Parent | on HN ]