Pokyny pre spustenie Buildah vo vnútri kontajnera

Aká je krása rozdelenia doby prevádzky kontajnera na samostatné komponenty nástrojov? Najmä tieto nástroje sa môžu začať kombinovať tak, aby sa navzájom chránili.

Pokyny pre spustenie Buildah vo vnútri kontajnera

Mnoho ľudí priťahuje myšlienku vytvárania kontajnerových obrázkov OCI v rámci Kubernetes alebo podobný systém. Povedzme, že máme CI/CD, ktoré neustále zbiera obrázky, potom niečo podobné Red Hat OpenShift/Kubernetes by bol celkom užitočný z hľadiska vyrovnávania záťaže počas zostavovania. Až donedávna väčšina ľudí jednoducho poskytla kontajnerom prístup k zásuvke Docker a umožnila im spustiť príkaz na zostavenie dockera. Pred niekoľkými rokmi sme ukázaliže je to veľmi neisté, v skutočnosti je to ešte horšie ako dať root alebo sudo bez hesla.

Preto sa ľudia neustále pokúšajú spustiť Buildah v kontajneri. Skrátka, tvorili sme príklad ako je podľa nášho názoru najlepšie spustiť Buildah v kontajneri a uverejniť príslušné obrázky na quay.io/buildah. Začnime...

nastavenie

Tieto obrázky sú zostavené zo súborov Dockerfiles, ktoré nájdete v úložisku Buildah v priečinku buildahimage.
Tu zvážime stabilná verzia 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

Namiesto OverlayFS, implementovaného na úrovni jadra hostiteľského Linuxu, používame program vo vnútri kontajnera poistka-prekrytie, pretože v súčasnosti sa OverlayFS môže pripojiť iba vtedy, ak mu dáte oprávnenia SYS_ADMIN pomocou schopností Linuxu. A chceme prevádzkovať naše kontajnery Buildah bez akýchkoľvek privilégií root. Fuse-overlay funguje pomerne rýchlo a má lepší výkon ako ovládač úložiska VFS. Upozorňujeme, že pri spustení kontajnera Buildah, ktorý používa Fuse, musíte poskytnúť zariadenie /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

Ďalej vytvoríme adresár pre ďalšie úložisko. Nádoba/sklad podporuje koncepciu pripojenia ďalších pamätí obrázkov len na čítanie. Môžete napríklad nakonfigurovať prekryvnú úložnú oblasť na jednom počítači a potom použiť NFS na pripojenie tohto úložného priestoru na iný počítač a použiť z neho obrázky bez sťahovania prostredníctvom sťahovania. Toto úložisko potrebujeme, aby sme mohli pripojiť nejaké úložisko obrázkov z hostiteľa ako zväzok a použiť ho vo vnútri kontajnera.

# 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

Nakoniec pomocou premennej prostredia BUILDAH_ISOLATION hovoríme kontajneru Buildah, aby sa štandardne spúšťal s izoláciou chroot. Dodatočná izolácia tu nie je potrebná, pretože už pracujeme v kontajneri. Aby Buildah vytvoril svoje vlastné kontajnery oddelené menným priestorom, vyžaduje sa privilégium SYS_ADMIN, čo by vyžadovalo uvoľnenie pravidiel kontajnera SELinux a SECCOMP, čo je v rozpore s našimi preferenciami vytvárať zo zabezpečeného kontajnera.

Spustenie Buildah v kontajneri

Vyššie diskutovaný obrazový diagram kontajnera Buildah vám umožňuje flexibilne meniť spôsoby spúšťania takýchto kontajnerov.

Rýchlosť verzus bezpečnosť

Počítačová bezpečnosť je vždy kompromisom medzi rýchlosťou procesu a mierou ochrany. Toto tvrdenie platí aj pri montáži kontajnerov, preto nižšie zvážime možnosti takéhoto kompromisu.

Vyššie diskutovaný obrázok kontajnera si zachová svoje úložisko v /var/lib/containers. Preto musíme pripojiť obsah do tohto priečinka a spôsob, akým to urobíme, výrazne ovplyvní rýchlosť vytvárania obrázkov kontajnera.

Zvážme tri možnosti.

1 Option. Ak sa vyžaduje maximálna bezpečnosť, potom pre každý kontajner môžete vytvoriť svoj vlastný priečinok pre kontajnery/obrázok a pripojiť ho ku kontajneru pomocou pripojenia zväzku. A okrem toho umiestnite kontextový adresár do samotného kontajnera, do priečinka /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

Bezpečnosť. Buildah spustený v takomto kontajneri má maximálnu bezpečnosť: nie sú mu udelené žiadne privilégiá root pomocou schopností a vzťahujú sa naň všetky obmedzenia SECOMP a SELinux. Takýto kontajner možno dokonca spustiť s izoláciou používateľského menného priestoru pridaním možnosti ako —uidmap 0: 100000:10000.

Performance. Výkon je tu však minimálny, pretože všetky obrázky z registrov kontajnerov sa zakaždým skopírujú do hostiteľa a ukladanie do vyrovnávacej pamäte vôbec nefunguje. Po dokončení svojej práce musí kontajner Buildah odoslať obrázok do registra a zničiť obsah na hostiteľovi. Pri ďalšom vytvorení obrazu kontajnera sa bude musieť znova stiahnuť z registra, pretože dovtedy na hostiteľovi nezostane nič.

2 Option. Ak potrebujete výkon na úrovni Docker, môžete hostiteľský kontajner/úložisko pripojiť priamo do kontajnera.

# 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

Bezpečnosť. Toto je najmenej bezpečný spôsob vytvárania kontajnerov, pretože umožňuje kontajneru upravovať úložisko hostiteľa a potenciálne by mohol poskytnúť Podmanovi alebo CRI-O škodlivý obraz. Okrem toho budete musieť zakázať separáciu SELinux, aby procesy v kontajneri Buildah mohli interagovať s úložiskom na hostiteľovi. Upozorňujeme, že táto možnosť je stále lepšia ako zásuvka Docker, pretože kontajner je uzamknutý zvyšnými bezpečnostnými funkciami a nemôže jednoducho spustiť kontajner na hostiteľovi.

Performance. Tu je to maximum, keďže ukladanie do vyrovnávacej pamäte je plne využité. Ak Podman alebo CRI-O už stiahli požadovaný obrázok do hostiteľa, proces Buildah vo vnútri kontajnera ho nebude musieť znova sťahovať a následné zostavy založené na tomto obrázku si budú môcť tiež vziať to, čo potrebujú z vyrovnávacej pamäte. .

3 Option. Podstatou tejto metódy je spojiť niekoľko obrázkov do jedného projektu so spoločným priečinkom pre obrázky kontajnerov.

# 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

V tomto príklade nevymažeme priečinok projektu (/var/lib/project3) medzi spusteniami, takže všetky nasledujúce zostavy v rámci projektu profitujú z ukladania do vyrovnávacej pamäte.

Bezpečnosť. Niečo medzi možnosťami 1 a 2. Na jednej strane kontajnery nemajú prístup k obsahu na hostiteľovi, a preto nemôžu vkĺznuť niečo zlé do úložiska obrázkov Podman/CRI-O. Na druhej strane môže kontajner v rámci svojho dizajnu prekážať pri montáži iných kontajnerov.

Performance. Tu je to horšie ako pri použití zdieľanej vyrovnávacej pamäte na úrovni hostiteľa, pretože nemôžete použiť obrázky, ktoré už boli stiahnuté pomocou Podman/CRI-O. Keď však Buildah stiahne obrázok, môže sa použiť v akýchkoľvek nasledujúcich zostavách v rámci projektu.

Dodatočné úložisko

У kontajnery/sklad Existuje taká skvelá vec, ako sú ďalšie obchody (ďalšie obchody), vďaka ktorým môžu kontajnerové motory pri spúšťaní a stavbe kontajnerov používať externé úložiská obrázkov v režime prekrytia iba na čítanie. V podstate môžete do súboru storage.conf pridať jedno alebo viacero ukladacích priestorov len na čítanie, takže keď spustíte kontajner, kontajnerový mechanizmus v nich vyhľadá požadovaný obrázok. Okrem toho stiahne obrázok z registra iba vtedy, ak ho nenájde v žiadnom z týchto úložísk. Kontajnerový stroj bude môcť zapisovať iba do zapisovateľného úložiska...

Ak sa posuniete nahor a pozriete sa na súbor Dockerfile, ktorý používame na vytvorenie obrázka quay.io/buildah/stable, sú tam riadky ako tento:

# 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

V prvom riadku upravíme /etc/containers/storage.conf vo vnútri obrazu kontajnera a povieme ovládaču úložiska, aby použil „additionalimagestores“ v priečinku /var/lib/shared. A v ďalšom riadku vytvoríme zdieľaný priečinok a pridáme pár uzamykacích súborov, aby nedošlo k zneužitiu kontajnerov/úložiska. V podstate jednoducho vytvárame prázdny zásobník obrázkov.

Ak pripojíte kontajnery/úložisko na úrovni vyššej ako je tento priečinok, Buildah bude môcť použiť obrázky.

Teraz sa vráťme k možnosti 2 diskutovanej vyššie, keď kontajner Buildah môže čítať a zapisovať do kontajnerov/ukladať na hostiteľoch, a teda má maximálny výkon vďaka ukladaniu obrázkov do vyrovnávacej pamäte na úrovni Podman/CRI-O, ale poskytuje minimálne zabezpečenie od r. môže zapisovať priamo do úložiska. Teraz sem pridajte ďalšie úložisko a získajte to najlepšie z oboch svetov.

# 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

Všimnite si, že /var/lib/containers/storage hostiteľa je pripojený k /var/lib/shared v kontajneri v režime iba na čítanie. Preto pri práci v kontajneri môže Buildah použiť akékoľvek obrázky, ktoré boli predtým stiahnuté pomocou Podman/CRI-O (ahoj, rýchlosť), ale môže zapisovať iba do vlastného úložiska (ahoj, bezpečnosť). Všimnite si tiež, že sa to robí bez vypnutia separácie SELinux pre kontajner.

Dôležitý odtieň

Za žiadnych okolností by ste nemali odstraňovať žiadne obrázky zo základného úložiska. V opačnom prípade môže kontajner Buildah zlyhať.

A to nie sú všetky výhody

Možnosti dodatočného úložiska nie sú obmedzené na vyššie uvedený scenár. Môžete napríklad umiestniť všetky obrázky kontajnerov na zdieľané sieťové úložisko a poskytnúť k nemu prístup všetkým kontajnerom Buildah. Povedzme, že máme stovky obrázkov, ktoré náš systém CI/CD pravidelne používa na vytváranie obrázkov kontajnerov. Všetky tieto obrázky sústreďujeme na jedného hostiteľa úložiska a potom pomocou preferovaných nástrojov sieťového úložiska (NFS, Gluster, Ceph, ISCSI, S3...) otvárame všeobecný prístup k tomuto úložisku všetkým uzlom Buildah alebo Kubernetes.

Teraz stačí pripojiť toto sieťové úložisko do kontajnera Buildah na /var/lib/shared a je to - kontajnery Buildah už nemusia sťahovať obrázky pomocou sťahovania. Vyhadzujeme tak fázu pred osídľovaním a sme okamžite pripravení vyložiť kontajnery.

A samozrejme to možno použiť v rámci živého systému Kubernetes alebo kontajnerovej infraštruktúry na spustenie a spustenie kontajnerov kdekoľvek bez akéhokoľvek sťahovania obrázkov. Okrem toho register kontajnerov, ktorý dostane požiadavku push na nahranie aktualizovaného obrázka, môže tento obrázok automaticky odoslať do zdieľaného sieťového úložiska, kde sa okamžite stane dostupným pre všetky uzly.

Obrázky kontajnerov môžu niekedy dosiahnuť veľkosť mnohých gigabajtov. Funkcionalita dodatočného úložiska vám umožňuje vyhnúť sa klonovaniu takýchto obrázkov medzi uzlami a robí spustenie kontajnerov takmer okamžitým.

Okrem toho momentálne pracujeme na novej funkcii nazvanej prekryvné držiaky objemu, vďaka ktorej bude stavanie kontajnerov ešte rýchlejšie.

Záver

Spustenie Buildah v kontajneri v Kubernetes/CRI-O, Podman alebo dokonca Docker je uskutočniteľné, jednoduché a oveľa bezpečnejšie ako používanie docker.socket. Výrazne sme zvýšili flexibilitu práce s obrázkami, takže ich môžete spúšťať rôznymi spôsobmi, aby ste optimalizovali rovnováhu medzi bezpečnosťou a výkonom.

Funkcionalita dodatočného úložiska umožňuje zrýchliť alebo dokonca úplne eliminovať sťahovanie obrázkov do uzlov.

Zdroj: hab.com

Pridať komentár