Mi a szépsége a konténer futtatókörnyezetének külön eszközkomponensekre történő szétválasztásában? Különösen az a tény, hogy ezeket az eszközöket el lehet kezdeni kombinálni, hogy megvédjék egymást.
Sok embert vonz az az ötlet, hogy OCI konténerképeket építsenek be
Tehát az emberek folyamatosan egy konténerben próbálják futtatni a Buildah-t. Röviden: létrehoztunk
beállítás
Ezek a képek a Dockerfilesből épülnek fel, amelyek a mappában található Buildah tárhelyben találhatók
Itt megfontoljuk
# 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
A gazdagép Linux kernelének szintjén implementált OverlayFS helyett a konténeren belüli programot használjuk
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
Ezután létrehozunk egy könyvtárat a további adattárak számára.
# 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
Végül a BUILDAH_ISOLATION környezeti változót használjuk, hogy megmondjuk a Buildah-tárolónak, hogy alapértelmezés szerint chroot elkülönítéssel induljon. Itt nincs szükség további szigetelésre, mivel már konténerben dolgozunk. Ahhoz, hogy a Buildah létrehozhassa saját névtérrel elválasztott tárolóit, a SYS_ADMIN jogosultságra van szükség, ami a tároló SELinux és SECCOMP szabályainak lazítását tenné szükségessé, ami ütközne a biztonságos tárolóból való építési beállításunkkal.
Futtassa a Buildah-t egy tárolóban
A fent tárgyalt Buildah konténer képséma lehetővé teszi az ilyen tárolók elindításának rugalmas megváltoztatását.
Sebesség kontra biztonság
A számítógép biztonsága mindig egy kompromisszum a folyamat sebessége és a körülötte lévő védelem között. Ez az állítás a konténerek összeszerelésére is igaz, ezért az alábbiakban megvizsgáljuk az ilyen kompromisszum lehetőségeit.
A fent tárgyalt konténerkép a /var/lib/containers könyvtárban fogja megőrizni a tárhelyét. Ezért ehhez a mappához kell tartalmat csatolnunk, és ennek módja nagyban befolyásolja a konténerképek felépítésének sebességét.
Nézzünk meg három lehetőséget.
Az 1 opció. Ha maximális biztonságra van szükség, akkor minden konténerhez létrehozhat saját mappát a konténerek / kép számára, és csatlakoztathatja a konténerhez a kötet-mount segítségével. Ezenkívül helyezze el a környezeti könyvtárat magában a tárolóban, a /build mappában:
# 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
Biztonság. Az ilyen tárolóban futó Buildah maximális biztonsággal rendelkezik: képességei nem kapnak root jogosultságokat, és minden SECOMP és SELinux korlátozás vonatkozik rá. Egy ilyen konténer akár User Namespace elkülönítéssel is futtatható, ha hozzáadunk egy opciót, mint például a --uidmap 0:100000:10000.
Teljesítmény. De a teljesítmény itt minimális, mivel a konténer-nyilvántartásokból származó képek minden alkalommal átmásolódnak a gazdagépre, és a gyorsítótárazás nem működik a „nincs mód” szóból. Amikor befejezte munkáját, a Buildah-tárolónak el kell küldenie a képet a rendszerleíró adatbázisnak, és meg kell semmisítenie a tartalmat a gazdagépen. A konténerkép legközelebbi elkészítésekor újra le kell tölteni a registry-ből, mivel addigra semmi sem marad a gazdagépen.
Az 2 opció. Ha Docker-szintű teljesítményre van szüksége, a gazdagép tárolóját/tárolóját közvetlenül a tárolóba csatlakoztathatja.
# 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
Biztonság. Ez a legkevésbé biztonságos módja a tárolók létrehozásának, mivel lehetővé teszi a tároló számára, hogy módosítsa a gazdagépen lévő tárhelyet, és potenciálisan rosszindulatú képet csúsztasson a Podman vagy a CRI-O rendszerbe. Ezenkívül le kell tiltania a SELinux szétválasztást, hogy a Buildah tárolóban lévő folyamatok kölcsönhatásba léphessenek a gazdagépen található tárolóval. Ne feledje, hogy ez a lehetőség még mindig jobb, mint egy Docker-foglalat, mivel a tárolót blokkolják a fennmaradó biztonsági szolgáltatások, és nem tud egyszerűen felvenni és futtatni bármely tárolót a gazdagépen.
Teljesítmény. Itt ez a maximum, mivel a gyorsítótárazás teljes mértékben érintett. Ha a Podman vagy a CRI-O már letöltötte a kívánt képet a gazdagépre, akkor a konténerben lévő Buildah folyamatnak nem kell újra letöltenie, és a későbbi, ezen a képen alapuló buildek is el tudják venni a szükségeset a gyorsítótárból. .
Az 3 opció. Ennek a módszernek az a lényege, hogy több képet egy projektben egyesítünk, a konténerképek közös mappájával.
# 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
Ebben a példában nem töröljük a projektmappát (/var/lib/project3) a futtatások között, így a projekten belüli összes későbbi build kihasználja a gyorsítótárazás előnyeit.
Biztonság. Valami az 1. és 2. lehetőség között. Egyrészt a konténerek nem férnek hozzá a gazdagépen található tartalomhoz, és ennek megfelelően nem csúsztathatnak be valami rosszat a Podman / CRI-O képtárba. Másrészt a saját projektjén belül egy konténer zavarhatja más konténerek összeszerelését.
Teljesítmény. Itt rosszabb, mint a megosztott gyorsítótár használata a gazdagép szintjén, mivel nem használhat olyan képeket, amelyeket már letöltöttek a Podman / CRI-O segítségével. Ha azonban a Buildah letöltötte a képet, az a kép felhasználható a projekten belüli bármely további összeállításban.
További tárhely
У
Ha felfelé görgetünk, és megnézzük a Dockerfile-t, amelyet a quay.io/buildah/stable kép elkészítéséhez használunk, akkor a következő sorokat láthatjuk:
# 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
Az első sorban módosítjuk az /etc/containers/storage.conf fájlt a tárolókép belsejében, és azt mondjuk a tároló-illesztőprogramnak, hogy használja az "additionalimagestores"-t a /var/lib/shared mappában. És a következő sorban létrehozunk egy megosztott mappát, és hozzáadunk néhány zárfájlt, hogy ne történjen visszaélés a tárolókkal / tárolókkal. Lényegében csak egy üres konténer képtárat hozunk létre.
Ha a konténereket/tárhelyet e mappa fölé helyezi, a Buildah képes lesz használni a képeket.
Most térjünk vissza a fent tárgyalt 2. lehetőséghez, amikor a Buildah konténer tud olvasni és írni a konténerekbe / tárolni a gazdagépeken, és ennek megfelelően maximális teljesítményt nyújt a Podman / CRI-O szintű képgyorsítótárnak köszönhetően, de minimális biztonságot nyújt, mivel közvetlenül a tárolóba tud írni. Most pedig további tárhelyet helyezünk el ide, és mindkét világból a legjobbat hozzuk ki.
# 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
Ne feledje, hogy a gazdagép /var/lib/containers/storage fájlja a tárolón belüli /var/lib/shared fájlhoz van csatlakoztatva írásvédett módban. Ezért konténerben dolgozva a Buildah bármilyen képet használhat, amelyet már letöltöttek a Podman / CRI-O segítségével (hello, speed), de csak a saját tárhelyére tud írni (hello, security). Vegye figyelembe azt is, hogy ez a tároló SELinux szétválasztásának letiltása nélkül történik.
Fontos árnyalat
Semmilyen körülmények között nem szabad képeket törölni az alapul szolgáló tárból. Ellenkező esetben a Buildah tároló összeomolhat.
És ez még nem minden előny.
A további tárolás lehetőségei nem korlátozódnak a fenti forgatókönyvre. Például elhelyezheti az összes tárolóképet egy megosztott hálózati tárolóban, és hozzáférést biztosíthat az összes Buildah-tárolónak. Tegyük fel, hogy több száz képünk van, amelyeket a CI/CD rendszerünk rendszeresen használ konténeres képek készítéséhez. Ezeket a képeket egyetlen tárhelyre koncentráljuk, majd a preferált hálózati tárolóeszközök (NFS, Gluster, Ceph, iSCSI, S3...) segítségével megosztjuk ezt a tárhelyet az összes Buildah vagy Kubernetes csomóponttal.
Most már elég ezt a hálózati tárolót a /var/lib/shared Buildah tárolójába beilleszteni, és ennyi – a Buildah konténereknek már egyáltalán nem kell húzással letölteniük a képeket. Így kidobjuk az előnépesítési fázist, és azonnal készen állunk a konténerek kigörgetésére.
És természetesen ez egy élő Kubernetes rendszeren vagy konténer-infrastruktúrán belül használható konténerek indítására és futtatására bárhol, képletöltés nélkül. Ezen túlmenően, ha egy konténer-nyilvántartás egy leküldési kérést kap egy frissített képfájl feltöltésére, automatikusan elküldheti ezt a képet egy megosztott hálózati tárolóra, ahol azonnal elérhető minden csomópont számára.
A tárolóképek néha több gigabájt méretűek is lehetnek. A további tárolók funkcionalitása szükségtelenné teszi az ilyen képek csomópontok általi klónozását, és a konténerek elindítását szinte azonnalivá teszi.
Emellett jelenleg egy új átfedő kötetrögzítő funkción dolgozunk, amely még gyorsabbá teszi a konténerek építését.
Következtetés
A Buildah futtatása egy tárolóban Kubernetes/CRI-O környezetben, Podmanben vagy akár Dockerben teljesen lehetséges, és egyszerű és sokkal biztonságosabb, mint a docker.socket használata. Nagymértékben megnöveltük a képekkel végzett munka rugalmasságát, és most már többféleképpen futtathatja őket a biztonság és a teljesítmény közötti legjobb egyensúly érdekében.
A további tárolók funkcionalitása lehetővé teszi a képek csomópontokba való letöltésének felgyorsítását vagy akár teljesen megszüntetését.
Forrás: will.com