Jaká je krása oddělení běhu kontejneru na samostatné komponenty nástrojů? Zejména se tyto nástroje mohou začít kombinovat tak, aby se navzájem chránily.
Mnoho lidí přitahuje myšlenka vytváření kontejnerových obrázků OCI uvnitř nebo podobný systém. Řekněme, že máme CI/CD, které neustále shromažďuje obrázky, pak něco podobného /Kubernetes by byl docela užitečný, pokud jde o vyrovnávání zátěže během sestavení. Až donedávna většina lidí jednoduše poskytla kontejnerům přístup k soketu Docker a umožnila jim spustit příkaz sestavení dockeru. že je to velmi nejisté, ve skutečnosti je to ještě horší než dát root nebo sudo bez hesla.
Proto se lidé neustále snaží spustit Buildah v kontejneru. Zkrátka jsme tvořili jak je podle našeho názoru nejlepší spustit Buildah uvnitř kontejneru a umístit odpovídající obrázky na . Začněme...
Nastavení
Tyto obrázky jsou sestaveny z Dockerfiles, které lze nalézt v úložišti Buildah ve složce .
Zde se podíváme 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
Namísto OverlayFS implementovaného na úrovni hostitelského jádra Linuxu používáme program uvnitř kontejneru , protože v současné době se OverlayFS může připojit pouze tehdy, pokud mu dáte oprávnění SYS_ADMIN pomocí schopností Linuxu. A chceme provozovat naše kontejnery Buildah bez jakýchkoli práv roota. Fuse-overlay funguje poměrně rychle a má lepší výkon než ovladač úložiště VFS. Vezměte prosím na vědomí, že při spuštění kontejneru Buildah, který používá Fuse, musíte poskytnout zařízení /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
Dále vytvoříme adresář pro další úložiště. podporuje koncept připojení dalších úložišť obrázků pouze pro čtení. Můžete například nakonfigurovat překryvnou úložnou oblast na jednom počítači a pak použít NFS k připojení tohoto úložiště na jiný počítač a používat obrazy z něj bez stahování pomocí pull. Toto úložiště potřebujeme, abychom mohli připojit nějaké úložiště obrázků z hostitele jako svazek a použít ho uvnitř kontejneru.
# 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
Nakonec pomocí proměnné prostředí BUILDAH_ISOLATION sdělujeme kontejneru Buildah, aby ve výchozím nastavení běžel s chrootovou izolací. Dodatečná izolace zde není nutná, protože již pracujeme v kontejneru. Aby Buildah vytvořil vlastní kontejnery oddělené jmenným prostorem, je vyžadováno oprávnění SYS_ADMIN, což by vyžadovalo uvolnění pravidel kontejneru SELinux a SECCOMP, což je v rozporu s našimi preferencemi stavět ze zabezpečeného kontejneru.
Spuštění Buildah uvnitř kontejneru
Výše diskutovaný obrázek kontejneru Buildah vám umožňuje flexibilně měnit způsoby spouštění takových kontejnerů.
Rychlost versus bezpečnost
Počítačová bezpečnost je vždy kompromisem mezi rychlostí procesu a mírou ochrany, která je kolem něj zabalena. Toto tvrzení platí i při sestavování kontejnerů, takže níže zvážíme možnosti takového kompromisu.
Obrázek kontejneru diskutovaný výše si ponechá své úložiště ve /var/lib/containers. Proto musíme připojit obsah do této složky a způsob, jakým to uděláme, výrazně ovlivní rychlost vytváření obrázků kontejneru.
Zvažme tři možnosti.
Možnost 1. Pokud je vyžadováno maximální zabezpečení, můžete pro každý kontejner vytvořit vlastní složku pro kontejnery/obrázek a připojit ji ke kontejneru pomocí připojení svazku. A kromě toho umístěte kontextový adresář do samotného kontejneru, do slož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
Security. Buildah běžící v takovém kontejneru má maximální zabezpečení: nejsou mu přidělena žádná práva root pomocí schopností a vztahují se na něj všechna omezení SECOMP a SELinux. Takový kontejner lze dokonce spustit s izolací User Namespace přidáním možnosti jako —uidmap 0: 100000:10000.
Výkon. Ale výkon je zde minimální, protože všechny obrázky z registrů kontejnerů se pokaždé zkopírují do hostitele a ukládání do mezipaměti vůbec nefunguje. Při dokončení své práce musí kontejner Buildah odeslat obrázek do registru a zničit obsah na hostiteli. Při příštím vytvoření bitové kopie kontejneru bude nutné ji znovu stáhnout z registru, protože do té doby na hostiteli nezůstane nic.
Možnost 2. Pokud potřebujete výkon na úrovni Dockeru, můžete hostitelský kontejner/úložiště připojit přímo do kontejneru.
# 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
Security. Toto je nejméně bezpečný způsob vytváření kontejnerů, protože umožňuje kontejneru upravovat úložiště hostitele a potenciálně by mohl podmanit Podman nebo CRI-O škodlivý obraz. Kromě toho budete muset zakázat separaci SELinux, aby procesy v kontejneru Buildah mohly interagovat s úložištěm na hostiteli. Všimněte si, že tato možnost je stále lepší než soket Docker, protože kontejner je uzamčen zbývajícími bezpečnostními funkcemi a nelze jej jednoduše spustit na hostiteli.
Výkon. Zde je to maximum, protože cachování je plně využito. Pokud Podman nebo CRI-O již stáhli požadovaný obrázek do hostitele, proces Buildah uvnitř kontejneru jej nebude muset znovu stahovat a následné sestavení založené na tomto obrázku si také budou moci vzít to, co potřebují z mezipaměti. .
Možnost 3. Podstatou této metody je spojení několika obrázků do jednoho projektu se společnou složkou pro obrázky kontejnerů.
# 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 příkladu neodstraňujeme složku projektu (/var/lib/project3) mezi spuštěními, takže všechna následující sestavení v rámci projektu těží z ukládání do mezipaměti.
Security. Něco mezi možnostmi 1 a 2. Na jedné straně kontejnery nemají přístup k obsahu na hostiteli, a proto nemohou do úložiště obrázků Podman/CRI-O vklouznout něco špatného. Na druhou stranu může kontejner v rámci své konstrukce překážet při montáži jiných kontejnerů.
Výkon. Zde je to horší než při použití sdílené mezipaměti na úrovni hostitele, protože nelze použít obrázky, které již byly staženy pomocí Podman/CRI-O. Jakmile však Buildah stáhne bitovou kopii, lze ji použít v jakýchkoli následujících sestaveních v rámci projektu.
Další úložiště
У Existuje taková skvělá věc, jako jsou další obchody (další obchody), díky kterým mohou kontejnerové enginy při spouštění a stavbě kontejnerů používat externí úložiště obrázků v režimu překrytí pouze pro čtení. V podstatě můžete do souboru storage.conf přidat jedno nebo více úložišť pouze pro čtení, takže když kontejner spustíte, kontejnerový modul v nich vyhledá požadovaný obrázek. Navíc stáhne obrázek z registru pouze v případě, že jej nenajde v žádném z těchto úložišť. Kontejnerový stroj bude moci zapisovat pouze do zapisovatelného úložiště...
Pokud se posunete nahoru a podíváte se na Dockerfile, který používáme k vytvoření obrázku quay.io/buildah/stable, jsou zde řádky jako 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 prvním řádku upravíme /etc/containers/storage.conf uvnitř obrazu kontejneru a řekneme ovladači úložiště, aby použil „additionalimagestores“ ve složce /var/lib/shared. A v dalším řádku vytvoříme sdílenou složku a přidáme pár souborů zámku, aby nedocházelo ke zneužití kontejnerů/úložišť. V podstatě jednoduše vytváříme prázdné úložiště obrázků kontejneru.
Pokud připojíte kontejnery/úložiště na vyšší úrovni, než je tato složka, Buildah bude moci používat obrazy.
Nyní se vraťme k možnosti 2 popsané výše, kdy kontejner Buildah může číst a zapisovat do kontejnerů/ukládat na hostitelích a má tedy maximální výkon díky ukládání obrázků do mezipaměti na úrovni Podman/CRI-O, ale poskytuje minimální zabezpečení. protože může zapisovat přímo do úložiště. Nyní sem přidejte další úložiště a získejte 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řipojen k /var/lib/shared uvnitř kontejneru v režimu pouze pro čtení. Proto při práci v kontejneru může Buildah používat jakékoli obrázky, které byly dříve staženy pomocí Podman/CRI-O (ahoj, rychlost), ale může zapisovat pouze do svého vlastního úložiště (ahoj, zabezpečení). Všimněte si také, že se to děje bez deaktivace separace SELinux pro kontejner.
Důležitý nuan
Za žádných okolností byste neměli odstraňovat žádné obrázky ze základního úložiště. V opačném případě může dojít k selhání kontejneru Buildah.
A to nejsou všechny výhody
Možnosti dalšího úložiště nejsou omezeny na výše uvedený scénář. Můžete například umístit všechny obrazy kontejnerů na sdílené síťové úložiště a poskytnout k němu přístup všem kontejnerům Buildah. Řekněme, že máme stovky obrazů, které náš systém CI/CD pravidelně používá k vytváření obrazů kontejnerů. Všechny tyto obrazy soustředíme na jednoho hostitele úložiště a poté pomocí preferovaných nástrojů síťového úložiště (NFS, Gluster, Ceph, ISCSI, S3...) otevíráme obecný přístup k tomuto úložišti všem uzlům Buildah nebo Kubernetes.
Nyní stačí připojit toto síťové úložiště do kontejneru Buildah na /var/lib/shared a je to - kontejnery Buildah již nemusí stahovat obrázky pomocí pull. Vyhazujeme tak předobslužnou fázi a jsme okamžitě připraveni vyvézt kontejnery.
A samozřejmě to lze použít v rámci živého systému Kubernetes nebo infrastruktury kontejnerů ke spouštění a spouštění kontejnerů kdekoli bez jakéhokoli stahování obrázků. Navíc registr kontejnerů, který obdrží požadavek push, aby do něj nahrál aktualizovaný obrázek, může tento obrázek automaticky odeslat do sdíleného síťového úložiště, kde je okamžitě dostupný všem uzlům.
Obrázky kontejnerů mohou někdy dosáhnout velikosti mnoha gigabajtů. Funkce dodatečného úložiště vám umožňuje vyhnout se klonování takových obrazů mezi uzly a umožňuje spouštění kontejnerů téměř okamžitě.
Kromě toho v současné době pracujeme na nové funkci nazvané připojování překryvných svazků, díky níž bude stavba kontejnerů ještě rychlejší.
Závěr
Spuštění Buildah uvnitř kontejneru v Kubernetes/CRI-O, Podman nebo dokonce Docker je proveditelné, jednoduché a mnohem bezpečnější než použití docker.socket. Výrazně jsme zvýšili flexibilitu práce s obrázky, takže je můžete spouštět různými způsoby, abyste optimalizovali rovnováhu mezi zabezpečením a výkonem.
Funkčnost dodatečného úložiště umožňuje zrychlit nebo dokonce zcela eliminovat stahování obrázků do uzlů.
Zdroj: www.habr.com