Docker does not remove all the Linux “crap” - it just hides it. Arguably that works fine in many cases, but I have seen many where it didn’t.

So in development and for small setups (basically 99% of all setups you will do on your own) I prefer not using docker.

Reply to this note

Please Login to reply.

Discussion

Have worked at companies with 40 devs, none proficient in Docker, using it for dev setup. We spent so much time on debugging and rebuilding containers, it was ridiculous.

As you just pointed out yourself, that's a skill issue.

If you don't read yourself in & go into containers with a 90's #Linux attitude, you *will* definitely fail.

I agree.

I did not say it is "removed", though. :)

It also does not "hide" it.

https://www.howtogeek.com/733522/docker-for-beginners-everything-you-need-to-know/

Not sure, which resource explains how #Docker works in the best way, but essentially, a container is derived from an image, which (container) only depends on the host's Kernel. Everything else is the container's doing.

Naturally, you usually wouldn't want ultra low level programs to be run inside a container, but this wouldn't make much sense, either way.

Everything else is fine inside containers.

As for your statement regarding "development" & "small setups" I have to oppose that strongly, in its entirety.

I barely setup any app without a Dockerfile, because it's a waste of time & I also do not want to pollute my servers with some Dev crap, because what feels like every Dev on GitHub must create his own shit, without respecting generalised standards.

Especially #Frontend projects are extremely invasive & annoying.

If the project does not deliver a ready made Dockerfile, I create one myself, ad-hoc. No problem.

The only times you get issues with Alpine, is if the maintainers did some nasty stuff, like depending on specific non-portable APIs, etc. Then yeah, you might not be able to `musl` that stuff.

However, even then, you can still use Debian or Ubuntu as a fallback base image, which will work for everything.

If there is ever something that does not work at all inside a #Docker container, it's in 99.9999999999999% of cases the Dev's fault for programming the project in the most non-portable, system-dependent & weirdly discaring way possible.

Like, when they inherently hardcode #SystemD calls into the program. I mean, come on, what the hell is wrong with you...

Needless to say, I naturally run #Kubernetes on my amd64 servers & self-made Docker Compose setups on my #RaspberryPi's.