რეკომენდაციები Buildah-ის კონტეინერში გაშვებისთვის

რა სილამაზეა კონტეინერის მუშაობის დროის ცალკე ინსტრუმენტების კომპონენტებად დაყოფა? კერძოდ, ამ ინსტრუმენტების გაერთიანება შეიძლება დაიწყოს ისე, რომ ისინი დაიცვან ერთმანეთი.

ბევრ ადამიანს იზიდავს კონტეინერირებული OCI სურათების შიგნით აშენების იდეა კუბერნეტები ან მსგავსი სისტემა. ვთქვათ, გვაქვს CI/CD, რომელიც მუდმივად აგროვებს სურათებს, შემდეგ რაღაც მსგავსს Red Hat OpenShift/Kubernetes საკმაოდ გამოსადეგი იქნებოდა დატვირთვის დაბალანსების თვალსაზრისით აშენების დროს. ბოლო დრომდე, ადამიანების უმეტესობა უბრალოდ აძლევდა კონტეინერებს Docker სოკეტზე წვდომას და საშუალებას აძლევდა მათ გაეტარებინათ docker build ბრძანება. რამდენიმე წლის წინ ვაჩვენეთრომ ეს ძალიან დაუცველია, ფაქტობრივად, ეს კიდევ უფრო უარესია, ვიდრე პაროლის გარეშე root ან სუდოს მიცემა.

ამიტომაც ადამიანები მუდმივად ცდილობენ Buildah-ს კონტეინერში გაშვებას. მოკლედ, ჩვენ შევქმენით მაგალითად ჩვენი აზრით, როგორ ჯობია Buildah-ის კონტეინერში გაშვება და შესაბამისი სურათების გამოქვეყნება quay.io/buildah. Დავიწყოთ...

რეგულირება

ეს სურათები აგებულია Dockerfiles-დან, რომელიც შეგიძლიათ იხილოთ საქაღალდეში Buildah საცავში აშენება.
აქ განვიხილავთ Dockerfile-ის სტაბილური ვერსია.

# stable/Dockerfile
#
# Build a Buildah container image from the latest
# stable version of Buildah on the Fedoras Updates System.
# https://bodhi.fedoraproject.org/updates/?search=buildah
# This image can be used to create a secured container
# that runs safely with privileges within the container.
#
FROM fedora:latest

# Don't include container-selinux and remove
# directories used by dnf that are just taking
# up space.
RUN yum -y install buildah fuse-overlayfs --exclude container-selinux; rm -rf /var/cache /var/log/dnf* /var/log/yum.*

# Adjust storage.conf to enable Fuse storage.
RUN sed -i -e 's|^#mount_program|mount_program|g' -e '/additionalimage.*/a "/var/lib/shared",' /etc/containers/storage.conf

OverlayFS-ის ნაცვლად, რომელიც განხორციელებულია მასპინძელი Linux-ის ბირთვის დონეზე, ჩვენ ვიყენებთ პროგრამას კონტეინერის შიგნით დაუკრავენ-გადაფარვა, რადგან ამჟამად OverlayFS-ის დამონტაჟება შესაძლებელია მხოლოდ იმ შემთხვევაში, თუ მისცემთ SYS_ADMIN ნებართვას Linux-ის შესაძლებლობების გამოყენებით. და ჩვენ გვინდა გავატაროთ ჩვენი Buildah კონტეინერები root პრივილეგიების გარეშე. Fuse-overlay მუშაობს საკმაოდ სწრაფად და აქვს უკეთესი შესრულება, ვიდრე VFS შენახვის დრაივერი. გთხოვთ, გაითვალისწინოთ, რომ Buildah კონტეინერის გაშვებისას, რომელიც იყენებს Fuse-ს, თქვენ უნდა მიაწოდოთ /dev/fuse მოწყობილობა.

podman run --device /dev/fuse quay.io/buildahctr ...
RUN mkdir -p /var/lib/shared/overlay-images /var/lib/shared/overlay-layers; touch /var/lib/shared/overlay-images/images.lock; touch /var/lib/shared/overlay-layers/layers.lock

შემდეგ ჩვენ ვქმნით დირექტორიას დამატებითი შენახვისთვის. კონტეინერი/შენახვა მხარს უჭერს დამატებითი მხოლოდ წასაკითხი სურათების მაღაზიების დაკავშირების კონცეფციას. მაგალითად, შეგიძლიათ დააკონფიგურიროთ გადაფარვის საცავის არე ერთ მანქანაზე და შემდეგ გამოიყენოთ NFS ამ საცავი სხვა მოწყობილობაზე დასამონტაჟებლად და მისგან გამოსახულების გამოყენება ჩამოტვირთვის გარეშე. ჩვენ გვჭირდება ეს საცავი, რათა შევძლოთ ჰოსტისგან ზოგიერთი სურათის საცავი დავაკავშიროთ როგორც მოცულობა და გამოვიყენოთ იგი კონტეინერის შიგნით.

# Set up environment variables to note that this is
# not starting with user namespace and default to
# isolate the filesystem with chroot.
ENV _BUILDAH_STARTED_IN_USERNS="" BUILDAH_ISOLATION=chroot

დაბოლოს, BUILDAH_ISOLATION გარემოს ცვლადის გამოყენებით, ჩვენ ვეუბნებით Buildah კონტეინერს ნაგულისხმევად იმუშაოს chroot იზოლაციით. აქ დამატებითი იზოლაცია არ არის საჭირო, რადგან ჩვენ უკვე ვმუშაობთ კონტეინერში. იმისათვის, რომ Buildah-მა შექმნას საკუთარი სახელების სივრცით გამოყოფილი კონტეინერები, საჭიროა SYS_ADMIN პრივილეგია, რომელიც მოითხოვს კონტეინერის SELinux-ისა და SECCOMP-ის წესების მოდუნებას, რაც ეწინააღმდეგება უსაფრთხო კონტეინერისგან აშენების ჩვენს უპირატესობას.

Buildah-ის გაშვება კონტეინერში

ზემოთ განხილული Buildah კონტეინერის გამოსახულების დიაგრამა საშუალებას გაძლევთ მოქნილად შეცვალოთ ასეთი კონტეინერების გაშვების მეთოდები.

სიჩქარე უსაფრთხოების წინააღმდეგ

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

ზემოთ განხილული კონტეინერის სურათი ინახავს მის შენახვას /var/lib/containers-ში. ამიტომ, ჩვენ უნდა დავამონტაჟოთ კონტენტი ამ საქაღალდეში და როგორ ვაკეთებთ ამას დიდ გავლენას მოახდენს კონტეინერის სურათების აგების სიჩქარეზე.

განვიხილოთ სამი ვარიანტი.

1 ვარიანტი. თუ მაქსიმალური უსაფრთხოებაა საჭირო, მაშინ თითოეული კონტეინერისთვის შეგიძლიათ შექმნათ თქვენი საკუთარი საქაღალდე კონტეინერებისთვის/გამოსახულებისთვის და დააკავშიროთ იგი კონტეინერთან volume-mount-ის საშუალებით. გარდა ამისა, მოათავსეთ კონტექსტური დირექტორია თავად კონტეინერში, საქაღალდეში /build:

# mkdir /var/lib/containers1
# podman run -v ./build:/build:z -v /var/lib/containers1:/var/lib/containers:Z quay.io/buildah/stable
buildah  -t image1 bud /build
# podman run -v /var/lib/containers1:/var/lib/containers:Z quay.io/buildah/stable buildah  push  image1 registry.company.com/myuser
# rm -rf /var/lib/containers1

უსაფრთხოება ასეთ კონტეინერში გაშვებულ Buildah-ს აქვს მაქსიმალური უსაფრთხოება: მას არ ენიჭება root პრივილეგიები შესაძლებლობების გამოყენებით და მასზე ვრცელდება ყველა SECOMP და SELinux შეზღუდვა. ასეთი კონტეინერის გაშვება შესაძლებელია მომხმარებლის სახელების სივრცის იზოლაციითაც კი, ისეთი ოფციის დამატებით, როგორიცაა —uidmap 0: 100000:10000.

შესრულება. მაგრამ აქ შესრულება მინიმალურია, რადგან კონტეინერის რეესტრიდან ნებისმიერი სურათი ყოველ ჯერზე კოპირდება ჰოსტზე და ქეშირება საერთოდ არ მუშაობს. სამუშაოს დასრულებისას Buildah კონტეინერმა უნდა გაგზავნოს სურათი რეესტრში და გაანადგუროს კონტენტი ჰოსტზე. შემდეგ ჯერზე, როდესაც კონტეინერის სურათი აშენდება, ის კვლავ უნდა გადმოიწეროს რეესტრიდან, რადგან ამ დროისთვის ჰოსტზე აღარაფერი დარჩება.

2 ვარიანტი. თუ გჭირდებათ Docker-ის დონის შესრულება, შეგიძლიათ დაამონტაჟოთ მასპინძელი კონტეინერი/საცავი პირდაპირ კონტეინერში.

# podman run -v ./build:/build:z -v /var/lib/containers:/var/lib/containers --security-opt label:disabled quay.io/buildah/stable buildah  -t image2 bud /build
# podman run -v /var/lib/containers:/var/lib/containers --security-opt label:disabled  quay.io/buildah/stable buildah push image2 registry.company.com/myuser

უსაფრთხოება ეს არის ყველაზე ნაკლებად უსაფრთხო გზა კონტეინერების შესაქმნელად, რადგან ის საშუალებას აძლევს კონტეინერს შეცვალოს საცავი ჰოსტზე და შეიძლება პოტენციურად მიაწოდოს Podman ან CRI-O მავნე გამოსახულება. გარდა ამისა, თქვენ უნდა გამორთოთ SELinux-ის განცალკევება, რათა Buildah-ის კონტეინერში პროცესებმა შეძლონ ურთიერთქმედება ჰოსტის საცავთან. გაითვალისწინეთ, რომ ეს ვარიანტი მაინც უკეთესია, ვიდრე Docker სოკეტი, რადგან კონტეინერი დაბლოკილია უსაფრთხოების დარჩენილი ფუნქციებით და უბრალოდ არ შეუძლია კონტეინერის გაშვება მასპინძელზე.

შესრულება. აქ მაქსიმალურია, რადგან ქეშირება სრულად არის გამოყენებული. თუ Podman-მა ან CRI-O-მ უკვე ჩამოტვირთა საჭირო სურათი ჰოსტში, მაშინ კონტეინერის შიგნით Buildah პროცესს არ მოუწევს მისი ხელახლა ჩამოტვირთვა და ამ სურათზე დაფუძნებული შემდგომი ნაგებობები ასევე შეძლებენ ქეშიდან საჭიროების აღებას. .

3 ვარიანტი. ამ მეთოდის არსი არის რამდენიმე სურათის გაერთიანება ერთ პროექტში საერთო საქაღალდეში კონტეინერის სურათებისთვის.

# mkdir /var/lib/project3
# podman run --security-opt label_level=s0:C100, C200 -v ./build:/build:z 
-v /var/lib/project3:/var/lib/containers:Z quay.io/buildah/stable buildah  -t image3 bud /build
# podman run --security-opt label_level=s0:C100, C200 
-v /var/lib/project3:/var/lib/containers quay.io/buildah/stable buildah push image3  registry.company.com/myuser

ამ მაგალითში, ჩვენ არ ვშლით პროექტის საქაღალდეს (/var/lib/project3) გაშვებებს შორის, ამიტომ პროექტის ფარგლებში ყველა შემდგომი ნაგებობა სარგებლობს ქეშირებით.

უსაფრთხოება რაღაც 1 და 2 ვარიანტებს შორის. ერთის მხრივ, კონტეინერებს არ აქვთ წვდომა ჰოსტის კონტენტზე და, შესაბამისად, არ შეუძლიათ რაიმე ცუდი გადაიტანონ Podman/CRI-O გამოსახულების საცავში. მეორეს მხრივ, როგორც მისი დიზაინის ნაწილი, კონტეინერს შეუძლია ხელი შეუშალოს სხვა კონტეინერების შეკრებას.

შესრულება. აქ უფრო უარესია, ვიდრე ჰოსტის დონეზე გაზიარებული ქეშის გამოყენებისას, რადგან თქვენ არ შეგიძლიათ გამოიყენოთ სურათები, რომლებიც უკვე გადმოწერილია Podman/CRI-O-ს გამოყენებით. თუმცა, მას შემდეგ, რაც Buildah ჩამოტვირთავს სურათს, სურათის გამოყენება შესაძლებელია პროექტის ფარგლებში ნებისმიერ შემდგომ ნაგებობაში.

დამატებითი საცავი

У კონტეინერები/საცავი არსებობს ისეთი მაგარი რამ, როგორიცაა დამატებითი მაღაზიები (დამატებითი მაღაზიები), რომლის წყალობითაც კონტეინერების გაშვებისას და აშენებისას, კონტეინერის ძრავებს შეუძლიათ გამოიყენონ გარე გამოსახულების მაღაზიები მხოლოდ წაკითხვის რეჟიმში. არსებითად, თქვენ შეგიძლიათ დაამატოთ ერთი ან მეტი მხოლოდ წაკითხვადი მეხსიერება storage.conf ფაილში ისე, რომ კონტეინერის გაშვებისას, კონტეინერის ძრავა ეძებს მათში სასურველ სურათს. უფრო მეტიც, ის ჩამოტვირთავს სურათს რეესტრიდან მხოლოდ იმ შემთხვევაში, თუ ვერ იპოვის მას რომელიმე ამ საცავში. კონტეინერის ძრავას შეეძლება ჩაწეროს მხოლოდ ჩასაწერ საცავში...

თუ გადაატრიალებთ ზემოთ და უყურებთ Dockerfile-ს, რომელსაც ჩვენ ვიყენებთ გამოსახულების შესაქმნელად quay.io/buildah/stable, არის ასეთი ხაზები:

# Adjust storage.conf to enable Fuse storage.
RUN sed -i -e 's|^#mount_program|mount_program|g' -e '/additionalimage.*/a "/var/lib/shared",' /etc/containers/storage.conf
RUN mkdir -p /var/lib/shared/overlay-images /var/lib/shared/overlay-layers; touch /var/lib/shared/overlay-images/images.lock; touch /var/lib/shared/overlay-layers/layers.lock

პირველ სტრიქონში ჩვენ ვცვლით /etc/containers/storage.conf კონტეინერის გამოსახულების შიგნით და ვეუბნებით შენახვის დრაივერს გამოიყენოს "additionalimagestores" /var/lib/გაზიარებული საქაღალდეში. შემდეგ სტრიქონში ჩვენ ვქმნით გაზიარებულ საქაღალდეს და ვამატებთ რამდენიმე დაბლოკვის ფაილს ისე, რომ არ მოხდეს ბოროტად გამოყენება კონტეინერებიდან/საცავებიდან. არსებითად, ჩვენ უბრალოდ ვქმნით ცარიელი კონტეინერის სურათების მაღაზიას.

თუ თქვენ დაამონტაჟებთ კონტეინერებს/საწყობს ამ საქაღალდეზე მაღალ დონეზე, Buildah შეძლებს სურათების გამოყენებას.

ახლა დავუბრუნდეთ ზემოთ განხილულ 2 ვარიანტს, როდესაც Buildah კონტეინერს შეუძლია წაიკითხოს და ჩაწეროს კონტეინერებში/შენახოს ჰოსტებზე და, შესაბამისად, აქვს მაქსიმალური შესრულება სურათების ქეშირების გამო Podman/CRI-O დონეზე, მაგრამ უზრუნველყოფს მინიმალურ უსაფრთხოებას. მას შეუძლია ჩაწეროს პირდაპირ საცავში. ახლა მოდით დავამატოთ დამატებითი მეხსიერება აქ და მივიღოთ საუკეთესო ორივე სამყაროდან.

# mkdir /var/lib/containers4
# podman run -v ./build:/build:z -v /var/lib/containers/storage:/var/lib/shared:ro -v  /var/lib/containers4:/var/lib/containers:Z  quay.io/buildah/stable 
 buildah  -t image4 bud /build
# podman run -v /var/lib/containers/storage:/var/lib/shared:ro  
-v >/var/lib/containers4:/var/lib/containers:Z quay.io/buildah/stable buildah push image4  registry.company.com/myuser
# rm -rf /var/lib/continers4

გაითვალისწინეთ, რომ ჰოსტის /var/lib/containers/storage დამონტაჟებულია /var/lib/shared კონტეინერის შიგნით მხოლოდ წაკითხვის რეჟიმში. ამიტომ, კონტეინერში მუშაობისას, Buildah-ს შეუძლია გამოიყენოს ნებისმიერი სურათი, რომელიც ადრე იყო გადმოწერილი Podman/CRI-O-ს გამოყენებით (გამარჯობა, სიჩქარე), მაგრამ შეუძლია ჩაწეროს მხოლოდ საკუთარ საცავში (გამარჯობა, უსაფრთხოება). ასევე გაითვალისწინეთ, რომ ეს კეთდება კონტეინერისთვის SELinux-ის გამოყოფის გამორთვის გარეშე.

მნიშვნელოვანი ნიუანსი

არავითარ შემთხვევაში არ უნდა წაშალოთ რაიმე სურათი ძირითადი საცავიდან. წინააღმდეგ შემთხვევაში, Buildah კონტეინერი შეიძლება ჩამოვარდეს.

და ეს არ არის ყველა უპირატესობა

დამატებითი შენახვის შესაძლებლობები არ შემოიფარგლება ზემოაღნიშნული სცენარით. მაგალითად, შეგიძლიათ განათავსოთ კონტეინერის ყველა სურათი საერთო ქსელის საცავში და მისცეთ მასზე წვდომა Buildah-ის ყველა კონტეინერზე. ვთქვათ, გვაქვს ასობით სურათი, რომელსაც ჩვენი CI/CD სისტემა რეგულარულად იყენებს კონტეინერის სურათების შესაქმნელად. ჩვენ ვაკონცენტრირებთ ყველა ამ სურათს ერთ საცავის ჰოსტზე და შემდეგ, სასურველი ქსელის შენახვის ხელსაწყოების გამოყენებით (NFS, Gluster, Ceph, ISCSI, S3...), ჩვენ ვხსნით ზოგად წვდომას ამ საცავზე ყველა Buildah ან Kubernetes კვანძზე.

ახლა საკმარისია ამ ქსელის საცავი დაამონტაჟოთ Buildah-ის კონტეინერში /var/lib/shared და ეს არის - Buildah-ის კონტეინერებს აღარ სჭირდებათ სურათების ჩამოტვირთვა pull-ის საშუალებით. ამრიგად, ჩვენ გამოვყრით წინასწარ პოპულაციის ფაზას და მაშინვე მზად ვართ კონტეინერების გასაშლელად.

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

კონტეინერის გამოსახულებები ზოგჯერ შეიძლება მიაღწიოს ბევრ გიგაბაიტს. დამატებითი შენახვის ფუნქციონირება საშუალებას გაძლევთ თავიდან აიცილოთ ასეთი სურათების კლონირება კვანძებში და კონტეინერების გაშვებას თითქმის მყისიერად ხდის.

გარდა ამისა, ჩვენ ამჟამად ვმუშაობთ ახალ ფუნქციაზე, სახელწოდებით overlay volume mounts, რაც კიდევ უფრო აჩქარებს კონტეინერების მშენებლობას.

დასკვნა

Buildah-ის გაშვება კონტეინერში Kubernetes/CRI-O-ში, Podman-ში ან თუნდაც Docker-ში არის შესაძლებელი, მარტივი და ბევრად უფრო უსაფრთხო, ვიდრე docker.socket-ის გამოყენება. ჩვენ მნიშვნელოვნად გავზარდეთ სურათებთან მუშაობის მოქნილობა, ასე რომ თქვენ შეგიძლიათ მათი გაშვება სხვადასხვა გზით უსაფრთხოებისა და შესრულების ბალანსის ოპტიმიზაციისთვის.

დამატებითი შენახვის ფუნქციონირება საშუალებას გაძლევთ დააჩქაროთ ან თუნდაც მთლიანად აღმოფხვრათ სურათების კვანძებში ჩამოტვირთვა.

წყარო: www.habr.com