[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Init systems and docker

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

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

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

Reply to: