LXC can be directly compared with a small, and quite insignificant, part of Docker: container runtime. Docker became popular not because it can run containers, many tools before Docker could do that (LXC included).
Docker became popular because it allows one to build, publish and then consume containers.
At least they mentioned it in their apple:oranges comparison.
there's also the global namespace thing. "FROM ubuntu:18.04" is pretty powerful.
I run a proxmox server with LXC but if I could use a dockerfile or equivalent, my containers would be much much more organized. I wouldn't like to pull images from the internet however.
Reproducible? No. Most Dockerfiles are incredibly unreproducible.
Yes, baking doesn't work the same at sea level vs say denver colorado @ 1 mile, but pretty much you can share your recipe with friends and save them lots of time.
It is possible to get to reproducibility though, by involving lots of checksums. For example you can use the checksum of a base image in your initial FROM line. You can download libraries as source code and install them. You can use package managers with lock files to get to reproducible environments of the language you are using. You can check checksums of other downloaded files. It takes work, but sometimes it is worth it.
Docker was good enough, simple enough, and got the job done. It won for good reason, but the next generation should learn from it's mistakes.
True, but Docker is an awful choice for those things (builds are performed "inside out" and aren't reproducible, publishing produces unauditable binary-blobs, consumption bypasses cryptographic security by fetching "latest" tags, etc.)
Docker supports multi-stage builds. They are quite powerful and allow you go beyond the "inside out" model (which still works fine for many use cases).
> ...and aren't reproducible
You can have reproducible builds with Docker. But Docker does not require your build to be reproducible. This allowed it to be widely adopted, because it meets users where they are. You can switch your imperfect build to Docker now, and gradually improve it over time.
This is a pragmatic approach which in the long run improves the state of the art more than a purist approach.
I though Dockerfile ensured that builds are indeed reproducible?
Lots of docker build scripts have the equivalent of
date > file.txt
curl https://www.random.org/integers/?num=1&min=1&max=1000&col=1&base=10&format=plain&rnd=new > file.txt
But yeah I don't see any reason why you couldn't theoretically make a reproducible build with Docker.
Buildah from Red Hat has an argument to set this programmatically instead of using the current date, but AFAIK there's no way to do that with plain old docker build.
If you wanted to guarantee reproducibility, a hypothetical purely-functional build system could do that. I personally don't think that's necessary though, or that it would be worth the requisite trade-offs.
> I [thought] Dockerfile ensured that builds are indeed reproducible?
The example straightforwardly disproves that.
That said, the above example isn’t specific to Docker.
This is probably a good argument because of how hard it is to do anything in a reproducible manner, if you care even about timestamps and such matching up.
Yet, i'd like to disagree that it's because of inherent flaws with Docker, merely how most people choose to build their software. Nobody wants to use their own Nexus instance as a storage for a small set of audited dependencies, configure it to be the only source for all of them, build their own base images, seek out alternatives for all of the web integrated build plugins etc.
Most people just want to feed the machine a single Dockerfile (or the technology specific equivalent, e.g. pom.xml) and get something that works out and thus the concerns around reproducibility get neglected. Just look at how much effort the folks over at Debian have put into reproducibility: https://wiki.debian.org/ReproducibleBuilds
That said, a decent middle ground is to use a package cache for your app dependencies, specific pinned versions of base images (or build your own ones on top of the common ones, e.g. a customized Alpine base image) and multi stage builds, you are probably 80% of the way there, since if need be, you could just dump the image's file system and diff it against a known copy.
Nexus (some prefer Artifactory, some other solutions): https://www.sonatype.com/products/repository-oss
Multi stage builds: https://docs.docker.com/develop/develop-images/multistage-bu...
The rest 20% might take a decade until reproducibility is as user friendly as Docker currently is, just look at how slowly Nix is adopted.
> publishing produces unauditable binary-blobs
It's just a file system that consists of a bunch of layers, isn't it? What prevents you from doing:
docker run --name dump-test alpine:some-very-specific-version sh -c exit
docker export -o alpine.tar dump-test
docker rm dump-test
> consumption bypasses cryptographic security by fetching "latest" tags
I'm not sure how security is bypassed if the user chooses to use whatever is the latest released version. That just seems like a bad default on Docker's part and a careless action on the user's part.
Actually, there's no reason why you should limit yourself to just using tags, since something like "my-image:2022-02-18" might be accidentally overwritten unless your repo specifically prevents this from being allowed. If you want, you can actually run images by their hashes, for example, Harbor makes this easy to do by letting you copy those values from their UI, though you can also do so manually.
For example, let's say that we have two Dockerfiles:
# testA.Dockerfile
FROM alpine:some-very-specific-version
RUN mkdir /test && echo "A" > /test/file
CMD cat/test/file
# testB.Dockerfile
FROM alpine:some-very-specific-version
RUN mkdir /test && echo "B" > /test/file
CMD cat/test/file
# Example of using version tags, possibly problematic
docker build -t test-a -f testA.Dockerfile .
docker run --rm test-a
docker build -t test-a -f testB.Dockerfile .
docker run --rm test-a
# Example of using hashes, more dependable
docker build -t test-a -f testA.Dockerfile .
docker image inspect test-a | grep "Id"
docker run --rm "sha256:93ee9f8e3b373940e04411a370a909b586e2ef882eef937ca4d9e44083cece7c"
docker build -t test-a -f testB.Dockerfile .
docker image inspect test-a | grep "Id"
docker run --rm "sha256:8dd9ba5f1544c327b55cbb75f314cea629cfb6bbfd563fe41f40e742e51348e2"
docker build -t test-a -f testA.Dockerfile .
docker image inspect test-a | grep "Id"
docker run --rm "sha256:93ee9f8e3b373940e04411a370a909b586e2ef882eef937ca4d9e44083cece7c"
Of course, that loops back to the reproducible build discussion if you care about hashes matching up, rather than just tags not being overwritten.
IMHO, the real 'trick' with Docker isn't really container runtimes, images, layers, etc. It's the willingness to avoid system dependencies in favour of doing everything inside a "container image" (AKA .tar.gz). That would seem crazy to a Makefile writer in the 80s, but once we become willing to do this, the actual technique can be implemented using something like Make (with appropriate use of `./configure --prefix` arguments, 'export PATH=...' commands, etc.).
Sure it would be leaky, inefficient, etc. but as you say, the majority of devs wouldn't mind (just like with Docker).
To be clear, I'm not advocating anyone actually try doing this with Make, or whatever. I'm just pointing out that many of the claimed advantages of containers (in general) and Docker (in particular), like being sort-of isolated, or sort-of cross-platform, etc. are actually completely orthogonal to the underlying technology. Instead, those advantages come from the way they tend to be used.
Unfortunately, some of the downsides also come from the way they tend to be used (e.g. putting an entire OS inside a container, rather than just the intended binary + its deps; or using 'latest' tags instead of hashes)
> It's just a file system that consists of a bunch of layers, isn't it?
Exactly. Hence it's hard to check whether, for example, the bin/foo executable contains a patch for CVE-1234, or whatever.
Compare this to e.g. Maven .poms, Nix .drvs, etc. which tell us what went into any particular artifact.
> Actually, there's no reason why you should limit yourself to just using tags, since something like "my-image:2022-02-18" might be accidentally overwritten unless your repo specifically prevents this from being allowed. If you want, you can actually run images by their hashes
Indeed, this is actually a really nice thing about Docker (which has since been incorporated into OCI). However, the tragedy is that it tends to get bypassed in favour of tags, and more specifically just 'latest'.