6 ms·

Apples to oranges. LXC can be directly compared with a small, and quite insignificant, part of Docker: container runtime. Docker became popular not because it

Apples to oranges. 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.

leecarraher 5y ago
i agree, docker added version control, online repository, with management, and search they also fixed some of the networking headaches in lxc. Prior to developing containerd docker was based on lxc containers.
drewcoo 5y ago
Isn't that where LXD is supposed to fit in? https://linuxcontainers.org/lxd/ https://linuxcontainers.org/lxd/
sarusso 5y ago
I agree on the apples to oranges, but LXC does not directly compare to a container runtime IMHO.. It is a proper engine to be fair, even if it provides much less functionalities as the Docker engine.
chriswarbo 5y ago
> Docker became popular because it allows one to build, publish and then consume containers. 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.)
- yjftsjthsd-h 5y ago
  It's still superior to everything that came before it (at least, that I'm aware of), and cleared the "good enough" bar. Actually, I'm still not aware of anything that solves those issues without making it way harder to use - ex. nix addresses your points but has an awful learning curve.
- tra3 5y ago
  Can you expand on how builds aren't reproducible? I though Dockerfile ensured that builds are indeed reproducible?
  - Ajedi32 5y ago
    Running the same script every time doesn't necessarily guarantee the same result. Lots of docker build scripts have the equivalent of date > file.txt or curl https://www.random.org/integers/?num=1&min=1&max=1000&col=1&base=10&format=plain&rnd=new > file.txt Buried deep somewhere in the code. But yeah I don't see any reason why you couldn't theoretically make a reproducible build with Docker.
    - tra3 5y ago
      If you have dynamism like this in your build, doesn't that imply that no build system is reproducible?
      - amarshall 5y ago
        Yes, but previous commenter said > I [thought] Dockerfile ensured that builds are indeed reproducible? The example straightforwardly disproves that.
      - Ajedi32 5y ago
        My point was just that Docker doesn't ensure reproducibility. Whether a build is reproducible or not depends on the steps used, so its possible but not "ensured". 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.
    - MD87 5y ago
      Docker images actually contain the timestamp each layer was built at, so are basically de-facto non-reproducible. 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.
- zapita 5y ago
  > builds are performed "inside out" 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.
- KronisLV 5y ago
  > builds are performed "inside out" and aren't reproducible 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 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 https://www.sonatype.com/products/repository-oss Multi stage builds: https://docs.docker.com/develop/develop-images/multistage-build/ 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 You get an archive that's the full file system of the container. Of course, you still need to check everything that's actually inside of it and where it came from (at least the image persists the information about how it was built normally), but to me it definitely seems doable > 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 If we use just tags to refer to the images, we can eventually have them be overriden, which can be problematic: # 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 In the second case we get the "B" output even though the tag is "test-a" because of a typo, user error or something else. Yet, we can also use hashes: # 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" Here we see that if your underlying build is reproducible, then the resulting image hash for the same container will be stable. Furthermore, someone overwriting the test-a tag didn't break you being able to run the first correctly built image because the tags are just convenience, so you'll be able to run the previous one. Of course, that loops back to the reproducible build discussion if you care about hashes matching up, rather than just tags not being overwritten.
tyingq 5y ago
The confusion is because LXD is more comparable (build/publish/consume) to Docker, but the command you use to run it is called "lxc", so some people call LXD "LXC".
itslennysfault 5y ago
More like Apples to Apple Core, but sure.
m463 5y ago
I would say docker's killer feature is the Dockerfile. It makes it understandable, reproducible and available to a broad range of people. 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.
- richardwhiuk 5y ago
  Understandable? Yes. Reproducible? No. Most Dockerfiles are incredibly unreproducible.
  - deleted 5y ago
    [deleted]
  - zelphirkalt 5y ago
    Most are not, that's true. 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.
    - GauntletWizard 5y ago
      That work is hard and the tooling is bad and it only takes one mistake, like forgetting to suppress the mtime of your files. 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.
  - m463 5y ago
    I think it's more reproducible like a recipe. 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.
fulafel 5y ago
LXD does all of that since a long time, eg here's a tutorial from 2015: https://ubuntu.com/blog/publishing-lxd-images https://ubuntu.com/blog/publishing-lxd-images

leecarraher 5y ago

i agree, docker added version control, online repository, with management, and search they also fixed some of the networking headaches in lxc. Prior to developing containerd docker was based on lxc containers.

drewcoo 5y ago

Isn't that where LXD is supposed to fit in? https://linuxcontainers.org/lxd/ https://linuxcontainers.org/lxd/

sarusso 5y ago

I agree on the apples to oranges, but LXC does not directly compare to a container runtime IMHO.. It is a proper engine to be fair, even if it provides much less functionalities as the Docker engine.

chriswarbo 5y ago

> Docker became popular because it allows one to build, publish and then consume containers. 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.)

yjftsjthsd-h 5y ago
It's still superior to everything that came before it (at least, that I'm aware of), and cleared the "good enough" bar. Actually, I'm still not aware of anything that solves those issues without making it way harder to use - ex. nix addresses your points but has an awful learning curve.
tra3 5y ago
Can you expand on how builds aren't reproducible? I though Dockerfile ensured that builds are indeed reproducible?
- Ajedi32 5y ago
  Running the same script every time doesn't necessarily guarantee the same result. Lots of docker build scripts have the equivalent of date > file.txt or curl https://www.random.org/integers/?num=1&min=1&max=1000&col=1&base=10&format=plain&rnd=new > file.txt Buried deep somewhere in the code. But yeah I don't see any reason why you couldn't theoretically make a reproducible build with Docker.
  - tra3 5y ago
    If you have dynamism like this in your build, doesn't that imply that no build system is reproducible?
    - amarshall 5y ago
      Yes, but previous commenter said > I [thought] Dockerfile ensured that builds are indeed reproducible? The example straightforwardly disproves that.
    - Ajedi32 5y ago
      My point was just that Docker doesn't ensure reproducibility. Whether a build is reproducible or not depends on the steps used, so its possible but not "ensured". 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.
  - MD87 5y ago
    Docker images actually contain the timestamp each layer was built at, so are basically de-facto non-reproducible. 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.
zapita 5y ago
> builds are performed "inside out" 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.
KronisLV 5y ago
> builds are performed "inside out" and aren't reproducible 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 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 https://www.sonatype.com/products/repository-oss Multi stage builds: https://docs.docker.com/develop/develop-images/multistage-build/ 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 You get an archive that's the full file system of the container. Of course, you still need to check everything that's actually inside of it and where it came from (at least the image persists the information about how it was built normally), but to me it definitely seems doable > 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 If we use just tags to refer to the images, we can eventually have them be overriden, which can be problematic: # 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 In the second case we get the "B" output even though the tag is "test-a" because of a typo, user error or something else. Yet, we can also use hashes: # 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" Here we see that if your underlying build is reproducible, then the resulting image hash for the same container will be stable. Furthermore, someone overwriting the test-a tag didn't break you being able to run the first correctly built image because the tags are just convenience, so you'll be able to run the previous one. Of course, that loops back to the reproducible build discussion if you care about hashes matching up, rather than just tags not being overwritten.

tyingq 5y ago

The confusion is because LXD is more comparable (build/publish/consume) to Docker, but the command you use to run it is called "lxc", so some people call LXD "LXC".

itslennysfault 5y ago

More like Apples to Apple Core, but sure.

m463 5y ago

I would say docker's killer feature is the Dockerfile. It makes it understandable, reproducible and available to a broad range of people. 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.

richardwhiuk 5y ago
Understandable? Yes. Reproducible? No. Most Dockerfiles are incredibly unreproducible.
- deleted 5y ago
  [deleted]
- zelphirkalt 5y ago
  Most are not, that's true. 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.
  - GauntletWizard 5y ago
    That work is hard and the tooling is bad and it only takes one mistake, like forgetting to suppress the mtime of your files. 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.
- m463 5y ago
  I think it's more reproducible like a recipe. 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.

fulafel 5y ago

LXD does all of that since a long time, eg here's a tutorial from 2015: https://ubuntu.com/blog/publishing-lxd-images https://ubuntu.com/blog/publishing-lxd-images