Biz çoxdan konteynerlərdə systemd istifadə mövzusunu izləyirik. Hələ 2014-cü ildə təhlükəsizlik mühəndisimiz Daniel Walsh bir məqalə yazdı , və bir neçə il sonra - başqa bir ad verildi , o, vəziyyətin çox da yaxşılaşmadığını bildirib. Xüsusilə, o yazdı ki, "təəssüf ki, və iki il sonra, əgər "Docker sistemi" ni google-da axtarsanız, ilk onun eyni köhnə məqaləsi açılır. Beləliklə, dəyişiklik vaxtıdır”. Bundan əlavə, biz artıq danışdıq .
Bu yazıda o vaxtdan bəri nələrin dəyişdiyini və Podmanın bu məsələdə bizə necə kömək edə biləcəyini göstərəcəyik.
Systemd-i konteynerin içərisində işə salmağın bir çox səbəbi var, məsələn:
- Multiservis konteynerləri – bir çox insan multiservis proqramlarını virtual maşınlardan çıxarıb konteynerlərdə işlətmək istəyir. Əlbəttə ki, bu cür tətbiqləri mikroservislərə bölmək daha yaxşı olardı, lakin hamı bunu necə edəcəyini hələ bilmir və ya sadəcə vaxt yoxdur. Beləliklə, bu proqramları vahid fayllardan systemd tərəfindən idarə olunan xidmətlər kimi işə salmaq mükəmməl məna kəsb edir.
- Sistem vahid faylları - konteynerlərin içərisində işləyən əksər proqramlar əvvəllər virtual və ya fiziki maşınlarda işlədilən koddan qurulur. Bu proqramlar bu proqramlar üçün yazılmış və onların necə işlədilməsi lazım olduğunu anlayan vahid fayla malikdir. Beləliklə, öz başlanğıc xidmətinizi sındırmaqdansa, dəstəklənən üsullardan istifadə edərək xidmətlərə başlamaq daha yaxşıdır.
- Systemd proses meneceridir. O, digər vasitələrdən daha yaxşı xidmətləri idarə edir (xidmətləri söndürür, yenidən işə salır və ya zombiləri öldürür).
Deyilənə görə, sistemi konteynerlərdə işə salmamaq üçün çoxlu səbəblər var. Əsas odur ki, systemd/journald konteynerlərin və kimi alətlərin çıxışını idarə edir və ya konteynerlər logları birbaşa stdout və stderr-ə yazmağı gözləyirlər. Beləliklə, əgər siz konteynerləri yuxarıdakı kimi orkestrləşdirmə alətləri ilə idarə edəcəksinizsə, o zaman sistem əsaslı konteynerlərdən istifadə etməyi ciddi düşünməlisiniz. Bundan əlavə, Docker və Moby tərtibatçıları tez-tez konteynerlərdə systemd istifadəsinə qəti şəkildə qarşı çıxırlar.
Podman gəlir
Vəziyyətin nəhayət irəli getdiyini elan etməkdən məmnunuq. Red Hat-da konteynerlərin idarə edilməsinə cavabdeh olan komanda inkişaf etməyə qərar verdi . Bir ad aldı və Docker ilə eyni komanda xətti interfeysini (CLI) təklif edir. Və demək olar ki, bütün Docker əmrləri Podman-da eyni şəkildə istifadə edilə bilər. Biz tez-tez seminarlar keçiririk, indi bu adlanır , və ilk slayd yazmağa çağırır: ləqəb docker=podman.
Bir çox insan məhz bunu edir.
Mənim Podman və mən heç bir şəkildə sistem əsaslı konteynerlərə qarşı deyilik. Axı, Systemd daha çox Linux-un init alt sistemi kimi istifadə olunur və onun konteynerlərdə düzgün işləməsinin qarşısını almaq minlərlə insanın konteynerləri işə salmağa öyrəşməsinə məhəl qoymamaq deməkdir.
Podman sistemin konteynerdə düzgün işləməsi üçün nə edilməli olduğunu bilir. Onun /run və /tmp-də tmpfs quraşdırması kimi şeylərə ehtiyacı var. O, "konteynerləşdirilmiş" mühitin aktiv olmasını sevir və qrup kataloqunun öz hissəsinə və /var/log/journald qovluğuna yazma icazələrini gözləyir.
İlk əmr olaraq init və ya systemd ilə konteyner işə saldıqda, Podman avtomatik olaraq tmpfs və Cgroups-u konfiqurasiya edir ki, systemd düzgün işə düşsün. Bu autostart rejimini söndürmək üçün --systemd=false seçimindən istifadə edin. Nəzərə alın ki, Podman yalnız systemd və ya init əmrini işə salması lazım olduğunu gördükdə systemd rejimindən istifadə edir.
Təlimatdan bir hissəni təqdim edirik:
kişi podman qaçır
...–systemd=true|false
Konteynerin systemd rejimində işlədilməsi. Defolt olaraq aktivdir.
Sistemd və ya init əmri konteynerin içərisində işləyirsə, Podman aşağıdakı qovluqlarda tmpfs quraşdırma nöqtələrini quracaq:
/run, /run/lock, /tmp, /sys/fs/cgroup/systemd, /var/lib/journal
Həmçinin SIGRTMIN+3 standart dayandırma siqnalı kimi istifadə olunacaq.
Bütün bunlar systemd-ə heç bir dəyişiklik etmədən qapalı konteynerdə işləməyə imkan verir.
QEYD: systemd cgroup fayl sisteminə yazmağa çalışır. Bununla belə, SELinux standart olaraq konteynerlərin bunu etməsinə mane olur. Yazmağa icazə vermək üçün container_manage_cgroup boolean parametrini aktivləşdirin:
setsebool -P container_manage_cgroup doğrudur
İndi Podman istifadə edərək konteynerdə systemd işlətmək üçün Dockerfile-nin necə göründüyünə baxın:
# cat Dockerfile
FROM fedora
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd
EXPOSE 80
CMD [ "/sbin/init" ]
Hamısı budur.
İndi konteyneri toplayırıq:
# podman build -t systemd .
SELinux-a deyin ki, systemd-ə Cgroups konfiqurasiyasını dəyişməyə icazə versin:
# setsebool -P container_manage_cgroup true
Yeri gəlmişkən, çoxları bu addımı unudurlar. Xoşbəxtlikdən, bunu yalnız bir dəfə etmək kifayətdir və sistemin yenidən başlamasından sonra parametr saxlanılır.
İndi konteynerə başlayırıq:
# 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.
Budur, xidmət işləyir və işləyir:
$ curl localhost
<html xml_lang="en" lang="en">
…
</html>
QEYD: Bunu Docker-də sınamayın! Bu cür qabları cindən keçirtmək üçün hələ də dəflə rəqs etmək lazımdır. (Bu işi Docker-də qüsursuz etmək üçün əlavə sahələr və paketlər tələb olunacaq və ya o, imtiyazlı konteynerdə işlədilməlidir. Təfərrüatlara baxın .)
Podman və systemd haqqında daha bir neçə gözəl şey
Podman sistem vahid fayllarında Docker-dən daha yaxşı işləyir
Sistemin açılışında konteynerlərin işə salınması lazımdırsa, o zaman sadəcə olaraq sistem vahidi faylına müvafiq Podman əmrlərini daxil edə bilərsiniz, bu da xidməti işə salacaq və ona nəzarət edəcək. Podman standart fork-exec modelindən istifadə edir. Başqa sözlə, konteyner prosesləri Podman prosesinin uşaqlarıdır, ona görə də systemd onları asanlıqla izləyə bilər.
Docker müştəri-server modelindən istifadə edir və Docker CLI əmrləri də birbaşa vahid faylına yerləşdirilə bilər. Bununla belə, Docker müştərisi Docker demonuna qoşulduqdan sonra o (müştəri) stdin və stdout ilə işləyən başqa bir prosesə çevrilir. Öz növbəsində, systemd-nin Docker müştərisi ilə Docker demonunu işlədən konteyner arasındakı əlaqə haqqında heç bir təsəvvürü yoxdur və buna görə də bu model çərçivəsində systemd prinsipcə xidmətə nəzarət edə bilməz.
Sistemin rozetka vasitəsilə aktivləşdirilməsi
Podman rozetkanın aktivləşdirilməsini düzgün idarə edir. Podman fork-exec modelindən istifadə etdiyi üçün rozetkanı uşaq konteyner proseslərinə yönləndirə bilər. Docker bunu edə bilməz, çünki o, müştəri-server modelindən istifadə edir.
Podmanın uzaq müştərilərin konteynerlərlə əlaqə saxlamasına imkan vermək üçün istifadə etdiyi varlink xidməti əslində rozetka üzərindən işə salınır. Node.js-də yazılmış və kokpit layihəsinin bir hissəsi olan kokpit-podman paketi insanlara veb interfeysi vasitəsilə Podman konteynerləri ilə əlaqə saxlamağa imkan verir. Kokpit-podman ilə işləyən veb demon, sistemin dinlədiyi varlink yuvasına mesajlar göndərir. Systemd daha sonra mesajları qəbul etmək və konteynerləri idarə etməyə başlamaq üçün Podman proqramını aktivləşdirir. rozetka üzərindən systemd-nin aktivləşdirilməsi uzaq API-ləri həyata keçirərkən daimi işləyən bir demon ehtiyacını aradan qaldırır.
Eyni Podman CLI-ni tətbiq edən, lakin konteynerləri işə salmaq üçün varlink çağıran podman-remote adlı başqa bir Podman müştərisini də inkişaf etdiririk. Podman-uzaqdan idarəsi SSH seanslarının üstündə işləyə bilər ki, bu da müxtəlif maşınlardakı konteynerlərlə təhlükəsiz əlaqə saxlamağa imkan verir. Zaman keçdikcə Linux ilə yanaşı MacOS və Windows-u dəstəkləmək üçün podman-remote-dan istifadə etməyi planlaşdırırıq ki, həmin platformalardakı tərtibatçılar Podman varlink ilə işləyən Linux virtual maşını işlətsin və konteynerlərin yerli maşında işlədiyini tam hiss etsinlər.
SD_NOTIFY
Systemd sizə lazım olan konteynerləşdirilmiş xidmət başlayana qədər köməkçi xidmətlərin başlamasını gecikdirməyə imkan verir. Podman SD_NOTIFY soketini konteynerləşdirilmiş xidmətə yönləndirə bilər ki, xidmət getməyə hazır olduğunu sistemə bildirsin. Və yenə də müştəri-server modelindən istifadə edən Docker necə olduğunu bilmir.
Planlarda
Verilmiş konteyneri idarə etmək üçün sistem vahid faylı yaradacaq podman generasiya sistemli CONTAINERID əmrini əlavə etməyi planlaşdırırıq. Bu, imtiyazsız konteynerlər üçün həm kök, həm də köksüz rejimlərdə işləməlidir. Biz hətta OCI uyğun sistemd-nspawn işləmə vaxtı üçün sorğu gördük.
Nəticə
Konteynerdə systemd işlətmək başa düşülən bir ehtiyacdır. Və Podman sayəsində, nəhayət, systemd-ə zidd olmayan, lakin istifadəsini asanlaşdıran bir konteyner işləmə vaxtı var.
Mənbə: www.habr.com