Programmering

Gjennomgang: Red Hat gjør Docker på den harde måten

Red Hats Project Atomic er en meningsfull måte å kjøre Linux-containere på. Atomic Host-operativsystemet leveres med Docker (containere), Flannel (nettverk), OSTree (vertsadministrasjon), Etcd (distribuert nøkkelverdilager) og Kubernetes (orkestrering) som allerede er installert.

Kubernetes er et av de to populære containerorkestrasjonssystemene, det andre er Docker Swarm. Du kan kalle det "full styrke", men med det kommer ekstra kompleksitet og administrativt overhead.

Kubernetes koordinerer opprettelsen av "pods" på tvers av flere Atomic-verter. Pods er grupper av Docker-containere som logisk skiller tjenester i et program. Containerne i en pod deler en IP-adresse og kommuniserer via localhost.

Flannel tilbyr et overleggsnettverk for Atomic-verter, slik at hver pod i klyngen kan kommunisere med en hvilken som helst annen pod eller tjeneste i klyngen. Dette overleggsnettverket brukes kun til containernettverk. En Kubernetes proxy-tjeneste gir tilgang til verten IP-plass.

Etcd brukes til å lagre konfigurasjoner for både Kubernetes og Flannel på tvers av alle vertene i klyngen.

Atomiske containerklynger antar visse antagelser på grunn av Kubernetes. Administratorer har virkelig ikke noe valg med Atomic: Bruk enten Kubernetes eller finn et annet container-operativsystem.

Hvis du mister "design by convention" og ønsker mer frihet og fleksibilitet i en containervert, kan du vurdere RancherOS eller VMware Photon. Hvis ditt endelige mål er å kjøre mange containere på mange verter, kan Atomic Host, Kubernetes og venner være akkurat det du trenger.

Atomic Host systemadministrasjon

Atomic Host bruker sin egen versjon av docker kommando, atomisk, skjønt den virkeligedocker kommandoen er tilgjengelig i / bin / docker. Plasseringen i / søppel antyder noen av omarbeidene som ble gjort mot RHEL / CentOS / Fedora for å lage Atomic OS spesialbygget for containere. Normalt ligger bare viktige systembinarier i / bin.

Du administrerer Atomic Host via to delsystemer. RPM-OSTree håndterer distribusjon og oppdateringer av vertssystemet, mens Docker håndterer klargjøring av containere for å kjøre tjenester og applikasjoner. Begge disse delsystemene administreres av atomisk kommandoen i / usr / bin /.

RPM-OSTree gjør Atomic-filsystemet uforanderlig; det vil si at filsystemet er skrivebeskyttet bortsett fra / var og / etc. / Var / lib / docker-katalogen er der alle Docker-relaterte filer og bilder er lagret, mens / etc har alle konfigurasjonsfilene. Som vi vil se senere, gir dette enklere og sikrere oppgraderinger og nedgraderinger av verten, et viktig krav når du håndterer potensielt tusenvis av containerverter i en klynge.

De atomisk kommandoen er ment å være et enkelt inngangspunkt til containerundersystemet - en paraplykommando for alle ting, inkludert vertsoperasjoner. De atomisk kommando ser ut og føles omtrent som docker kommandoen, men adresserer et grunnleggende problem som deles av alle operativsystemer for containerverter: å starte en systemnivå-tjeneste i en container ved oppstart, på en pålitelig og gjennomsiktig måte, ved hjelp av Systemd-enhetsfiler.

I Atomic gjøres dette med det som kalles en super-privilegert container, som har evnen til å se og manipulere verten selv. Så, skjønt atomisk ser ut som en standard Docker-kommando, den fyller ut hullene mellom Docker og RPM-OSTree - konfigurering av installeringsskript, konfigurering av tjenester, tildeling av riktige privilegier og lignende - for å muliggjøre pålitelig distribusjon av et containerbasert program.

Enkelt sagt, denatomisk kommandoen lar deg manipulere den underliggende vertsinfrastrukturen (cgroups, namespaces, SELinux, etc.) for å kjøre applikasjonene dine. La oss for eksempel si at du bygde en Network Time Protocol (ntpd) container-applikasjon som krever SYS_TIME-funksjonen for å endre vertens systemtid. Du kan konfigurere dette ved å legge til metadata i containerbildet ditt ved hjelp av kommandoen:

LABEL RUN / usr / bin / docker run -d —cap-add = SYS_TYPE ntpd

Når du kjører containeren (atomkjøring ntpd), vil systemet lese metadataene og konfigurere SYS_TIME-funksjonen og andre ressurser for containeren.

Atomic Host installasjon og konfigurasjon

Installasjon var en kamp, ​​mest fordi jeg syntes dokumentasjonen var uorganisert og forvirrende. Dokumentene antar et høyt kunnskapsnivå om Red Hat-økosystemet som ikke alle lesere vil ha. Etter noen falske starter klarte jeg endelig å installere fra en ISO-plate med bare metall. Støtte for installasjon av virtuell maskin med alt annet enn virt-manager er smertefullt. Atomic Host er definitivt ikke Windows- eller Mac-vennlig i denne forbindelse.

For alle som er kjent med en CentOS-installasjon, er metallmetoden enkel. De eneste merkbare forskjellene er i diskoppsettet, med plass reservert automatisk for Docker og containere, sammen med mengden monteringer for SELinux, cgroups, etc. som følger med en container OS-installasjon.

Å bruke Kubernetes til å administrere containere over en klynge er betydelig mer komplisert enn å kjøre Docker på en enkelt vert, men med større kompleksitet kommer større pålitelighet og mulighet. Med Kubernetes får du også komforten ved å vite at systemet er blitt kamptestet i store produksjonsmiljøer (hos Google).

Det er ingen enkel måte å sette opp en Kubernetes-mester. Dokumentasjonen er spredt over forskjellige prosjektnettsteder, og mange ganger går dokumentene til andre nettsteder for detaljer, så vær forberedt på å bruke mye tid på å lese, jage dokumenter og eksperimentere. Summen av den totale innsatsen innebærer å endre noen titalls filer spredt over noen få / etc kataloger. Selvfølgelig er trikset å vite hva disse modifikasjonene er. Kubernetes er egentlig ikke laget for tilfeldig eksperimentering med containere. Dette er tunge produksjons ting.

Etter å ha konfigurert mesteren med Kubernetes, sertifikater, tjenester og et Flannel overlay-nettverk, og deretter installert Flannel (flanneld), Kubernetes (kubelet) og Etcd på hver node, hadde jeg endelig en fem-noders container-klynge i gang. Dessverre forbrukte dette ganske mye minne, og jeg kunne ikke finne en måte å teste ved hjelp av en enkelt node, som jeg gjorde da jeg testet RancherOS og VMware Photon.

På dette punktet kan Kubernetes brukes til å starte og administrere pods, de grupper av containere som innkapsler tjenester og applikasjoner.

Atomic Host lagring og nettverk

Som de fleste containervertsoperativsystemer tar Atomic Host en minimalistisk tilnærming, med akkurat nok diskplass inkludert til å kjøre verten. Det gir ikke mye igjen for de mange Docker-containere en typisk klynge vil kjøre, så du må koble ekstern lagring til verten for det.

I Docker lagres bilder og relaterte filer vanligvis i / var / lib / docker, og på de fleste standardoperativsystemer vil du bare montere en enhet på det tidspunktet i filsystemet for å legge til lagring. Imidlertid bruker Atomic direkte LVM (Linux Volume Manager) volumer via Device Mapper bakenden for å lagre Docker-bilder og metadata: / dev / atomicos / docker-data og / dev / atomicos / docker-meta. Det betyr at du må lære noe om LVM og volumer for å gi plass til en Atomic-vert.

Utgangspunktet for lagringsadministrasjon i Atomic er installeringsskriptet, / etc / sysconfig / docker-storage-setup. Atomic Host har et lagringsbasseng for lagring av Docker (og host), så kunsten her er å legge til en ny enhet i dette bassenget. Du vil gjøre dette ved å legge til listen over enheter i filen, slik:

DEVS = "/ dev / vdb / dev / vdc"

Deretter kjører du hjelpeskriptet, / usr / bin / docker-storage-setup. Hvis alt går bra, har diskene dine blitt lagt til i bassenget, og din Atomic-vert har plass til Docker. Jeg antar at LVM vil bli administrert i produksjon med eksisterende administrasjonsverktøy, eller med slike som Ansible / Salt / Chef / Puppet-skript, så det vil trolig fremstå som mer standard for administratorer som jobber i store datasentermiljøer.

Project Atomic bruker Flannel for å gi et containeroverleggsnettverk via Etcd. Du konfigurerer dette ved å skyve en JSON-konfigurasjonsfil inn i Etcd-nøkkelverdilageret, ved hjelp av verktøy som Curl. For å konfigurere et undernett for containerne, kan vi opprette en JSON-fil som ser slik ut:

“Nettverk”: “172.16.0.0/12”,

“SubnetLen”: 24,

"Baksiden": {

“Type”: “vxlan”

   }

}

Og for å få dette inn i Etcd-masteren, skyver vi det inn i nettverkskonfigurasjonsnøkkelen:

curl -L //localhost:2379/v2/keys/atomic.io/config -XPUT --data-urlencode [email protected]

Selv om det er litt tungvint, er det håndterbart. Jeg vil gjerne se en innpakning for disse konfigurasjonskommandoene som gjør det mer intuitivt for Unix-administratoren, kanskje noe sånt som atomic ifconfig ..., atomvei ..., etc.

Det er en annen forskjell her som er verdt å understreke: Kubernetes-begrepene pods og services. En pod er en gruppe containere som er relativt tett koblet. Alle beholderne i en pod deler samme vert og samme IP-adresse, og de lever eller dør sammen. Du angir hvor mange forekomster av en pod du vil kjøre, og Kubernetes utfører bestillingen. Hvis en forekomst stopper eller mislykkes, spinner Kubernetes opp en annen for å matche ønsket tilstand.

En Kubernetes-tjeneste er en abstraksjon som definerer et logisk sett med pods og en policy for å få tilgang til dem. Dette gir en (mikro) tjeneste et enkelt, stabilt navn og adresse over hele podsyklusen. Det er mye mer til dette, men det skal hjelpe deg å forstå hvorfor du trenger en egen komponent for å administrere nettverket. I Atomic Host er den komponenten Flannel.

Atomic Host oppgraderinger og nedgraderinger

Atomic Host bruker en pakkehåndtering kalt RPM-OSTree, som kombinerer funksjonene i den tradisjonelle RPM og OSTree. RPM-OSTree gir oss muligheten til pålitelig å rulle fremover og bakover, siden prosessen er “atomisk” (i ordets databaseforstand). RPM-OSTree gir pålitelige transaksjoner for oppdateringer, noe som betyr at det er lite sannsynlig at operativsystemet brytes. I likhet med kommandoene for containere, vert oppgraderinger og tilbakeføringer foran atomisk styringssystem:

atomvertsoppgradering

tilbakeføring av atomverten

Merk at jeg ikke testet tilbakestilling, fordi jeg ikke hadde noe å rulle tilbake til.

Red Hat Atomic Host er best egnet for organisasjoner med store investeringer i Red Hat ferdigheter og infrastruktur. Bedrifter som starter fra en annen vinkel, vil kanskje vurdere andre alternativer. Inkluderingen av Kubernetes og historien til Red Hat i store produksjonsmiljøer betyr at Atomic Host nesten vil være et "drop-in" for å kjøre containeriserte arbeidsbelastninger i bedrifter. Men jeg ser ikke utviklere som plukker den opp som deres valgte Docker-plattform.

$config[zx-auto] not found$config[zx-overlay] not found