6 ms·

This happened because docker, in addition to an isolation system, also bundled a user friendly interface to a per-app persistent filesystem. No matter how many

This happened because docker, in addition to an isolation system, also bundled a user friendly interface to a per-app persistent filesystem. No matter how many people sing the praises of isolation and security to Docker, I will continue to suspect that almost all of its adopters use it because packaging software with dependencies is hard, poorly understood, terribly tooled (looking at you, Python), and even more poorly executed in the vast majority of projects and companies. Docker gives you a very simple way to not think about that (at least until your massive container that bundles ancient versions of a dozen different CVE-filled libraries bites you in the ass down the road). It's not novel. It's not even particularly elegant. But Docker users don't want elegance; most of them just don't want to think about how to configure a production environment to work like their development environment, so we get the old joke: "It works on my machine!" "Then we'll ship your machine"...and so we got docker.

cwp 7y ago
Yes, this is exactly right. Dependency management is a hard problem, and with Docker you only have to get it right once. I think Docker wouldn't exist if Amazon had shipped a way to build and test an AMI locally.
- takeda 7y ago
  There is already a solutions such as Guix and Nix, but then people aren't willing to learn a new language that allows expressing dependencies. Docker solves dependencies in same way a disk image does, you save the image and it should look the same way each time you look at it. The Dockerfile is not a reproducible though, you just list steps iteratively to generate an image, but it doesn't guarantee to produce the same result. I saw multiple times scenario that docker image built fine for one person and didn't work for another. The main reason for it is that majority of Dockerfiles rely on network to build the image and files received (or even your apt-get command) might produce different results for different people. Recently I saw example where even a docker image built on build system didn't work on deployments system. Both machines of course were x86_64. Turned out that one of dependencies enabled compile optimizations for the CPU it was built on. You could argue that it isn't Docker's fault, but isn't its promise to provide reproducible builds?
  - cwp 7y ago
    Agreed. Nix and Guix actually solve the dependency problem, Docker allows you to work around it. But a work around is better than nothing.
    - takeda 7y ago
      Well, but my point there isn't nothing, there are alternatives, which can (or at least nix can) generate docker or OCI containers. Docker is trying to sell itself as something more than it is, in reality it is just an overglorified zip file.
  - deleted 7y ago
    [deleted]
RcouF1uZ4gsC 7y ago
> I will continue to suspect that almost all of its adopters use it because packaging software with dependencies is hard, poorly understood, terribly tooled (looking at you, Python), and even more poorly executed in the vast majority of projects and companies. Static linking solves a lot of these deployment issues. But I guess people are worried about duplicating libraries and security vulnerabilities. So we end up with Docker which has these problems, but even worse.
- zbentley 7y ago
  Can't easily statically link a big complex application written in a dynamic language.
  - burpsnard 7y ago
    That's a reason to avoid dynalangs. Otoh, java and .net have ears and assemblies
  - 08-15 7y ago
    Depends on the language, doesn't it? Many Scheme implementations have "unexec".
gigatexal 7y ago
Yep, never underestimate a good interface. I can do most of what ZFS does with dm-crypt, llvm, etc but that’s a handful of interfaces to learn. ZFS includes it all. (Probably a bad analogy but it gets the idea across).
sedachv 7y ago
> No matter how many people sing the praises of isolation and security to Docker, I will continue to suspect that almost all of its adopters use it because packaging software with dependencies is hard, poorly understood, terribly tooled (looking at you, Python), and even more poorly executed in the vast majority of projects and companies. Here is a quote from Eberhard Wolff's _A Practical Guide to Continuous Delivery_: "It is laborious to install a real application including all components. Of course, it is even more laborious to automate this process... When an installation crashes, it has to be restarted. In such a scenario the system is in a state where some parts have already been installed. Just to start the installation again can create problems. The script usually expects to find the system in a state without any installed software... This problems is also the reason why updates to a new software version are problematic. In such a case there is already an old version of the software installed on the system that has to be updated. This means that files might already be present and have to be overwritten. The script has to implement the necessary logic for this. In addition, superfluous elements that are not required anymore for the new version have to be deleted. If this does not happen, problems can arise with the new installation because old values might still be read out and used. However, it is very laborious to cover and automate all update paths that occur in practice." If a self-professed expert that writes books on the subject does not realize that package managers exist, and proposes that the only alternatives for software installation are either hand-hacked shell scripts or Docker, what do you think the average developer knows?
- icebraining 7y ago
  To be fair to Wolff, it's not uncommon for deb and rpm packages of complex daemons (e.g. postgres) to include shell scripts - postinst, preinst, etc - that makes changes to the system, and which do have to be coded in such a way to handle re-execution after partial failure. Taking my /var/cache/apt/ directory as a (poor) sample, about 1/3 of packages had such scripts.
  - burpsnard 7y ago
    that libc update spawned a wealth of dependency solutions. And 'dll hell' of course

cwp 7y ago

Yes, this is exactly right. Dependency management is a hard problem, and with Docker you only have to get it right once. I think Docker wouldn't exist if Amazon had shipped a way to build and test an AMI locally.

takeda 7y ago
There is already a solutions such as Guix and Nix, but then people aren't willing to learn a new language that allows expressing dependencies. Docker solves dependencies in same way a disk image does, you save the image and it should look the same way each time you look at it. The Dockerfile is not a reproducible though, you just list steps iteratively to generate an image, but it doesn't guarantee to produce the same result. I saw multiple times scenario that docker image built fine for one person and didn't work for another. The main reason for it is that majority of Dockerfiles rely on network to build the image and files received (or even your apt-get command) might produce different results for different people. Recently I saw example where even a docker image built on build system didn't work on deployments system. Both machines of course were x86_64. Turned out that one of dependencies enabled compile optimizations for the CPU it was built on. You could argue that it isn't Docker's fault, but isn't its promise to provide reproducible builds?
- cwp 7y ago
  Agreed. Nix and Guix actually solve the dependency problem, Docker allows you to work around it. But a work around is better than nothing.
  - takeda 7y ago
    Well, but my point there isn't nothing, there are alternatives, which can (or at least nix can) generate docker or OCI containers. Docker is trying to sell itself as something more than it is, in reality it is just an overglorified zip file.
- deleted 7y ago
  [deleted]

RcouF1uZ4gsC 7y ago

> I will continue to suspect that almost all of its adopters use it because packaging software with dependencies is hard, poorly understood, terribly tooled (looking at you, Python), and even more poorly executed in the vast majority of projects and companies. Static linking solves a lot of these deployment issues. But I guess people are worried about duplicating libraries and security vulnerabilities. So we end up with Docker which has these problems, but even worse.

zbentley 7y ago
Can't easily statically link a big complex application written in a dynamic language.
- burpsnard 7y ago
  That's a reason to avoid dynalangs. Otoh, java and .net have ears and assemblies
- 08-15 7y ago
  Depends on the language, doesn't it? Many Scheme implementations have "unexec".

gigatexal 7y ago

Yep, never underestimate a good interface. I can do most of what ZFS does with dm-crypt, llvm, etc but that’s a handful of interfaces to learn. ZFS includes it all. (Probably a bad analogy but it gets the idea across).

sedachv 7y ago

> No matter how many people sing the praises of isolation and security to Docker, I will continue to suspect that almost all of its adopters use it because packaging software with dependencies is hard, poorly understood, terribly tooled (looking at you, Python), and even more poorly executed in the vast majority of projects and companies. Here is a quote from Eberhard Wolff's _A Practical Guide to Continuous Delivery_: "It is laborious to install a real application including all components. Of course, it is even more laborious to automate this process... When an installation crashes, it has to be restarted. In such a scenario the system is in a state where some parts have already been installed. Just to start the installation again can create problems. The script usually expects to find the system in a state without any installed software... This problems is also the reason why updates to a new software version are problematic. In such a case there is already an old version of the software installed on the system that has to be updated. This means that files might already be present and have to be overwritten. The script has to implement the necessary logic for this. In addition, superfluous elements that are not required anymore for the new version have to be deleted. If this does not happen, problems can arise with the new installation because old values might still be read out and used. However, it is very laborious to cover and automate all update paths that occur in practice." If a self-professed expert that writes books on the subject does not realize that package managers exist, and proposes that the only alternatives for software installation are either hand-hacked shell scripts or Docker, what do you think the average developer knows?

icebraining 7y ago
To be fair to Wolff, it's not uncommon for deb and rpm packages of complex daemons (e.g. postgres) to include shell scripts - postinst, preinst, etc - that makes changes to the system, and which do have to be coded in such a way to handle re-execution after partial failure. Taking my /var/cache/apt/ directory as a (poor) sample, about 1/3 of packages had such scripts.
- burpsnard 7y ago
  that libc update spawned a wealth of dependency solutions. And 'dll hell' of course