A Kubernetes rendszerbe történő üzembe helyezés első lépése az alkalmazás tárolóba helyezése. Ebben a sorozatban megvizsgáljuk, hogyan hozhat létre kisméretű, biztonságos tárolóképet.
A Dockernek köszönhetően a konténerképek létrehozása még soha nem volt ilyen egyszerű. Adjon meg egy alapképet, adja hozzá a módosításokat, és hozzon létre egy tárolót.
Noha ez a technika nagyszerű az induláshoz, az alapértelmezett alapképek használata nem biztonságos munkavégzéshez vezethet a sebezhetőségekkel teli nagyméretű képekkel.
Ezenkívül a legtöbb Docker-kép Debiant vagy Ubuntu-t használ alapképként, és bár ez kiváló kompatibilitást és egyszerű testreszabást biztosít (egy Docker-fájl csak két sornyi kódot vesz igénybe), az alapképek több száz megabájt további terhelést adhatnak a tárolóhoz. Például egy egyszerű node.js fájl egy Go "hello-world" alkalmazáshoz körülbelül 700 megabájt, míg a tényleges alkalmazás csak néhány megabájt méretű.
Tehát ez a többletmunka a digitális tér pazarlása, és remek búvóhely a biztonsági rések és hibák számára. Nézzünk tehát két módot a tárolókép méretének csökkentésére.
Az első a kis alapképek, a második a Builder Pattern használata. Kisebb alapképek használata valószínűleg a legegyszerűbb módja a tároló méretének csökkentésének. Valószínűleg a használt nyelv vagy verem olyan eredeti alkalmazásképet biztosít, amely sokkal kisebb, mint az alapértelmezett kép. Vessünk egy pillantást a node.js tárolónkra.
A Dockerben alapértelmezés szerint a node:8 alapképméret 670 MB, a node: 8-alpine képméret pedig csak 65 MB, azaz 10-szer kisebb. A kisebb alpesi alapkép használatával jelentősen csökkenti a konténer méretét. Az Alpine egy kicsi és könnyű Linux disztribúció, amely nagyon népszerű a Docker-felhasználók körében, mivel számos alkalmazással kompatibilis, miközben a konténereket kicsiben tartja. A szabványos Docker „node” képpel ellentétben a „node:alpine” sok szolgáltatásfájlt és programot eltávolít, és csak azokat hagyja meg, amelyek elegendőek az alkalmazás futtatásához.
Ha egy kisebb alapképre szeretne váltani, egyszerűen frissítse a Dockerfile-t, hogy elkezdjen dolgozni az új alapképpel:
Most, a régi onbuild lemezképtől eltérően, be kell másolnia a kódot a tárolóba, és telepítenie kell a függőségeket. Egy új Dockerfile-ban a tároló egy node:alpine képfájllal indul, majd létrehoz egy könyvtárat a kód számára, telepíti a függőségeket az NPM-csomagkezelő segítségével, és végül a server.js fájlt futtatja.
Ez a frissítés 10-szer kisebb méretű tárolót eredményez. Ha a programozási nyelv vagy a verem nem rendelkezik alapkép-csökkentési funkcióval, használja az Alpine Linuxot. Lehetővé teszi a tartály tartalmának teljes körű kezelését is. A kis alapképek használata nagyszerű módja a kis tárolók gyors létrehozásának. De még nagyobb csökkentés érhető el a Builder Pattern használatával.
Az értelmezett nyelveken a forráskódot először átadják a tolmácsnak, majd közvetlenül végrehajtják. A lefordított nyelveken a forráskódot először lefordított kóddá alakítják. A fordítás azonban gyakran olyan eszközöket használ, amelyekre valójában nincs szükség a kód futtatásához. Ez azt jelenti, hogy ezeket az eszközöket teljesen eltávolíthatja a végső tartályból. Ehhez használhatja a Builder Patternet.
A kód az első tárolóban jön létre és lefordításra kerül. A lefordított kód ezután egy végső konténerbe kerül a kód fordításához szükséges fordítók és eszközök nélkül. Futtassunk egy Go alkalmazást ezen a folyamaton. Először az onbuild lemezképről az Alpine Linuxra térünk át.
Az új Dockerfile-ban a tároló egy golang:alpine képpel kezdődik. Ezután létrehoz egy könyvtárat a kód számára, bemásolja a forráskódba, összeállítja a forráskódot, és futtatja az alkalmazást. Ez a tároló sokkal kisebb, mint az onbuild konténer, de még mindig tartalmazza a fordítót és más Go eszközöket, amelyekre nincs igazán szükségünk. Tehát csak bontsuk ki a lefordított programot, és tegyük a saját tárolójába.
Ebben a Docker-fájlban valami furcsaságot észlelhet: két FROM sort tartalmaz. Az első 4 soros szakasz pontosan ugyanúgy néz ki, mint az előző Dockerfile, kivéve, hogy az AS kulcsszót használja ennek a szakasznak a megnevezéséhez. A következő részben egy új FROM sor található az új kép indításához, ahol a golang:alpine kép helyett a Raw alpine-t használjuk alapképként.
A Raw Alpine Linuxra nincs telepítve SSL-tanúsítvány, ami a legtöbb HTTPS-en keresztüli API-hívás meghiúsulását okozza, ezért telepítsünk néhány gyökér CA-tanúsítványt.
Most jön a szórakoztató rész: a lefordított kód másolásához az első tárolóból a másodikba, egyszerűen használja a COPY parancsot, amely a második szakasz 5. sorában található. Csak egy alkalmazásfájlt másol, és nincs hatással a Go segédprogramokra. Az új, többlépcsős Docker-fájl csak 12 megabájt méretű konténerképet tartalmaz majd, szemben az eredeti 700 megabájtos tárolóképpel, ami nagy különbség!
Így a kis alapképek és az Builder Pattern használata nagyszerű módja annak, hogy sokkal kisebb konténereket készítsen sok munka nélkül.
Lehetséges, hogy az alkalmazásveremtől függően további módszerek is vannak a kép- és tárolóméret csökkentésére, de valóban van-e mérhető előnye a kisméretű tárolóknak? Nézzünk meg két olyan területet, ahol a kis konténerek rendkívül hatékonyak – a teljesítmény és a biztonság.
A teljesítménynövekedés értékeléséhez vegye figyelembe a tároló létrehozásának, a rendszerleíró adatbázisba való behelyezésének (push), majd onnan történő lekérésének (pull) folyamatának időtartamát. Láthatja, hogy egy kisebb tárolónak határozott előnye van a nagyobb konténerrel szemben.
A Docker gyorsítótárba helyezi a rétegeket, így a következő buildek nagyon gyorsak lesznek. A konténerek felépítésére és tesztelésére használt CI-rendszerek közül azonban sok nem gyorsítótárazzák a rétegeket, így jelentős időmegtakarítás érhető el. Amint láthatja, egy nagy konténer megépítésének ideje a gép teljesítményétől függően 34-54 másodperc, konténer használatakor pedig a Builder Pattern használatával - 23-ról 28 másodpercre. Az ilyen jellegű műveleteknél a termelékenység növekedése 40-50%. Tehát gondoljon csak arra, hányszor készíti el és teszteli a kódot.
A tároló felépítése után a képfájlt (tárolókép leküldése) be kell helyeznie a tároló-nyilvántartásba, hogy ezután felhasználhassa a Kubernetes-fürtben. Javaslom a Google Container Registry használatát.
A Google Container Registry (GCR) segítségével csak a nyers tárolásért és a hálózatépítésért kell fizetnie, és nincsenek további konténerkezelési díjak. Privát, biztonságos és nagyon gyors. A GCR számos trükköt alkalmaz a húzási művelet felgyorsítására. Amint láthatja, egy Docker Container Image tároló behelyezése a go:onbuild használatával 15-48 másodpercig tart a számítógép teljesítményétől függően, és ugyanez a művelet egy kisebb tárolóval 14-16 másodpercig tart, és kevésbé termelékeny gépeknél. a működési sebesség előnye 3-szorosára nő. Nagyobb gépeknél az idő nagyjából ugyanannyi, mivel a GCR globális gyorsítótárat használ a képek megosztott adatbázisához, vagyis egyáltalán nem kell betölteni őket. Egy kis fogyasztású számítógépben a CPU jelenti a szűk keresztmetszetet, így a kis konténerek használatának előnye itt sokkal nagyobb.
Ha GCR-t használ, erősen ajánlom a Google Container Builder (GCB) használatát az összeállítási rendszer részeként.
Amint látható, használatával sokkal jobb eredményeket érhet el a Build+Push művelet időtartamának csökkentésében, mint akár egy produktív gép esetében is - ebben az esetben a konténerek felépítése és a gazdagéphez való küldése majdnem 2-szer gyorsabb. Ráadásul minden nap 120 ingyenes építési percet kap, ami a legtöbb esetben fedezi a konténerépítési igényeit.
Ezután következik a legfontosabb teljesítménymutató – a Pull-tárolók lekérésének vagy letöltésének sebessége. És ha nem sokat törődik a push művelettel töltött idővel, akkor a lehúzási folyamat hossza komoly hatással van a rendszer általános teljesítményére. Tegyük fel, hogy van egy három csomópontból álló fürt, és az egyik meghibásodik. Ha olyan felügyeleti rendszert használ, mint például a Google Kubernetes Engine, az automatikusan lecseréli a halott csomópontot egy újra. Ez az új csomópont azonban teljesen üres lesz, és az összes tárolót bele kell húznia, hogy működjön. Ha a lehúzási művelet elég sokáig tart, a fürt egész idő alatt alacsonyabb teljesítménnyel fog futni.
Számos eset fordulhat elő, amikor ez megtörténhet: új csomópont hozzáadása egy fürthöz, csomópontok frissítése, vagy akár új tárolóra váltás a telepítéshez. Így kulcsfontosságú tényezővé válik a kihúzási idő minimalizálása. Tagadhatatlan, hogy egy kis tároló sokkal gyorsabban tölt le, mint egy nagy. Ha több tárolót futtat egy Kubernetes-fürtben, az időmegtakarítás jelentős lehet.
Vessen egy pillantást erre az összehasonlításra: a kis konténereken végzett húzási művelet a gép teljesítményétől függően 4-9-szer kevesebb időt vesz igénybe, mint ugyanaz a művelet a go:onbuild használatával. A megosztott, kisméretű konténer-alapképek használata jelentősen felgyorsítja az új Kubernetes-csomópontok üzembe helyezésének és online megjelenésének idejét és sebességét.
Nézzük a biztonság kérdését. A kisebb konténereket sokkal biztonságosabbnak tekintik, mint a nagyobbakat, mert kisebb a támadási felületük. Ez valóban? A Google Container Registry egyik leghasznosabb funkciója az a képesség, hogy automatikusan átvizsgálja a tárolókat a sebezhetőségekért. Néhány hónappal ezelőtt létrehoztam az onbuild és a többlépcsős konténereket is, szóval nézzük meg, vannak-e sérülékenységek.
Az eredmény elképesztő: egy kis konténerben mindössze 3 közepes méretű sebezhetőséget észleltek, egy nagy konténerben pedig 16 kritikus és 376 egyéb sebezhetőséget találtak. Ha megnézzük egy nagy konténer tartalmát, láthatjuk, hogy a legtöbb biztonsági probléma semmi köze az alkalmazásunkhoz, hanem olyan programokhoz kapcsolódik, amelyeket nem is használunk. Tehát amikor az emberek nagy támadási felületről beszélnek, akkor erre gondolnak.
A lényeg egyértelmű: építsen kis konténereket, mert valódi teljesítmény- és biztonsági előnyöket biztosítanak a rendszer számára.
Néhány hirdetés 🙂
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, , a belépő szintű szerverek egyedülálló analógja, amelyet mi találtunk ki Önnek: (RAID1 és RAID10, akár 24 maggal és akár 40 GB DDR4-gyel is elérhető).
A Dell R730xd kétszer olcsóbb az amszterdami Equinix Tier IV adatközpontban? Csak itt Hollandiában! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollártól! Olvasni valamiről
Forrás: will.com