3 ms·

> Docker is essentially a sandwich of disk images where you can shove absolutely anything, and then these images get executed by running whatever legacy softwar

> Docker is essentially a sandwich of disk images where you can shove absolutely anything, and then these images get executed by running whatever legacy software you’ve crammed in there, regardless of how horrific or inconsistent it might be, with zero behavioral controls. Is this a problem with Docker, or a problem with people who use Docker? Without much controversy I feel this argument could be made about literally any abstract entity in society from `get_foo` to national institutions. Abstractions seem to be a necessary evil in corporative societies. Also, the article is way too short and meatless to provoke any real thoughts, and comes across as "If you don't already know what Kubernetes is, just know that it's bad". I don't see how that's going to sway anyone's opinion on anything.

caymanjim 1y ago
It's not a problem with anything. Docker can be misused like anything else. It's a massive net win for security and maintainability because it completely eliminates barriers to updating software.
lmm 1y ago
It's a problem with Docker. It's a real lowest-common-denominator interface, worse-is-better triumphing all over again. Heck, the fundamental flaw is essentially the same as make. Just when most people have finally accepted that a structured dependency/project management system is a better way to build your software than running random shell commands, we recapitulate the whole thing one level higher.
- ffsm8 1y ago
  But that's a pretty much entirely separate concern? Docker is about creating an image that can then be run on any supporting Linux server. It's not aimed at dependency management, really. It's aimed at producing an artifact you can then test and deploy. Sure, in most languages dependency management is a core part of this process, but it doesn't have to be. Most downloaded images are petty fundamental and only include things that can be installed via a systems package manager, e.g nginx to get a web server, or node to get a nodejs runtime etc. This significantly improved the issue of things working only in certain environments, because each environment was actually running exactly the same way. Then came k8s, which tried to solve the issue of deploying across clusters of machines, PaaS. That's not a trivial problem to solve, and consequently is still hard, even with it. But if you need to deploy countless services across hundreds of nodes... It's ultimately a great tool. As k8s became more and more widespread, it made sense to also use it for smaller deployments, because it solves a pretty fundamental issue you still have to solve, and if everyone is using it ... It's easier to onboard new people
  - lmm 1y ago
    > This significantly improved the issue of things working only in certain environments, because each environment was actually running exactly the same way. It doesn't though, because it's still just running some random unmanaged commands. If you download a Dockerfile that's a couple of years old and hasn't been maintained, it probably won't work. If you download the built image then it might work for a bit longer, but you won't be able to make any changes to it, and it will still break sooner or later due to e.g. certificate expiry, or being built for the wrong CPU architecture. > Then came k8s, which tried to solve the issue of deploying across clusters of machines, PaaS. That's not a trivial problem to solve, and consequently is still hard, even with it. But if you need to deploy countless services across hundreds of nodes... It's ultimately a great tool. Declarative deployment definitely has a lot of value. But k8s shoots itself in the foot by being Docker based, even as the world gradually moves onto better models (language-specific serverless deployments).
    - ffsm8 1y ago
      You seem to have a fundamental misunderstanding about what docker actually does, and how it's achieving it > If you download a Dockerfile that's a couple of years old and hasn't been maintained, it probably won't work The dockerfile is not the produced artifact, that's merely the most common way to build the artifact. The artifact is the image. Which itself is only a zip file of a linux filesystem, basically. This will behave the same, no matter when you downloaded it. And I might add: the goal you seem to have: to make an image runnable forevermore is not the goal of docker, again. But if you made a new image, you can then test the exact same deployment in another environment. You do not need to e.g. run apt update on prod and pray to the gods that nothing breaks. Instead you build the image, deploy to test, see that nothing breaks and then deploy to prod. Also k8s isn't technically backed by the docker backend anymore. It hasn't for a pretty long time now. It's currently using containerd by default https://github.com/containerd/containerd https://github.com/containerd/containerd But supports other backends too https://kubernetes.io/docs/setup/production-environment/container-runtimes/ https://kubernetes.io/docs/setup/production-environment/cont...
      - 1y ago
jauntywundrkind 1y ago
There are Distroless images! You can make a container with nothing but one executable in it. https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless has some helpers but you can just put your rust or go program into an image & ship it! For if you really want to go super far super hard against layer sandwiches. Personally, I think you're making awful tradeoffs that radically hamper your team's ability to act operationally. That you are showing enormously low respect by handcuffing your team like so. I hope you have lots of help for how to bring out debug containers to apply tooling that your images are incapable of providing themselves. I beg you to not, but for the uptight, the freaks, the paranoids and those who must go on griping about containers, it's really very easy to do! Anyhow. What's extra funny and sick is that some of this article valorizes VMs. Which have far far more of a bucket of bits what-is-all-this-nonsense problem, that requires providing far more scripting, tailoring, configuration make. Unless you are running bootc or zerg or unikernel stuff, it feels like VM'ers are in in no moral position to look down on containers, my heavens! This article has a couple little gems in it here & there. You call it short, but it's just short on understanding thought concern and perspective. It wrings the same blood from the stone again and again and again. Complexity bad, Kubernetes complex, this is garbage, again and again and again. Without really having much to say, just inferring, just trying to condescend you into belief. But there are a couple little good gems here & there (pro CORBA?! Wasm/wasi hype...)

caymanjim 1y ago

It's not a problem with anything. Docker can be misused like anything else. It's a massive net win for security and maintainability because it completely eliminates barriers to updating software.

lmm 1y ago

It's a problem with Docker. It's a real lowest-common-denominator interface, worse-is-better triumphing all over again. Heck, the fundamental flaw is essentially the same as make. Just when most people have finally accepted that a structured dependency/project management system is a better way to build your software than running random shell commands, we recapitulate the whole thing one level higher.

ffsm8 1y ago
But that's a pretty much entirely separate concern? Docker is about creating an image that can then be run on any supporting Linux server. It's not aimed at dependency management, really. It's aimed at producing an artifact you can then test and deploy. Sure, in most languages dependency management is a core part of this process, but it doesn't have to be. Most downloaded images are petty fundamental and only include things that can be installed via a systems package manager, e.g nginx to get a web server, or node to get a nodejs runtime etc. This significantly improved the issue of things working only in certain environments, because each environment was actually running exactly the same way. Then came k8s, which tried to solve the issue of deploying across clusters of machines, PaaS. That's not a trivial problem to solve, and consequently is still hard, even with it. But if you need to deploy countless services across hundreds of nodes... It's ultimately a great tool. As k8s became more and more widespread, it made sense to also use it for smaller deployments, because it solves a pretty fundamental issue you still have to solve, and if everyone is using it ... It's easier to onboard new people
- lmm 1y ago
  > This significantly improved the issue of things working only in certain environments, because each environment was actually running exactly the same way. It doesn't though, because it's still just running some random unmanaged commands. If you download a Dockerfile that's a couple of years old and hasn't been maintained, it probably won't work. If you download the built image then it might work for a bit longer, but you won't be able to make any changes to it, and it will still break sooner or later due to e.g. certificate expiry, or being built for the wrong CPU architecture. > Then came k8s, which tried to solve the issue of deploying across clusters of machines, PaaS. That's not a trivial problem to solve, and consequently is still hard, even with it. But if you need to deploy countless services across hundreds of nodes... It's ultimately a great tool. Declarative deployment definitely has a lot of value. But k8s shoots itself in the foot by being Docker based, even as the world gradually moves onto better models (language-specific serverless deployments).
  - ffsm8 1y ago
    You seem to have a fundamental misunderstanding about what docker actually does, and how it's achieving it > If you download a Dockerfile that's a couple of years old and hasn't been maintained, it probably won't work The dockerfile is not the produced artifact, that's merely the most common way to build the artifact. The artifact is the image. Which itself is only a zip file of a linux filesystem, basically. This will behave the same, no matter when you downloaded it. And I might add: the goal you seem to have: to make an image runnable forevermore is not the goal of docker, again. But if you made a new image, you can then test the exact same deployment in another environment. You do not need to e.g. run apt update on prod and pray to the gods that nothing breaks. Instead you build the image, deploy to test, see that nothing breaks and then deploy to prod. Also k8s isn't technically backed by the docker backend anymore. It hasn't for a pretty long time now. It's currently using containerd by default https://github.com/containerd/containerd https://github.com/containerd/containerd But supports other backends too https://kubernetes.io/docs/setup/production-environment/container-runtimes/ https://kubernetes.io/docs/setup/production-environment/cont...
    - 1y ago

jauntywundrkind 1y ago

There are Distroless images! You can make a container with nothing but one executable in it. https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless has some helpers but you can just put your rust or go program into an image & ship it! For if you really want to go super far super hard against layer sandwiches. Personally, I think you're making awful tradeoffs that radically hamper your team's ability to act operationally. That you are showing enormously low respect by handcuffing your team like so. I hope you have lots of help for how to bring out debug containers to apply tooling that your images are incapable of providing themselves. I beg you to not, but for the uptight, the freaks, the paranoids and those who must go on griping about containers, it's really very easy to do! Anyhow. What's extra funny and sick is that some of this article valorizes VMs. Which have far far more of a bucket of bits what-is-all-this-nonsense problem, that requires providing far more scripting, tailoring, configuration make. Unless you are running bootc or zerg or unikernel stuff, it feels like VM'ers are in in no moral position to look down on containers, my heavens! This article has a couple little gems in it here & there. You call it short, but it's just short on understanding thought concern and perspective. It wrings the same blood from the stone again and again and again. Complexity bad, Kubernetes complex, this is garbage, again and again and again. Without really having much to say, just inferring, just trying to condescend you into belief. But there are a couple little good gems here & there (pro CORBA?! Wasm/wasi hype...)