Ohjelmointi

Arvostelu: Red Hat tekee Dockerille vaikean tavan

Red Hatin Project Atomic on mielipide-tapa ajaa Linux-kontteja. Atomic Host -käyttöjärjestelmään on jo asennettu Docker (säilöt), Flannel (verkko), OSTree (isännän hallinta), Etcd (hajautettu avainarvosäilö) ja Kubernetes (orkestrointi).

Kubernetes on yksi suosituimmista konttiorkesterijärjestelmistä, toinen Docker Swarm. Voisit kutsua sitä "täydelliseksi vahvuudeksi", mutta siihen liittyy lisä monimutkaisuutta ja hallinnollisia lisäkustannuksia.

Kubernetes koordinoi "podien" luomisen useiden Atomic-isäntien välillä. Pods ovat Docker-säilöjen ryhmiä, jotka erottavat palvelut loogisesti sovelluksessa. Podissa olevat säilöt jakavat IP-osoitteen ja kommunikoivat paikallisen isännän kautta.

Flannel tarjoaa peittoverkon Atomic-isännöille, jolloin kaikki klusterin podit voivat kommunikoida minkä tahansa klusterin toisen podin tai palvelun kanssa. Tätä peittoverkkoa käytetään vain konttiverkostoon. Kubernetes-välityspalvelu tarjoaa pääsyn isännän IP-tilaan.

Etcd: tä käytetään sekä Kubernetesin että Flannelin kokoonpanojen tallentamiseen klusterin kaikkien isäntien kesken.

Atomikonttijoukot tekevät tiettyjä oletuksia Kubernetesin takia. Järjestelmänvalvojilla ei todellakaan ole valinnanvaraa Atomicin kanssa: Käytä joko Kubernetesia tai etsi toinen kontti-käyttöjärjestelmä.

Jos hankaa "design by konvencion" ja haluat enemmän vapautta ja joustavuutta konttiisännässä, kannattaa harkita RancherOS: ta tai VMware Photonia. Jos lopullinen tavoitteesi on ajaa monia kontteja monilla isännöillä, Atomic Host, Kubernetes ja ystävät saattavat olla juuri sitä mitä tarvitset.

Atomic Host -järjestelmän hallinta

Atomic Host käyttää omaa versiotaan satamatyöläinen komento, atomi-, vaikka todellinensatamatyöläinen komento on käytettävissä / bin / docker. Sen sijainti / bin viittaa joihinkin uudistuksiin, jotka tehtiin RHEL / CentOS / Fedoralle, jotta Atomic-käyttöjärjestelmä olisi tarkoitettu konttien käyttöä varten. Normaalisti vain tärkeät järjestelmän binäärit ovat / bin.

Hallitset Atomic Hostia kahden alijärjestelmän kautta. RPM-OSTree huolehtii isäntäjärjestelmän käyttöönotosta ja päivityksistä, kun taas Docker huolehtii konttien toimittamisesta palvelujen ja sovellusten ajamiseksi. Molempia alijärjestelmiä hallinnoi atomi- komento sijaitsee / usr / bin /.

RPM-OSTree tekee Atomic-tiedostojärjestelmästä muuttumattoman; ts. tiedostojärjestelmä on vain luku -toiminto paitsi / var ja / jne. / Var / lib / docker-hakemistoon tallennetaan kaikki Dockeriin liittyvät tiedostot ja kuvat, kun taas / etc: llä on kaikki määritystiedostot. Kuten näemme myöhemmin, tämä tekee yksinkertaisemmista ja turvallisemmista isäntäkoneen päivityksistä, mikä on olennainen vaatimus hallitessa mahdollisesti tuhansia konttiisäntiä klusterissa.

atomi- -komento on tarkoitettu yhdeksi pääsykohdaksi konttiosajärjestelmään - kattokomento kaikelle kontille, isäntäoperaatiot mukaan lukien. atomi- komento näyttää ja tuntuu paljon satamatyöläinen komento, mutta se käsittelee kaikkien konttiisäntäkoneen käyttöjärjestelmien jakaman perustavanlaatuisen ongelman: järjestelmätason palvelun käynnistäminen säilössä käynnistyshetkellä luotettavalla ja läpinäkyvällä tavalla Systemd-yksikötiedostoja käyttämällä.

Atomicissa tämä tehdään ns. Etuoikeutetulla kontilla, jolla on kyky nähdä ja manipuloida itse isäntää. Joten vaikka atomi- näyttää tavalliselta Docker-komennolta, se täyttää aukot Dockerin ja RPM-OSTree: n välillä - konfiguroi asennuskomentosarjoja, määrittää palveluja, osoittaa oikeuksia ja vastaavia - jotta konttipohjainen sovellus voidaan ottaa käyttöön luotettavasti.

Yksinkertaisesti sanottunaatomi- -komennon avulla voit manipuloida taustalla olevaa isäntäinfrastruktuuria (ryhmät, nimitilat, SELinux jne.) sovellusten ajamiseksi. Oletetaan esimerkiksi, että olet rakentanut Network Time Protocol (ntpd) -sovellussovelluksen, joka vaatii SYS_TIME-ominaisuuden isännän järjestelmän ajan muuttamiseksi. Voit määrittää tämän lisäämällä metatiedot säilökuvaan komennolla:

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

Sitten kun suoritat kontin (atomiajo ntpd), järjestelmä lukee metatiedot ja määrittää SYS_TIME-ominaisuuden ja muut resurssit säilölle.

Atomic Hostin asennus ja määritykset

Asennus oli taistelua lähinnä siksi, että pidin dokumentaatiota järjestämättömänä ja hämmentävänä. Asiakirjat olettavat Red Hat -ekosysteemin korkean tietämyksen, jota kaikilla lukijoilla ei ole. Muutaman väärän käynnistyksen jälkeen onnistuin vihdoin asentamaan paljaasta metallista ISO: sta. Tuki virtuaalikoneen asennukselle muulla kuin virt-managerilla on tuskallista. Atomic Host ei todellakaan ole Windows- tai Mac-ystävällinen tässä suhteessa.

Kaikille, jotka tuntevat CentOS-asennuksen, paljaan metallin käsittely on helppoa. Ainoat huomattavat erot ovat levyn asettelussa, jossa tilaa varataan automaattisesti Dockerille ja säiliöille sekä lukuisia SELinux-alustoja, cgroupeja jne., Jotka ovat mukana kontti-käyttöjärjestelmän asennuksessa.

Kubernetesin käyttäminen konttien hallintaan klusterissa on huomattavasti monimutkaisempaa kuin Dockerin suorittaminen yhdellä isännällä, mutta entistä monimutkaisemmalla tasolla on suurempi luotettavuus ja kyky. Kubernetes tarjoaa sinulle myös mukavuuden siitä, että tiedät, että järjestelmä on testattu laajamittaisissa tuotantoympäristöissä (Google).

Kubernetes-masterin asentaminen ei ole helppoa. Dokumentaatio on jaettu useille projektisivustoille, ja monta kertaa asiakirjat siirtyvät muihin sivustoihin saadaksesi lisätietoja, joten ole valmis viettämään paljon aikaa lukemiseen, asiakirjojen jahtaamiseen ja kokeiluihin. Kokonaisponnistelujen summa sisältää muutaman tusinan tiedostojen muokkaamisen muutamiin / jne. Hakemistoihin. Tietysti temppu on tietää, mitkä muutokset ovat. Kubernetesia ei todellakaan ole tehty rennolle kokeilulle konttien kanssa. Tämä on raskasta tuotantotavaraa.

Kun pääkonfiguraatio oli määritetty Kubernetesilla, varmenteilla, palveluilla ja Flannel overlay -verkolla, asennettu Flannel (flanneld), Kubernetes (kubelet) ja Etcd kuhunkin solmuun, minulla oli viiden solmun konttiryhmä käynnissä. Valitettavasti tämä kulti melko vähän muistia, enkä löytänyt tapaa testata yhdellä solmulla, kuten tein RancherOSia ja VMware Photonia testattaessa.

Tässä vaiheessa Kubernetesia voidaan käyttää palvelujen ja sovellusten kapseloivien podien, niiden säilöryhmien, käynnistämiseen ja hallintaan.

Atomic Host -tallennus ja verkottuminen

Kuten useimmat kontti-isäntäkäyttöjärjestelmät, Atomic Host käyttää minimalistista lähestymistapaa, ja siinä on vain tarpeeksi levytilaa isännän suorittamiseen. Tämä ei jätä paljoa tyypillisen klusterin käyttämille monille Docker-säilöille, joten sinun on liitettävä siihen isäntälaitteeseen ulkoinen tallennustila.

Dockerissa kuvat ja niihin liittyvät tiedostot tallennetaan yleensä hakemistoon / var / lib / docker, ja useimmissa tavallisissa käyttöjärjestelmissä sinun tarvitsee vain liittää laite tiedostojärjestelmän tähän kohtaan lisätäksesi tallennustilaa. Atomic käyttää kuitenkin suoria LVM (Linux Volume Manager) -taltioita Device Mapper -käyttöjärjestelmän kautta Docker-kuvien ja metatietojen tallentamiseen: / dev / atomicos / docker-data ja / dev / atomicos / docker-meta. Tämä tarkoittaa, että sinun on opittava jotain LVM: stä ja volyymeistä, jotta voit lisätä tilaa Atomic-isäntään.

Atomicin tallennuksen hallinnan lähtökohta on asennusohjelma, / etc / sysconfig / docker-storage-setup. Atomic Hostissa on tallennusallas Docker (ja isäntä) -tallennustilaa varten, joten tässä temppu on uuden laitteen lisääminen tähän altaaseen. Teet tämän lisäämällä tiedoston laitteiden luetteloon seuraavasti:

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

Suoritat sitten auttajaskriptin, / usr / bin / docker-storage-setup. Jos kaikki menee hyvin, levyt on lisätty pooliin, ja Atomic-isännässäsi on tilaa Dockerille. Oletan, että LVM: ää hallitaan tuotannossa olemassa olevilla hallintatyökaluilla tai vastaavilla Ansible / Salt / Chef / Puppet -skripteillä, joten se näyttää todennäköisesti tavallisemmalta järjestelmänvalvojille, jotka työskentelevät suurissa datakeskusympäristöissä.

Project Atomic käyttää Flannelia tarjotakseen konttipeittoverkon Etcd: n kautta. Määrität tämän työntämällä JSON-määritystiedoston Etcd-avainarvosäilöön työkaluilla, kuten Curl. Voit määrittää aliverkon säilöille luomalla JSON-tiedoston, joka näyttää tältä:

"Verkko": "172.16.0.0/12",

“SubnetLen”: 24,

"Backend": {

"Tyyppi": "vxlan"

   }

}

Ja saadaksesi tämän Etcd-masteriin, työnnämme sen verkon määritysavaimeen:

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

Vaikka se on hieman hankala, se on hallittavissa. Haluaisin nähdä näiden määrityskomentojen kääreen, joka tekee siitä intuitiivisemman Unix-järjestelmänvalvojalle, ehkä jotain sellaista atomic ifconfig…, atomireitti…, jne.

Tässä on toinen korostamisen arvoinen ero: Kubernetes-käsitteet palkoista ja palveluista. Palkki on ryhmä kontteja, jotka on suhteellisen tiukasti kytketty toisiinsa. Kaikilla podin säiliöillä on sama isäntä ja sama IP-osoite, ja ne kaikki elävät tai kuolevat yhdessä. Määrität, kuinka monta pod-esiintymää haluat suorittaa, ja Kubernetes suorittaa tilauksen. Jos ilmentymä pysähtyy tai epäonnistuu, Kubernetes pyörii toisen vastaamaan haluttua tilaa.

Kubernetes-palvelu on abstraktio, joka määrittelee loogisen pod-sarjan ja käytännön, jolla niitä voidaan käyttää. Tämä antaa (mikro) palvelulle yhden, vakaan nimen ja osoitteen kaikkialla. Tässä on paljon muuta, mutta sen pitäisi auttaa sinua ymmärtämään, miksi tarvitset erillistä komponenttia verkon hallintaan. Atomic Hostissa kyseinen komponentti on Flannel.

Atomic Host -päivitykset

Atomic Host käyttää RPM-OSTree-nimistä paketinhallintaa, joka yhdistää perinteisten RPM- ja OSTree-ominaisuuksien ominaisuudet. RPM-OSTree antaa meille mahdollisuuden luotettavasti siirtyä eteenpäin ja taaksepäin, koska prosessi on "atominen" (sanan tietokannan merkityksessä). RPM-OSTree tarjoaa luotettavia tapahtumia päivityksille, mikä tarkoittaa, että on epätodennäköistä, että se rikkoo käyttöjärjestelmää. Kuten konttien komennot, myös isäntäkoneen päivitykset ja palautukset ovat atomi- hallintajärjestelmä:

atomi-isäntäpäivitys

atomin isännän palautus

Huomaa, että en testannut palautusta, koska minulla ei ollut mitään palautettavaa.

Red Hat Atomic Host sopii parhaiten organisaatioille, joilla on paljon investointeja Red Hat -taitoihin ja -infrastruktuuriin. Eri kulmasta lähtevät yritykset saattavat haluta harkita muita vaihtoehtoja. Kubernetesin ja Red Hatin historian sisällyttäminen suuriin tuotantoympäristöihin tarkoittaa, että Atomic Host on melkein "drop-in" konttikonttikuormien ajamiseksi yrityksissä. Mutta en näe kehittäjiä hakemassa sitä valitsemallaan Docker-alustalla.

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