Projekt Atomic Red Hat-a je domišljav način za zagon vsebnikov Linuxa. Operacijski sistem Atomic Host ima že nameščene Docker (vsebniki), Flannel (mreženje), OSTree (upravljanje gostitelja), Etcd (porazdeljeno shrambo ključev in vrednosti) in Kubernetes (orkestracija).
Kubernetes je eden izmed dveh priljubljenih sistemov za orkestracijo zabojnikov, drugi pa je Docker Swarm. Lahko bi mu rekli "polna moč", s tem pa dodatno zapletenost in administrativne obremenitve.
Kubernetes koordinira ustvarjanje "podov" na več atomskih gostiteljih. Pods so skupine Dockerjevih vsebnikov, ki logično ločujejo storitve v aplikaciji. Vsebniki v podsu si delijo naslov IP in komunicirajo prek localhosta.
Flannel ponuja prekrivno omrežje za Atomic hosts, ki omogoča, da vsak pod v gruči komunicira s katerim koli drugim podom ali storitvijo znotraj grozda. To prekrivno omrežje se uporablja samo za mreženje vsebnikov. Proxy storitev Kubernetes omogoča dostop do gostiteljskega prostora IP.
Etcd se uporablja za shranjevanje konfiguracij za Kubernetes in Flannel na vseh gostiteljih v gruči.
Grozdi atomskih vsebnikov zaradi Kubernetesa sprejemajo določene predpostavke. Skrbniki pri Atomicu res nimajo izbire: bodisi uporabite Kubernetes bodisi poiščite drug OS kontejnerja.
Če se izogibate "oblikovanju po dogovoru" in želite več svobode in prilagodljivosti v gostiteljskem vsebniku, lahko razmislite o RancherOS ali VMware Photon. Če je vaš končni cilj zagnati veliko zabojnikov na številnih gostiteljih, potem so Atomic Host, Kubernetes in prijatelji morda ravno tisto, kar potrebujete.
Administracija sistema Atomic Host
Atomic Host uporablja svojo različico docker ukaz, atomska, čeprav resničnodocker ukaz je na voljo v / bin / docker. Njegova lokacija v / bin namiguje na nekatere predelave, ki so bile opravljene pri RHEL / CentOS / Fedora, da bi bil Atomic OS namensko zasnovan za zabojnike. Običajno so v / bin le pomembni sistemski binarni programi.
Atomsko gostiteljico upravljate prek dveh podsistemov. RPM-OSTree skrbi za uvajanje in posodobitve gostiteljskega sistema, medtem ko Docker skrbi za zagotavljanje vsebnikov za izvajanje storitev in aplikacij. Oba podsistema upravlja atomska ukaz v / usr / bin /.
RPM-OSTree naredi datotečni sistem Atomic nespremenljiv; tj. datotečni sistem je samo za branje, razen za / var in / itd. V imeniku / var / lib / docker so shranjene vse datoteke in slike, povezane z Dockerjem, medtem ko ima / etc vse konfiguracijske datoteke. Kot bomo videli kasneje, to omogoča enostavnejše in varnejše nadgradnje in nadgradnje gostitelja, kar je bistvena zahteva pri upravljanju na tisoče gostiteljev vsebnikov v gruči.
The atomska ukaz naj bi bil ena vstopna točka v podsistem vsebnika - krovni ukaz za vse stvari, vključno z gostiteljskimi operacijami. The atomska ukaz izgleda in se počuti podobno kot docker ukaz, vendar obravnava temeljno težavo, ki si jo delijo vsi operacijski sistemi gostiteljskih vsebnikov: zagon storitve na ravni sistema v vsebniku ob zagonu na zanesljiv in pregleden način z uporabo datotek enote Systemd.
V Atomicu se to stori s tako imenovanim super privilegiranim vsebnikom, ki lahko vidi in manipulira samega gostitelja. Torej, čeprav atomska izgleda kot standardni ukaz Docker, zapolnjuje vrzeli med Dockerjem in RPM-OSTree - konfigurira namestitvene skripte, nastavlja storitve, podeljuje ustrezne privilegije in podobno -, da omogoči zanesljivo uvajanje aplikacije na osnovi vsebnika.
Preprosto povedanoatomska ukaz vam omogoča upravljanje osnovne infrastrukture gostitelja (skupine, imenski prostori, SELinux itd.) za zagon aplikacij. Recimo, na primer, da ste zgradili aplikacijo vsebnika Network Time Protocol (ntpd), ki zahteva zmožnost SYS_TIME, da spremeni sistemski čas gostitelja. To lahko konfigurirate tako, da v sliko vsebnika dodate metapodatke z ukazom:
LABEL RUN / usr / bin / docker run -d —cap-add = SYS_TYPE ntpd
Potem, ko zaženete vsebnik (atomski zagon ntpd), sistem bo prebral te metapodatke in konfiguriral zmožnost SYS_TIME in druge vire za vsebnik.
Namestitev in konfiguracija Atomic Host
Namestitev je bila težavna, predvsem zato, ker se mi je zdela dokumentacija neurejena in zmedena. Dokumenti predvidevajo visoko raven znanja o ekosistemu Red Hat, ki ga ne bo imel vsak bralec. Po nekaj napačnih zagonih mi je končno uspelo namestiti iz golo kovine ISO. Podpora za namestitev navideznega računalnika s čim drugim, razen z virt-managerjem, je boleča. Atomic Host v tem pogledu zagotovo ni primeren za Windows ali Mac.
Za vse, ki poznate namestitev CentOS, bo postopek brez kovine enostaven. Edine opazne razlike so v postavitvi diska, pri čemer je prostor samodejno rezerviran za Docker in vsebnike, skupaj z obilico nosilcev za SELinux, cgroups itd., Ki spremljajo namestitev OS vsebnika.
Uporaba Kubernetesa za upravljanje vsebnikov v gruči je bistveno bolj zapletena kot zagon Dockerja na enem samem gostitelju, vendar z večjo zapletenostjo prihaja do večje zanesljivosti in zmogljivosti. S Kubernetesom se tudi udobno zavedate, da je sistem preizkušen v obsežnih proizvodnih okoljih (pri Googlu).
Ni enostavnega načina za postavitev mojstra Kubernetesa. Dokumentacija je razpršena po različnih spletnih mestih projektov, dokumenti pa velikokrat poiščejo druga spletna mesta za podrobnosti, zato bodite pripravljeni porabiti veliko časa za branje, lovljenje dokumentov in eksperimentiranje. Skupni napor vključuje spreminjanje kakih ducat datotek, razporejenih po nekaj imenikih / etc. Trik je seveda vedeti, katere so te spremembe. Kubernetes v resnici ni namenjen priložnostnemu eksperimentiranju s posodami. To so težke proizvodne stvari.
Ko sem konfiguriral glavno enoto s Kubernetesom, potrdili, storitvami in omrežjem s prekrivnimi mrežami, nato pa na vsako vozlišče namestil Flannel (flanneld), Kubernetes (kubelet) in Etcd, sem končno zagnal gručo vsebnikov s petimi vozli. Na žalost je to porabilo precej pomnilnika in nisem mogel najti načina za testiranje z enim samim vozliščem, kot sem to storil pri testiranju RancherOS in VMware Photon.
Na tej točki lahko Kubernetes uporabljamo za zagon in upravljanje pods, tistih skupin vsebnikov, ki vsebujejo storitve in aplikacije.
Shranjevanje in mreženje Atomic Host
Kot večina operacijskih sistemov gostiteljskih vsebnikov tudi Atomic Host uporablja minimalističen pristop z vključenim dovolj prostora na disku za zagon gostitelja. To ne pušča veliko za veliko Dockerjevih zabojnikov, ki se bodo izvajali tipični gruči, zato boste morali gostitelju za to pritrditi zunanji pomnilnik.
V Dockerju se slike in z njimi povezane datoteke običajno shranijo v / var / lib / docker in v večini standardnih operacijskih sistemov bi na to točko v datotečni sistem preprosto namestili napravo, da bi dodali pomnilnik. Vendar Atomic uporablja neposredne nosilce LVM (Linux Volume Manager) prek zaledja Device Mapper za shranjevanje Dockerjevih slik in metapodatkov: / dev / atomicos / docker-data in / dev / atomicos / docker-meta. To pomeni, da se boste morali naučiti nekaj o LVM in količinah, da boste Atomskemu gostitelju dodali prostor.
Izhodišče za upravljanje pomnilnika v Atomicu je namestitveni skript, / etc / sysconfig / docker-storage-setup. Atomic Host ima shrambo za shrambo Dockerja (in gostitelja), zato je trik tukaj dodajanje nove naprave v to področje. To boste storili tako, da boste na seznam naprav v datoteki dodali tako:
DEVS = "/ dev / vdb / dev / vdc"
Nato zaženete pomožni skript / usr / bin / docker-storage-setup. Če je vse v redu, so bili vaši diski dodani v bazen in vaš Atomic gostitelj ima prostor za Docker. Predvidevam, da bo LVM v proizvodnji upravljan z obstoječimi skrbniškimi orodji ali s podobnimi skripti Ansible / Salt / Chef / Lutka, zato bo skrbnikom, ki delajo v velikih okoljih podatkovnih središč, verjetno videti bolj standardno.
Project Atomic uporablja Flannel za zagotavljanje mreže prekrivnih vsebnikov prek Etcd. To konfigurirate tako, da potisnete konfiguracijsko datoteko JSON v shrambo ključ-vrednost Etcd z uporabo orodij, kot je Curl. Če želite konfigurirati podomrežje za vsebnike, lahko ustvarimo datoteko JSON, ki je videti takole:
{ “Network”: “172.16.0.0/12”,
“SubnetLen”: 24,
"Backend": {
“Type”: “vxlan”
}
}
In če želimo to spraviti v glavni računalnik Etcd, ga potisnemo v omrežni konfiguracijski ključ:
curl -L //localhost:2379/v2/keys/atomic.io/config -XPUT --data-urlencode [email protected]
Čeprav je nekoliko okoren, je obvladljiv. Rad bi videl ovoj za te konfiguracijske ukaze, zaradi katerega je skrbnik Unixa bolj intuitiven, morda kaj podobnega atomska ifconfig ..., atomska pot ...itd.
Tu je treba poudariti še eno razliko: koncepti Kubernetes strokov in storitev. Strok je skupina posod, ki so razmeroma tesno povezane. Vsi vsebniki v stroju imajo istega gostitelja in isti naslov IP in vsi živijo ali umrejo skupaj. Določite, koliko primerkov stroka želite zagnati, in Kubernetes izvede naročilo. Če se primerek ustavi ali ne uspe, Kubernetes zavrti drugega, da se ujema z želenim stanjem.
Storitev Kubernetes je abstrakcija, ki opredeljuje logični nabor strokov in politiko dostopa do njih. To daje (mikro) storitvi eno samo stabilno ime in naslov v celotnem življenjskem ciklu stroka. To je še veliko več, vendar bi vam to moralo pomagati razumeti, zakaj potrebujete ločeno komponento za upravljanje omrežja. V Atomic Host je ta komponenta Flannel.
Nadgradnje in znižanja Atomic Host
Atomic Host uporablja upravitelja paketov z imenom RPM-OSTree, ki združuje značilnosti tradicionalnega RPM in OSTree. RPM-OSTree nam omogoča zanesljivo premikanje naprej in nazaj, saj je postopek "atomski" (v pomenu besede v bazi podatkov). RPM-OSTree zagotavlja zanesljive transakcije za posodobitve, kar pomeni, da je malo verjetno, da bo pokvaril operacijski sistem. Tako kot ukazi za vsebnike, so nadgradnje gostiteljev in povratne datoteke usmerjene v atomska upravljalni sistem:
nadgradnja atomskega gostiteljaodmik atomskega gostitelja
Upoštevajte, da povratka nisem preizkusil, ker se nisem imel do česa vrniti.
Red Hat Atomic Host je najbolj primeren za organizacije, ki veliko vlagajo v znanje in infrastrukturo Red Hat. Podjetja, ki začenjajo z drugega zornega kota, bodo morda želela razmisliti o drugih možnostih. Vključitev Kubernetesa in zgodovina Red Hat-a v velika proizvodna okolja pomeni, da bo Atomic Host skorajda "izpad" za izvajanje delovnih obremenitev v zabojnikih v podjetjih. Toda ne vidim, da bi ga razvijalci ubrali kot svojo izbrano platformo Docker.
