Prvním krokem nasazení do Kubernetes je umístění vaší aplikace do kontejneru. V této sérii se podíváme, jak vytvořit obraz malého a bezpečného kontejneru.
Díky Dockeru bylo vytváření obrazů kontejnerů nikdy jednodušší. Uveďte základní obraz, přidejte své změny a vytvořte kontejner.
I když je tento přístup skvělý pro začátek, používání základních obrazů ve výchozím nastavení může vést k nebezpečnému používání velkých obrazů, plných zranitelností.
Navíc většina obrazů v Dockeru používá jako základní obraz Debian nebo Ubuntu, a ačkoliv to zajišťuje skvělou kompatibilitu a snadnou adaptaci (soubor Docker obsahuje pouze dvě řádky kódu), základní obrazy mohou přidat stovky megabajtů dodatečné zátěže do vašeho kontejneru. Například jednoduchý soubor aplikace node.js Go „hello-world“ zabírá přibližně 700 megabajtů, přičemž velikost samotné aplikace činí pouze několik megabajtů.
Celá tato dodatečná zátěž je zbytečná ztráta digitálního prostoru a skvělý úkryt pro zranitelnosti a chyby v systémové bezpečnosti. Pojďme se tedy podívat na dva způsoby, jak zmenšit velikost obrazu kontejneru.
Prvním je použití základních obrazů malé velikosti, druhým je použití návrhového vzoru Builder Pattern. Použití menších základních obrazů je pravděpodobně nejjednodušší způsob, jak snížit velikost vašeho kontejneru. Pravděpodobně právě jazyk nebo technologie, kterou používáte, poskytují původní obraz aplikace mnohem menší velikosti, než je obraz ve výchozím nastavení. Podívejme se na náš kontejner node.js.
Ve výchozím nastavení má základní obraz node:8 velikost 670 MB, zatímco node:8-alpine má pouhých 65 MB, což je desetkrát méně. Použitím menšího základního obrazu Alpine výrazně zmenšíte velikost vašeho kontejneru. Alpine je malá a lehká distribuce Linuxu, která je mezi uživateli Dockeru velmi populární, protože je kompatibilní s mnoha aplikacemi a zároveň zachovává malou velikost kontejnerů. Na rozdíl od standardního obrazu Docker 'node' odstraňuje 'node:alpine' řadu systémových souborů a programů, přičemž ponechává pouze to, co je nezbytné pro spuštění vaší aplikace.
Chcete-li přejít na menší základní obraz, jednoduše aktualizujte Dockerfile, abyste začali používat nový základní obraz:
Nyní, na rozdíl od starého obrazu onbuild, musíte zkopírovat svůj kód do kontejneru a nainstalovat všechny závislosti. V novém Dockerfile kontejner začíná s obrazem node:alpine, poté vytvoří adresář pro kód, nainstaluje závislosti pomocí správce balíčků NPM a nakonec spustí server.js.
Díky této aktualizaci získáte kontejner o velikosti desetkrát menší. Pokud váš programovací jazyk nebo stack nemá možnost snížení základního obrazu, použijte Alpine Linux. Ten také poskytne možnost plně spravovat obsah kontejneru. Použití základních obrazů s malou velikostí je skvělý způsob, jak rychle vytvářet malé kontejnery. Je však možné dosáhnout ještě většího zmenšení pomocí Builder Pattern.
V interpretovaných jazycích je zdrojový kód nejprve předán interpretu a poté je vykonán. V kompilovaných jazycích je zdrojový kód nejprve převeden na zkompilovaný kód. Při kompilaci často používáme nástroje, které ve skutečnosti nejsou potřebné pro spuštění kódu. To znamená, že tyto nástroje můžete úplně odstranit z finálního kontejneru. K tomu lze použít Builder Pattern.
Kód je vytvořen v prvním kontejneru a zkompilován. Poté je zkompilovaný kód zabalen do finálního kontejneru bez kompilátorů a nástrojů potřebných pro kompilaci tohoto kódu. Pojďme tímto procesem projít pomocí aplikace Go. Nejprve přejdeme z obrazu onbuild na Alpine Linux.
Nový Docker soubor začíná s obrazem golang:alpine. Poté vytvoří adresář pro kód, zkopíruje do něj zdrojový kód, zkompiluje 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 jednoduše vyextrahujeme zkompilovaný program a umístíme ho do vlastního kontejneru.
Můžete si všimnout něčeho zvláštního v tomto Docker souboru: obsahuje dvě řádky FROM. První sekce z 4 řádků vypadá přesně tak jako předchozí Docker soubor, s tím rozdílem, že používá klíčové slovo AS, aby pojmenovala tuto fázi. V následující sekci je nová řádka FROM, která umožňuje začít nový obraz, přičemž místo obrazu golang:alpine jako základního obrazu použijeme Raw alpine.
Raw Alpine Linux nemá nainstalované žádné SSL certifikáty, což způsobí selhání většiny API volání přes protokol HTTPS, takže nainstalujeme několik kořenových certifikátů CA.
A teď to nejzajímavější: pro kopírování zkompilovaného kódu z prvního kontejneru do druhého můžeme jednoduše použít příkaz COPY umístěný v 5. řádku druhé sekce. Zkopíruje pouze jeden soubor aplikace a nezasáhne pomocné nástroje Go. Nový vícestupňový Docker soubor bude obsahovat obraz kontejneru o velikosti pouhých 12 megabajtů, přičemž původní obraz kontejneru měl 700 megabajtů, což je velký rozdíl!
Používání malých základních obrazů a Builder Pattern jsou skvélé způsoby, jak vytvářet kontejnery mnohem menších velikostí bez velkého úsilí.
Je možné, že v závislosti na aplikačním stacku existují další způsoby, jak zmenšit velikost obrazu a kontejneru, ale mají opravdu malé kontejnery měřitelné výhody? Podívejme se na dva aspekty, kde jsou malé kontejnery extrémně efektivní – to jsou výkonnost a bezpečnost.
Aby ocenit nárůst výkonu, podívejme se na délku procesu vytváření kontejneru, jeho vložení do registru (push) a následné vytažení odtud (pull). Můžete vidět, že menší kontejner má nepopiratelné výhody oproti většímu kontejneru.
Docker bude ukládat vrstvy do cache, takže další sestavení budou probíhat velmi rychle. Nicméně v mnoha CI systémech, které se používají pro sestavení a testování kontejnerů, vrstvy nejsou cachovány, což přináší výraznou úsporu času. Jak vidíte, doba sestavení velkého kontejneru se v závislosti na výkonu vašeho stroje pohybuje od 34 do 54 sekund, zatímco při použití kontejneru zmenšeného pomocí vzoru Builder je to od 23 do 28 sekund. Pro takové operace bude nárůst výkonu činit 40-50%. Přemýšlejte tedy, kolikrát sestavujete a testujete svůj kód.
Po dokončení konstrukce kontejneru musíte vložit jeho obraz (push container image) do registra kontejnerů, abyste jej mohli použít ve svém Kubernetes clusteru. Doporučuji použít Google Container Registry.
Při použití Google Container Registry (GCR) platíte pouze za „syrové“ úložiště a síť, a dodatečné poplatky za správu kontejnerů nejsou vybírány. Je to důvěrné, bezpečné a velmi rychlé. GCR používá mnoho triků ke zrychlení operace pull. Jak vidíte, vložení obrazu kontejneru Docker Container Image při použití go:onbuild, v závislosti na výkonu počítače, trvá od 15 do 48 sekund, zatímco stejná operace s menším kontejnerem trvá od 14 do 16 sekund, přičemž pro méně výkonné stroje se výhoda rychlosti operace zvyšuje až trojnásobně. Pro velké stroje je doba přibližně stejná, protože GCR používá globální cache pro společnou databázi obrázků, takže je nemusíte stahovat vůbec. V počítači s nízkým výkonem je CPU úzkým místem, takže výhoda používání malých kontejnerů je zde mnohem výraznější.
Pokud používáte GCR, důrazně doporučuji používat Google Container Builder (GCB) jako součást vašeho systému sestavení.
Jak vidíte, jeho použití umožňuje dosáhnout mnohem lepších výsledků při zkracování doby operace Build+Push než dokonce na výkonné stanici – v tomto případě se proces sestavování a odesílání kontejnerů na host zrychluje téměř dvakrát. Navíc každý den získáte zdarma 120 minut sestavování, což většinou splňuje požadavky na vytváření kontejnerů.
Dále se zaměříme na nejdůležitější metriku výkonnosti – rychlost vyjmutí, nebo stahování kontejnerů Pull. A pokud vás příliš nezajímá čas, který je stráven operací push, tak doba procesu pull výrazně ovlivňuje celkový výkon systému. Představte si, že máte cluster se třemi uzly a jeden z nich selže. Pokud používáte systém správy, například Google Kubernetes Engine, automaticky nahradí nefunkční uzel novým. Avšak tento nový uzel bude úplně prázdný a budete muset do něj přenést všechny vaše kontejnery, aby začal fungovat. Pokud bude operace pull dostatečně dlouhá, váš cluster bude po celou tuto dobu pracovat s nižším výkonem.
Existuje mnoho případů, kdy může k takové situaci dojít: je to například přidání nového uzlu do clusteru, aktualizace uzlů nebo i přepnutí na nový kontejner pro nasazení. Minimální doba vyjmutí pull se tak stává klíčovým faktorem. Nepochybně je, že malý kontejner se stahuje mnohem rychleji než velký. Pokud používáte několik kontejnerů v clusteru Kubernetes, úspora času může být velmi významná.
Podívejte se na toto porovnání: operace pull při práci s malými kontejnery trvá 4-9krát méně času v závislosti na výkonu stroje, než stejná operace při použití go:onbuild. Používání sdílených základních obrazů kontejnerů malého formátu výrazně urychluje dobu a rychlost, s jakou mohou nové uzly Kubernetes být nasazeny a připojeny k internetu.
Pojďme se podívat na otázku bezpečnosti. Předpokládá se, že menší kontejnery jsou mnohem bezpečnější než velké, protože mají menší útočnou plochu. Je to opravdu pravda? Jednou z nejužitečnějších funkcí Google Container Registry je možnost automaticky skenovat vaše kontejnery na zranitelnosti. Před několika měsíci jsem vytvořil jak onbuild, tak vícefázové kontejnery, takže se podívejme, zda tam existují nějaká zranitelná místa.
Výsledek je ohromující: v malém kontejneru byly nalezeny pouze 3 střední zranitelnosti, zatímco ve velkém - 16 kritických a 376 dalších zranitelností. Pokud se podíváme na obsah velkého kontejneru, je 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. Když lidé hovoří o velké útočné ploše, přesně tímto mají na mysli.
Závěr je jasný: vytvářejte malé kontejnery, protože poskytují skutečné výhody v oblasti výkonu a bezpečnosti vašeho systému.
Malá reklama 🙂
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ých materiálů? Podpořte nás objednávkou nebo doporučením známým, , unikátní alternativa entry-level serverů, kterou jsme pro vás vymysleli: (k dispozici varianty s RAID1 a RAID10, až 24 jader a až 40GB DDR4).
Dell R730xd je dvakrát levnější v datovém centru Equinix Tier IV v Amsterdamu? Jen u nás v Nizozemsku! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 $! Čtěte o tom
Zdroj: habr.com
