4 ms·
The most basic problem with Docker is the use of a daemon that is not init. Access control is at best problematic. Upgrading the daemon without losing state i
by xorcist 7y ago
The most basic problem with Docker is the use of a daemon that is not init.
Access control is at best problematic.
Upgrading the daemon without losing state is tricky.
Requiring daemon access to build images is insane.
Building this functionality into something like systemd would be more robust but it's way harder to sell as a product.
- Smithalicious 7y agoYeah Docker should get with the times and be assimilated into systemd like everything else
- Nullabillity 7y agoSeems to be on its way! systemd-nspawn (the container subsystem) seems to have support for OCI images since march.[0] [0]: https://github.com/systemd/systemd/pull/9762/files https://github.com/systemd/systemd/pull/9762/files
- oblio 7y agoYou could argue about many things bundled with systemd, but since containers are just souped-up processes, this is actually an use case that make sense for an init system.
- ahartmetz 7y agoI see them as souped-down virtual machines or the new vServers but with a decent interface. vServers (a bunch of hacks to separate users as if running different Linux instances) were pretty awful.
- CameronNemo 7y agoI disagree. I would prefer to have a model where the supervisor needs no knowledge of the LSM profile, namespaces, seccomp profile, or cgroups applied to a service. Additionaly, I would prefer a non-init service supervisor.
- ahartmetz 7y agoOkay Lennart, if you say so.