2 ms·

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 de

by 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...
  - lmm 1y ago
    > You seem to have a fundamental misunderstanding about what docker actually does, and how it's achieving it On the contrary, I understand what it actually does (or tries to) for very well, you're hung up on what its proponents say it's meant to do (or perhaps retreat to in motte-and-bailey fashion). > 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. But it won't. It's architecture-specific, it may rely on other interfaces that are ultimately moving targets, and you'll face things like certificate expiration. And modifying it in place is not sustainable, you need to be able to rebuild it. > 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. That's not nothing but it's something decent language deployment systems already had for years. Build your structured app image, it's a stable artifact, and you can deploy it any number of times and places. > But supports other backends too But they're all using that same model of unpack some random unmanaged bytes and try to run them as a Linux executable, right? Yes you can swap out the implementation, but the interface is fundamentally at the wrong level of abstraction.

by ffsm8 1y ago

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...
- lmm 1y ago
  > You seem to have a fundamental misunderstanding about what docker actually does, and how it's achieving it On the contrary, I understand what it actually does (or tries to) for very well, you're hung up on what its proponents say it's meant to do (or perhaps retreat to in motte-and-bailey fashion). > 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. But it won't. It's architecture-specific, it may rely on other interfaces that are ultimately moving targets, and you'll face things like certificate expiration. And modifying it in place is not sustainable, you need to be able to rebuild it. > 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. That's not nothing but it's something decent language deployment systems already had for years. Build your structured app image, it's a stable artifact, and you can deploy it any number of times and places. > But supports other backends too But they're all using that same model of unpack some random unmanaged bytes and try to run them as a Linux executable, right? Yes you can swap out the implementation, but the interface is fundamentally at the wrong level of abstraction.