On 12-11-2016 18:18, Nicolas George wrote: > If I understand correctly how Docker works, its images are big blobs > that contain the program they are meant to distribute plus all its > dependencies. Am I mistaken? > > If it works like that, that means when the next OpenSSL security issue > is found, we have to cross our fingers very tightly and hope whoever > released the image will release an update with a fixed library. With > what I have in mind, unless the maintainer of the third-party repository > did something very wrong, its packages will be dynamically linked with > OpenSSL from the base system, and benefit from the updates immediately. > > It makes a big difference: in one case, you have to trust the third > party to do a good job and continue that way in the future, on the other > case you only have to trust it to do a not-bad job once. > > Personally, I would rather unpack a dynamically-linked binary somewhere > in /opt and install the dependencies myself than use a package system > with bundled libraries. Or, of course, install from source. >
The end result is indeed, for practical purposes, a big package with everything needed to run an application. But I don't expect you to simply download pre-built blobs, but rather to build your own. It's easier to understand from an example. Take a look at this Dockerfile: https://gist.github.com/rmoehn/1d82f433f517e3002124df52f7a73678 . Basically it says "start with a minimal debian stable system, install some packages, then make some necessary configurations". Docker downloads the base image (the minimal debian system), and executes the rest of the commands to create a new image that includes the installed packages, resulting in a self-contained image that allows execution of the application in question. [That's a huge simplification, but the end result is roughly as described. We need not concern with the internals.] [If you don't want to trust the creator of the base image, you can create your own.] I've used that Dockerfile to run anki (which is currently broken in testing). It's kind of a chroot, but with more isolation. Also, if I wanted to run another program from stable, I could build another docker image for that, but due to the clever way docker works, there'd be only one copy of the base system plus two layers, one for each image, with only the applications in question. That's a big advantage in relation to chroots or virtual machines. And yet, even if a base layer is shared, docker images are completely isolated from one another and from the host system. If you want to share data, you need to explicitly configure that. That does solve the isolation problem, and allows you to run packages from different repositories simultaneously, with different versions of libraries if necessary; and allows you to install packages from untrusted sources (or that are not available as .deb's) without messing with your "real" system. It does not solve the problem you mention: if there is an update of OpenSSL, the images will continue to use the old version unless you rebuild them. The process can be automated, but at least you'll need to run a command to rebuild the images, and this can be time consuming. Now might be a good time to dive into some of the internals, such as how the images and layers work: https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/ That might give you some ideas for your solution. Take a look also at the pages "AUFS storage driver in practice" and "OverlayFS storage in practice". While you won't be able to do what you want with docker, perhaps you can get some ideas. I'd guess you'd need some kind of layering like done by docker, but sometimes changing the bottom layers (which is not possible with docker - only the topmost layer is ever changed). -- Eduardo M KALINOWSKI edua...@kalinowski.com.br
