Aká je výhoda rozdelenia prostredia vykonávania kontajnerov na jednotlivé nástroje? Predovšetkým to, že tieto nástroje môžeme začať kombinovať, aby sa navzájom chránili.
Mnohých láka myšlienka vykonávať zostavovanie kontajnerových OCI obrazov v rámci alebo podobného systému. Predpokladajme, že máme CI/CD, ktoré neustále zostavuje obrazy, potom niečo ako /Kubernetes было бы весьма полезно с точки зрения распределения нагрузки при сборке. До недавних пор большинство людей просто давали контейнерам доступ к Docker-сокету и разрешали выполнять команду docker build. , že je to veľmi nebezpečné, v skutočnosti je to dokonca horšie, ako dať bezheslový root alebo sudo.
Preto sa ľudia neustále snažia spúšťať Buildah v kontajneri. Skrátka, vytvorili sme to, ako, podľa nášho názoru, najlepšie spúšťať Buildah vo vnútri kontajnera, a zverejnili sme príslušné obrazy na . Poďme na to…
Nastavenie
Tieto obrazy sú zostavené z Dockerfiles, ktoré nájdete v repozitári Buildah v priečinku .
Tu sa pozrieme na .
# 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, implementovanej na úrovni Linuxového jadra hostiteľa, používame vo vnútri kontajnera program , pretože v súčasnosti môže OverlayFS vykonávať montovanie, len ak jej poskytneme oprávnenia SYS_ADMIN prostriedkami Linux capabilities. A chceme spúšťať naše Buildah kontajnery bez akýchkoľvek root oprávnení. Fuse-overlay pracuje dosť rýchlo a po výkonnostnej stránke je lepšie ako storage ovládač VFS. Upozorňujeme, že pri spúšťaní Buildah kontajnera, ktorý používa Fuse, je potrebné 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žiská. podporuje koncept pripojenia ďalších read-only úložísk obrazov. Napríklad, môžeme nakonfigurovať overlay storage area na jednom počítači a potom to úložisko pripojiť pomocou NFS na inom počítači a používať obrazy z neho bez sťahovania cez pull. Toto úložisko potrebujeme na to, aby sme mohli pripojiť ako zväzok nejaké úložisko obrazov z hostiteľa 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
A nakoniec, pomocou premennej prostredia BUILDAH_ISOLATION hovoríme, že predvolene by sa kontajner Buildah mal spúšťať s izoláciou chroot. Dodatočná izolácia nie je potrebná, pretože už pracujeme v kontajneri. Na to, aby Buildah vytváral svoje vlastné kontajnery s oddelením priestorov mien, je potrebná právo SYS_ADMIN, a na to bude potrebné oslabiť pravidlá SELinux a SECCOMP pre kontajner, čo je v rozpore s našou inštaláciou na vykonávanie zostavení v bezpečnom kontajneri.
Spúšťame Buildah vo vnútri kontajnera
Prediskutovaný obraz kontajnera Buildah umožňuje flexibilne variabilné spôsoby spúšťania takýchto kontajnerov.
Rýchlosť vs. bezpečnosť
Počítačová bezpečnosť je vždy kompromisom medzi rýchlosťou vykonávania procesu a množstvom ochrany, ktorá je okolo toho. Toto tvrdenie platí aj pri zostavovaní kontajnerov, preto sa nižšie pozrieme na možnosti takého kompromisu.
Prediskutovaný obraz kontajnera bude uchovávať svoje úložisko v /var/lib/containers. Preto musíme pripojiť obsah do tejto zložky, a to, ako to spravíme, bude mať veľký vplyv na rýchlosť zostavovania obrazov kontajnerov.
Preskúmajme tri možnosti.
Možnosť 1. Ak je potrebná maximálna bezpečnosť, pre každý kontajner je možné vytvoriť svoju vlastnú zložku pre containers/image a pripojiť ju ku kontajneru pomocou volume-mount. Okrem toho, môžeme umiestniť kontextovú zložku priamo do kontajnera, do zložky /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 pracujúci v takomto kontajneri má maximálnu bezpečnosť: nemá žiadne root privilégia pomocou capabilities a naň sa aplikujú všetky obmedzenia SECOMP a SELinux. Takýto kontajner je možné spúšťať aj s izoláciou User Namespace, pridaním možnosti ako —uidmap 0:100000:10000.
Výkon. Tu je však výkon minimálny, pretože akékoľvek obrazy z kontajnerových registratúrov sa zakaždým kopírujú na hostiteľa a cacheovanie nefunguje od slova „nič“. Na konci svojej práce musí kontajner Buildah poslať obraz do registru a zničiť obsah na hostiteľovi. Keď sa kontajnerový obraz bude budúci raz zostavovať, bude ho potrebné znovu stiahnuť z registra, pretože na hostiteľovi už v tom čase nič neostane.
Možnosť 2. Ak potrebujete výkon na úrovni Dockeru, môžete pripojiť container/storage hosta 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 zostavovania kontajnerov, pretože kontajner má povolené upravovať úložisko na hoste a potenciálne môže preniknúť do Podmanu alebo CRI-O s nebezpečným obrazom. Okrem toho bude potrebné vypnúť oddelenie SELinux, aby procesy vo vnútri kontajnera Buildah mohli interagovať s úložiskom na hoste. Všimnite si, že táto možnosť je predsa len lepšia ako Docker socket, pretože kontajner je chránený zvyšnými bezpečnostnými funkciami a nemôže len tak vziať a spustiť nejaký kontajner na hoste.
Výkon. Tu je maximálna, pretože sa úplne využíva cache. Ak už Podman alebo CRI-O stihli stiahnuť potrebný obraz na host, proces Buildah vo vnútri kontajnera ho nebude musieť sťahovať znova a následné zostavovania na základe tohto obrazu ho tiež budú môcť získať z cache.
Možnosť 3. Podstatou tohto spôsobu je spojiť niekoľko obrazov do jedného projektu so spoločným priečinkom pre kontajnerové obrazy.
# 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 nezmizne priečinok projektu (/var/lib/project3) medzi spusteniami, takže všetky ďalšie zostavenia v rámci projektu využívajú výhody cachovania.
Bezpečnosť. Niečo medzi možnosťami 1 a 2. Na jednej strane kontajnery nemajú prístup k obsahu na hoste a teda nemôžu preniknúť do úložiska obrazov Podman/CRI-O. Na druhej strane môže kontajner vo svojom projekte zasahovať do zostavovania iných kontajnerov.
Výkon. Tu je to horšie ako pri používaní spoločnej cache na úrovni hosta, pretože nie je možné použiť obrazy, ktoré už boli predtým stiahnuté pomocou Podman/CRI-O. Avšak po tom, ako Buildah stiahne obraz, tento obraz je možné použiť v akýchkoľvek nasledujúcich zostaveniach v rámci projektu.
Ďalšie úložiská
U Existuje skvělá funkce jako dodatečné úložiště (additional stores), díky které mohou kontejnerové motory při spuštění a sestavování kontejnerů používat externí úložiště obrazů v režimu pouze pro čtení overlay. V podstatě je možné do souboru storage.conf přidat jedno nebo více „pouze pro čtení“ úložišť, aby kontejnerový motor při spuštění kontejneru hledal potřebný obraz v nich. Stáhne obraz z registru pouze v případě, že jej nenajde v žádném z těchto úložišť. Kontejnerový motor bude moci zapisovat pouze do úložišť, která jsou dostupná pro zápis...
Pokud se posuneme nahoru a podíváme se na Dockerfile, který používáme pro sestavení obrazu quay.io/buildah/stable, najdeme tam tyto řádky:
# 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 prvním řádku modifikujeme /etc/containers/storage.conf uvnitř kontejnerového obrazu, říkáme storage-drivers, aby použil „additionalimagestores“ v adresáři /var/lib/shared. V následujícím řádku vytváříme sdílenou složku a přidáváme několik zámkových souborů, aby nedocházelo k problémům ze strany containers/storage. V podstatě vytváříme prázdné úložiště kontejnerových obrazů.
Pokud připojíme containers/storage o úroveň výš než tato složka, Buildah bude moci používat obrazy.
Nyní se vraťme k Variantu 2, kdy může Buildah-kontejner číst a zapisovat do containers/store na hostitelích a má tak maximální výkon díky ukládání obrazů na úrovni Podman/CRI-O, ale poskytuje minimální bezpečnost, protože může zapisovat přímo do úložišť. A nyní přidáme dodatečná úložiště a získáme to nejlepší z obou světů.
# 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šimněte si, že /var/lib/containers/storage hostitele je připojena do /var/lib/shared uvnitř kontejneru v režimu pouze pro čtení. Proto může Buildah při práci v kontejneru používat jakékoli obrazy, které byly dříve staženy pomocí Podman/CRI-O (ahoj, rychlost), ale zapisovat může pouze do svého vlastního úložiště (ahoj, bezpečnost). Také si dejte pozor, že to je provedeno bez vypnutí oddělení SELinux pro kontejner.
Důležitá poznámka
V žádném případě by se neměly mazat žádné obrazy z podkladového úložiště. Jinak může Buildah-kontejner vyletět.
A to rozhodně nejsou všechny výhody
Možnosti dodatočných úložísk sa neobmedzujú len na vyššie opísaný scenár. Napríklad, môžeme umiestniť všetky kontajnerové obrazy do spoločného sieťového úložiska a poskytnúť k nemu prístup všetkým kontajnerom Buildah. Predpokladajme, že máme stovky obrazov, ktoré náš CI/CD systém pravidelne využíva na zostavovanie kontajnerových obrazov. Soustredíme všetky tieto obrazy na nejakom jednom hostiteľskom úložisku a potom, pomocou preferovaných prostriedkov sieťového ukladania (NFS, Gluster, Ceph, ISCSI, S3…), otvoríme spoločný prístup k tomuto úložisku všetkým nodom Buildah alebo Kubernetes.
Teraz stačí podmontovať toto sieťové úložisko do kontajnera Buildah na /var/lib/shared a to je všetko – kontajnerom Buildah už vôbec nebude potrebné sťahovať obrazy cez pull. Týmto spôsobom eliminujeme fázu predbežného naplnenia (pre-population) a okamžite sme pripravení nasadzovať kontajnery.
A samozrejme, to možno využiť v rámci existujúceho systému Kubernetes alebo kontajnerovej infraštruktúry, aby sa kontajnery spúšťali a vykonávali kdekoľvek bez akéhokoliv sťahovania obrazov cez pull. Navyše, registrovaný kontajner, ktorý prijíma push-request na nahranie aktualizovaného obrazu, môže automaticky odoslať tento obraz do spoločného sieťového úložiska, kde sa okamžite stáva dostupným všetkým nodom.
Veľkosti kontajnerových obrazov môžu niekedy dosahovať niekoľko gigabajtov. Funkcionalita dodatočných úložísk umožňuje vyhnúť sa klonovaniu týchto obrazov po nodách a robí spúšťanie kontajnerov takmer okamžitým.
Okrem toho v súčasnosti pracujeme na novej funkcii overlay volume mounts, ktorá urobí vytváranie kontajnerov ešte rýchlejším.
Záver
Vykonávať Buildah vo vnútri kontajnera v prostredí Kubernetes/CRI-O, Podman alebo dokonca v Dockeri je celkom reálne, navyše je to jednoduchšie a oveľa bezpečnejšie, než používať docker.socket. Výrazne sme zvýšili flexibilitu práce s obrazmi a teraz ich môžete spúšťať rôznymi spôsobmi pre optimálnu rovnováhu medzi bezpečnosťou a výkonom.
Funkcionalita dodatočných úložísk umožňuje urýchliť alebo dokonca úplne eliminovať sťahovanie obrazov na nody.
Zdroj: habr.com
