Работи во контејнер

Темата за користење на systemd во контејнери ја следиме подолго време. Назад во 2014 година, нашиот инженер за безбедност Даниел Волш напиша статија Работи системски во докер контејнер, а неколку години подоцна - друг, кој беше наречен Системот работи во непривилегиран контејнер, во која тој изјави дека состојбата не е многу подобрена. Конкретно, тој напиша дека „за жал, дури и две години подоцна, ако гуглате „Docker system“, првото нешто што ќе се појави е истиот негов стар напис. Значи, време е да промениме нешто“. Покрај тоа, ние веќе разговаравме за конфликт помеѓу Docker и системските програмери.

Во оваа статија ќе покажеме што се сменило со текот на времето и како Подман може да ни помогне во ова прашање.

Постојат многу причини да се работи на системот во контејнер, како што се:

1. Мултисервисни контејнери – многу луѓе сакаат да ги извлечат своите мулти-сервисни апликации од виртуелните машини и да ги користат во контејнери. Би било подобро, се разбира, да се разделат таквите апликации во микросервиси, но не секој сè уште знае како да го направи тоа или едноставно нема време. Затоа, пуштањето на такви апликации како услуги лансирани од systemd од единечни датотеки има совршена смисла.
2. Датотеки со системски единици – Повеќето апликации што работат во контејнери се изградени од код што претходно работел на виртуелни или физички машини. Овие апликации имаат единица датотека што е напишана за овие апликации и разбира како тие треба да се стартуваат. Затоа, сепак е подобро да започнете услуги со помош на поддржани методи, наместо да ја хакирате сопствената иницијална услуга.
3. Systemd е менаџер на процеси. Управува со услугите (ги исклучува, ги рестартира услугите или ги убива процесите на зомби) подобро од која било друга алатка.

Како што рече, има многу причини да не се работи на системот во контејнери. Главната е дека systemd/journald го контролира излезот од контејнерите и алатките како Кубернети или openshift очекувајте контејнерите да пишуваат дневник директно на stdout и stderr. Затоа, ако сакате да управувате со контејнери преку алатки за оркестрација како оние споменати погоре, треба сериозно да размислите за користење на контејнери базирани на систем. Дополнително, програмерите на Docker и Moby честопати беа силно против користењето на systemd во контејнери.

Доаѓањето на Подман

Среќни сме да известиме дека ситуацијата конечно напредува. Тимот одговорен за водење на контејнери во Red Hat одлучи да се развие свој мотор за контејнер. Доби име Подман и го нуди истиот интерфејс на командната линија (CLI) како и Docker. И скоро сите Docker команди може да се користат во Podman на ист начин. Често спроведуваме семинари, кои сега се нарекуваат Промена на Docker во Podman, а првиот слајд бара пишување: алијас docker=podman.

Многу луѓе го прават ова.

Мојот Podman и јас во никој случај не сме против контејнери базирани на систем. На крајот на краиштата, Systemd е најчесто користениот подсистем за Linux init, а не дозволувајќи му да работи правилно во контејнерите значи игнорирање на тоа како илјадници луѓе се навикнати да работат со контејнери.

Подман знае што да направи за системот да работи правилно во контејнер. Потребни се работи како монтажа на tmpfs на /run и /tmp. Таа сака да има овозможена „контејнеризирана“ околина и очекува дозволи за пишување на нејзиниот дел од директориумот cgroup и во папката /var/log/journald.

Кога стартувате контејнер во кој првата команда е init или systemd, Podman автоматски ги конфигурира tmpfs и Cgroups за да се осигура дека systemd започнува без проблеми. За да го блокирате овој режим на автоматско стартување, користете ја опцијата --systemd=false. Имајте предвид дека Podman користи системски режим само кога ќе види дека треба да изврши команда systemd или init.

Еве извадок од прирачникот:

човек podman трчање
...

–systemd=true|неточно

Водење контејнер во системски режим. Стандардно е овозможено.

Ако извршите команда 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 true

Сега погледнете како изгледа Dockerfile за водење на системот во контејнер користејќи 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 во датотеката на единицата systemd, која ќе ја стартува услугата и ќе ја следи. Podman го користи стандардниот модел fork-exec. Со други зборови, контејнерските процеси се деца на процесот Podman, така што systemd може лесно да ги следи.

Docker користи модел клиент-сервер, а командите на Docker CLI исто така може да се стават директно во единица датотека. Меѓутоа, штом клиентот на Docker ќе се поврзе со демонот на Docker, тој (клиентот) станува само уште еден процес за ракување со stdin и stdout. За возврат, systemd нема идеја за врската помеѓу клиентот Docker и контејнерот што работи под контрола на Docker демонот, и затоа, во рамките на овој модел, systemd фундаментално не може да ја следи услугата.

Активирање на системот преку штекер

Podman правилно се справува со активирањето преку штекерот. Бидејќи Podman го користи моделот fork-exec, тој може да го препрати штекерот до процесите на својот дете контејнер. Docker не може да го направи ова бидејќи користи модел клиент-сервер.

Услугата varlink што ја користи Podman за да комуницира со далечински клиенти во контејнери всушност се активира преку приклучок. Пакетот cockpit-podman, напишан во Node.js и дел од проектот на кокпитот, им овозможува на луѓето да комуницираат со контејнерите на Podman преку веб-интерфејс. Веб-демонот кој работи на кокпит-подман испраќа пораки до штекерот varlink што системот го слуша. Systemd потоа ја активира програмата Podman за да прима пораки и да започне да управува со контејнерите. Активирањето на systemd преку приклучок ја елиминира потребата од постојано работи демон при имплементирање на далечински API.

Дополнително, развиваме уште еден клиент на Podman наречен подман-далечински управувач, кој го имплементира истиот Podman CLI, но го повикува varlink да работи контејнери. Podman-далечинскиот управувач може да работи на врвот на сесиите на SSH, што ви овозможува безбедно да комуницирате со контејнери на различни машини. Со текот на времето, планираме да овозможиме подман-далечински управувач да поддржува MacOS и Windows заедно со Linux, така што програмерите на тие платформи можат да работат на виртуелна машина Линукс со Podman varlink што работи и да имаат целосно искуство дека контејнерите работат на локалната машина.

SD_NOTIFY

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

Во плановите

Планираме да ја додадеме командата podman generate systemd CONTAINERID, која ќе генерира системска единица датотека за управување со одреден контејнер наведен. Ова треба да работи и во режими за root и без корен за непривилегирани контејнери. Видовме дури и барање за OCI-компатибилно време на траење systemd-nspawn.

Заклучок

Системското работење во контејнер е разбирлива потреба. И благодарение на Podman, конечно имаме време на траење на контејнер што не е во конфликт со systemd, но го прави лесен за користење.

Извор: www.habr.com