Docker – full functional systemd with docker container: полнофункциональный docker контейнер с systemd

В одной из предыдущих публикаций я показал как собрать образ с нуля для контейнера на основе пакетной базы CentOS использую классический supermin инструмент.
Однако все такие контейнеры на базе некоторого исполняемого кода (как endpoint или cmd), берушего на себя функции начального процесса с PID 1, далеки от какой-либо эмуляции присутствия среды “контейнерной” ОС. Весь функционал пакета приложения может быть использован только если среда будет максимально похожа на ставшую уже стандартом де-факто systemd. Для этого нужен полноценный init (читай systemd) процесс, способный работать с сервисами в контейнерной изоляции docker как в обычной полной виртуализации или на обычном сервере. Почему это важно – понятно от сюда (https://docs.docker.com/config/containers/start-containers-automatically/).
Контенейры могут стартовать автоматически, а вот вся остальная логика запуска сервисов будет в руках менеджеров процессов.
Все это ни в коей мере не нужно если изолируется минимальный набор микро-приложения собственной сборки с интерпретатором и его зависимостями или тем более бинарник статической сборки. Изоляция кастомных микропрограмм по сути единственное важное и нужное в применении изоляций в docker или k3s.

В “родных” контейнерах изоляторах построенных на базе контейнеров systemd-nspawn все это заложено изначально, и такие контейнеры сразу запуcкают полноценный процесс init – systemd. Но так ли сложно обойти “костыли” архитектуры docker/k8s/k3s и запустить systemd под его изоляцией полноценно? Давайте проверим.

Углубившись слегка в понимание процесса загрузки ОС, в котором ядро передает управление некоему процессу init, мы можем понять, что любой такой процесс будет выполнять ряд логических процессов инициализации сервисов и среды из одной начальной точки до некоторого целевого состояния. И совсем не факт что мы не можем пропустить большую часть этих действий по своему усмотрению.

В systemd все это крутится вокруг сущностей целей, сервисов и юнитов. Значит, передавая в докер контейнер systemd как начальную входную точку, мы можем попытаться определить его цель по умолчанию на основе специфики обоих платформ. Хотя по всему видно, что они друг другу не друзья. И контейнеры на базе systemd-nspawn обладает не меньшей мощью и гибкостью.

Допустим, что как и в предыдущей публикации, мы уже знаем как создать базовую сущность supermin5 только с одним пакетом – yum.
Теперь попробуем создать это с двумя пакетами – systemd и yum:

$ supermin --verbose --prepare yum systemd -o centos8s.supermin.base.systemd

Просмотрев построенное файловое дерево конфигурационных файлов, уже видим, что появились новые пути в дереве каталогов где мы можем размещать файлы конфигурации systemd.
Далее создаем реальное дерево файлов на основе конфигурации в chroot с установкой всех пакетов:

$ supermin --verbose --build --include-packagelist --format chroot centos8s.supermin.base -o centos8s.build.chroot.systemd.stage1

Все готово к данному моменту для создания файла целевой загрузки systemd – default.target.
default.target – это все тот же юнит типа target. Соответственно, если мы определим в качестве зависимостей к таргету другие юниты, вы заставим systemd загружать иные сервисы и т.д.
А default.target будет конечной точкой состояния системы. Весь процесс инициализации systemd можно представить в виде дерева, где в корне расположен default.target. Systemd начинает строить дерево зависимостей сверху вниз, начиная с default.target, а вот запускаются сервисы в обратном пордяке, соблюдая зависимости по пути движения к конечному состоянию.

Переходим в структуру каталогов в свежесозданной инсталляции (centos8s.appliance.d/etc/systemd/system) и создаем файл с именем isolated.target и линк на него из default.target

$ cd centos8s.appliance.d/etc/systemd/system

$ tree -L 1
.
├── basic.target.wants
├── bluetooth.target.wants
├── getty.target.wants
├── graphical.target.wants
├── multi-user.target.wants
├── remote-fs.target.wants
├── sockets.target.wants
├── sysinit.target.wants
└── timers.target.wants

$ cat isolated.target
[Unit]
Description = systemd in docker containers

$ ln -sf isolated.target default.target

$ tree -L 1
.
├── basic.target.wants
├── bluetooth.target.wants
├── default.target -> isolated.target
├── getty.target.wants
├── graphical.target.wants
├── isolated.target
├── multi-user.target.wants
├── remote-fs.target.wants
├── sockets.target.wants
├── sysinit.target.wants
└── timers.target.wants

Все теперь мы можем упаковать это дерево установки в chroot в архив tar который будет представлять архив нового файлового образа для импорта в среду docker, не забывая добавить волшебную переменную для yum. И импортируем в локальные образы:

$ mkdir -p centos8s.appliance.d/etc/dnf/vars
$ mkdir -p centos8s.appliance.d/etc/yum

$ ln -sr centos8s.appliance.d/etc/dnf/vars -t centos8s.appliance.d/etc/yum
$ echo 8 > centos8s.appliance.d/etc/yum/vars/releasever

$ tar --numeric-owner -cpf centos8s_zero_systemd.tar -C centos8s.appliance.d .

$ cat centos8s_zero_systemd.tar | docker import - local/centos8s-zero-systemd
sha256:30c8fd5159c9694b5eb3d960431213b7ef831f501772e89efa3ae739a6c2e4ae

$ docker images
REPOSITORY                         TAG       IMAGE ID       CREATED          SIZE
local/centos8s-zero-systemd        latest    30c8fd5159c9   12 seconds ago   354MB
...

Теперь можем запустить на выполнение контейнер на базе этого файлового образа в интерактивном режиме, указав в качестве команды запуск оболочки bash:

$ docker run -it --restart unless-stopped local/centos8s-zero-systemd /bin/bash
5f74d3aa55cf9f1ebf62883968ee746f8c47262a0f671e582c1fc9a54b9ca10d

В контейнере доустанавливаем пакеты до минимального набора и готовим среду ssh сервера:

bash-4.4# ldconfig
bash-4.4# yum clean all && yum makecache && yum -y install rpm rpm-build-libs rpm-libs python3-rpm yum cracklib cracklib-dicts binutils dbus-libs device-mapper device-mapper-libs file iproute iptables iptables-services iputils groff-base less libcroco libgomp libunistring vim rootfiles openssh-server

bash-4.4# ssh-keygen -A
ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519

bash-4.4# mkdir /var/run/sshd
bash-4.4# echo 'root:12345678' | chpasswd
bash-4.4# exit
exit

Теперь как и в предыдущей статье экспортируем содержимое файловой системы контейнера в tar архив. И далее в новый образ.

$ docker ps -a
CONTAINER ID   IMAGE                              COMMAND           CREATED          STATUS          PORTS                                   NAMES
32b81a03314c   local/centos8s-zero-systemd        "/bin/bash"       12 minutes ago   Up 2 minutes                                            interesting_roentgen

$ docker export 32b81a03314c > centos8s_minimal_systemd.tar
$ cat centos8s_minimal_systemd.tar | docker import - local/centos8s-minimal-systemd

$  docker images
REPOSITORY                         TAG       IMAGE ID       CREATED          SIZE
local/centos8s-minimal-systemd     latest    8679c3c72188   10 seconds ago   880MB

Теперь для дальнейшего создания минимального контейнера запускающего systemd я создаю подходящий Dockerfile, который использует ENDPOINT для запуска первого процесса.

$ cat dockerfile_centos8s_minimal_systemd
FROM local/centos8s-minimal-systemd
ENV container=docker
ENTRYPOINT ["/sbin/init"]
CMD ["--log-level=info"]
STOPSIGNAL SIGRTMIN+3

И создаем образ из базового образа и Dockerfile:

А теперь создаем контейнер монтирую спец директории внутрь контейнера:

Ныряем в контейнер и видим резуьтат

“Загнали” systemd в изоляцию, но он все равно выполнил все установленные сервисы и запустил в этой изоляции sshd! Имею почти ОС))) Однако о безопасности и стабильности не сказано ни слова. Так же ни слова о том что эти процессы могут создать перегрузки без должного контроля лимитов памяти и процессора. Тем не менее делаем как я и наслаждаемся еще однои вариантом изоляции разработчиков – этих парней надо держать на правильном поводке))