Prvním krokem nasazení na Kubernetes je umístění aplikace do kontejneru. V této sérii se podíváme na to, jak můžete vytvořit malý, bezpečný obrázek kontejneru.
Díky Dockeru nebylo vytváření obrázků kontejnerů nikdy jednodušší. Zadejte základní obrázek, přidejte změny a vytvořte kontejner.
I když je tato technika skvělá pro začátek, použití výchozích základních obrázků může vést k nebezpečné práci s velkými obrázky plnými zranitelností.
Většina obrazů v Dockeru navíc používá jako základní obraz Debian nebo Ubuntu, a přestože to poskytuje vynikající kompatibilitu a snadné přizpůsobení (soubor Dockeru zabere pouze dva řádky kódu), základní obrazy mohou do vašeho kontejneru přidat další stovky megabajtů. Například jednoduchý soubor node.js pro aplikaci Go „hello-world“ má asi 700 megabajtů, zatímco vaše skutečná aplikace má velikost jen několik megabajtů.
Takže celá tato další zátěž je plýtváním digitálním prostorem a skvělým úkrytem pro bezpečnostní zranitelnosti a chyby. Podívejme se tedy na dva způsoby, jak zmenšit velikost obrázku kontejneru.
Prvním je použití malých základních obrázků, druhým použití Builder Pattern. Použití menších základních obrázků je pravděpodobně nejjednodušší způsob, jak zmenšit velikost kontejneru. Jazyk nebo zásobník, který používáte, s největší pravděpodobností poskytuje původní obraz aplikace, který je mnohem menší než výchozí obraz. Pojďme se podívat na náš kontejner node.js.
Ve výchozím nastavení v Dockeru je velikost základního obrázku node:8 670 MB a velikost obrázku node: 8-alpine je pouze 65 MB, tedy 10krát menší. Použitím menšího základního obrázku Alpine výrazně zmenšíte velikost svého kontejneru. Alpine je malá a lehká linuxová distribuce, která je mezi uživateli Dockeru velmi oblíbená, protože je kompatibilní s mnoha aplikacemi a zároveň udržuje malé kontejnery. Na rozdíl od standardního obrazu "node" Dockeru, "node:alpine" odstraňuje mnoho servisních souborů a programů a ponechává pouze ty, které jsou dostatečné pro spuštění vaší aplikace.
Chcete-li přejít na menší základní bitovou kopii, jednoduše aktualizujte Dockerfile a začněte pracovat s novou základní bitovou kopií:
Nyní, na rozdíl od starého onbuild obrazu, musíte zkopírovat kód do kontejneru a nainstalovat všechny závislosti. V novém souboru Dockerfile kontejner začíná obrázkem node:alpine, poté vytvoří adresář pro kód, nainstaluje závislosti pomocí správce balíčků NPM a nakonec spustí server.js.
Výsledkem tohoto upgradu je kontejner, který je 10krát menší. Pokud váš programovací jazyk nebo zásobník nemá funkci redukce základního obrazu, použijte Alpine Linux. Poskytne také možnost plně spravovat obsah kontejneru. Použití malých základních obrázků je skvělý způsob, jak rychle vytvořit malé nádoby. Ale ještě větší redukce lze dosáhnout pomocí Builder Pattern.
V interpretovaných jazycích je zdrojový kód nejprve předán interpretovi a poté přímo spuštěn. V kompilovaných jazycích je zdrojový kód nejprve převeden na kompilovaný kód. Kompilace však často používá nástroje, které ve skutečnosti nejsou ke spuštění kódu potřeba. To znamená, že tyto nástroje můžete z konečného kontejneru zcela odstranit. K tomu můžete použít Builder Pattern.
Kód je vytvořen v prvním kontejneru a zkompilován. Zkompilovaný kód je pak zabalen do finálního kontejneru bez kompilátorů a nástrojů potřebných ke kompilaci tohoto kódu. Spusťte tímto procesem aplikaci Go. Nejprve se přesuneme od onbuild obrazu k Alpine Linuxu.
V novém souboru Dockerfile kontejner začíná obrázkem golang:alpine. Poté vytvoří adresář pro kód, zkopíruje jej do zdrojového kódu, sestaví tento zdrojový kód a spustí aplikaci. Tento kontejner je mnohem menší než kontejner onbuild, ale stále obsahuje kompilátor a další nástroje Go, které ve skutečnosti nepotřebujeme. Takže jen extrahujeme zkompilovaný program a dáme jej do vlastního kontejneru.
V tomto souboru Docker si můžete všimnout něčeho zvláštního: obsahuje dva řádky FROM. První 4 řádková sekce vypadá úplně stejně jako předchozí Dockerfile kromě toho, že k pojmenování této fáze používá klíčové slovo AS. V další sekci je nový řádek FROM pro spuštění nového obrázku, kde místo obrázku golang:alpine použijeme jako základní obrázek Raw alpine.
Raw Alpine Linux nemá nainstalované žádné certifikáty SSL, což způsobí selhání většiny volání API přes HTTPS, takže nainstalujme nějaké kořenové certifikáty CA.
Nyní přichází ta zábavná část: ke zkopírování zkompilovaného kódu z prvního kontejneru do druhého můžete jednoduše použít příkaz COPY umístěný na řádku 5 druhé sekce. Zkopíruje pouze jeden soubor aplikace a neovlivní nástroje nástroje Go. Nový vícestupňový soubor Docker bude obsahovat obrázek kontejneru o velikosti pouze 12 megabajtů ve srovnání s původním obrázkem kontejneru, který měl 700 megabajtů, což je velký rozdíl!
Takže použití malých základních obrázků a Builder Pattern jsou skvělé způsoby, jak vytvořit mnohem menší kontejnery bez velké práce.
Je možné, že v závislosti na zásobníku aplikací existují další způsoby, jak snížit velikost obrázku a kontejneru, ale mají malé kontejnery skutečně měřitelný přínos? Podívejme se na dvě oblasti, kde jsou malé kontejnery mimořádně efektivní – výkon a bezpečnost.
Chcete-li vyhodnotit zvýšení výkonu, zvažte dobu trvání procesu vytváření kontejneru, jeho vkládání do registru (push) a následného načítání odtud (pull). Můžete vidět, že menší nádoba má výraznou výhodu oproti nádobě větší.
Docker uloží vrstvy do mezipaměti, takže následné sestavení bude velmi rychlé. Mnoho systémů CI používaných k vytváření a testování kontejnerů však neukládá vrstvy do mezipaměti, takže dochází k výrazné úspoře času. Jak vidíte, čas na sestavení velkého kontejneru je v závislosti na výkonu vašeho stroje od 34 do 54 sekund a při použití kontejneru zkrácený pomocí Builder Pattern - z 23 na 28 sekund. U operací tohoto druhu bude zvýšení produktivity činit 40–50 %. Přemýšlejte o tom, kolikrát svůj kód sestavujete a testujete.
Po sestavení kontejneru je třeba vložit jeho image (obraz kontejneru push) do registru kontejneru, abyste jej pak mohli použít ve svém clusteru Kubernetes. Doporučuji používat Google Container Registry.
S Google Container Registry (GCR) platíte pouze za nezpracované úložiště a síť a neplatíte žádné další poplatky za správu kontejnerů. Je to soukromé, bezpečné a velmi rychlé. GCR používá mnoho triků k urychlení operace pull. Jak můžete vidět, vložení kontejneru Docker Container Image pomocí go:onbuild bude trvat 15 až 48 sekund v závislosti na výkonu počítače a stejná operace s menším kontejnerem bude trvat 14 až 16 sekund a u méně produktivních strojů výhoda v provozní rychlosti se zvyšuje 3krát. U větších strojů je doba přibližně stejná, protože GCR používá globální mezipaměť pro sdílenou databázi obrázků, což znamená, že je nemusíte vůbec načítat. V počítači s nízkou spotřebou energie je CPU úzkým hrdlem, takže výhoda použití malých kontejnerů je zde mnohem větší.
Pokud používáte GCR, důrazně doporučuji používat Google Container Builder (GCB) jako součást vašeho systému sestavování.
Jak můžete vidět, jeho použití vám umožňuje dosáhnout mnohem lepších výsledků při zkrácení doby trvání operace Build+Push než dokonce i produktivní stroj - v tomto případě je proces sestavování a odesílání kontejnerů hostiteli zrychlen téměř dvakrát . Navíc každý den získáte 2 minut na stavbu zdarma, což ve většině případů pokryje vaše potřeby při stavbě kontejnerů.
Následuje nejdůležitější metrika výkonu – rychlost načítání nebo stahování kontejnerů Pull. A pokud se moc nestaráte o čas strávený push operací, pak má délka procesu stahování vážný dopad na celkový výkon systému. Řekněme, že máte shluk tří uzlů a jeden z nich selže. Pokud používáte systém správy, jako je Google Kubernetes Engine, automaticky nahradí mrtvý uzel novým. Tento nový uzel však bude zcela prázdný a budete do něj muset přetáhnout všechny své kontejnery, aby začal fungovat. Pokud operace stahování trvá dostatečně dlouho, váš cluster poběží celou dobu s nižším výkonem.
Existuje mnoho případů, kdy k tomu může dojít: přidání nového uzlu do clusteru, upgrade uzlů nebo dokonce přechod na nový kontejner pro nasazení. Klíčovým faktorem se tak stává minimalizace doby vytahování. Je nepopiratelné, že malý kontejner se stahuje mnohem rychleji než velký. Pokud provozujete více kontejnerů v clusteru Kubernetes, úspora času může být značná.
Podívejte se na toto srovnání: operace tažení na malých kontejnerech trvá 4-9krát méně času, v závislosti na výkonu stroje, než stejná operace pomocí go:onbuild. Použití sdílených bitových kopií malých kontejnerů výrazně zrychluje čas a rychlost, s jakou lze nové uzly Kubernetes nasadit a připojit se online.
Podívejme se na otázku bezpečnosti. Menší nádoby jsou považovány za mnohem bezpečnější než ty větší, protože mají menší útočnou plochu. Je to skutečné? Jednou z nejužitečnějších funkcí Google Container Registry je schopnost automaticky skenovat vaše kontejnery na zranitelnosti. Před několika měsíci jsem vytvořil jak onbuild, tak vícestupňové kontejnery, tak se podívejme, jestli tam nejsou nějaké zranitelnosti.
Výsledek je úžasný: v malém kontejneru byly detekovány pouze 3 střední zranitelnosti a ve velkém kontejneru bylo nalezeno 16 kritických a 376 dalších zranitelností. Pokud se podíváme na obsah velkého kontejneru, můžeme vidět, že většina bezpečnostních problémů nemá nic společného s naší aplikací, ale souvisí s programy, které ani nepoužíváme. Takže když lidé mluví o velké útočné ploše, mají na mysli právě to.
Závěr je jasný: vytvářejte malé kontejnery, protože poskytují vašemu systému skutečné výhody v oblasti výkonu a zabezpečení.
Nějaké inzeráty 🙂
Děkujeme, že s námi zůstáváte. Líbí se vám naše články? Chcete vidět více zajímavého obsahu? Podpořte nás objednávkou nebo doporučením přátelům, , jedinečný analog serverů základní úrovně, který jsme pro vás vymysleli: (k dispozici s RAID1 a RAID10, až 24 jader a až 40 GB DDR4).
Dell R730xd 2krát levnější v datovém centru Equinix Tier IV v Amsterdamu? Pouze zde V Nizozemsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 $! Číst o
Zdroj: www.habr.com