Někteří lidé říkají, že na linuxových distribucích již nezáleží s kontejnery. Alternativní přístupy, jako je distroless a scratch kontejnery, se zdají být v módě. Zdá se, že zvažujeme a činíme technologická rozhodnutí spíše na základě módního citu a okamžitého emocionálního uspokojení než přemýšlení o sekundárních účincích našich rozhodnutí. Měli bychom si klást otázky jako:Jak tyto volby ovlivní údržbu po šesti měsících? Jaké jsou technické kompromisy? Jak tato změna paradigmatu ovlivňuje naše sestavovací systémy ve velkém?
Je frustrující se na to dívat. Pokud zapomeneme, že inženýrství je hra s nulovým součtem s měřitelnými kompromisy – výhodami a nevýhodami, s náklady a přínosy různých přístupů – uděláme medvědí službu sobě, uděláme medvědí službu našim zaměstnavatelům a uděláme svým kolegům, kteří nakonec udrží naše kód medvědí službu. Nakonec všem správcům (zdravíme správce!) škodíme tím, že si nevážíme jejich práce.
Pochopení problému
Abychom problém pochopili, musíme prozkoumat, proč jsme vůbec začali používat distribuce Linuxu. Důvody bych seskupil do dvou hlavních skupin:jádra a další balíčky. Kompilace jader je ve skutečnosti poměrně snadná. Slackware a Gentoo (stále mám slabé místo v srdci) nás to naučili.
Na druhou stranu ohromné množství vývojového a runtime softwaru, který je potřeba zabalit do použitelného linuxového systému, může být skličující. Kromě toho jediný způsob, jak zajistit, aby bylo možné nainstalovat a spolupracovat miliony permutací balíčků, je použití starého paradigmatu:zkompilujte jej a odešlete společně jako věc (tj. linuxová distribuce). Proč tedy distribuce Linuxu kompilují jádra a všechny balíčky dohromady? Jednoduché:zajistit, aby věci fungovaly společně.
Nejprve si povíme něco o jádrech. Jádro je speciální. Zavedení systému Linux bez zkompilovaného jádra je trochu problém. Je to jádro operačního systému Linux a je to první věc, na kterou se spoléháme při startu systému. Jádra mají při kompilaci mnoho různých konfiguračních možností, které mohou mít obrovský vliv na to, jak hardware a software běží na jednom. Sekundárním problémem v tomto segmentu je, že systémový software, jako jsou kompilátory, knihovny C a interpreti, musí být vyladěn pro možnosti, které jste zabudovali do jádra. Gentoo nás to naučilo viscerálním způsobem, což z každého udělalo miniaturního správce distribuce.
S rozpaky (protože jsem posledních pět let pracoval s kontejnery) musím přiznat, že jsem jádra kompiloval poměrně nedávno. Musel jsem zprovoznit vnořené KVM na RHEL 7, abych mohl spouštět OpenShift na virtuálních strojích OpenStack, ve virtuálním stroji KVM na mém notebooku, stejně jako naši sadu Container Development Kit (CDK). #justsayin Stačí říct, že jsem v té době spustil RHEL7 na zcela novém jádře 4.X. Jako každý správný sysadmin jsem se trochu obával, že mi unikají některé důležité konfigurační možnosti a záplaty. A samozřejmě jsem měl uniklo nějaké věci. Režim spánku přestal správně fungovat, moje dokovací stanice přestala fungovat správně a objevilo se mnoho dalších malých, náhodných chyb. Ale fungovalo to dost dobře pro živé demo OpenShift na OpenStack v jediném virtuálním stroji KVM na mém notebooku. No tak, to je docela zábava, ne? Ale to jsem odbočil…
Nyní si promluvme o všech ostatních balíčcích. Zatímco kompilace jádra a souvisejícího systémového softwaru může být složitá, mnohem, mnohem větším problémem z hlediska pracovního zatížení je kompilace tisíců a tisíců balíčků, abychom získali použitelný systém Linux. Každý balíček vyžaduje odbornou znalost předmětu. Některé části softwaru vyžadují spuštění pouze tří příkazů:./configure , vytvořit a proveďte instalaci . Jiné vyžadují mnoho odborných znalostí v oboru, od přidávání uživatelů a konfigurace konkrétních výchozích hodnot v atd ke spouštění poinstalačních skriptů a přidávání souborů systemd unit. Soubor dovedností nezbytných pro tisíce různých částí softwaru, které můžete používat, je skličující pro každého jednotlivce. Pokud však chcete použitelný systém s možností zkoušet nový software, kdykoli budete chtít, musíte se naučit, jak zkompilovat a nainstalovat nový software, než se vůbec začnete učit používat. To je Linux bez linuxové distribuce. To je technický problém, se kterým souhlasíte, když se vzdáte distribuce Linuxu.
Jde o to, že vše musíte sestavit dohromady, abyste zajistili, že to bude fungovat společně s jakoukoli rozumnou úrovní spolehlivosti, a k vytvoření použitelné kohorty balíčků je potřeba spousta znalostí. To je více znalostí, než jaké se kdy kterýkoli vývojář nebo správce systému přiměřeně naučí a uchová. Každý problém, který jsem popsal, se týká vašeho hostitele kontejneru (jádro a systémový software) a obrazu kontejneru (systémový software a všechny ostatní balíčky) – všimněte si překrývání; v obrazu kontejneru jsou také kompilátory, knihovny C, interpreti a JVM.
Řešení
Už to víte, ale řešením jsou linuxové distribuce. Přestaňte číst a pošlete svému nejbližšímu správci balíku (opět pozdravujte správce!) elektronickou pohlednici (počkej, prozradil jsem jen svůj věk?). Ale vážně, tito lidé odvedou spoustu práce a je to opravdu nedoceněné. Kubernetes, Istio, Prometheus a Knative:Dívám se na tebe. Přichází i váš čas, kdy budete v režimu údržby, nadměrně využíváni a nedoceněni. Tento stejný článek napíšu znovu, pravděpodobně o Kubernetes, asi za sedm až 10 let.
První principy sestavení kontejnerů
Stavění od nuly a stavění ze základních obrázků existují kompromisy.
Budování ze základních obrázků
Sestavení ze základních obrazů má tu výhodu, že většina operací sestavení není nic jiného než instalace nebo aktualizace balíčku. Spoléhá na spoustu práce odvedené správci balíčků v distribuci Linuxu. Má to také tu výhodu, že záplatovací událost za šest měsíců – nebo dokonce za 10 let – od nynějška (s RHEL) je událostí správce operací/systémů (mňam aktualizace), nikoli událostí vývojáře (která vyžaduje probírání kódu, aby se zjistilo, proč argument funkce již nefunguje).
Pojďme na to trochu dvakrát kliknout. Aplikační kód se spoléhá na mnoho knihoven, od knihoven mungování JSON po objektově relační mapovače. Na rozdíl od linuxového jádra a Glibc se tyto typy knihoven mění s velmi malým ohledem na porušení kompatibility API. To znamená, že za tři roky ode dneška se vaše opravná událost pravděpodobně stane událostí změny kódu, nikoli událostí aktualizace yum. Rozumím, nechte to zapadnout. Vývojáři, budete odvoláni ve 2:00, pokud bezpečnostní tým nemůže najít hack firewallu, který by zneužití zablokoval.
Vytváření ze základního obrazu není dokonalé; existují nevýhody, jako je velikost všech závislostí, které se zatahují. Díky tomu budou obrázky kontejnerů téměř vždy větší než vytváření od začátku. Další nevýhodou je, že nebudete mít vždy přístup k nejnovějšímu upstream kódu. To může být pro vývojáře frustrující, zvláště když chcete jen něco dostat ze dveří, ale ne tak frustrující jako být stránkovaný, abyste se podívali na knihovnu, o které jste tři roky nepřemýšleli a kterou původní správci celou dobu měnili. .
Pokud jste webový vývojář a valíte na mě oči, mám pro vás jedno slovo:DevOps. To znamená, že nosíte pager, příteli.
Budování od začátku
Scratch buildy mají tu výhodu, že jsou opravdu malé. Když se nespoléháte na linuxovou distribuci v kontejneru, máte velkou kontrolu, což znamená, že si můžete vše přizpůsobit svým potřebám. Toto je nejlepší model a je platný v určitých případech použití. Další výhodou je, že máte přístup k nejnovějším balíčkům. Nemusíte čekat, až linuxové distro něco aktualizuje. Máte to pod kontrolou, takže si vyberete, kdy strávíte inženýrské práce na začlenění nového softwaru.
Pamatujte, že ovládání všeho něco stojí. Aktualizace na nové knihovny s novými funkcemi často vede k nechtěným změnám API, což znamená opravu nekompatibility v kódu (jinými slovy, shaping yaks). Holit jaky ve 2 hodiny ráno, když aplikace nefunguje, není legrace. Naštěstí se s kontejnery můžete vrátit zpět a oholit si jaky další pracovní den, ale i tak vám to zabere čas na dodání nové hodnoty do vašich aplikací a nových funkcí. Vítejte v životě systémového správce.
Dobře, jsou chvíle, kdy stavět od nuly dává smysl. Zcela připustím, že staticky zkompilované programy Golang a C programy jsou dva slušní kandidáti na sestavení scratch/distroless. U těchto typů programů je každé sestavení kontejneru událostí kompilace. Za tři roky se stále musíte bát rozbití API, ale pokud jste obchodem Golang, měli byste mít dovednosti, které časem opraví.
Závěr
V podstatě linuxové distribuce odvedou spoustu práce, aby vám ušetřily čas – na běžném systému Linux nebo s kontejnery. Znalosti, které mají správci, jsou ohromné a tolik využívané, aniž by byly skutečně oceněny. Přijetí kontejnerů tento problém ještě zhoršilo, protože je ještě více abstraktní.
S kontejnerovými hostiteli vám distribuce Linuxu nabízí přístup k širokému hardwarovému ekosystému, od malých systémů ARM, přes obří boxy 128 CPU x86 až po virtuální počítače poskytovatelů cloudu. Nabízejí fungující kontejnerové motory a doby běhu kontejnerů ihned po vybalení, takže můžete své kontejnery pouze zapálit a nechat někoho jiného, aby se staral o to, aby věci fungovaly.
Pokud jde o obrazy kontejnerů, distribuce Linuxu vám nabízejí snadný přístup k velkému množství softwaru pro vaše projekty. I když stavíte od nuly, pravděpodobně se podíváte na to, jak správce balíčků stavěl a dodával věci – dobrý umělec je dobrý zloděj – takže tuto práci nepodceňujte.
Takže děkuji všem správcům ve Fedoře, RHEL (Františku, jsi můj hrdina), Debianu, Gentoo a každé další distribuci Linuxu. Vážím si vaší práce, i když jsem „kontejnerový chlap.“