undefined | Better HN

0 pointsfoxhill5y ago0 comments

> Docker solved a real problem

> everybody thinks they need k8s and simply cargo cult it for a simple Wordpress blog

docker _also_ has this problem though. there are probably 6 people in the world that need to run one program built with gcc 4.7.1 linked against libc 2.18 and another built with clang 7 and libstdc++ at the same time on the same machine.

and yes, docker "provides benefits" other than package/binary/library isolation, but it's _really_ not doing anything other than wrapping cgroups and namespacing from the kernel - something for which you don't need docker to do (see https://github.com/p8952/bocker).

docker solved the wrong problem, and poorly, imo: the packaging of dependencies required to run an app.

and now we live in a world where there are a trillion instances of musl libc (of varying versions) deployed :)

sorry, this doesn't have much to do with k8s, i just really dislike docker, it seems.

0 comments

pas5y ago

Of course the correct approach is the NixOS one. What docker really did is solve the packaging, distribution, and updating problem.

The dependency thing is just the fallout of the (bad) default provided by distributions.

alephu55y ago

I am a big fan of using namespaces via docker, in particular for development. If I want to test my backend component I can expose a single port and then hook it up to the database, redis, nginx etc. via docker networks. You don't need to worry about port clashes and it's easy to "factory reset".

In production this model is quite a good way to guarantee your internal components aren't directly exposed too.

foxhillOP5y ago

that's sort of my point though - namespacing is a great feature that allows for more independent & isolated testing and execution, there is no doubt. docker provides none of it.

i would argue that relying on docker hiding public visibilty of your internal components is akin to using a mobile phone as a door-stop - it'll probably work but there are more appropriate (and auditable) tools for the job.

harpratap5y ago

> docker _also_ has this problem though. there are probably 6 people in the world that need to run one program built with gcc 4.7.1 linked against libc 2.18 and another built with clang 7 and libstdc++ at the same time on the same machine.

You are supposed to keep only a single process inside one docker container. If you want two processes to be tightly coupled then use multi-container pods.

j / k navigate · click thread line to collapse