Изпълнение на systemd в контейнер

Следим темата за използването на systemd в контейнери от дълго време. През 2014 г. нашият инженер по сигурността Даниел Уолш написа статия Изпълнение на systemd в Docker контейнер, а няколко години по-късно - друг, който се наричаше Стартиране на systemd в непривилегирован контейнер, в който заяви, че ситуацията не се е подобрила много. По-специално той пише, че „за съжаление, дори две години по-късно, ако търсите в Google „Docker system“, първото нещо, което се появява, е същата стара статия. Така че е време да променим нещо." Освен това вече говорихме за конфликт между разработчиците на Docker и systemd.

В тази статия ще покажем какво се е променило с времето и как Podman може да ни помогне по този въпрос.

Има много причини да стартирате systemd вътре в контейнер, като например:

1. Мултисервизни контейнери – много хора искат да изтеглят своите мултисервизни приложения от виртуални машини и да ги изпълняват в контейнери. Би било по-добре, разбира се, да разбиете такива приложения в микроуслуги, но не всеки знае как да направи това все още или просто няма време. Следователно стартирането на такива приложения като услуги, стартирани от systemd от модулни файлове, е напълно логично.
2. Systemd модулни файлове – Повечето приложения, работещи в контейнери, са изградени от код, който преди това е изпълняван на виртуални или физически машини. Тези приложения имат единичен файл, който е написан за тези приложения и разбира как трябва да бъдат стартирани. Така че все още е по-добре да стартирате услуги, като използвате поддържани методи, вместо да хакнете собствената си услуга за стартиране.
3. Systemd е мениджър на процеси. Той управлява услуги (изключва, рестартира услуги или убива зомби процеси) по-добре от всеки друг инструмент.

Въпреки това има много причини да не стартирате systemd в контейнери. Основният е, че systemd/journald контролира изхода на контейнери и инструменти като Kubernetes или отворена смяна очаквайте контейнерите да записват регистрационни файлове директно в stdout и stderr. Следователно, ако ще управлявате контейнери чрез инструменти за оркестрация като тези, споменати по-горе, трябва сериозно да обмислите използването на базирани на systemd контейнери. Освен това, разработчиците на Docker и Moby често са силно против използването на systemd в контейнери.

Идването на Подман

Щастливи сме да съобщим, че ситуацията най-накрая се е променила. Екипът, отговорен за управлението на контейнери в Red Hat, реши да се развива вашия собствен контейнерен двигател. Има име Подман и предлага същия интерфейс на командния ред (CLI) като Docker. И почти всички Docker команди могат да се използват в Podman по същия начин. Често провеждаме семинари, които сега се наричат Промяна на Docker на Podman, а първият слайд призовава за писане: alias docker=podman.

Много хора правят това.

Моят Podman и аз по никакъв начин не сме против базирани на systemd контейнери. В края на краищата Systemd е най-често използваната подсистема за стартиране на Linux и да не й позволявате да работи правилно в контейнери означава да игнорирате как хиляди хора са свикнали да работят с контейнери.

Podman знае какво да направи, за да накара systemd да работи правилно в контейнер. Има нужда от неща като монтиране на tmpfs на /run и /tmp. Тя обича да има активирана "контейнеризирана" среда и очаква разрешения за запис в нейната част от директорията на cgroup и в папката /var/log/journald.

Когато стартирате контейнер, в който първата команда е init или systemd, Podman автоматично конфигурира tmpfs и Cgroups, за да гарантира, че systemd стартира без проблеми. За да блокирате този режим на автоматично стартиране, използвайте опцията --systemd=false. Моля, обърнете внимание, че Podman използва режим systemd само когато види, че трябва да изпълни команда systemd или init.

Ето извадка от ръководството:

man podman run
...

–systemd=true|false

Изпълнение на контейнер в режим systemd. Активирано по подразбиране.

Ако изпълните команда systemd или init вътре в контейнер, Podman ще конфигурира точките за монтиране на tmpfs в следните директории:

/run, /run/lock, /tmp, /sys/fs/cgroup/systemd, /var/lib/journal

Също така стоп сигналът по подразбиране ще бъде SIGRTMIN+3.

Всичко това позволява на systemd да работи в затворен контейнер без никакви модификации.

ЗАБЕЛЕЖКА: systemd се опитва да пише във файловата система cgroup. SELinux обаче не позволява на контейнерите да правят това по подразбиране. За да активирате писането, активирайте булевия параметър container_manage_cgroup:

setsebool -P container_manage_cgroup вярно

Сега вижте как изглежда Dockerfile за стартиране на systemd в контейнер с помощта на Podman:

# cat Dockerfile

FROM fedora

RUN dnf -y install httpd; dnf clean all; systemctl enable httpd

EXPOSE 80

CMD [ "/sbin/init" ]

Това е всичко.

Сега сглобяваме контейнера:

# podman build -t systemd .

Казваме на SELinux да позволи на systemd да променя конфигурацията на Cgroups:

# setsebool -P container_manage_cgroup true

Между другото, много хора забравят за тази стъпка. За щастие, това трябва да се направи само веднъж и настройката се запазва след рестартиране на системата.

Сега просто стартираме контейнера:

# podman run -ti -p 80:80 systemd

systemd 239 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)

Detected virtualization container-other.

Detected architecture x86-64.

Welcome to Fedora 29 (Container Image)!

Set hostname to <1b51b684bc99>.

Failed to install release agent, ignoring: Read-only file system

File /usr/lib/systemd/system/systemd-journald.service:26 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling.

Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.)

[  OK ] Listening on initctl Compatibility Named Pipe.

[  OK ] Listening on Journal Socket (/dev/log).

[  OK ] Started Forward Password Requests to Wall Directory Watch.

[  OK ] Started Dispatch Password Requests to Console Directory Watch.

[  OK ] Reached target Slices.

…

[  OK ] Started The Apache HTTP Server.

Това е всичко, услугата е готова и работи:

$ curl localhost

<html  xml_lang="en" lang="en">

…

</html>

ЗАБЕЛЕЖКА: Не опитвайте това на Docker! Там все още трябва да танцувате с дайре, за да стартирате тези видове контейнери през демона. (Ще са необходими допълнителни полета и пакети, за да може всичко това да работи безпроблемно в Docker, или ще трябва да се изпълнява в привилегирован контейнер. За подробности вж. Статия.)

Още няколко страхотни неща за Podman и systemd

Podman работи по-добре от Docker във файловете на системния модул

Ако контейнерите трябва да бъдат стартирани, когато системата се зарежда, тогава можете просто да вмъкнете подходящите команди на Podman във файла на системния модул, който ще стартира услугата и ще я наблюдава. Podman използва стандартния модел fork-exec. С други думи, контейнерните процеси са деца на процеса Podman, така че systemd може лесно да ги наблюдава.

Docker използва модел клиент-сървър и Docker CLI командите могат също да бъдат поставени директно в единичен файл. Въпреки това, след като клиентът на Docker се свърже с демона на Docker, той (клиентът) става просто друг процес, обработващ stdin и stdout. На свой ред systemd няма представа за връзката между клиента на Docker и контейнера, който работи под контрола на демона на Docker, и следователно в рамките на този модел systemd по принцип не може да наблюдава услугата.

Активиране на systemd чрез сокет

Podman обработва правилно активирането чрез сокет. Тъй като Podman използва модела fork-exec, той може да препрати сокета към своите дъщерни контейнерни процеси. Docker не може да направи това, защото използва модел клиент-сървър.

Услугата varlink, която Podman използва за комуникация с отдалечени клиенти към контейнери, всъщност се активира чрез сокет. Пакетът cockpit-podman, написан на Node.js и част от проекта cockpit, позволява на хората да взаимодействат с контейнерите на Podman чрез уеб интерфейс. Уеб демонът, изпълняващ cockpit-podman, изпраща съобщения до сокет varlink, който systemd слуша. След това Systemd активира програмата Podman, за да получава съобщения и да започне да управлява контейнери. Активирането на systemd през сокет елиминира необходимостта от постоянно работещ демон при внедряване на отдалечени API.

Освен това разработваме друг клиент на Podman, наречен podman-remote, който прилага същия CLI на Podman, но извиква varlink за изпълнение на контейнери. Podman-remote може да работи върху SSH сесии, което ви позволява сигурно да взаимодействате с контейнери на различни машини. С течение на времето планираме да активираме podman-remote да поддържа MacOS и Windows заедно с Linux, така че разработчиците на тези платформи да могат да стартират Linux виртуална машина с Podman varlink и да имат пълно изживяване, че контейнерите работят на локалната машина.

SD_NOTIFY

Systemd ви позволява да отложите стартирането на спомагателни услуги, докато не започне контейнерната услуга, която те изискват. Podman може да препрати сокета SD_NOTIFY към контейнерната услуга, така че услугата да уведоми systemd, че е готова за работа. И отново, Docker, който използва модел клиент-сървър, не може да направи това.

В плановете

Планираме да добавим командата podman generate systemd CONTAINERID, която ще генерира системен файл с единица за управление на конкретен указан контейнер. Това трябва да работи както в root, така и в режим без root за непривилегировани контейнери. Дори видяхме заявка за OCI-съвместима среда за изпълнение на systemd-nspawn.

Заключение

Изпълнението на systemd в контейнер е разбираема нужда. И благодарение на Podman най-накрая имаме време за изпълнение на контейнер, което не е в конфликт със systemd, но го прави лесен за използване.

Източник: www.habr.com