Programmēšana

Pārskats: Red Hat dara Docker grūti

Red Hat’s Project Atomic ir domājošs veids, kā palaist Linux konteinerus. Operētājsistēmas Atomic Host komplektācijā ietilpst jau instalēti Docker (konteineri), Flannel (tīklošana), OSTree (resursdatora pārvaldība), Etcd (izplatīts atslēgu vērtību krātuve) un Kubernetes (orķestrēšana).

Kubernetes ir viena no divām populārām konteineru orķestrēšanas sistēmām, otra ir Docker Swarm. Jūs to varētu nosaukt par “pilnvērtīgu”, taču līdz ar to rodas papildu sarežģītība un administratīvā pieskaitāmā summa.

Kubernetes koordinē “pākšu” izveidi vairākos Atomic resursdatoros. Pākstis ir Docker konteineru grupas, kas loģiski atdala pakalpojumus lietojumprogrammā. Tvertnē esošie konteineri koplieto IP adresi un sazinās, izmantojot vietējo hostu.

Flannel nodrošina pārklājuma tīklu Atomic saimniekiem, ļaujot katram klastera pākstim sazināties ar jebkuru citu klastera pogu vai pakalpojumu. Šis pārklājuma tīkls tiek izmantots tikai konteineru tīklošanai. Kubernetes starpniekserveris nodrošina piekļuvi resursdatora IP vietai.

Etcd tiek izmantots, lai saglabātu gan Kubernetes, gan Flannel konfigurācijas visos klastera resursdatoros.

Atomu konteineru kopas Kubernetes dēļ pieņem noteiktus pieņēmumus. Administratoriem patiešām nav izvēles iespējas ar Atomic: vai nu izmantojiet Kubernetes, vai atrodiet citu konteinera OS.

Ja jūs nobremzējat “dizains pēc vienošanās” un vēlaties lielāku brīvību un elastību konteineru saimniekdatorā, jūs varētu apsvērt RancherOS vai VMware Photon. Ja jūsu galvenais mērķis ir palaist daudz konteineru uz daudziem resursdatoriem, tad Atomic Host, Kubernetes un draugi var būt tieši tas, kas jums nepieciešams.

Atomic Host sistēmas administrēšana

Atomic Host izmanto savu dokeris komanda, atomu, kaut arī īstaisdokeris komanda ir pieejama mapē / bin / docker. Tā atrašanās vieta / tvertne norāda uz dažiem pārstrādes darbiem, kas tika veikti ar RHEL / CentOS / Fedora, lai Atomic OS būtu īpaši izveidota konteineriem. Parasti mapē / bin atrodas tikai svarīgi sistēmas binārie faili.

Jūs pārvaldāt Atomic Host, izmantojot divas apakšsistēmas. RPM-OSTree apstrādā resursdatora sistēmas izvietošanu un atjauninājumus, bet Docker - konteineru nodrošināšanu pakalpojumu un lietojumprogrammu darbināšanai. Abas šīs apakšsistēmas pārvalda atomu komanda atrodas / usr / bin /.

RPM-OSTree padara Atomic failu sistēmu nemaināmu; i., failu sistēma ir tikai lasāma, izņemot / var un / utt. Direktorijā / var / lib / docker tiek glabāti visi ar Docker saistītie faili un attēli, savukārt / etc ir visi konfigurācijas faili. Kā redzēsim vēlāk, tas padara vienkāršāku un drošāku resursdatora jaunināšanu un pazemināšanu, kas ir būtiska prasība, pārvaldot potenciāli tūkstošiem konteineru resursdatoru klasterī.

The atomu komanda ir paredzēta kā vienots ieejas punkts konteinera apakšsistēmā - jumta komanda visām lietām konteinerā, ieskaitot resursdatora darbības. The atomu komanda izskatās un jūtas līdzīga dokeris komandu, bet tā risina būtisku problēmu, kas ir kopīga visām konteinera resursdatora operētājsistēmām: sistēmas līmeņa pakalpojuma palaišana konteinerā sāknēšanas laikā, uzticami un pārredzami, izmantojot Systemd vienības failus.

Programmā Atomic tas tiek darīts ar tā saukto super-privileģēto konteineru, kam ir iespēja redzēt un manipulēt ar pašu resursdatoru. Tātad, kaut arī atomu izskatās kā standarta Docker komanda, tā aizpilda nepilnības starp Docker un RPM-OSTree - instalēšanas skriptu konfigurēšana, pakalpojumu iestatīšana, atbilstošu privilēģiju piešķiršana un tamlīdzīgi - lai nodrošinātu drošu konteineru lietojumprogrammas izvietošanu.

Vienkāršāk sakotatomu komanda ļauj manipulēt ar galveno resursdatora infrastruktūru (cgroups, namespaces, SELinux utt.), lai palaistu lietojumprogrammas. Piemēram, pieņemsim, ka esat izveidojis tīkla laika protokola (ntpd) konteinera lietojumprogrammu, kurai nepieciešama SYS_TIME spēja, lai mainītu resursdatora sistēmas laiku. To varētu konfigurēt, pievienojot metadatus konteinera attēlam, izmantojot komandu:

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

Tad, kad palaižat konteineru (atomu skrējiens ntpd), sistēma nolasīs šos metadatus un konfigurēs konteinera SYS_TIME iespējas un citus resursus.

Atomic Host instalēšana un konfigurēšana

Instalēšana bija cīņa, galvenokārt tāpēc, ka dokumentācija man šķita nesakārtota un mulsinoša. Dokumenti pieņem augstu zināšanu līmeni par Red Hat ekosistēmu, kas nebūs katram lasītājam. Pēc dažiem nepatiesiem startiem man beidzot izdevās instalēt no kaila metāla ISO. Atbalsts virtuālās mašīnas instalēšanai ar jebko citu, izņemot virt-manager, ir sāpīgs. Atomic Host šajā ziņā noteikti nav piemērots Windows vai Mac.

Ikvienam, kurš zina CentOS instalāciju, vienkārša metāla procedūra būs vienkārša. Vienīgās ievērojamās atšķirības ir diska izkārtojumā, jo vieta tiek automātiski rezervēta Docker un konteineriem, kā arī pārpilnība SELinux, cgroups utt.

Kubernetes izmantošana konteineru pārvaldīšanai visā klasterī ir ievērojami sarežģītāka nekā Docker palaišana vienā resursdatorā, taču ar lielāku sarežģītību tiek nodrošināta lielāka uzticamība un iespējas. Izmantojot Kubernetes, jūs gūstat arī komfortu, zinot, ka sistēma ir pārbaudīta cīņā liela mēroga ražošanas vidēs (Google).

Kubernetes meistara iestatīšana nav vienkārša. Dokumentācija ir izplatīta dažādās projekta vietnēs, un daudzas reizes dokumenti tiek meklēti citās vietnēs, lai iegūtu sīkāku informāciju, tāpēc esiet gatavs daudz laika pavadīt, lasot, vajājot dokumentus un eksperimentējot. Kopējā piepūle ir saistīta ar dažu desmitu failu pārveidošanu, kas izplatīti dažos / utt direktorijos. Protams, triks ir zināt, kādas ir šīs modifikācijas. Kubernetes nav īsti paredzēts gadījuma eksperimentiem ar konteineriem. Tas ir lieljaudas ražošanas materiāls.

Pēc kapteiņa konfigurēšanas ar Kubernetes, sertifikātiem, pakalpojumiem un Flannel pārklājuma tīklu, pēc tam katrā mezglā instalējot Flannel (flanneld), Kubernetes (kubelet) un Etcd, man beidzot bija piecu mezglu konteineru kopa. Diemžēl tas patērēja diezgan daudz atmiņas, un es nevarēju atrast veidu, kā testēt, izmantojot vienu mezglu, kā es to darīju, testējot RancherOS un VMware Photon.

Šajā brīdī Kubernetes var izmantot, lai palaistu un pārvaldītu pākstis - tās konteineru grupas, kas iekapsulē pakalpojumus un lietojumprogrammas.

Atomic Host uzglabāšana un tīklošana

Tāpat kā lielākajai daļai konteineru resursdatora operētājsistēmu, arī Atomic Host izmanto minimālistisku pieeju, tajā ir pietiekami daudz diska vietas, lai palaistu resursdatoru. Tas daudz neatstāj daudzos Docker konteineros, kurus darbinās tipisks kopa, tāpēc jums tam būs jāpiesaista ārējā krātuve resursdatoram.

Programmā Docker attēli un saistītie faili parasti tiek glabāti mapē / var / lib / docker, un lielākajā daļā standarta operētājsistēmu faila sistēmas tajā brīdī vienkārši jāpiestiprina ierīce, lai pievienotu krātuvi. Tomēr Atomic izmanto tiešos LVM (Linux Volume Manager) sējumus, izmantojot Device Mapper aizmuguri, lai saglabātu Docker attēlus un metadatus: / dev / atomicos / docker-data un / dev / atomicos / docker-meta. Tas nozīmē, ka jums būs jāapgūst kaut kas par LVM un apjomiem, lai pievienotu vietu Atomic resursdatoram.

Atomic krātuves pārvaldības sākumpunkts ir iestatīšanas skripts, / etc / sysconfig / docker-storage-setup. Atomic Host ir Docker (un resursdatora) krātuves krātuve, tāpēc triks šeit ir jaunas ierīces pievienošana šim baseinam. Jūs to izdarīsit, pievienojot failu ierīču sarakstam šādi:

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

Pēc tam palaižat palīga skriptu / usr / bin / docker-storage-setup. Ja viss izdosies, jūsu diski ir pievienoti baseinam, un jūsu Atomic resursdatorā ir vieta Docker. Es pieņemu, ka LVM tiks pārvaldīts ražošanā ar esošajiem administrēšanas rīkiem vai ar tādiem kā Ansible / Salt / Chef / Puppet skriptiem, tāpēc, iespējams, tas būs daudz standarts administratoriem, kuri strādā lielās datu centru vidēs.

Project Atomic izmanto Flannel, lai nodrošinātu konteineru pārklājuma tīklu, izmantojot Etcd. Jūs to konfigurējat, nospiežot JSON konfigurācijas failu Etcd atslēgas vērtību krātuvē, izmantojot tādus rīkus kā Curl. Lai konfigurētu konteineru apakštīklu, mēs varētu izveidot šādu JSON failu:

“Tīkls”: “172.16.0.0/12”,

“SubnetLen”: 24,

“Backend”: {

“Tips”: “vxlan”

   }

}

Un, lai to iegūtu Etcd master, mēs to ievietojam tīkla konfigurācijas atslēgā:

čokurošanās -L //localhost:2379/v2/keys/atomic.io/config -XPUT --data-urlencode [email protected]

Kaut arī tas ir nedaudz apgrūtinošs, tas ir vadāms. Es labprāt redzētu iesaiņojumu šīm konfigurācijas komandām, kas padara to intuitīvāku Unix administratoram, iespējams, kaut ko līdzīgu atomic ifconfig…, atomu ceļš…utt.

Šeit ir vēl viena atšķirība, kuru vērts uzsvērt: Kubernetes pākšu un pakalpojumu jēdzieni. Pāksts ir konteineru grupa, kas ir samērā cieši savienota. Visiem podā esošajiem konteineriem ir viens un tas pats resursdators un viena IP adrese, un viņi visi dzīvo vai mirst kopā. Jūs norādāt, cik pākstis vēlaties palaist, un Kubernetes izpilda pasūtījumu. Ja eksemplārs apstājas vai neizdodas, Kubernetes pagriež citu, lai tas atbilstu vēlamajam stāvoklim.

Kubernetes pakalpojums ir abstrakcija, kas nosaka loģisku pākšu kopu un politiku, pēc kuras tām piekļūt. Tas (mikro) pakalpojumam piešķir vienu, stabilu vārdu un adresi visā poda dzīves ciklā. Šajā ziņā ir daudz vairāk, taču tam vajadzētu palīdzēt saprast, kāpēc tīkla pārvaldībai ir nepieciešams atsevišķs komponents. Programmā Atomic Host šī sastāvdaļa ir Flaneļa.

Atomic Host jauninājumi un pazemināšana

Atomic Host izmanto pakotņu pārvaldnieku RPM-OSTree, kas apvieno tradicionālo RPM un OSTree iezīmes. RPM-OSTree dod mums iespēju droši pārvietoties uz priekšu un atpakaļ, jo process ir “atoms” (šī vārda datubāzes nozīmē). RPM-OSTree nodrošina uzticamus atjauninājumu darījumus, kas nozīmē, ka maz ticams, ka tas izjauks operētājsistēmu. Tāpat kā komandas konteineriem, arī resursdatora jauninājumus un atcelšanu nodrošina atomu vadības sistēma:

atomu resursdatora jauninājums

atomu saimnieka atcelšana

Ņemiet vērā, ka es nepārbaudīju atcelšanu, jo man nebija pie kā atgriezties.

Red Hat Atomic Host ir vispiemērotākais organizācijām, kurām ir lielas investīcijas Red Hat prasmēs un infrastruktūrā. Uzņēmumi, sākot no cita rakursa, varētu vēlēties apsvērt citas iespējas. Kubernetes un Red Hat vēstures iekļaušana lielās ražošanas vidēs nozīmē, ka Atomic Host būs gandrīz “piliens” konteineru noslodzes darbināšanai uzņēmumos. Bet es neredzu, ka izstrādātāji to izvēlas kā savu izvēlēto Docker platformu.

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