Hello folks, I have a simple query regarding containers .. how do you cope with . . .

Docker
#1

Akash Agarwal:
Hello folks, I have a simple query regarding containers … how do you cope with the absence of systemd as init system in a container ? because there are multiple events when the cli app is systemd dependant

#2

Alistair Mackay:
What do you mean the cli app is systemd dependant?

A container is a partition of the host operating system. It’s not a virtual machine, therefore it does not have an init system.

#3

Akash Agarwal:
I meant that certain command line utilities like cockpit are systemd dependent similarly there are some services which are too … Similarly creating and managing services is easy with systemd as init system by container does not have an init system at all

#4

Alistair Mackay:
cockpit isn’t designed to be run in a container. You need to install it on the host directly, as it administers the host.

#5

Akash Agarwal:
Cockpit uses systemd and the DBus APIs it provides to configure and monitor core aspects of the system. Use of alternate system APIs are not currently implemented.

#6

Akash Agarwal:
Says cockpit website

#7

Sam Leibowitz:
Can I ask, what is the problem you’re trying to solve by running a cockpit container?

#8

Akash Agarwal:
I presented it as an example, my main query was if there’s a need for systemd based service in an container how could it be solved?

#9

Sam Leibowitz:
Ah, okay. The short answer is that there’s generally no need to run systemd inside a container. Systemd’s purpose is mostly to standardize the startup and shutdown of multiple processes (services). But a container can be thought of as a neatly packaged, installed version of a single application. It’s possible to run multiple processes inside a container, but it’s usually a bad idea, and if a container gets complex enough to require it’s own systemd to manage services then you’re almost certainly doing something wrong.

#10

Sam Leibowitz:
Real life example - in the Ruby on Rails world there’s an often used service called Sidekiq, which handles asynchronous jobs. if you were deploying a Ruby on Rails app via container, you might have an image that includes both the actual web app infrastructure, and Sidekiq, but you’d start multiple containers, some for the web side and some for the async side.

#11

Akash Agarwal:
So the multiple containers is the solution we have ?

#12

Sam Leibowitz:
Yup. If you need a solution to orchestrate multiple running containers that depend on each other, you have a few options, the most popular of which is probably kubernetes.