სისტემური გაშვება კონტეინერში

უკვე დიდი ხანია ვაკვირდებით systemd-ის კონტეინერებში გამოყენების თემას. ჯერ კიდევ 2014 წელს, ჩვენმა უსაფრთხოების ინჟინერმა დანიელ უოლშმა დაწერა სტატია სისტემური გაშვება Docker Container-ში, და ორიოდე წლის შემდეგ - მეორე, რომელსაც ე.წ სისტემური გაშვება არაპრივილეგირებულ კონტეინერში, რომელშიც მან განაცხადა, რომ მდგომარეობა დიდად არ გაუმჯობესებულა. კერძოდ, მან დაწერა, რომ „სამწუხაროდ, ორი წლის შემდეგაც კი, თუ Google-ში „Docker system“-ს დაათვალიერებთ, პირველი, რაც გამოვა, არის მისი ძველი სტატია. ასე რომ, დროა რაღაცის შეცვლა. ” გარდა ამისა, ჩვენ უკვე ვისაუბრეთ კონფლიქტი Docker-სა და systemd დეველოპერებს შორის.

ამ სტატიაში ჩვენ გაჩვენებთ, რა შეიცვალა დროთა განმავლობაში და როგორ დაგვეხმარება პოდმანი ამ საკითხში.

არსებობს მრავალი მიზეზი კონტეინერში სისტემის გასაშვებად, როგორიცაა:

1. მულტისერვისის კონტეინერები – ბევრ ადამიანს სურს ამოიღოს თავისი მრავალსერვისიანი აპლიკაციები ვირტუალური მანქანებიდან და გაუშვას ისინი კონტეინერებში. უკეთესი იქნებოდა, რა თქმა უნდა, ასეთი აპლიკაციების მიკროსერვისებად დაყოფა, მაგრამ ყველამ არ იცის როგორ გააკეთოს ეს ჯერ ან უბრალოდ არ აქვს დრო. ამიტომ, ისეთი აპლიკაციების გაშვება, როგორიცაა სერვისები, რომლებიც გაშვებულია systemd-ის მიერ ერთეული ფაილებიდან, სრულიად აზრიანია.
2. სისტემური ერთეული ფაილები – კონტეინერებში გაშვებული აპლიკაციების უმეტესობა აგებულია კოდისგან, რომელიც ადრე მუშაობდა ვირტუალურ ან ფიზიკურ მანქანებზე. ამ აპლიკაციებს აქვთ ერთეული ფაილი, რომელიც დაიწერა ამ აპლიკაციებისთვის და ესმის, როგორ უნდა მოხდეს მათი გაშვება. ასე რომ, მაინც უკეთესია სერვისების დაწყება მხარდაჭერილი მეთოდების გამოყენებით, ვიდრე საკუთარი init სერვისის გატეხვა.
3. Systemd არის პროცესის მენეჯერი. ის მართავს სერვისებს (თიშავს, განაახლებს სერვისებს ან კლავს ზომბების პროცესებს) უკეთესად, ვიდრე ნებისმიერი სხვა ინსტრუმენტი.

ამის თქმით, არსებობს მრავალი მიზეზი, რომ სისტემა არ იმუშაოს კონტეინერებში. მთავარი ის არის, რომ systemd/journald აკონტროლებს კონტეინერების გამომავალს და მსგავს ინსტრუმენტებს კუბერნეტები ან openshift ველით, რომ კონტეინერებმა ჩაწერონ ჟურნალი პირდაპირ stdout-სა და stderr-ზე. ამიტომ, თუ თქვენ აპირებთ კონტეინერების მართვას ზემოთ ნახსენები საორკესტრო ინსტრუმენტების მეშვეობით, სერიოზულად უნდა იფიქროთ სისტემაზე დაფუძნებული კონტეინერების გამოყენებაზე. გარდა ამისა, Docker და Moby დეველოპერები ხშირად კატეგორიულად ეწინააღმდეგებოდნენ systemd-ის გამოყენებას კონტეინერებში.

პოდმანის მოსვლა

მოხარულნი ვართ შეგატყობინოთ, რომ სიტუაცია საბოლოოდ წინ წავიდა. Red Hat-ში კონტეინერების გაშვებაზე პასუხისმგებელმა გუნდმა გადაწყვიტა განვითარება თქვენი საკუთარი კონტეინერის ძრავა. მან მიიღო სახელი პოდმანი და გთავაზობთ იგივე ბრძანების ხაზის ინტერფეისს (CLI), როგორც Docker. და თითქმის ყველა Docker ბრძანება შეიძლება გამოყენებულ იქნას Podman-ში იმავე გზით. ხშირად ვატარებთ სემინარებს, რომლებსაც ახლა ე.წ დოკერის შეცვლა პოდმანზე, და პირველივე სლაიდი მოითხოვს დაწერას: alias docker=podman.

ბევრი ადამიანი აკეთებს ამას.

მე და ჩემი Podman არანაირად არ ვართ წინააღმდეგი სისტემაზე დაფუძნებული კონტეინერების. ყოველივე ამის შემდეგ, Systemd არის ყველაზე ხშირად გამოყენებული Linux init ქვესისტემა და არ დაუშვათ მას სწორად იმუშაოს კონტეინერებში, ნიშნავს იგნორირებას, თუ როგორ არის ათასობით ადამიანი მიჩვეული კონტეინერების გაშვებას.

პოდმანმა იცის რა უნდა გააკეთოს იმისათვის, რომ სისტემამ სწორად იმუშაოს კონტეინერში. მას სჭირდება ისეთი რამ, როგორიცაა tmpfs-ის დაყენება /run-ზე და /tmp-ზე. მას მოსწონს "კონტეინერიზებული" გარემოს ჩართვა და ელის ჩაწერის ნებართვებს cgroup დირექტორიაში და /var/log/journald საქაღალდეში.

როდესაც იწყებთ კონტეინერს, რომელშიც პირველი ბრძანება არის init ან systemd, Podman ავტომატურად აკონფიგურირებს tmpfs და Cgroups-ს, რათა უზრუნველყოს, რომ systemd იწყება უპრობლემოდ. ამ ავტომატური გაშვების რეჟიმის დასაბლოკად გამოიყენეთ --systemd=false ვარიანტი. გთხოვთ გაითვალისწინოთ, რომ Podman იყენებს systemd რეჟიმს მხოლოდ მაშინ, როდესაც ხედავს, რომ მას სჭირდება systemd ან init ბრძანების გაშვება.

აქ არის ამონარიდი სახელმძღვანელოდან:

კაცი პოდმენის გაშვება
...

–systemd=true|false

კონტეინერის გაშვება სისტემურ რეჟიმში. ნაგულისხმევად ჩართულია.

თუ თქვენ აწარმოებთ 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 unit ფაილში, რომელიც დაიწყებს სერვისს და მონიტორინგს გაუწევს მას. Podman იყენებს სტანდარტული fork-exec მოდელს. სხვა სიტყვებით რომ ვთქვათ, კონტეინერის პროცესები პოდმანის პროცესის ბავშვებია, ამიტომ systemd-ს შეუძლია ადვილად გააკონტროლოს ისინი.

Docker იყენებს კლიენტ-სერვერის მოდელს და Docker CLI ბრძანებები ასევე შეიძლება განთავსდეს პირდაპირ ერთეულ ფაილში. თუმცა, როგორც კი Docker კლიენტი დაუკავშირდება Docker daemon-ს, ის (კლიენტი) ხდება კიდევ ერთი პროცესის დამუშავება stdin და stdout. თავის მხრივ, systemd-ს არ აქვს წარმოდგენა Docker კლიენტსა და კონტეინერს შორის კავშირის შესახებ, რომელიც მუშაობს Docker daemon-ის კონტროლის ქვეშ და, შესაბამისად, ამ მოდელის ფარგლებში, systemd-ს ფუნდამენტურად არ შეუძლია სერვისის მონიტორინგი.

სისტემის გააქტიურება სოკეტის საშუალებით

პოდმანი სწორად ამუშავებს ჩართვას სოკეტის საშუალებით. იმის გამო, რომ Podman იყენებს fork-exec მოდელს, მას შეუძლია გადააგზავნოს სოკეტი მისი შვილობილი კონტეინერის პროცესებში. Docker-ს არ შეუძლია ამის გაკეთება, რადგან ის იყენებს კლიენტ-სერვერის მოდელს.

varlink სერვისი, რომელსაც Podman იყენებს დისტანციურ კლიენტებთან კონტეინერებთან კომუნიკაციისთვის, რეალურად გააქტიურებულია სოკეტის საშუალებით. Cockpit-podman-ის პაკეტი, რომელიც დაწერილია Node.js-ში და კაბინის პროექტის ნაწილია, საშუალებას აძლევს ადამიანებს დაუკავშირდნენ Podman კონტეინერებს ვებ ინტერფეისის საშუალებით. ვებ დემონი, რომელიც მუშაობს სალონში, აგზავნის შეტყობინებებს varlink სოკეტში, რომელსაც სისტემა უსმენს. ამის შემდეგ Systemd ააქტიურებს Podman პროგრამას, რათა მიიღოს შეტყობინებები და დაიწყოს კონტეინერების მართვა. სოკეტზე systemd-ის გააქტიურება გამორიცხავს მუდმივად გაშვებული დემონის საჭიროებას დისტანციური API-ების დანერგვისას.

გარდა ამისა, ჩვენ ვამუშავებთ სხვა Podman კლიენტს სახელწოდებით podman-remote, რომელიც ახორციელებს იგივე Podman CLI-ს, მაგრამ უწოდებს varlink-ს კონტეინერების გასაშვებად. Podman-დისტანციური პულტი შეიძლება იმუშაოს SSH სესიების თავზე, რაც საშუალებას მოგცემთ უსაფრთხოდ დაუკავშირდეთ კონტეინერებს სხვადასხვა მანქანებზე. დროთა განმავლობაში, ჩვენ ვგეგმავთ გავააქტიუროთ პოდმენის დისტანციური მართვა MacOS-ისა და Windows-ის მხარდასაჭერად Linux-თან ერთად, რათა ამ პლატფორმებზე დეველოპერებმა შეძლონ Linux-ის ვირტუალური მანქანა გაშვებული Podman varlink-ით და ჰქონდეთ სრული გამოცდილება, რომ კონტეინერები მუშაობს ადგილობრივ აპარატზე.

SD_NOTIFY

Systemd გაძლევთ საშუალებას გადადოთ დამხმარე სერვისების გაშვება მანამ, სანამ არ დაიწყება მათთვის საჭირო კონტეინერირებული სერვისი. Podman-ს შეუძლია გადააგზავნოს SD_NOTIFY სოკეტი კონტეინერიზებულ სერვისში, რათა სერვისმა აცნობოს სისტემას, რომ ის მზად არის ფუნქციონირებისთვის. და კიდევ, Docker, რომელიც იყენებს კლიენტ-სერვერის მოდელს, ამას არ შეუძლია.

გეგმებში

ჩვენ ვგეგმავთ დავამატოთ ბრძანება podman generate systemd CONTAINERID, რომელიც გამოიმუშავებს systemd unit ფაილს მითითებული კონკრეტული კონტეინერის სამართავად. ეს უნდა იმუშაოს როგორც root, ასევე rootless რეჟიმში არაპრივილეგირებული კონტეინერებისთვის. ჩვენ ვნახეთ მოთხოვნა OCI-თან თავსებადი systemd-nspawn გაშვების დროის შესახებ.

დასკვნა

კონტეინერში სისტემური გაშვება გასაგები საჭიროებაა. და Podman-ის წყალობით, ჩვენ საბოლოოდ გვაქვს კონტეინერის გაშვების დრო, რომელიც არ ეწინააღმდეგება systemd-ს, მაგრამ აადვილებს გამოყენებას.

წყარო: www.habr.com