Red Hats Project Atomic er en meningsfuld måde at køre Linux-containere på. Atomic Host-operativsystemet leveres med Docker (containere), Flannel (netværk), OSTree (værtadministration), Etcd (distribueret nøgleværdilager) og Kubernetes (orkestrering), der allerede er installeret.
Kubernetes er et af de to populære container orkestreringssystemer, det andet er Docker Swarm. Du kan kalde det "fuld styrke", men med det kommer yderligere kompleksitet og administrativt overhead.
Kubernetes koordinerer oprettelsen af "bælg" på tværs af flere Atomic-værter. Pods er grupper af Docker-containere, der logisk adskiller tjenester i en applikation. Containerne i en pod deler en IP-adresse og kommunikerer via localhost.
Flannel giver et overlay-netværk til Atomic-værter, der gør det muligt for hver pod i klyngen at kommunikere med enhver anden pod eller tjeneste i klyngen. Dette overlay-netværk bruges kun til containernetværk. En Kubernetes-proxytjeneste giver adgang til værtens IP-plads.
Etcd bruges til at gemme konfigurationer for både Kubernetes og Flannel på tværs af alle værterne i klyngen.
Atomiske containerklynger antager visse antagelser på grund af Kubernetes. Administratorer har virkelig ikke noget valg med Atomic: Brug enten Kubernetes eller find et andet container-OS.
Hvis du chafler efter "design by convention", og du vil have mere frihed og fleksibilitet i en containerhost, kan du overveje RancherOS eller VMware Photon. Hvis dit endelige mål er at køre mange containere på mange værter, kan Atomic Host, Kubernetes og venner måske være lige hvad du har brug for.
Atomic Host systemadministration
Atomic Host bruger sin egen version af docker kommando, atomar, selvom den virkeligedocker kommandoen er tilgængelig i / bin / docker. Dens placering i / bin antyder nogle af de omarbejdninger, der blev udført til RHEL / CentOS / Fedora for at gøre Atomic OS specialbygget til containere. Normalt er der kun vigtige systembinarier i / bin.
Du administrerer Atomic Host via to undersystemer. RPM-OSTree håndterer implementering og opdateringer af værtssystemet, mens Docker håndterer klargøring af containere til kørsel af tjenester og applikationer. Begge disse undersystemer administreres af atomar kommando placeret i / usr / bin /.
RPM-OSTree gør Atomic-filsystemet uforanderligt; dvs. filsystemet er skrivebeskyttet med undtagelse af / var og / osv. Mappen / var / lib / docker er, hvor alle de Docker-relaterede filer og billeder er gemt, mens / etc har alle konfigurationsfiler. Som vi vil se senere, giver dette enklere og sikrere opgraderinger og nedgraderinger af værten, et væsentligt krav, når man administrerer potentielt tusindvis af containerværter i en klynge.
Det atomar kommandoen er beregnet til at være et enkelt indgangspunkt til containerundersystemet - en paraplykommando til alle ting container inklusive værtsoperationer. Det atomar kommando ser ud og føles meget som docker kommando, men løser et grundlæggende problem, der deles af alle containerhost-operativsystemer: start af en systemtjeneste i en container ved opstartstid på en pålidelig og gennemsigtig måde ved hjælp af Systemd-enhedsfiler.
I Atomic gøres dette med det, der kaldes en super-privilegeret container, som har evnen til at se og manipulere værten selv. Så selvom atomar ligner en standard Docker-kommando, den udfylder hullerne mellem Docker og RPM-OSTree - konfigurering af installationsskripter, opsætning af tjenester, tildeling af passende privilegier og lignende - for at muliggøre pålidelig implementering af en containerbaseret applikation.
Enkelt sagt, denatomar kommando giver dig mulighed for at manipulere den underliggende værtsinfrastruktur (cgroups, namespaces, SELinux osv.) til at køre dine applikationer. Lad os for eksempel sige, at du har bygget en Network Time Protocol (ntpd) containerapplikation, der kræver SYS_TIME-kapaciteten for at ændre værtens systemtid. Du kan konfigurere dette ved at tilføje metadata til dit containerbillede ved hjælp af kommandoen:
LABEL RUN / usr / bin / docker run -d — cap-add = SYS_TYPE ntpd
Når du kører containeren (atomkørsel ntpd), vil systemet læse disse metadata og konfigurere SYS_TIME-kapaciteten og andre ressourcer til containeren.
Atomic Host installation og konfiguration
Installation var en kamp, hovedsagelig fordi jeg fandt dokumentationen uorganiseret og forvirrende. Dokumenterne antager et højt niveau af viden om Red Hat-økosystemet, som ikke alle læsere vil have. Efter et par falske starter lykkedes det mig endelig at installere fra et ISO-metal med bare metal. Support til installation af virtuel maskine med alt andet end virt-manager er smertefuldt. Atomic Host er bestemt ikke Windows- eller Mac-venlig i denne henseende.
For alle, der er fortrolige med en CentOS-installation, er proceduren med bare metal let. De eneste bemærkelsesværdige forskelle er i disklayoutet, med plads reserveret automatisk til Docker og containere sammen med overfloden af monteringer til SELinux, cgroups osv., Der ledsager en container OS-installation.
Brug af Kubernetes til at styre containere på tværs af en klynge er betydeligt mere kompliceret end at køre Docker på en enkelt vært, men med større kompleksitet kommer større pålidelighed og kapacitet. Med Kubernetes får du også komforten ved at vide, at systemet er blevet kamptestet i store produktionsmiljøer (hos Google).
Der er ikke nogen nem måde at oprette en Kubernetes-mester på. Dokumentation er spredt på forskellige projektwebsteder, og mange gange går dokumenterne til andre websteder for detaljer, så vær forberedt på at bruge meget tid på at læse, jage dokumenter og eksperimentere. Summen af den samlede indsats involverer ændring af et dusin eller deromkring filer spredt over et par / osv. Mapper. Naturligvis er tricket at vide, hvad disse ændringer er. Kubernetes er ikke rigtig lavet til afslappet eksperimentering med containere. Dette er tunge produktionsmaterialer.
Efter at have konfigureret masteren med Kubernetes, certifikater, tjenester og et Flannel-overlay-netværk og derefter installeret Flannel (flanneld), Kubernetes (kubelet) og Etcd på hver node, havde jeg endelig en fem-node container klynge kørende. Desværre forbrugte dette en hel del hukommelse, og jeg kunne ikke finde en måde at teste ved hjælp af en enkelt knude på, som jeg gjorde, når jeg testede RancherOS og VMware Photon.
På dette tidspunkt kan Kubernetes bruges til at starte og administrere bælg, de grupper af containere, der indkapsler tjenester og applikationer.
Atomic Host-opbevaring og netværk
Som de fleste containerhost-operativsystemer tager Atomic Host en minimalistisk tilgang med lige nok diskplads inkluderet til at køre værten. Det efterlader ikke meget for de mange Docker-containere, som en typisk klynge kører, så du bliver nødt til at knytte eksternt lager til værten til det.
I Docker gemmes billeder og relaterede filer typisk i / var / lib / docker, og på de fleste standardoperativsystemer vil du blot montere en enhed på det tidspunkt i filsystemet for at tilføje lager. Atomic bruger dog direkte LVM (Linux Volume Manager) -volumener via Device Mapper-backenden til at gemme Docker-billeder og metadata: / dev / atomicos / docker-data og / dev / atomicos / docker-meta. Det betyder, at du bliver nødt til at lære noget om LVM og volumener for at tilføje plads til en Atomic-vært.
Udgangspunktet for lagerstyring i Atomic er installationsscriptet, / etc / sysconfig / docker-storage-setup. Atomic Host har en lagringspool til Docker (og host) -lagring, så tricket her er at tilføje en ny enhed til denne pool. Du gør dette ved at tilføje til listen over enheder i filen, som denne:
DEVS = "/ dev / vdb / dev / vdc"
Derefter kører du hjælpeskriptet / usr / bin / docker-storage-setup. Hvis alt går godt, er dine diske blevet føjet til puljen, og din Atomic-vært har plads til Docker. Jeg formoder, at LVM styres i produktion med eksisterende administrationsværktøjer eller med lignende Ansible / Salt / Chef / Puppet-scripts, så det vil sandsynligvis forekomme mere standard for administratorer, der arbejder i store datacentermiljøer.
Project Atomic bruger Flannel til at levere et containeroverlay-netværk via Etcd. Du konfigurerer dette ved at skubbe en JSON-konfigurationsfil til Etcd-nøgleværdilageret ved hjælp af værktøjer som Curl. For at konfigurere et undernet til containerne opretter vi muligvis en JSON-fil, der ser sådan ud:
{ “Netværk”: “172.16.0.0/12”,
“SubnetLen”: 24,
"Bagende": {
“Type”: “vxlan”
}
}
Og for at få dette ind i Etcd-masteren skubber vi det ind i netværkskonfigurationsnøglen:
krølle -L //localhost:2379/v2/keys/atomic.io/config -XPUT --data-urlencode væ[email protected]
Mens det er lidt besværligt, er det håndterbart. Jeg vil meget gerne se en indpakning til disse konfigurationskommandoer, der gør det mere intuitivt for Unix-administratoren, måske noget som atomær ifconfig ..., atomrute ..., etc.
Der er en anden forskel her, der er værd at understrege: Kubernetes-begreberne bælg og tjenester. En bælg er en gruppe containere, der er relativt tæt koblet. Alle containere i en pod deler den samme vært og den samme IP-adresse, og de lever eller dør sammen. Du angiver, hvor mange forekomster af en pod, du vil køre, og Kubernetes udfører ordren. Hvis en forekomst stopper eller mislykkes, spinder Kubernetes en anden op for at matche den ønskede tilstand.
En Kubernetes-tjeneste er en abstraktion, der definerer et logisk sæt bælg og en politik, hvormed man får adgang til dem. Dette giver en (mikro) tjeneste et enkelt, stabilt navn og adresse på tværs af podens livscyklus. Der er meget mere til dette, men det skal hjælpe dig med at forstå, hvorfor du har brug for en separat komponent til at styre netværket. I Atomic Host er denne komponent Flannel.
Atomic Host opgraderinger og nedgraderinger
Atomic Host bruger en pakkehåndtering kaldet RPM-OSTree, som kombinerer funktioner i traditionel RPM og OSTree. RPM-OSTree giver os muligheden for pålideligt at rulle frem og tilbage, da processen er “atomisk” (i databasens forstand af ordet). RPM-OSTree giver pålidelige transaktioner til opdateringer, hvilket betyder, at det er usandsynligt, at operativsystemet brydes. Ligesom kommandoer for containere er værtopgraderinger og tilbagesendelser frontet af atomar styringssystem:
atomværtsopgraderingatom-vært tilbageførsel
Bemærk, at jeg ikke testede en tilbageførsel, fordi jeg ikke havde noget at rulle tilbage til.
Red Hat Atomic Host er bedst egnet til organisationer med en stor investering i Red Hat-færdigheder og infrastruktur. Virksomheder, der starter fra en anden vinkel, vil måske overveje andre muligheder. Inkluderingen af Kubernetes og historien om Red Hat i store produktionsmiljøer betyder, at Atomic Host næsten vil være et "drop-in" til kørsel af containeriserede arbejdsbelastninger i virksomheder. Men jeg kan ikke se udviklere hente det som deres valgte Docker-platform.
