Or we could just ditch Docker for one of the alternatives, like Podman that doesn't need root, nor a daemon.
The W3C[1] says "if you connect to a service on one of these ports you can be fairly sure that you have the real thing, and not a fake which some hacker has put up for you." Well, in 2019 computers aren't mainframes run by institutions and hackers can be root of their own system and run whatever they want on port 22.
It's such an incovenience that I'm sure it caused countless services to be unnecessarily run as root.
[1]: https://www.w3.org/Daemon/User/Installation/PrivilegedPorts....
sysctl net.ipv4.ip_unprivileged_port_start=443
( https://stackoverflow.com/questions/413807/is-there-a-way-fo... )
It sucks.
It flies in the face of traditional Linux process management where child processes are child processes.
(Unless you want an init system, where you need a daemon. But docker is a sucky init system.)
Docker breaks even the most basic things.
$ time docker run some heavy computation
If you want the fork-exec model then docker is indeed the wrong tool for the job.
I used to use systemd+rkt for simple container setups when I didn't need all of Kubernetes. Never noticed any downsides versus using Docker, but on the flip side, I had far fewer issues with my containers not properly starting at boot.
Don't know if that accounts for the whole reason or not.
https://jpetazzo.github.io/2017/02/24/from-dotcloud-to-docke...?
Here's the scene: Most of the web projects I work on will never have a billion users. They might have 5, or 10. One or two have thousands. Several of them have 1 (me).
Docker-compose works for me. I set up a container for my backend, a container for whatever's serving the static resources for the frontend, and a container for whatever databases are needed (Postgres, Redis, whatever). The databases get a filesystem volume mount that I can snapshot off the disk with a nightly cron job.
I have a script that will transform a brand shiny new $5/mo DigitalOcean Ubuntu image into a machine with nginx+LetsEncrypt for SSL termination, and with Docker and docker-compose installed (and the Docker port firewalled off, natch). From there, I run "docker-compose up -d" and my project fires up and goes. Maybe I have to edit a line or two in the nginx.conf that my script put in place.
To deploy, I do a local build on my laptop (or Jenkins for a few projects where it makes sense) via a script that pushes the built containers to Docker Hub, and runs docker-compose pull on the host.
This has served me beautifully.
I've looked at Kube more than once. It looks cool for things dramatically bigger than what I'm working on. For something that isn't massive scale, it's bloody complicated. If one of these projects ever gets to the point where a $40/mo DigitalOcean box can't handle the load, I'll probably look at it again. Until then, though, it feels like a very expensive (time-wise) premature optimization.
(I mean, projects that set up containers for backend, database, and front-end servers and push them to digitalocean etc.. I can imagine how each piece works, but I'd love to see how a coherent and manageable project in that style is organized as a whole.)
The cost of running a managed kubernetes is too expensive to justify for the benefits in these cases. And if you choose to self-manage to cut the money cost, it ends up being significantly more expensive from a time and sanity perspective.
Are you referring to the cost of migration (since most Kubernetes adopters are probably also learning K8s for the first time as well?)