Koja je ljepota razdvajanja vremena rada kontejnera na zasebne komponente alata? Konkretno, ovi alati mogu početi da se kombinuju tako da štite jedni druge.
Mnoge ljude privlači ideja o izgradnji kontejnerskih OCI slika unutar ili sličan sistem. Recimo da imamo CI/CD koji stalno skuplja slike, onda nešto slično /Kubernetes bi bio prilično koristan u smislu balansiranja opterećenja tokom izgradnje. Donedavno, većina ljudi je jednostavno davala kontejnerima pristup Docker socketu i dozvoljavala im da pokreću naredbu za izgradnju dockera. da je ovo vrlo nesigurno, u stvari, čak je gore od davanja root-a bez lozinke ili sudo-a.
Zato ljudi stalno pokušavaju pokrenuti Buildah u kontejneru. Ukratko, stvorili smo kako je, po našem mišljenju, najbolje pokrenuti Buildah unutar kontejnera i postaviti odgovarajuće slike na . Hajde da počnemo...
podešavanje
Ove slike su napravljene od Dockerfiles-a, koji se mogu naći u Buildah repozitorijumu u fascikli .
Ovdje ćemo razmotriti .
# 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
Umjesto OverlayFS-a, implementiranog na nivou Linux kernela hosta, koristimo program unutar kontejnera , jer se trenutno OverlayFS može montirati samo ako mu date SYS_ADMIN dozvole koristeći Linux mogućnosti. I želimo pokrenuti naše Buildah kontejnere bez ikakvih root privilegija. Fuse-overlay radi prilično brzo i ima bolje performanse od VFS drajvera za skladištenje. Imajte na umu da kada pokrećete Buildah kontejner koji koristi Fuse, morate osigurati /dev/fuse uređaj.
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
Zatim kreiramo direktorij za dodatnu pohranu. podržava koncept povezivanja dodatnih skladišta slika samo za čitanje. Na primjer, možete konfigurirati područje za pohranu preklapanja na jednoj mašini, a zatim koristiti NFS da montirate ovu pohranu na drugu mašinu i koristite slike sa nje bez preuzimanja putem povlačenja. Ovo skladište nam je potrebno da bismo mogli da povežemo neku pohranu slika sa hosta kao volumen i koristimo je unutar kontejnera.
# 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
Konačno, korištenjem varijable okruženja BUILDAH_ISOLATION, govorimo Buildah kontejneru da radi sa chroot izolacijom prema zadanim postavkama. Ovdje nije potrebna dodatna izolacija, jer već radimo u kontejneru. Da bi Buildah stvorio vlastite kontejnere odvojene prostorom imena, potrebna je privilegija SYS_ADMIN, što bi zahtijevalo opuštanje SELinux i SECCOMP pravila kontejnera, što je u suprotnosti s našim preferencijama da gradimo iz sigurnog kontejnera.
Pokretanje Buildaha unutar kontejnera
Dijagram slike kontejnera Buildah koji je gore razmotren omogućava vam da fleksibilno varirate metode pokretanja takvih kontejnera.
Brzina nasuprot sigurnosti
Kompjuterska sigurnost je uvijek kompromis između brzine procesa i količine zaštite koja je omotana oko njega. Ova izjava vrijedi i za sastavljanje kontejnera, pa ćemo u nastavku razmotriti opcije za takav kompromis.
Slika kontejnera o kojoj smo gore govorili će zadržati svoju pohranu u /var/lib/containers. Stoga moramo montirati sadržaj u ovu mapu, a način na koji to radimo uvelike će utjecati na brzinu pravljenja slika kontejnera.
Razmotrimo tri opcije.
Opcija 1. Ako je potrebna maksimalna sigurnost, onda za svaki kontejner možete kreirati svoj folder za kontejnere/sliku i povezati ga sa kontejnerom preko volume-mount-a. Osim toga, postavite kontekstni direktorij u sam kontejner, u /build folder:
# 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
Sigurnost. Buildah koji radi u takvom kontejneru ima maksimalnu sigurnost: ne daje mu nikakve root privilegije koristeći mogućnosti, a na njega se primjenjuju sva SECOMP i SELinux ograničenja. Takav kontejner se čak može pokrenuti s izolacijom korisničkog imenskog prostora dodavanjem opcije poput —uidmap 0: 100000:10000.
Performanse. Ali performanse su ovdje minimalne, budući da se sve slike iz registara kontejnera svaki put kopiraju na host, a keširanje uopće ne radi. Kada završi svoj rad, Buildah kontejner mora poslati sliku u registar i uništiti sadržaj na hostu. Sljedeći put kada se napravi slika kontejnera, morat će se ponovo preuzeti iz registra, jer do tada na hostu neće ostati ništa.
Opcija 2. Ako su vam potrebne performanse na nivou Dockera, možete montirati host kontejner/skladište direktno u kontejner.
# 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
Sigurnost. Ovo je najmanje siguran način za pravljenje kontejnera jer omogućava kontejneru da modificira pohranu na hostu i potencijalno može hraniti Podman ili CRI-O zlonamjernu sliku. Osim toga, morat ćete onemogućiti odvajanje SELinuxa kako bi procesi u Buildah kontejneru mogli komunicirati sa pohranom na hostu. Imajte na umu da je ova opcija i dalje bolja od Docker socketa jer je kontejner zaključan preostalim sigurnosnim karakteristikama i ne može jednostavno pokrenuti kontejner na hostu.
Performanse. Ovdje je maksimalno, pošto je keširanje u potpunosti iskorišteno. Ako su Podman ili CRI-O već preuzeli potrebnu sliku na host, tada proces Buildah unutar kontejnera neće morati ponovo da je preuzima, a naknadne izrade zasnovane na ovoj slici će također moći uzeti ono što im treba iz keša. .
Opcija 3. Suština ove metode je kombinovanje nekoliko slika u jedan projekat sa zajedničkim folderom za slike kontejnera.
# 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
U ovom primjeru, ne brišemo projektnu fasciklu (/var/lib/project3) između pokretanja, tako da sve naredne gradnje unutar projekta imaju koristi od keširanja.
Sigurnost. Nešto između opcija 1 i 2. S jedne strane, kontejneri nemaju pristup sadržaju na hostu i, shodno tome, ne mogu ubaciti nešto loše u Podman/CRI-O skladište slika. S druge strane, kao dio svog dizajna, kontejner može ometati montažu drugih kontejnera.
Performanse. Ovdje je gore nego kada koristite dijeljenu keš memoriju na nivou hosta, jer ne možete koristiti slike koje su već preuzete pomoću Podman/CRI-O. Međutim, kada Buildah preuzme sliku, slika se može koristiti u bilo kojoj narednoj gradnji unutar projekta.
Dodatna pohrana
У Postoji tako zgodna stvar kao što su dodatne prodavnice (dodatne prodavnice), zahvaljujući kojima prilikom pokretanja i izgradnje kontejnera, motori kontejnera mogu koristiti eksterne prodavnice slika u režimu preklapanja samo za čitanje. U suštini, možete dodati jedno ili više skladišta samo za čitanje u datoteku storage.conf tako da kada pokrenete kontejner, mehanizam kontejnera traži željenu sliku u njima. Štaviše, on će preuzeti sliku iz registra samo ako je ne pronađe ni u jednom od ovih skladišta. Kontejnerski mehanizam će moći pisati samo u memoriju za pisanje...
Ako skrolujete gore i pogledate Dockerfile koji koristimo za izgradnju slike quay.io/buildah/stable, postoje redovi poput ove:
# 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
U prvom redu mijenjamo /etc/containers/storage.conf unutar slike kontejnera, govoreći drajveru za skladištenje da koristi “additionalimagestores” u /var/lib/shared folderu. I u sljedećem redu kreiramo dijeljeni folder i dodajemo par fajlova zaključavanja kako ne bi bilo zloupotreba od strane kontejnera/skladišta. U suštini, mi jednostavno kreiramo prazno skladište slika kontejnera.
Ako montirate kontejnere/skladište na višem nivou od ovog foldera, Buildah će moći koristiti slike.
Sada se vratimo na opciju 2 o kojoj smo gore govorili, kada Buildah kontejner može čitati i pisati u kontejnere/spremište na hostovima i, u skladu s tim, ima maksimalne performanse zbog keširanja slika na nivou Podman/CRI-O, ali pruža minimalnu sigurnost budući da može pisati direktno u memoriju. Sada dodajmo dodatni prostor za pohranu i iskoristimo najbolje od oba svijeta.
# 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
Imajte na umu da je /var/lib/containers/storage hosta montiran na /var/lib/shared unutar kontejnera u načinu samo za čitanje. Stoga, radeći u kontejneru, Buildah može koristiti sve slike koje su prethodno preuzete pomoću Podman/CRI-O (zdravo, brzina), ali može pisati samo u vlastitu pohranu (zdravo, sigurnost). Takođe imajte na umu da se ovo radi bez onemogućavanja SELinux razdvajanja za kontejner.
Važna nijansa
Ni pod kojim okolnostima ne biste trebali brisati slike iz osnovnog spremišta. U suprotnom, Buildah kontejner se može srušiti.
I to nisu sve prednosti
Mogućnosti dodatnog skladištenja nisu ograničene na gornji scenario. Na primjer, možete postaviti sve slike kontejnera na dijeljenu mrežnu pohranu i dati joj pristup svim Buildah kontejnerima. Recimo da imamo stotine slika koje naš CI/CD sistem redovno koristi za pravljenje slika kontejnera. Koncentrišemo sve ove slike na jedan host memorije, a zatim, koristeći preferirane alate za mrežno skladištenje (NFS, Gluster, Ceph, ISCSI, S3...), otvaramo opšti pristup ovoj memoriji za sve Buildah ili Kubernetes čvorove.
Sada je dovoljno montirati ovu mrežnu pohranu u Buildah kontejner na /var/lib/shared i to je to - Buildah kontejneri više ne moraju preuzimati slike putem povlačenja. Dakle, izbacujemo fazu pred-populacije i odmah smo spremni za izbacivanje kontejnera.
I naravno, ovo se može koristiti unutar živog Kubernetes sistema ili kontejnerske infrastrukture za pokretanje i pokretanje kontejnera bilo gdje bez ikakvog preuzimanja slika. Štaviše, registar kontejnera, primajući push zahtjev za učitavanje ažurirane slike u njega, može automatski poslati ovu sliku u dijeljenu mrežnu pohranu, gdje ona odmah postaje dostupna svim čvorovima.
Slike kontejnera ponekad mogu dostići veličinu od mnogo gigabajta. Funkcionalnost dodatnog prostora za skladištenje omogućava vam da izbegnete kloniranje takvih slika preko čvorova i čini pokretanje kontejnera skoro trenutnim.
Osim toga, trenutno radimo na novoj funkciji koja se zove overlay volume mounts, koja će učiniti izgradnju kontejnera još bržom.
zaključak
Pokretanje Buildaha unutar kontejnera u Kubernetes/CRI-O, Podmanu ili čak Dockeru je izvodljivo, jednostavno i mnogo sigurnije od korištenja docker.socket. Uvelike smo povećali fleksibilnost rada sa slikama, tako da ih možete pokrenuti na različite načine kako biste optimizirali ravnotežu između sigurnosti i performansi.
Funkcionalnost dodatne memorije omogućava vam da ubrzate ili čak potpuno eliminišete preuzimanje slika u čvorove.
izvor: www.habr.com