3 ms·

I think most of the comments here largely miss the point of the article. The guy doesn't complain about docker as a whole and doesn't criticise it's usage for s

I think most of the comments here largely miss the point of the article. The guy doesn't complain about docker as a whole and doesn't criticise it's usage for software deployment which normally is the main application. He complains about Docker being used as a software distribution method, that is as a replacement for say Debian package, pip package, npm package etc. So in order to use that software you need to run a Docker image from the internet which is often poorly made and is incompatible with your infrastructure. Had a package been available you'd simply do "install" inside your own image built with your infrastructure in mind. With that I agree completely. Docker and worse even docker-compose are terrible ways of software distribution and should never be used except for demos and for rare cases where software is not distributed to the customer in the normal sense but rather directly deployed into his system. Docker and docker-compose are still very good methods of software deployment.

turtlebits 3y ago
I have rarely seen end user software being distributed as a docker image, only server applications. Occasionally I see CLI tools that are hard to package available as docker images, but those are generally done because the maintainer hasn't provided precompiled binaries.
solatic 3y ago
This, but I want to add, I think the root cause is less due to the ease of writing a Dockerfile vs writing a deb, rpm, etc. and more due to the low cost of hosting. Whatever low-quality Dockerfile you write, you can sign up on Docker Hub, build and push there, and you're done. GitHub Packages doesn't support deb or rpm, and anyway for better or for worse, packages are tightly coupled to the distribution they're packaged for. That means either getting your package into the package repository of each distribution you want to target, or hosting your own package repository, which is non-trivial in both financial and labor cost. Docker has a lot more crap, but it did dramatically lower the barrier of entry, which is a good thing. The proper response isn't to bemoan the lower barrier of entry, but to attempt to lower the barrier of entry of traditional packaging.
cderpz 3y ago
>He complains about Docker being used as a software distribution method, that is as a replacement for say Debian package, pip package, npm package etc. If that is a valid complaint, why does he choose two examples where that is not the case? Nextcloud AIO is just one option among many and certainly not the "standard way" of hosting your nextcloud instance. Coincidentally I came from hosting nextcloud the "standard way" and I'm really glad AIO exists and I don't have to manage nonsense like nextcloud ending support for the latest Debian php version. And Home Assistant is mainly distributed as the OS variant with the docker version being the step child afterthought that barely functions.
Too 3y ago
Don’t tell this guy about Helm-charts. Oboy, if you thought docker images overriding default configuration options was bad. Wait until you add yet another layer of new config parameters on top, that do absolutely nothing at all, just translate down into an environment variable that the docker image translates into the application config. The ever increasingly popular ones from bitnami are the worst in this regard. I always get questioned for reinventing the wheel when writing my own Dockerfiles. In the end it always end up more maintainable. The problem is these premade charts put a wheel inside a wheel inside a wheel. If you get a flat tire, you have to open up all of them at once to understand what is going on.

turtlebits 3y ago

I have rarely seen end user software being distributed as a docker image, only server applications. Occasionally I see CLI tools that are hard to package available as docker images, but those are generally done because the maintainer hasn't provided precompiled binaries.

solatic 3y ago

This, but I want to add, I think the root cause is less due to the ease of writing a Dockerfile vs writing a deb, rpm, etc. and more due to the low cost of hosting. Whatever low-quality Dockerfile you write, you can sign up on Docker Hub, build and push there, and you're done. GitHub Packages doesn't support deb or rpm, and anyway for better or for worse, packages are tightly coupled to the distribution they're packaged for. That means either getting your package into the package repository of each distribution you want to target, or hosting your own package repository, which is non-trivial in both financial and labor cost. Docker has a lot more crap, but it did dramatically lower the barrier of entry, which is a good thing. The proper response isn't to bemoan the lower barrier of entry, but to attempt to lower the barrier of entry of traditional packaging.

cderpz 3y ago

>He complains about Docker being used as a software distribution method, that is as a replacement for say Debian package, pip package, npm package etc. If that is a valid complaint, why does he choose two examples where that is not the case? Nextcloud AIO is just one option among many and certainly not the "standard way" of hosting your nextcloud instance. Coincidentally I came from hosting nextcloud the "standard way" and I'm really glad AIO exists and I don't have to manage nonsense like nextcloud ending support for the latest Debian php version. And Home Assistant is mainly distributed as the OS variant with the docker version being the step child afterthought that barely functions.

Too 3y ago

Don’t tell this guy about Helm-charts. Oboy, if you thought docker images overriding default configuration options was bad. Wait until you add yet another layer of new config parameters on top, that do absolutely nothing at all, just translate down into an environment variable that the docker image translates into the application config. The ever increasingly popular ones from bitnami are the worst in this regard. I always get questioned for reinventing the wheel when writing my own Dockerfiles. In the end it always end up more maintainable. The problem is these premade charts put a wheel inside a wheel inside a wheel. If you get a flat tire, you have to open up all of them at once to understand what is going on.