Vai Dokers un Kubernetes piedāvā labāko arhitektūru?

Sveiki, es esmu atpakaļ pie vēl viena raksta. Bet šoreiz man ir noskaņojums atrisināt dažus mītus.

Pasaule mainās katru sekundi, tāpat kā tehnoloģija. Kas attiecas uz Docker un Kubernetes, jums ir jāklausās daudz ko. It īpaši viņu arhitektūras salīdzinājums. Daudzi cilvēki domā, kurš no tiem ir labāks?

Ir daudz citu jautājumu, un es tos visus pieminu. Kāpēc? Vienīgais iemesls ir tas, ka tas palīdzēs jums saprast Kubernetes un Docker. Tātad, kā Docker un Kubernetes ir mainījuši programmatūras attīstību? Vai kāds no viņiem piedāvā spēcīgu arhitektūru? Vai ir iespējams vienādot attīstības un integrācijas procesus? Ja jā, kādi ir ierobežojumi? Vai tas mazinās sarežģījumus izstrādātājiem?

Pirmkārt, saprotiet, ka salīdzināt Docker un Kubernetes nav tik vienkārši, kā jūs domājat. Kas ir labāks? Dokers vai Kubernetes? Es uzskatu, ka nav “labāka”, jo viņi abi ir atšķirīgi. Dokers ir autobuss, bet Kubernetes ir autobusa osta. Tātad, kas ir svarīgi? Noteikti abi ir svarīgi. Jums vajag viņus abus.

Tātad šajā rakstā mēs ceļosim no reālās dzīves uz attīstības procesiem uz arhitektūru un atpakaļ uz reālo dzīvi.

Tālāk mēs identificēsim dažādus komponentus un principus, kas ir arhitektūras sastāvdaļa. Noslēgumā secinājums varētu jūs pārsteigt vai iepriecināt. Tas ir atkarīgs no jūsu uztveres un pieredzes ar Docker un Kubernetes.

Pirmais solis no reālās dzīves uz attīstības darbplūsmām

Vai jūs zināt, kāpēc attīstības procesi ir svarīgi? Ja nav attīstības procesu, nav arī labi virzītas vispārinātas pieejas. Izstrādes process samazina laiku no idejas rašanās līdz tās realizēšanai. Tas vienkāršo procesu un uztur kvalitāti.

Ir divu veidu idejas: viena ir laba, otra - slikta. Attīstībā nav trešā veida starpposma idejas. Ideja var būt laba vai slikta, bet to var izmērīt tikai ar ieviešanu. Ja tā ir slikta ideja, jūs to īstenojat un atceļat! Ja tā ir laba ideja, jūs vienkārši turpiniet. Atcelšanu kontrolē robots, t.i., automatizācija.

No tā visa pastāvīga integrācija un piegādes sistēma ir kļuvusi par dzīvības glābēju. Tas ir atvieglojis lietas. Ja jums ir ideja un kods, īstenojiet to! Bet ir viena maza problēma ar integrāciju un piegādes sistēmu. Procesu ir grūti formalizēt atrauti no tehnoloģijām un biznesa procesiem, kas raksturīgi tieši jūsu uzņēmumam.

Tātad, kā šī problēma tika atrisināta?

Tagad šī problēma tika atrisināta ar Docker un Kubernetes palīdzību. Viņi abi parādījās kā mesijas. Abstrakcijas līmenis un ideoloģiskā pieeja atrisināja gandrīz 80% problēmas. Labi, 80% ir ļoti labs procents attīstības nozarē. 20% joprojām ir, un, lai to atrisinātu, ir jābūt radošam ģēnijam. Tas ir atkarīgs no lietojuma veida un tā risināšanas veida.

Docker risina attīstības darbplūsmas problēmu. Docker piedāvā vienkāršu procesu un ir pietiekams lielākajai daļai darba vides.

Attēla avots: https://cdn-images-1.medium.com/max/800/0*nDrc_jeOKTMS7akB.

Ar šīs pieejas palīdzību var visu automatizēt un apvienot.

Ievads attīstības vidē

Pirmkārt, projektā jāiekļauj fails docker-compose.yml. Šī faila priekšrocība ir tā, ka tas noņems slodzi, kas saistīta ar lietojumprogrammas / pakalpojuma darbību vietējā mašīnā. Izstrādātājam par to nav jādomā. Patiesībā, lai palaistu savu lietojumprogrammu, pietiek ar vienkāršu dokotāju-sastādīt komandu. Komanda rūpējas arī par atkarībām, datu bāzes aizpildīšanu ar armatūru, lokālā koda augšupielādi konteinera iekšienē, koda izsekošanas iespējošanu un reaģēšanu paredzētajā ostā.

Papildus visam, jums arī nav jāuztraucas par sākšanu, izmaiņu veikšanu, ietvaru izvēli utt. Viss un iepriekš ir aprakstīts standarta instrukcijās. To diktē pakalpojumu veidnes, kā paredzēts tādās konfigurācijās kā priekšējā daļa, aizmugure un darbinieks.

Laiks automatizētai pārbaudei

Vai esat dzirdējuši par “melno kasti”? Tas reģistrē visu, pat pēdējās sekundes pirms lidmašīnas avārijas. Kas notika? Kā tas notika? Tas viss tiek iegūts no melnās kastes. Tāpat šeit ir melnā kaste.

Attēla avots: https://cdn-images-1.medium.com/max/800/0*B5Qn9D5W4lscB86h.

Tāpat kā oriģinālā melnā kaste, arī mūsu konteineru melnajā kastē tiek glabāts viss. Visi binārie dati, 1 vai 0, utt., Tiek saglabāti melnajā lodziņā. Tātad, kā notiek automatizācija? Tas ir vienkārši, jums ir komandu komplekts, un dokotājs-komponents.yml apraksta visas tā atkarības. Tas noved pie automatizācijas un vienotas testēšanas. Nav nepieciešams koncentrēties uz ieviešanas detaļām.

Sistēmu piegāde

Attēla avots: https://cdn-images-1.medium.com/max/800/0*DC5Ubn7Y5seJPeSO.

Projekta uzstādīšanas vietai un laikam nav nozīmes. Nav atšķirības, kuru visas ekosistēmas daļu jūs instalēsit. Instalācijas procesa rezultāts vienmēr būs vienāds. Vissvarīgākais ir “idempotence”. No jūsu puses norādiet mainīgos, kas kontrolē instalēšanu.

Tam visam ir algoritms. Ļaujiet mums to pakāpeniski uzskaitīt.

(1) Apkopojiet attēlus no Dockerfiles.

(2) Attēlu piegādei izmantojiet metaprojektu. Tie jāpiegādā Kubernetes, izmantojot Kube API. Nepieciešamie ievades parametri ir:

(a) Kube API galapunkts

b) slepens objekts, kas atšķiras atkarībā no konteksta (vietējais / izstāžu zāle / inscenējums / producēšana)

Šo sistēmu sistēmu nosaukumi un Docker attēlu tagi.

Piemēram, apsveriet metaprojektu, kas sastāv no visām sistēmām un pakalpojumiem. Tas nozīmē, ka projektā ir aprakstīts ekosistēmas izvietojums un aprakstīts, kā tai tiek piegādāti atjauninājumi. Šajā nolūkā es integrēšanai ar Kube API izmantošu iespējamos sarakstus. Bet ir arī citas iespējas! Kopumā arhitektūras pārvaldīšanai ir jādomā centralizētā virzienā. Kad esat pārliecināts par to, varat ērti pārvaldīt pakalpojumus / sistēmas.

Vides uzstādīšana ir nepieciešama izstāžu zālē (manuālai pārbaudei un sistēmas atkļūdošanai), iestudēšana (gandrīz tiešai videi un integrācijai) un ražošana (faktiskā vide tiešajam lietotājam).

Nepārtraukta piegāde un integrācija

Jūs esat laimīgs cilvēks, ja sekojat vienotam Docker attēlu pārbaudes veidam. Tas palīdzēs jums nemanāmi integrēt funkciju filiāli GIT repozitorija augšējā vai galvenā filiālē. Vienīgais, kas jārūpējas, ir saglabāt integrācijas un piegādes secību. Ja izlaišanas nav, kā jūs varētu novērst “sacensību apstākļus” vienā sistēmā ar vairākām paralēlām funkciju atzarām?

Kāds ir risinājums? Procesam vajadzētu sākties, kad nav konkurences.

Darbības:

(1) Atjauniniet funkciju filiāli augšup.

(2) Veidojiet attēlus.

(3) Pārbaudiet uzceltos attēlus.

(4) Sāciet un pagaidiet, līdz 2. darbība ir pabeigta un attēli tiek piegādāti.

(5) Ja 4. solis neizdodas, atlieciet ekosistēmu atpakaļ uz iepriekšējo soli.

(6) Apvienot funkciju filiāli augšpus. Nosūtiet to krātuvei.

Ja kāda no iepriekšminētajām darbībām neizdodas, piegādes process nekavējoties tiek pārtraukts. Uzdevums tiek atdots izstrādātājam, līdz tas nav atrisināts. Tas pats process var darboties ar vairāk nekā vienu repozitoriju. Katra no šīm darbībām jāveic līdzīgi, bet katrai krātuvei. Piemēram, 1. darbība krātuvei A un solis krātuvei B un tā tālāk.

Kubernetes dod jums brīvību ieviest atjauninājumus pa daļām. Neskaitāmas AB pārbaudes var izvērst un iziet riska analīzi. Kubernetes iekšēji atdala pakalpojumus un lietojumprogrammas.

Atcelšanas sistēmas

No dažām no svarīgākajām spēcīgas arhitektūras struktūras spējām ir spēja atgriezties. Ir vairākas skaidras un netiešas nianses. Apskatīsim viņus:

(1) Dienestam vajadzētu būt iespējai izveidot savu vidi un arī atgriešanos.

(2) Ja atcelšana nav iespējama, pakalpojumam jābūt polimorfam. Tam būtu jāatbalsta gan vecā, gan jaunā koda versijas.

(3) Pēc atcelšanas jebkuram pakalpojumam jābūt atpakaļejošai.

Kubernetes klasterī ir viegli atcelt stāvokļus. Bet tas darbosies tikai tad, ja jūsu metaprojektā būs informācija par šo momentuzņēmumu. Sarežģīti piegādes atcelšanas algoritmi tiek atturēti, taču ir nepieciešami.

Tātad kādos apstākļos vajadzētu iedarbināt atcelšanas mehānismu?

(1) Ja pēc izlaišanas ir augsts lietojumprogrammas kļūdu procents.

(2) Kad sākat saņemt signālus no galvenajiem uzraudzības punktiem.

(3) Ja dūmu testi neizdodas.

(4) To var izdarīt manuāli.

Drošības pasākumi

Padarīt ekosistēmu ložu necaurlaidīgu nav viegli. To nevar izdarīt, vienkārši sekojot vienai darbplūsmai. Arhitektūras sistēmai jābūt pietiekami drošai, lai risinātu visus jautājumus. Kubernetes komplektā ir daži labi iebūvēti piekļuves kontroles, tīkla politikas, notikumu audita utt. Mehānismi. Ir daži informācijas drošības rīki, un tie ir izrādījušies lieliski aizsardzības ziņā.

Nākamais solis, sākot no izstrādes darbplūsmām un beidzot ar arhitektūru

Gandrīz obligāts ir arhitektūras ietvars, kas piedāvā elastību, mērogojamību, pieejamību, uzticamību, aizsardzību pret draudiem utt. Tā ir izšķiroša lieta. Faktiski šī vajadzība noveda pie jaunas koncepcijas. Vai ir kādi minējumi? Jā, DevOps. Tas noveda pie pilnīgas automatizācijas un optimizācijas infrastruktūras koncepcijas.

Tagad bija pienācis laiks mainīt arhitektūru no Monolithic uz Microservices. Tas piedāvā milzīgas uz pakalpojumu orientētas arhitektūras priekšrocības. Vismaz Docker un Kubernetes ideoloģiski ir nepareizi izmantot monolītu arhitektūru. Noteikti apspriedīšu dažus mikropakalpojumu arhitektūras punktus. Lai iegūtu padziļinātas zināšanas par DevOps, lūdzu, izlasiet šo rakstu par DevOps.

Tagad mēs ātri apspriedīsim galvenos kritiskos komponentus un labas arhitektūras risinājumus.

Kritiskās sastāvdaļas

1. numurs - identitātes pakalpojums:

Identitātes mikropakalpojums attiecas uz “identitāti kā mikropakalpojumu”. Pakalpojumi ir viegli. Tas nodrošina modularitāti un ļauj elastīgi lietot. Identitātes mikropakalpojums ir jaudīgs, un tam ir pieeja visiem profila datiem. Tas spēj nodrošināt visu nepieciešamo, kas ir visu lietojumu pamatā.

Ja vēlaties būt tādu lielu uzņēmumu platformu kā IBM, Google, Microsoft utt. Klients, piekļuvi apstrādā pārdevēja pakalpojumi. Bet ko darīt, ja vēlaties savu risinājumu? Topošajā sadaļā esošais saraksts palīdzēs jums to izlemt.

Numurs 2 - automatizēta pakalpojumu sniegšana:

Izveidotie pakalpojumi ir neatkarīgi viens no otra. Tas noved pie vieglas izstrādes un mazāk kļūdu. Tas palīdz arī dinamiskā un automatizētā veidā meklēt citus pakalpojumus.

Kubernetes samazina nepieciešamību pēc papildu komponentiem. Bet tomēr ir jā automatizē jaunu mašīnu pievienošana. Šeit ir rīku saraksts:

(1) KOPS - palīdz instalēt kopu AWS vai GCE.

(2) Teraform - palīdz pārvaldīt jebkuras vides infrastruktūru.

(3) Iespējams - piedāvā jebkura veida automatizāciju.

Es personīgi iesaku Ansible, jo tas palīdz strādāt gan ar serveriem, gan ar Kubernetes objektiem.

Numurs 3 - Git krātuve un uzdevumu izsekošana:

Izmantojot Git krātuves, ar uzdevumiem var tikt galā viegli. Pamatideja ir neliela krātuve. Tas kalpo kā vides izsekotājs. Saturs ietver kāda veida versijas, kas izmantojamas dažādiem pakalpojumiem. Vēlamā avota kontroles sistēma tam ir “git”.

Visām svarīgajām diskusijām vajadzētu būt atbilstošai darba vietai komandas darbam un kodu glabāšanai. Ja vēlaties bezmaksas pakalpojumu, dodieties uz Redmine. Citādi, Jira ir maksas pakalpojums un diezgan noderīgs. Kodu krātuvē Gerrit ir lieliska izvēle par brīvu!

Numurs 4 - dokotāju reģistrs:

Dakšu reģistrs ir uzglabāšanas un satura piegādes sistēmas tips. Tam ir Docker attēlu nosaukums un tas ir pieejams dažādās versijās ar marķējumu. Lai mijiedarbotos ar reģistru, lietotājam vajadzētu aktivizēt push and pull komandas.

Dokera attēlu pārvaldības sistēma ir diezgan svarīga. Sistēmai vajadzētu arī atbalstīt piekļuvi lietotājiem un lietotāju grupai. Šim nolūkam izvēlieties mākoņa risinājumu vai kādu privātu mitinātu pakalpojumu. Labs variants ir Vmware osta.

Numurs 5 - CI / CD un pakalpojumu piegāde:

Tikai nepārtraukta integrācija un piegādes pakalpojums savieno iepriekš apspriestos komponentus. Nepārtraukta piegāde nozīmē, ka pakalpojums ir vienkāršs un tam nav loģikas. KI / CD pakalpojumam būtu jāreaģē tikai uz ārējās pasaules notikumiem, piemēram, izmaiņām GIT krātuvē utt.

Integrācijas pakalpojums ir atbildīgs par automātisku pakalpojumu testēšanu, pakalpojumu piegādi, atcelšanu, pakalpojumu noņemšanu un attēlu veidošanu.

Skaitlis 6 - žurnāla savākšana un analīze:

Jebkurā mikropakalpojumu lietojumprogrammā ir svarīgi izsekot problēmai. Izsekošana ir iespējama ar mežizstrādes palīdzību. Tātad reģistrēšana un uzraudzība sniedz jums visaptverošu sistēmas pārskatu.

Žurnāli ir pieejami, rakstot tos sakņu procesa STDOUT vai STDERR. Žurnālu datiem jābūt pieejamiem pēc nepieciešamības. Tajā jābūt arī ierakstiem no pagātnes.

Skaitlis 7 - izsekošana, uzraudzība un trauksme:

Rīki, piemēram, Opentracing un Zipkin, palīdz saprast kļūdu. Piemēram, kur tu nogāji greizi? Šie rīki palīdzēs jums atbildēt uz šādiem jautājumiem. Neveiksmes notiek, un ir svarīgi tās izsekot.

Turklāt uzraudzību iedala trīs līmeņos. Tie ir fiziskais līmenis, klasteru līmenis un pakalpojumu līmenis. Pārraudzībā nav pieļaujamas kļūdas. Rīki, piemēram, Prometheus un OpsGenie, ir izrādījušies diezgan noderīgi uzraudzībā. OpsGenie arī brīdina un paziņo par problēmām visos līmeņos. Tāpēc izsekošanu, uzraudzību un brīdinājumus nekad nevajadzētu uztvert viegli. Tie ir pieteikuma aizsardzības daļa.

Numurs 8- API vārteja ar vienreizēju pierakstīšanos:

Mikropakalpojumos visiem zvaniem jāiet tikai caur API vārteju. Tas palīdz uzturēt drošību. Tas ir arī atbildīgs par API pieprasījumu maršrutēšanu. Tātad API vārteja ir piekļuves punkts visiem attiecīgajiem mikropakalpojumiem. Vienreizēja pierakstīšanās attiecas uz sesiju. Tas ir sava veida lietotāja autentifikācijas pakalpojums. Kā vienu vārdu, pieteikšanās akreditācijas dati tiek iestatīti vienreiz vai vienu reizi. Pēc tam to var izmantot, lai piekļūtu vairākām lietojumprogrammām.

Nepieciešams uzticams pakalpojums, lai apstrādātu tādus uzdevumus kā autorizācija, autentifikācija, lietotāja reģistrācija, vienreizēja pierakstīšanās utt. Pakalpojums tiek integrēts ar API vārteju, un ar to viss tiek apstrādāts.

Numurs 9 - Pasākumu autobuss:

Ja ekosistēmai ir simtiem pakalpojumu, tie jārisina uzmanīgi. Starpsaziņu komunikācija ir obligāta, un tajā nav pieļaujama kļūda. Datu plūsma ir jāracionalizē. Pasākumu kopne attiecas uz labi virzītu notikumu plūsmu no viena mikropakalpojuma uz otru.

Numurs 10 - datu bāzes un valsts pakalpojumi:

Mikropakalpojumu lietojumprogrammā parasti ir daudz pakalpojumu. Datu glabāšanas prasības visiem ir atšķirīgas atkarībā no pakalpojuma lomām. Tātad daži pakalpojumi ir labi ar relāciju datu bāzi, un citiem var būt nepieciešama NoSQL datu bāze, piemēram, MongoDB.

Doksers ir mainījis spēles noteikumus. Datu bāze ieņem centrālo vietu uzglabāšanas pasaulē. Lai kāds būtu risinājums, tam vajadzētu būt iespējai viegli strādāt Kubernetes vidē.

Atpakaļ uz realitāti, no arhitektūras līdz reālajai dzīvei

Es būšu diezgan godīgs pret jums, daloties manos uzskatos. Es uzskatu, ka nākotnē visa arhitektūra tiks uzskatīta par kļūmēm. Projektēšanas principi, pamati utt. Viss mainās! Bet jums jāpaliek spēles virsotnei. Tādēļ integrējieties profesionālajā sabiedrībā. Agrāk vai vēlāk jums būs jāpielāgojas šīm izmaiņām. Tad kāpēc gan nesākt pats tagad?

Ir daudz iespēju, bet tikai tad, ja atjaunināt sevi ar jaunajiem tehnoloģiskajiem atjauninājumiem.

Tagad atgriezīsimies pie šī raksta nosaukuma. Docker un Kubernetes ir labākā arhitektūra? Pagaidām noteikti “Jā”. Bet šī varētu būt pagaidām tikai labākā arhitektūra. Tiecieties vairāk, tiecieties pēc labākas, nevis labākās arhitektūras veidošanas!

Es ar jums visiem kopīgoju dažas noderīgas saites.

Docker raksts: Docker apmācība: konteineri, virtuālās mašīnas un doki iesācējiem

Docker Video Tutorial: Docker Video Tutorial Series

Kubernetes raksts: Kubernetes Bībele iesācējiem un izstrādātājiem

Kubernetes video apmācība: Kubernetes video apmācības sērija