Šajā apmācībā Java izstrādātāji tiek iepazīstināti ar Docker Swarm. Jūs uzzināsiet, kāpēc tik daudz uzņēmumu veikalu ir pieņēmuši konteineru pārvaldītu attīstību, izmantojot Docker, un kāpēc kopu veidošana ir svarīga tehnika darbā ar Docker konteineriem. Jūs arī uzzināsiet, kā salīdzina divas populāras Docker kopu veidošanas tehnoloģijas - Amazon ECS un Docker Swarm, un saņemsiet ātru ceļvedi, kā izvēlēties pareizo risinājumu savam veikalam vai projektam. Apmācība noslēdzas ar praktisku Docker Swarm izmantošanas demonstrāciju divu mezglu uzņēmuma kopas izstrādei un pārvaldībai.
Lasīt tūlīt: Konteineru pārvaldīta izstrāde ar Docker
Pirms ienirt Docker Swarm, ieteicams iepazīties ar konteineru pārvaldītu attīstību un Docker pamatiem. Turpmāk ir sniegts pārskats, bet padziļinātākas diskusijas skatiet manā ievadā Docker. Izstrādātājiem, kuri pārzina šos pamatus, vajadzētu pāriet uz nākamo sadaļu.
Kāds ir darījums ar Docker?
Docker ir atvērta platforma izplatītu lietojumprogrammu veidošanai, nosūtīšanai un darbināšanai. Dokerizētās lietojumprogrammas var darboties lokāli ar izstrādātāja mašīnu, un tās var izvietot ražošanā visā mākoņa infrastruktūrā. Docker ir spējīgs strauji attīstīties un nodrošina nepārtrauktu integrāciju un nepārtrauktu ieviešanu, kā to nedara gandrīz neviena cita tehnoloģija. Šo funkciju dēļ tā ir platforma, kuru katram izstrādātājam vajadzētu zināt, kā to izmantot.
Ir svarīgi saprast, ka Dokers ir a konteinerizēšana tehnoloģija, nevis a virtualizācija tehnoloģija. Tā kā virtuālajā mašīnā ir pilnīga operētājsistēma, un to pārvalda smagsvara process, ko sauc par hipervizoru, konteiners ir paredzēts ļoti vieglam un patstāvīgam. Katrā serverī tiek palaists dēmona process, ko sauc par Docker motoru, kurš vada konteinerus un tulko operētājsistēmas zvanus konteinerā vietējos zvanos resursdatora operētājsistēmā. Tvertne, kas ir analoga virtuālajai mašīnai, tikai daudz mazāka, mitina jūsu lietojumprogrammu, izpildlaika vidi un barebones operētājsistēmu. Konteineri parasti darbojas virtuālajās mašīnās. Lai gan virtuālās mašīnas palaišana var aizņemt minūtes, konteiners to var izdarīt dažu sekunžu laikā.
1. attēlā parādīta atšķirība starp konteineru un virtuālo mašīnu.
Docker konteineri ir patstāvīgi, tas nozīmē, ka tie ietver visu nepieciešamo, lai palaistu jūsu lietojumprogrammu. Piemēram, tīmekļa lietojumprogrammai, kas darbojas Tomcat, konteinerā būtu jāietver:
- WAR fails
- Runcis
- JVM
- Bāzes operētājsistēma
2. attēlā parādīta tīmekļa lietotnes arhitektūra Docker konteinerā.
Docker gadījumā katra virtuālā mašīna palaiž dēmonu procesu, ko sauc par Dokera dzinējs. Jūs izveidojat savu lietojumprogrammu, piemēram, WAR failu, un pēc tam izveidojat atbilstošu Dockerfile. Dockerfile ir teksta fails, kurā aprakstīts, kā izveidot Dokera attēls, kas ir binārs fails, kurā ir viss nepieciešamais lietojumprogrammas darbināšanai. Piemēram, jūs varētu izveidot Dockerfile no Tomcat bāzes attēla, kas satur bāzes Linux OS, Java izpildlaiku un Tomcat. Pēc tam, kad Docker ir uzdots kopēt WAR failu Tomcat tīmekļa lietojumprogrammu direktorijā, Dockerfile tiks apkopots Docker attēlā, kas sastāv no pamata OS, JVM, Tomcat un jūsu WAR faila. Jūs varat palaist Docker attēlu lokāli, bet galu galā to publicēsit vietnē Dokeru krātuve, piemēram, DockerHub.
Lai gan Docker Image ir jūsu konteinera binārā versija, Docker Image izpildlaika instanci sauc par Docker konteiners. Docker konteinerus vada jūsu Dokera dzinējs. Mašīnu, kas darbojas jūsu Docker motorā, sauc par Dokera saimnieks; tas var būt jūsu vietējais klēpjdators vai mākoņa platforma, atkarībā no lietojumprogrammas mēroga.
Šīs sadaļas pamati ir pamats, lai saprastu, kāpēc klasterošana ir svarīgs jūsu Docker rīkkopas papildinājums. Lai uzzinātu vairāk, skatiet manu ievadu Docker.
Dokera kopu veidošana
Lielākā daļa izstrādātāju, kas sāk darbu ar Docker, izveidos Dockerfile un palaidīs to lokāli klēpjdatorā. Bet konteineru pārvaldītajā attīstībā ir vairāk nekā atsevišķu Docker konteineru palaišana lokāli. Docker lielvalsts ir tā spēja dinamiski mērogot konteinerus uz augšu vai uz leju. Ražošanā tas nozīmē Docker palaišanu klasterī pāri daudzām mašīnām vai virtuālajām mašīnām.
Ir pieejamas dažādas Docker kopu veidošanas tehnoloģijas, taču divas populārākās ir Amazon EC2 Container Service (ECS) un Docker Swarm.
Amazon ECS
Amazon Docker klasteru tehnoloģija izmanto Amazon Web Services (AWS), lai izveidotu virtuālo mašīnu kopu, kas var palaist Docker konteinerus. ECS kopu veido pārvaldītie ECS gadījumi, kas ir EC2 gadījumi ar Docker motoru un ECS aģentu. ECS izmanto automātiskās mērogošanas grupu, lai paplašinātu un noslēgtu līgumu skaitu, pamatojoties uz CloudWatch politikām. Piemēram, kad ECS gadījumu vidējais CPU lietojums ir pārāk augsts, varat lūgt ECS sākt vairāk gadījumu, nepārsniedzot maksimālo gadījumu skaitu, kas noteikts automātiskās mērogošanas grupā.
Docker konteinerus pārvalda ECS pakalpojums un konfigurēts pēc skaitļošanas jaudas (CPU) un RAM apjoma, kas konteineram ir nepieciešams, lai palaistu. ECS pakalpojumam ir saistīts elastīgais slodzes līdzsvarotājs (ELB). Sākot un apturot Docker konteinerus, ECS dienests reģistrē un atceļ šo konteineru reģistrāciju ELB. Kad esat izveidojis sava klastera noteikumus, Amazon ECS nodrošina, ka jums darbojas vēlamais konteineru skaits un visi šie konteineri ir pieejami caur ELB. 3. attēlā parādīts Amazon ECS augsta līmeņa skats.
Ir svarīgi nošķirt ECS gadījumi un uzdevumi. ECS kopa pārvalda jūsu ECS gadījumus, kas ir īpaši EC2 gadījumi, kas darbojas automātiskās mērogošanas grupā. ECS dienests pārvalda uzdevumus, kas var saturēt vienu vai vairākus Docker konteinerus un kuri darbojas klasterī. ELB sēž ECS gadījumu priekšā, kas darbojas jūsu Docker konteineros un sadala slodzi jūsu Docker konteineros. Saistība starp ECS uzdevumiem un Docker konteineriem ir tāda, ka uzdevuma definīcija ECS dienestam norāda, kurus Docker konteinerus palaist, un šo konteineru konfigurāciju. ECS dienests izpilda uzdevumu, kas palaiž Docker konteinerus.
Skatiet manu ievadu Amazon ECS vietnē VMTurbo.com.
Dokera bars
Docker vietējā klasterizācijas tehnoloģija Docker Swarm ļauj darbināt vairākus Docker konteinerus virtuālo mašīnu kopā. Docker Swarm nosaka a vadītājs konteiners, kas darbojas virtuālajā mašīnā, kas pārvalda vidi, izvieto konteinerus dažādiem aģentiem un ziņo par klastera konteinera statusu un izvietošanas informāciju.
Palaižot Docker Swarm, pārvaldnieks ir galvenais Docker interfeiss. Aģenti ir "dokeru mašīnas", kas darbojas virtuālās mašīnās, kuras reģistrējas pie pārvaldnieka un vada Docker konteinerus. Kad klients nosūta pārvaldniekam pieprasījumu sākt konteineru, pārvaldnieks atrod pieejamo aģentu tā palaišanai. Tas izmanto vismazāk izmantoto algoritmu, lai nodrošinātu, ka aģents, kurš vada vismazāk konteineru, darbinās tikko pieprasīto konteineru. 4. attēlā parādīta Docker Swarm konfigurācijas paraugs, kuru izstrādāsit nākamajā sadaļā.
Pārvaldnieka process zina par visiem aktīvajiem aģentiem un konteineriem, kas darbojas ar šiem aģentiem. Kad aģenta virtuālās mašīnas tiek startētas, tās reģistrējas pārvaldniekā un pēc tam ir pieejamas Docker konteineru palaišanai. 4. attēlā sniegtajā piemērā ir divi aģenti (Agent1 un Agent2), kuri ir reģistrēti pārvaldniekā. Katrs aģents vada divus Nginx konteinerus.
Docker Swarm vs Amazon ECS
Šajā rakstā ir Docker Swarm, taču ir lietderīgi salīdzināt konteineru tehnoloģijas. Tā kā Amazon ECS piedāvā labi izstrādātu risinājumu pēc atslēgas, Docker Swarm dod jums iespēju konfigurēt vairāk savas infrastruktūras. Piemēram, Amazon ECS pārvalda gan konteinerus, gan kravas līdzsvarotājus, savukārt Docker Swarm jūs konfigurējat tādu slodzes līdzsvarošanas risinājumu kā Cisco LocalDirector, F5 BigIp vai Apache vai Nginx programmatūras procesu.
Ja jūs jau lietojat savu lietotni AWS, tad ECS atvieglo Docker konteineru palaišanu un pārvaldīšanu nekā ārējs risinājums. Kā AWS izstrādātājs jūs, iespējams, jau izmantojat automātiskās mērogošanas grupas, ELB, virtuālo privāto mākoņu (VPC), identitātes un piekļuves pārvaldības (IAM) lomas un politikas utt. ECS labi integrējas visās no tām, tāpēc tas ir ceļš. Bet, ja jūs nedarbojaties AWS, tad Docker Swarm ciešā integrācija ar Docker rīkiem padara to par lielisku izvēli.
AWS un Docker Swarm hibrīda mākonī
Amazon Web Services var konfigurēt ļoti augstai pieejamībai, mērogojamībai un veiktspējai, iespējams, tāpēc tas apkalpo 25% no visas interneta trafika, ieskaitot masveidā mērogoto Netflix pakalpojumu infrastruktūru. Tomēr pēdējā laikā ir notikusi virzība uz hibrīda mākoņu vidi. A hibrīds mākonis ir mākonis, kurā daļa lietojumprogrammas vai dažreiz pilna tās kopija darbojas publiskā mākonī, piemēram, AWS, un daļa no tā darbojas privātā mākonī. Šajā gadījumā populāra iespēja ir palaist OpenStack privātā datu centrā.
Hibrīds mākonis ir droša stratēģija uzņēmumam, kas dažas vai visas darbības pārceļ uz mākoni, bet tam jāiet lēnām un jāiegūst pārliecība par publiskiem mākoņiem. Izvēloties hibrīda mākoņa opciju, virs pamata mākoņu tehnoloģijām ir jāizveido abstrakcijas slānis, kas nozīmē, ka jūs varat tikpat viegli izvietot Docker Swarm, kas darbojas OpenStack, savā datu centrā, kā arī ECS, kas darbojas AWS . Tādi rīki kā Šefpavārs un Leļļu var palīdzēt, ļaujot abstrakti definēt savu vidi, deleģējot tiem rīkoties ar daudzām atšķirībām starp dažādām vidēm.
Darba sākšana ar Docker Swarm
Iepriekšējā sadaļā jūs redzējāt divu mezglu Docker Swarm kopas arhitektūras paraugu. Tagad jūs izveidosiet šo kopu, izmantojot divus Nginx Docker konteineru gadījumus. Nginx ir populārs tīmekļa serveris, kas publiski pieejams kā Docker attēls vietnē DockerHub. Tā kā šis raksts ir koncentrēts uz Docker Swarm, es gribēju izmantot Docker konteineru, kuru tas ir ātri un viegli iedarbināms un vienkārši pārbaudāms. Jūs varat brīvi izmantot jebkuru vēlamo Docker konteineru, bet ilustratīviem nolūkiem es šim piemēram izvēlējos Nginx.
Manā ievadā Docker ir iekļauts ceļvedis Docker iestatīšanai jūsu attīstības vidē. Ja esat instalējis un iestatījis Docker Toolbox, tajā ir iekļauts viss nepieciešamais, lai palaistu Docker Swarm. Papildinformāciju par uzstādīšanu skatiet dokera oficiālajā dokumentācijā.
Docker Swarm komandrindā
Ja iepriekš esat lietojis Docker, esat iepazinies ar dokeris komandrinda, lai palaistu un apturētu konteinerus. Izmantojot Docker Swarm, jūs tirgosieties dokeris priekš dokotājs-mašīna. Docker Machine Docker dokumentācijā ir definēts šādi:
Ja esat instalējis Docker, instalācijā jau ir iekļauta Docker Machine. Lai sāktu darbu ar Docker Swarm, palaidiet Docker un datorā atveriet termināli. Izpildiet sekojošo docker-machine ls komandu, lai uzskaitītu visus vietējās mašīnas VM:
$ docker-machine ls NOSAUKUMS AKTĪVS PADĪTĀJA VALSTS URL SWARM noklusējums * virtualbox Darbojas TCP: //192.168.99.100: 2376 Ja Docker esat palaidis tikai no vietējās mašīnas, noklusējuma Docker virtuālajai mašīnai vajadzētu darboties ar IP adresi: 192.168.99.100. Lai taupītu resursus vietējā mašīnā, varat apturēt šo virtuālo mašīnu, izpildot: docker-machine stop noklusējums.
Izveido baru
Docker bars sastāv no divām vai virtuālām mašīnām, kurās darbojas Docker gadījumi. Šim demonstrējumam mēs izveidosim trīs jaunas virtuālās mašīnas: vadītājs, aģents1 un aģents2. Izveidojiet savas virtuālās mašīnas, izmantojot docker-machine izveidot komanda:
$ docker-machine create -d virtuālās kastes pārvaldnieks $ docker-machine create -d virtuālās kastes aģents1 $ docker-machine create -d virtuālās kastes aģents2 The docker-machine izveidot komanda izveido jaunu "mašīnu". Iet to -d arguments ļauj norādīt draiveri, kuru izmantot mašīnas izveidošanai. Skrienot lokāli, tā tam vajadzētu būt virtuālā kaste. Pirmā izveidotā mašīna ir vadītājs, kas uzņems menedžera procesu. Pēdējās divas mašīnas, aģents1 un aģents2ir aģentu mašīnas, kas uzņem aģenta procesus.
Šajā brīdī jūs esat izveidojis virtuālās mašīnas, bet neesat izveidojis faktisko Swarm pārvaldnieku vai aģentus. Lai apskatītu virtuālās mašīnas un to stāvokli, izpildiet docker-machine ls komanda:
$ docker-machine ls NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS agent1 - virtualbox Running tcp: //192.168.99.101: 2376 v1.11.1 agent2 - virtualbox Running tcp: //192.168.99.102: 2376 v1.11.1 default - virtualbox Stopped Unknown manager * virtualbox Running tcp: //192.168.99.100: 2376 v1.11.1 
