On Fri, 2019-10-11 at 19:25 -0400, Jose-Luis Rivas wrote: > There's not much sense in using systemd inside a docker container, to > be honest. To put it another way, in the container world the init system belongs outside of the container. That is because the closest thing equivalent to a container is not a box running Debian doing multiple things, it's a single process. In fact if you are Google it's actually simpler - it's a process whose executable is a single statically linked file. It pulls it's configuration from something like etcd (something that lives in the cloud), it uses the file system as an extension of it's RAM - temporary storage that can be blown away when the process exits, if it needs persistent storage comes in the form of a database it connects to using TCP/IP. It's utility doesn't arise because it's more powerful and flexible than the environment Debian provides. On the contrary, it is fare less rich, and flexible than the environment Debian provides. It's power arises because reduces the dependencies to an absolute minimum. It is one file whose main configuration is the TCP endpoints its receives commands from and sends results to, and TCP endpoints of services, log storage and databases it depends on. It's only dependency outside of that list of endpoints is an amd64 machine with some amount of RAM and CPU cycles and the Linux syscall API - something that can be replicated 1000's or millions of times automatically and on demand. A major part of it's utility that unlike Debian dependencies (like say a Web Server or a .so of the right version) that programmers tend to assume is there or their program can break in weird and wonderful ways, programmers tend to assume this one dependency, a TCP connection, is unreliable and ephemeral. So you can create these things and destroy them to handle varying loads, and outages in any one data centre can be handled by shifting the load to another one. The consistency of persistent data is not a problem because it's stored in a full ACID database. An init system of any sort in this is just unwanted complexity. What replaces the init system is something starts up these containers and connects them together on an as needed basis. Kubernetes is one such system, but there alternatives. Docker Swarm is a much simpler thing that creates something is closer to a Debian box (a collection of containers running on one physical box). In the most evolved container systems inside a container it's not just the init system that's considered an anti-pattern, a distribution Debian is also out of place. None of the services Debian provides (like packaging, dependencies, security upgraded) are helpful. The host box will have an OS - but it's just a support system for Kubernetes and you don't really need an entire distribution just to run one program. However, that is the extreme edge. It's where you have a team of programmers creating a static app that includes all of the services it needs, like a web server. Us smaller guys will use pre-packaged software provided by a distribution simply because we are familiar with nginx or apache, and don't want to compile stuff to do off the shelf functions. The rest remains the same - a container is a single process, configuration is primarily connecting TCP end points, things are written to retry when a TCP connection dies, security patches are "installed" by rebuilding the container and restarting it, shells and what not in containers are there merely to facilitate development, debugging and fault analysis. The most popular container distribution is I think Alpine Linux which has an impressively small base install. If Debian wanted to compete in this area it would have to start by shrinking it's minbase install by a factor or 10 or so. Anybody arguing about what sort of init system that install includes hasn't groked containers yet.
Attachment:
signature.asc
Description: This is a digitally signed message part