Red Hat’s Project Atomic je zdvořilý způsob spouštění kontejnerů Linux. Operační systém Atomic Host je dodáván s již nainstalovanými Docker (kontejnery), Flannel (síť), OSTree (správa hostitele), Etcd (distribuovaný úložiště klíč-hodnota) a Kubernetes (orchestrace).
Kubernetes je jedním ze dvou populárních systémů orchestrace kontejnerů, druhým je Docker Swarm. Dalo by se to nazvat „plnou silou“, ale s tím přichází další složitost a administrativní režie.
Kubernetes koordinuje vytváření „lusků“ napříč několika atomovými hostiteli. Pods jsou skupiny Docker kontejnerů, které logicky oddělují služby v aplikaci. Kontejnery v modulu sdílejí IP adresu a komunikují přes localhost.
Flannel poskytuje překryvnou síť pro atomové hostitele, což umožňuje každému modulu v klastru komunikovat s jakýmkoli jiným modulem nebo službou v klastru. Tato překryvná síť se používá pouze pro vytváření sítí kontejnerů. Služba proxy Kubernetes poskytuje přístup k hostitelskému prostoru IP.
Etcd se používá k ukládání konfigurací pro Kubernetes i Flannel napříč všemi hostiteli v klastru.
Atomové clustery kontejnerů vytvářejí určité předpoklady kvůli Kubernetes. Správci s Atomic opravdu nemají na výběr: Použijte Kubernetes nebo najděte jiný kontejnerový OS.
Pokud se obáváte o „design by convention“ a chcete více svobody a flexibility v hostiteli kontejneru, můžete zvážit RancherOS nebo VMware Photon. Pokud je vaším konečným cílem provozovat mnoho kontejnerů na mnoha hostitelích, pak Atomic Host, Kubernetes a přátelé mohou být právě to, co potřebujete.
Správa systému Atomic Host
Atomic Host používá vlastní verzi přístavní dělník příkaz, atomový, ačkoli skutečnýpřístavní dělník příkaz je k dispozici v / bin / docker. Jeho umístění v / bin naznačuje některé přepracování, které bylo provedeno pro RHEL / CentOS / Fedora, aby byl Atomic OS účelový pro kontejnery. Normálně se v / bin nacházejí pouze důležité systémové binární soubory.
Atomic Host spravujete prostřednictvím dvou subsystémů. RPM-OSTree zpracovává nasazení a aktualizace hostitelského systému, zatímco Docker zpracovává zajišťování kontejnerů pro běh služeb a aplikací. Oba tyto subsystémy jsou spravovány atomový příkaz umístěný v / usr / bin /.
Díky RPM-OSTree je souborový systém Atomic neměnný; tj. souborový systém je pouze pro čtení, kromě / var a / atd. V adresáři / var / lib / docker jsou uloženy všechny soubory a obrázky související s Dockerem, zatímco / etc má všechny konfigurační soubory. Jak uvidíme později, to umožňuje jednodušší a bezpečnější upgrady a downgrady hostitele, což je základní požadavek při správě potenciálně tisíců hostitelů kontejnerů v clusteru.
The atomový příkaz má být jediným vstupním bodem do kontejnerového subsystému - zastřešující příkaz pro všechny věci kontejneru, včetně operací hostitele. The atomový příkaz vypadá a vypadá podobně jako přístavní dělník příkaz, ale řeší zásadní problém sdílený všemi operačními systémy hostitele kontejneru: spuštění služby na úrovni systému v kontejneru při spuštění, spolehlivým a transparentním způsobem, pomocí souborů jednotek Systemd.
V Atomic se to děje s takzvaným super privilegovaným kontejnerem, který má schopnost vidět a manipulovat samotného hostitele. Takže ačkoli atomový vypadá jako standardní příkaz Dockeru, vyplňuje mezery mezi Dockerem a RPM-OSTree - konfiguruje instalační skripty, nastavuje služby, přiřazuje správná oprávnění a podobně - umožňuje spolehlivé nasazení kontejnerové aplikace.
Jednoduše řečenoatomový Příkaz umožňuje manipulovat se základní infrastrukturou hostitele (cgroups, namespaces, SELinux atd.) pro spuštění vašich aplikací. Řekněme například, že jste vytvořili kontejnerovou aplikaci Network Time Protocol (ntpd), která vyžaduje schopnost SYS_TIME, aby bylo možné upravit systémový čas hostitele. Můžete to nakonfigurovat přidáním metadat do obrazu kontejneru pomocí příkazu:
LABEL RUN / usr / bin / docker run -d —cap-add = SYS_TYPE ntpd
Pak při spuštění kontejneru (atomový běh ntpd), systém načte tato metadata a nakonfiguruje schopnost SYS_TIME a další zdroje pro kontejner.
Instalace a konfigurace atomového hostitele
Instalace byla bojem, hlavně proto, že dokumentace mi byla neuspořádaná a matoucí. Dokumenty předpokládají vysokou úroveň znalostí o ekosystému Red Hat, kterou nebude mít každý čtenář. Po několika falešných začátcích se mi konečně podařilo nainstalovat z ISO holého kovu. Podpora instalace virtuálního stroje s čímkoli jiným než virt-manager je bolestivá. Atomic Host v tomto ohledu rozhodně není vhodný pro Windows nebo Mac.
Pro kohokoli, kdo je obeznámen s instalací CentOS, bude postup holým kovem snadný. Jediné znatelné rozdíly jsou v rozložení disku, kde je automaticky vyhrazen prostor pro Docker a kontejnery, spolu s množstvím připojení pro SELinux, cgroups atd., Které doprovázejí instalaci OS kontejneru.
Používání Kubernetes ke správě kontejnerů napříč klastrem je podstatně komplikovanější než běh Dockeru na jednom hostiteli, ale s větší složitostí přichází i větší spolehlivost a možnosti. S Kubernetes také získáte pohodlí vědět, že systém byl testován ve velkém produkčním prostředí (na Googlu).
Není žádný snadný způsob, jak nastavit mistra Kubernetes. Dokumentace je rozložena na různé webové stránky projektu a dokumenty mnohokrát vyhledávají podrobnosti na dalších webech, takže buďte připraveni strávit spoustu času čtením, honěním za dokumenty a experimentováním. Součet celkového úsilí zahrnuje úpravu několika desítek souborů rozložených do několika adresářů / etc. Samozřejmě trikem je vědět, jaké jsou tyto úpravy. Kubernetes není určen pro příležitostné experimentování s kontejnery. To je těžká výroba.
Po konfiguraci masteru s Kubernetes, certifikáty, službami a překryvnou sítí Flanel, následnou instalací Flanel (flanneld), Kubernetes (kubelet) a Etcd na každém uzlu jsem konečně spustil pětidodový kontejnerový cluster. Bohužel to spotřebovalo dost paměti a nebyl jsem schopen najít způsob testování pomocí jediného uzlu, jako jsem to udělal při testování RancherOS a VMware Photon.
V tomto okamžiku lze Kubernetes použít ke spuštění a správě lusků, těchto skupin kontejnerů, které zapouzdřují služby a aplikace.
Úložiště a připojení k síti Atomic Host
Jako většina operačních systémů hostitele kontejnerů, i Atomic Host zaujímá minimalistický přístup a na spuštění hostitele je zahrnuto jen dostatek místa na disku. To nezanechává mnoho pro mnoho kontejnerů Docker, které bude běžet běžný cluster, takže k tomu budete muset k hostiteli připojit externí úložiště.
V Dockeru jsou obrázky a související soubory obvykle uloženy v adresáři / var / lib / docker a na většině standardních operačních systémů stačí v daném bodě souborového systému připojit zařízení a přidat úložiště. Atomic však používá přímé svazky LVM (Linux Volume Manager) přes back-end zařízení Device Mapper k ukládání obrazů a metadat Dockeru: / dev / atomicos / docker-data a / dev / atomicos / docker-meta. To znamená, že se budete muset naučit něco o LVM a svazcích, abyste přidali místo atomovému hostiteli.
Výchozím bodem pro správu úložiště v Atomic je instalační skript, / etc / sysconfig / docker-storage-setup. Atomic Host má fond úložiště pro úložiště Docker (a hostitele), takže trikem je přidání nového zařízení do tohoto fondu. Uděláte to přidáním do seznamu zařízení v souboru, například takto:
DEVS = "/ dev / vdb / dev / vdc"
Poté spustíte pomocný skript, / usr / bin / docker-storage-setup. Pokud vše půjde dobře, byly vaše disky přidány do fondu a váš hostitel Atomic má místo pro Docker. Předpokládám, že LVM bude ve výrobě spravován pomocí stávajících administračních nástrojů nebo pomocí skriptů Ansible / Salt / Chef / Puppet, takže se správcům pracujícím v prostředích velkých datových center pravděpodobně bude jevit standardněji.
Project Atomic využívá Flannel k zajištění překryvné sítě kontejnerů přes Etcd. Nakonfigurujete to tak, že vložíte konfigurační soubor JSON do úložiště klíč-hodnota Etcd pomocí nástrojů, jako je Curl. Chcete-li nakonfigurovat podsíť pro kontejnery, můžeme vytvořit soubor JSON, který vypadá takto:
{ „Network“: „172.16.0.0/12“,
„SubnetLen“: 24,
„Backend“: {
„Type“: „vxlan“
}
}
A abychom to dostali do masteru Etcd, vložíme ho do klíče konfigurace sítě:
curl -L //localhost:2379/v2/keys/atomic.io/config -XPUT --data-urlencode [email protected]
I když je to trochu těžkopádné, dá se to zvládnout. Rád bych viděl souhrn těchto konfiguračních příkazů, díky nimž je pro správce Unix intuitivnější, třeba něco podobného atomová ifconfig…, atomová cesta…, atd.
Zde je třeba zdůraznit ještě jeden rozdíl: koncepty pod a služeb Kubernetes. Pods je skupina kontejnerů, které jsou relativně pevně spojené. Všechny kontejnery v modulu sdílejí stejného hostitele a stejnou adresu IP a všechny žijí nebo umírají společně. Určete, kolik instancí podu chcete spustit, a Kubernetes provede pořadí. Pokud se instance zastaví nebo selže, Kubernetes roztočí další, aby odpovídal požadovanému stavu.
Služba Kubernetes je abstrakce, která definuje logickou sadu lusků a zásadu, podle které k nim přistupovat. To dává (mikro) službě jediný stabilní název a adresu v celém životním cyklu pod. Je toho mnohem víc, ale to by vám mělo pomoci pochopit, proč ke správě sítě potřebujete samostatnou součást. V atomovém hostiteli je touto komponentou flanel.
Upgrady a downgrade Atomic Host
Atomic Host používá správce balíčků s názvem RPM-OSTree, který kombinuje funkce tradičních RPM a OSTree. RPM-OSTree nám dává schopnost spolehlivě se pohybovat dopředu a dozadu, protože proces je „atomový“ (ve smyslu slova v databázi). RPM-OSTree poskytuje spolehlivé transakce pro aktualizace, což znamená, že je nepravděpodobné, že by došlo k poškození operačního systému. Stejně jako u příkazů pro kontejnery jsou i upgrady hostitele a odvolání před atomový systém řízení:
upgrade atomového hostitelevrácení atomového hostitele
Všimněte si, že jsem netestoval vrácení zpět, protože jsem se neměl k čemu vrátit.
Red Hat Atomic Host je nejvhodnější pro organizace, které mají velké investice do dovedností a infrastruktury Red Hat. Společnosti začínající z jiného úhlu mohou chtít zvážit jiné možnosti. Zahrnutí Kubernetes a historie Red Hat do velkých produkčních prostředí znamenají, že Atomic Host bude téměř „drop-in“ pro provozování kontejnerových úloh v podnicích. Ale nevidím vývojáře, kteří by si to vybrali jako svou zvolenou platformu Docker.
