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 vagy hasonló rendszer. Tegyük fel, hogy van egy CI/CD-nk, ami folyamatosan képeket készít, aztán valami ilyesmi A /Kubernetes nagyon hasznos lenne a terheléselosztás szempontjából. Egészen a közelmúltig a legtöbb ember egyszerűen hozzáférést adott a tárolóknak egy Docker-foglalathoz, és lehetővé tette számukra a docker build parancs futtatását. hogy ez nagyon nem biztonságos, sőt, még rosszabb, mint jelszó nélküli root vagy sudo megadása.
Tehát az emberek folyamatosan egy konténerben próbálják futtatni a Buildah-t. Röviden: létrehoztunk véleményünk szerint hogyan a legjobb a Buildah-t egy tárolóban futtatni, és a megfelelő képeket közzétenni . Kezdjük el...
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 , mert jelenleg az OverlayFS csak akkor tud felcsatolni, ha SYS_ADMIN engedélyeket ad neki a Linux képességein keresztül. És a Buildah-tárolóinkat minden root jogosultság nélkül szeretnénk futtatni. A Fuse-overlay elég gyors, és jobban teljesít, mint a VFS tároló-illesztőprogram. Vegye figyelembe, hogy ha egy Buildah tárolót Fuse használatával futtat, a /dev/fuse eszközt meg kell adni.
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. támogatja a további csak olvasható képtárak csatlakoztatásának koncepcióját. Például beállíthat egy átfedéses tárolóterületet az egyik gépen, majd az NFS segítségével csatlakoztathatja ezt a tárolót egy másik gépre, és az onnan származó képeket lekéréses letöltés nélkül használhatja fel. Erre a tárhelyre azért van szükségünk, hogy a gazdagépről kötetként csatlakoztathassunk néhány képtárat, és a tárolóban használhassuk.
# 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
У van egy olyan menő dolog, mint a kiegészítő tárolók (további boltok), aminek köszönhetően a konténerek indításakor és felépítésekor a konténermotorok csak olvasható overlay módban használhatják a külső képtárakat. Valójában egy vagy több írásvédett tárolót is hozzáadhat a storage.conf fájlhoz, így a tároló elindulásakor a konténermotor megkeresi bennük a kívánt képet. Ezenkívül a rendszerleíró adatbázisból csak akkor tölti le a képet, ha nem találja egyik tárolóban sem. A konténermotor csak írható tárhelyre tud majd írni...
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
