Hacker News new | past | comments | ask | show | jobs | submit login

> 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.




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.


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.


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.


> 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.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: