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.
Mnoho ľudí priťahuje myšlienku vytvárania kontajnerových obrázkov OCI v rámci
Preto sa ľudia neustále pokúšajú spustiť Buildah v kontajneri. Skrátka, tvorili sme
nastavenie
Tieto obrázky sú zostavené zo súborov Dockerfiles, ktoré nájdete v úložisku Buildah v priečinku
Tu zvážime
# 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
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.
# 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
У
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