ProHoster > Blogs > Administrācija > Darbojas sistēmā konteinerā

Darbojas sistēmā konteinerā

Tēmai par systemd lietoÅ”anu konteineros sekojam lÄ«dzi jau ilgu laiku. 2014. gadā mÅ«su droŔības inženieris Daniels VolÅ”s uzrakstÄ«ja rakstu Darbojas sistēma Docker konteinerā, un pāris gadus vēlāk - vēl viens, kas saucās Darbojas systemd priviliģētā konteinerā, kurā viņŔ norādÄ«ja, ka situācija nav Ä«paÅ”i uzlabojusies. Jo Ä«paÅ”i viņŔ rakstÄ«ja, ka "diemžēl pat divus gadus vēlāk, ja jÅ«s Google meklējat "Docker system", pirmais, kas parādās, ir viņa vecais raksts. Tāpēc ir pienācis laiks kaut ko mainÄ«t." Turklāt mēs jau runājām par konflikts starp Docker un sistēmas izstrādātājiem.

Darbojas sistēmā konteinerā

Å ajā rakstā mēs parādÄ«sim, kas laika gaitā ir mainÄ«jies un kā Podman var mums palÄ«dzēt Å”ajā jautājumā.

Ir daudz iemeslu, lai palaistu sistēmu konteinerā, piemēram:

  1. Daudzpakalpojumu konteineri ā€“ daudzi cilvēki vēlas izņemt savas daudzpakalpojumu lietojumprogrammas no virtuālajām maŔīnām un palaist tās konteineros. Protams, labāk bÅ«tu sadalÄ«t Ŕādas lietojumprogrammas mikropakalpojumos, taču ne visi vēl zina, kā to izdarÄ«t, vai vienkārÅ”i nav laika. Tāpēc ir pilnÄ«gi saprātÄ«gi palaist Ŕādas lietojumprogrammas kā pakalpojumus, ko systemd palaida no vienÄ«bas failiem.
  2. Sistēmas vienÄ«bas faili - Lielākā daļa lietojumprogrammu, kas darbojas konteineros, ir veidotas no koda, kas iepriekÅ” darbojās virtuālajās vai fiziskās maŔīnās. Å Ä«m lietojumprogrammām ir vienÄ«bas fails, kas ir rakstÄ«ts Ŕīm lietojumprogrammām un saprot, kā tās ir jāpalaiž. Tāpēc joprojām ir labāk sākt pakalpojumus, izmantojot atbalstÄ«tas metodes, nevis uzlauzt savu sākuma pakalpojumu.
  3. Systemd ir procesu vadÄ«tājs. Tas pārvalda pakalpojumus (izslēdzas, restartē pakalpojumus vai nogalina zombiju procesus) labāk nekā jebkurÅ” cits rÄ«ks.

Tas nozÄ«mē, ka ir daudz iemeslu nedarbināt systemd konteineros. Galvenais ir tas, ka systemd/journald kontrolē konteineru un lÄ«dzÄ«gu rÄ«ku izvadi Kubernetes vai openshift sagaidāms, ka konteineri ierakstÄ«s žurnālu tieÅ”i stdout un stderr. Tāpēc, ja plānojat pārvaldÄ«t konteinerus, izmantojot tādus orÄ·estrÄ“Å”anas rÄ«kus kā iepriekÅ” minētie, jums nopietni jāapsver uz systemd balstÄ«tu konteineru izmantoÅ”ana. Turklāt Docker un Moby izstrādātāji bieži vien ir stingri iebilduÅ”i pret systemd izmantoÅ”anu konteineros.

Podmena atnākŔana

Mēs esam priecÄ«gi ziņot, ka situācija beidzot ir virzÄ«jusies uz priekÅ”u. Komanda, kas atbild par konteineru ekspluatāciju uzņēmumā Red Hat, nolēma attÄ«stÄ«ties savs konteinera dzinējs. ViņŔ ieguva vārdu Podmans un piedāvā tādu paÅ”u komandrindas interfeisu (CLI) kā Docker. Un gandrÄ«z visas Docker komandas Podman var izmantot tādā paŔā veidā. Mēs bieži vadām seminārus, kurus tagad sauc par Docker maiņa uz Podman, un pats pirmais slaids aicina rakstÄ«t: alias docker=podman.

Daudzi cilvēki to dara.

Mans Podmans un es nekādā gadÄ«jumā neesam pret uz systemd balstÄ«tiem konteineriem. Galu galā Systemd ir visbiežāk izmantotā Linux sākumsistēmas apakÅ”sistēma, un neļaut tai pareizi darboties konteineros, tas nozÄ«mē ignorēt to, kā tÅ«kstoÅ”iem cilvēku ir pieraduÅ”i darbināt konteinerus.

Podman zina, kas jādara, lai sistēma pareizi darbotos konteinerā. Tam ir vajadzÄ«gas tādas lietas kā tmpfs uzstādÄ«Å”ana uz /run un /tmp. Viņai patÄ«k, ja ir iespējota "konteineru" vide, un viņa sagaida rakstÄ«Å”anas atļaujas savai cgroup direktorija daļai un mapei /var/log/journald.

Kad startējat konteineru, kurā pirmā komanda ir init vai systemd, Podman automātiski konfigurē tmpfs un Cgroups, lai nodroÅ”inātu, ka systemd tiek palaists bez problēmām. Lai bloķētu Å”o automātiskās palaiÅ”anas režīmu, izmantojiet opciju --systemd=false. LÅ«dzu, ņemiet vērā, ka Podman izmanto systemd režīmu tikai tad, ja redz, ka tai ir jāpalaiž systemd vai init komanda.

Šeit ir izvilkums no rokasgrāmatas:

cilvēks podman palaist
...

ā€“systemd=true|false

Konteinera palaiÅ”ana systemd režīmā. Iespējots pēc noklusējuma.

Ja palaižat systemd vai init komandu konteinerā, Podman konfigurēs tmpfs pievienoÅ”anas punktus Ŕādos direktorijos:

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

ArÄ« noklusējuma apturÄ“Å”anas signāls bÅ«s SIGRTMIN+3.

Tas viss ļauj systemd darboties slēgtā konteinerā bez jebkādām izmaiņām.

PIEZÄŖME: systemd mēģina rakstÄ«t cgroup failu sistēmā. Tomēr SELinux neļauj konteineriem to darÄ«t pēc noklusējuma. Lai iespējotu rakstÄ«Å”anu, iespējojiet BÅ«la parametru container_manage_cgroup:

setsebool -P container_manage_cgroup true

Tagad apskatiet, kā izskatās Dockerfile, lai palaistu systemd konteinerā, izmantojot Podman:

# cat Dockerfile

FROM fedora

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

EXPOSE 80

CMD [ "/sbin/init" ]

Tas ir viss.

Tagad mēs saliekam konteineru:

# podman build -t systemd .

Mēs sakām SELinux, lai ļautu systemd modificēt Cgroups konfigurāciju:

# setsebool -P container_manage_cgroup true

Starp citu, daudzi cilvēki aizmirst par Å”o soli. Par laimi, tas ir jādara tikai vienu reizi, un iestatÄ«jums tiek saglabāts pēc sistēmas pārstartÄ“Å”anas.

Tagad mēs vienkārÅ”i sākam konteineru:

# 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.

Tas ir viss, pakalpojums ir izveidots un darbojas:

$ curl localhost

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

ā€¦

</html>

PIEZÄŖME. Nemēģiniet to lietot Docker! Tur jums joprojām ir jādejo ar tamburÄ«nu, lai palaistu Ŕāda veida konteinerus caur dēmonu. (Lai tas viss darbotos nevainojami programmā Docker, bÅ«s nepiecieÅ”ami papildu lauki un pakotnes, vai arÄ« tas bÅ«s jāpalaiž priviliģētā konteinerā. PlaŔāku informāciju skatiet sadaļā raksts.)

Vēl dažas interesantas lietas par Podman un systemd

Podman darbojas labāk nekā Docker sistēmas vienību failos

Ja konteineri ir jāuzsāk sistēmas sāknÄ“Å”anas laikā, varat vienkārÅ”i ievietot atbilstoŔās Podman komandas systemd vienÄ«bas failā, kas sāks pakalpojumu un uzraudzÄ«s to. Podman izmanto standarta fork-exec modeli. Citiem vārdiem sakot, konteineru procesi ir Podman procesa atvases, tāpēc systemd tos var viegli pārraudzÄ«t.

Docker izmanto klienta-servera modeli, un Docker CLI komandas var arÄ« ievietot tieÅ”i vienÄ«bas failā. Tomēr, tiklÄ«dz Docker klients izveido savienojumu ar Docker dēmonu, tas (klients) kļūst tikai par vēl vienu procesa apstrādes stdin un stdout. Savukārt systemd nav ne jausmas par savienojumu starp Docker klientu un konteineru, kas darbojas Docker dēmona kontrolē, un tāpēc Ŕī modeļa ietvaros systemd fundamentāli nevar pārraudzÄ«t pakalpojumu.

Sistēmas aktivizÄ“Å”ana caur kontaktligzdu

Podman pareizi apstrādā aktivizÄ“Å”anu, izmantojot ligzdu. Tā kā Podman izmanto modeli fork-exec, tas var pārsÅ«tÄ«t ligzdu saviem pakārtotajiem konteineru procesiem. Docker to nevar izdarÄ«t, jo tas izmanto klienta-servera modeli.

Varlink pakalpojums, ko Podman izmanto, lai sazinātos ar attāliem klientiem uz konteineriem, faktiski tiek aktivizēts, izmantojot ligzdu. Cockpit-podman pakotne, kas rakstÄ«ta Node.js un ir daļa no kabÄ«nes projekta, ļauj cilvēkiem mijiedarboties ar Podman konteineriem, izmantojot tÄ«mekļa saskarni. TÄ«mekļa dēmons, kurā darbojas kabÄ«nes-podman, nosÅ«ta ziņojumus uz varlink ligzdu, kuru systemd klausās. Pēc tam Systemd aktivizē programmu Podman, lai saņemtu ziņojumus un sāktu pārvaldÄ«t konteinerus. Systemd aktivizÄ“Å”ana, izmantojot ligzdu, novērÅ” nepiecieÅ”amÄ«bu pēc pastāvÄ«gi strādājoÅ”a dēmona, ievieÅ”ot attālās API.

Turklāt mēs izstrādājam citu Podman klientu ar nosaukumu podman-remote, kas ievieÅ” to paÅ”u Podman CLI, bet izsauc varlink, lai palaistu konteinerus. Podman-tālvadÄ«bas pults var darboties papildus SSH sesijām, ļaujot droÅ”i mijiedarboties ar konteineriem dažādās iekārtās. Laika gaitā mēs plānojam iespējot podman-remote, lai atbalstÄ«tu MacOS un Windows kopā ar Linux, lai Å”o platformu izstrādātāji varētu palaist Linux virtuālo maŔīnu, kurā darbojas Podman varlink, un gÅ«t pilnu pieredzi, ka konteineri darbojas vietējā datorā.

SD_NOTIFY

Systemd ļauj atlikt palÄ«gpakalpojumu palaiÅ”anu, lÄ«dz sākas tiem nepiecieÅ”amais konteinerizētais pakalpojums. Podman var pārsÅ«tÄ«t SD_NOTIFY ligzdu konteinerizētajam pakalpojumam, lai pakalpojums paziņotu sistēmai, ka tas ir gatavs darbam. Un atkal, Docker, kas izmanto klienta-servera modeli, to nevar izdarÄ«t.

Plānos

Mēs plānojam pievienot komandu podman generate systemd CONTAINERID, kas Ä£enerēs systemd vienÄ«bas failu, lai pārvaldÄ«tu konkrētu norādÄ«to konteineru. Tam vajadzētu darboties gan saknes, gan bezsakņu režīmā nepieŔķirtiem konteineriem. Mēs pat esam redzējuÅ”i pieprasÄ«jumu pēc OCI saderÄ«ga systemd-nspawn izpildlaika.

Secinājums

Systemd darbināŔana konteinerā ir saprotama nepiecieŔamība. Pateicoties Podman, mums beidzot ir konteinera izpildlaiks, kas nav pretrunā ar systemd, bet padara to viegli lietojamu.

Avots: www.habr.com

Pievieno komentāru