ProHoster > Blogs > Administrācija > Nepārtrauktas piegādes prakse ar Docker (pārskats un video)

Nepārtrauktas piegādes prakse ar Docker (pārskats un video)

Mēs sāksim savu emuāru ar publikācijām, kuru pamatā ir mÅ«su tehniskā direktora jaunākās runas distol (Dmitrijs Stoļarovs). Tās visas notika 2016. gadā dažādos profesionālos pasākumos un bija veltÄ«tas DevOps un Docker tēmai. Viens video no Docker Moscow sanāksmes Badoo birojā jau ir publicēts TieÅ”saistē. Jaunajiem tiks pievienoti raksti, kas atspoguļo ziņojumu bÅ«tÄ«bu. Tātadā€¦

31. maijā konferencē RootConf 2016, kas notika festivāla ā€œKrievijas interneta tehnoloÄ£ijasā€ (RIT++ 2016) ietvaros, sadaļa ā€œNepārtraukta ievieÅ”ana un izvietoÅ”anaā€ tika atklāta ar ziņojumu ā€œParaugprakse nepārtrauktai piegādei ar Dockerā€. Tajā tika apkopota un sistematizēta labākā prakse nepārtrauktas piegādes (CD) procesa izveidei, izmantojot Docker un citus atvērtā pirmkoda produktus. Ar Å”iem risinājumiem strādājam ražoÅ”anā, kas ļauj paļauties uz praktisko pieredzi.

Nepārtrauktas piegādes prakse ar Docker (pārskats un video)

Ja ir iespēja pavadīt stundu reportāžas video, iesakām to noskatīties pilnībā. Pretējā gadījumā tālāk ir sniegts galvenais kopsavilkums teksta formā.

Nepārtraukta piegāde ar Docker

Saskaņā ar Nepārtraukta Piegāde mēs saprotam notikumu ķēdi, kuras rezultātā lietojumprogrammas kods no Git repozitorija vispirms nonāk ražoÅ”anā un pēc tam nonāk arhÄ«vā. Tas izskatās Ŕādi: Git ā†’ BÅ«vÄ“Å”ana ā†’ PārbaudÄ«t ā†’ Atlaist ā†’ Darbināt.

Nepārtrauktas piegādes prakse ar Docker (pārskats un video)
Lielākā daļa ziņojuma ir veltÄ«ta izveides posmam (lietojumprogrammas montāžai), un Ä«sumā tiek skartas tēmas, kas tiek atbrÄ«votas un darbojas. Mēs runāsim par problēmām un modeļiem, kas ļauj tos atrisināt, un Å”o modeļu konkrētās realizācijas var atŔķirties.

Kāpēc Å”eit vispār vajadzÄ«gs Dokers? Ne velti mēs nolēmām runāt par nepārtrauktas piegādes praksi Ŕī atvērtā pirmkoda rÄ«ka kontekstā. Lai gan viss pārskats ir veltÄ«ts tā lietoÅ”anai, apsverot galveno lietojumprogrammas koda izlaiÅ”anas modeli, tiek atklāti daudzi iemesli.

Galvenais izvērÅ”anas modelis

Tātad, izlaižot jaunas lietojumprogrammas versijas, mēs noteikti saskaramies ar dÄ«kstāves problēma, kas Ä£enerēts ražoÅ”anas servera pārslēgÅ”anas laikā. Trafiku no lietojumprogrammas vecās versijas uz jauno nevar pārslēgt uzreiz: vispirms ir jāpārliecinās, ka jaunā versija ir ne tikai veiksmÄ«gi lejupielādēta, bet arÄ« ā€œiesildÄ«taā€ (t.i., pilnÄ«bā gatava pieprasÄ«jumu apkalpoÅ”anai).

Nepārtrauktas piegādes prakse ar Docker (pārskats un video)
Tādējādi kādu laiku abas lietojumprogrammas versijas (vecā un jaunā) darbosies vienlaikus. Kas automātiski noved pie kopÄ«gu resursu konflikts: tÄ«kls, failu sistēma, IPC utt. Izmantojot Docker, Ŕī problēma ir viegli atrisināma, palaižot dažādas lietojumprogrammas versijas atseviŔķos konteineros, kuriem tiek garantēta resursu izolācija vienā un tajā paŔā resursdatorā (serveris/virtuālā maŔīna). Protams, ar dažiem trikiem var iztikt arÄ« bez siltināŔanas, taču, ja ir gatavs un ērts rÄ«ks, tad ir pretējs pamatojums - nepamest to novārtā.

Ievietojot konteineru, tiek nodroÅ”inātas daudzas citas priekÅ”rocÄ«bas. JebkurÅ” pieteikums ir atkarÄ«gs no konkrēta versija (vai versiju diapazons) tulks, moduļu/paplaÅ”inājumu pieejamÄ«ba utt., kā arÄ« to versijas. Un tas attiecas ne tikai uz tieÅ”o izpildāmo vidi, bet arÄ« uz visu vidi, ieskaitot sistēmas programmatÅ«ra un tā versija (lÄ«dz izmantotajam Linux izplatÄ«Å”anai). Sakarā ar to, ka konteineros ir ne tikai lietojumprogrammas kods, bet arÄ« iepriekÅ” instalēta nepiecieÅ”amo versiju sistēmas un lietojumprogrammatÅ«ra, jÅ«s varat aizmirst par problēmām ar atkarÄ«bām.

Vispārināsim galvenais izvērÅ”anas modelis jaunas versijas, ņemot vērā Ŕādus faktorus:

  1. Sākumā lietojumprogrammas vecā versija darbojas pirmajā konteinerā.
  2. Pēc tam jaunā versija tiek izrullēta un ā€œuzsildÄ«taā€ otrā konteinerā. JāatzÄ«mē, ka Å”ajā jaunajā versijā var bÅ«t ne tikai atjaunināts lietojumprogrammas kods, bet arÄ« jebkura no tā atkarÄ«bām, kā arÄ« sistēmas komponenti (piemēram, jauna OpenSSL versija vai viss izplatÄ«jums).
  3. Kad jaunā versija ir pilnÄ«bā gatava pieprasÄ«jumu apkalpoÅ”anai, datplÅ«sma tiek pārslēgta no pirmā konteinera uz otro.
  4. Veco versiju tagad var apturēt.

Šāda pieeja dažādu lietojumprogrammas versiju izvietoÅ”anai atseviŔķos konteineros nodroÅ”ina vēl vienas ērtÄ«bas - ātra atgrieÅ”ana uz veco versiju (galu galā pietiek, lai pārslēgtu trafiku uz vēlamo konteineru).

Nepārtrauktas piegādes prakse ar Docker (pārskats un video)
Pēdējais pirmais ieteikums izklausās pēc kaut kā tāda, kurā pat kapteinis nevarēja atrast vainu: "[organizējot nepārtrauktu piegādi ar Docker] Izmantojiet Docker [un saprast, ko tas dod]" Atcerieties, ka Ŕī nav "sudraba lode", kas atrisinās katru problēmu, bet gan instruments, kas nodroÅ”ina brÄ«niŔķīgu pamatu.

Reproducējamība

Ar ā€œreproducējamÄ«buā€ mēs saprotam vispārēju problēmu kopumu, kas raduŔās, darbinot lietojumprogrammas. Mēs runājam par Ŕādiem gadÄ«jumiem:

  • Skripti, kurus kvalitātes nodaļa ir pārbaudÄ«jusi iestudÄ“Å”anai, ir precÄ«zi jāatveido ražoÅ”anā.
  • Lietojumprogrammas tiek publicētas serveros, kas var saņemt pakotnes no dažādiem repozitoriju spoguļiem (laika gaitā tās tiek atjauninātas, un lÄ«dz ar tām arÄ« instalēto lietojumprogrammu versijas).
  • ā€œUz vietas man viss darbojas!ā€ (...un izstrādātājiem nav atļauts ražot.)
  • Vajag kaut ko pārbaudÄ«t vecajā (arhivētajā) versijā.
  • ...

To vispārējā bÅ«tÄ«ba ir saistÄ«ta ar to, ka ir nepiecieÅ”ama pilnÄ«ga izmantotās vides atbilstÄ«ba (kā arÄ« cilvēka faktora neesamÄ«ba). Kā mēs varam garantēt reproducējamÄ«bu? Izveidojiet Docker attēlus pamatojoties uz kodu no Git, un pēc tam izmantot tos jebkuram uzdevumam: testÄ“Å”anas vietās, ražoÅ”anā, programmētāju vietējās iekārtās... Tajā paŔā laikā ir svarÄ«gi samazināt darbÄ«bas, kas tiek veiktas. pēc attēla salikÅ”ana: jo vienkārŔāk tas ir, jo mazāka ir kļūdu iespējamÄ«ba.

Infrastruktūra ir kods

Ja infrastruktÅ«ras prasÄ«bas (servera programmatÅ«ras pieejamÄ«ba, tās versija utt.) nav formalizētas un ā€œieprogrammētasā€, jebkura lietojumprogrammas atjauninājuma ievieÅ”ana var izraisÄ«t postoÅ”as ā€‹ā€‹sekas. Piemēram, inscenējot jÅ«s jau esat pārgājis uz PHP 7.0 un attiecÄ«gi pārrakstÄ«jis kodu - tad tā parādÄ«Å”anās ražoÅ”anā ar kādu vecu PHP (5.5) noteikti kādu pārsteigs. JÅ«s nedrÄ«kstat aizmirst par bÅ«tiskām izmaiņām tulka versijā, taču "velns slēpjas detaļās": pārsteigums var bÅ«t nelielas atkarÄ«bas atjauninājums.

Pieeja Ŕīs problēmas risināŔanai ir pazÄ«stama kā IaC (infrastruktÅ«ra kā kods, "infrastruktÅ«ra kā kods") un ietver infrastruktÅ«ras prasÄ«bu uzglabāŔanu kopā ar lietojumprogrammas kodu. Izmantojot to, izstrādātāji un DevOps speciālisti var strādāt ar vienu un to paÅ”u Git lietojumprogrammu repozitoriju, bet dažādās tā daļās. No Ŕī koda Git tiek izveidots Docker attēls, kurā lietojumprogramma tiek izvietota, ņemot vērā visas infrastruktÅ«ras specifikas. VienkārÅ”i sakot, attēlu salikÅ”anas skriptiem (noteikumiem) jāatrodas vienā repozitorijā ar avota kodu un jāapvieno kopā.

Nepārtrauktas piegādes prakse ar Docker (pārskats un video)

Daudzslāņu lietojumprogrammu arhitektÅ«ras gadÄ«jumā, piemēram, ir nginx, kas atrodas lietojumprogrammas priekŔā, kas jau darbojas Docker konteinerā, katram slānim ir jāizveido Docker attēli no koda Git. Tad pirmajā attēlā bÅ«s lietojumprogramma ar tulku un citām ā€œtuvāmā€ atkarÄ«bām, bet otrajā attēlā bÅ«s augÅ”pus nginx.

Docker attēli, komunikācija ar Git

Visi no Git savāktie Docker attēli tiek sadalÄ«ti divās kategorijās: pagaidu un izlaiÅ”anas. Pagaidu attēli ir atzÄ«mēti ar filiāles nosaukumu Git, tos var pārrakstÄ«t ar nākamo apņemÅ”anos, un tie tiek izlaisti tikai priekÅ”skatÄ«Å”anai (nevis ražoÅ”anai). Å Ä« ir viņu galvenā atŔķirÄ«ba no izlaiduma versijām: jÅ«s nekad nezināt, kura konkrētā apņemÅ”anās tajās ir ietverta.

Ir jēga apkopot pagaidu attēlos: galveno atzaru (to var automātiski izlikt atseviŔķā vietnē, lai pastāvÄ«gi redzētu paÅ”reizējo galvenā versija), filiāles ar izlaidumiem, konkrētu jauninājumu filiāles.

Nepārtrauktas piegādes prakse ar Docker (pārskats un video)
Pēc tam, kad pagaidu attēlu priekÅ”skatÄ«jumā rodas nepiecieÅ”amÄ«ba pēc tulkoÅ”anas ražoÅ”anā, izstrādātāji ievieto noteiktu atzÄ«mi. Automātiski savākti pēc atzÄ«mes atbrÄ«vot attēlu (tā atzÄ«me atbilst tagam no Git) un tiek izlaista uz iestudējumu. Ja kvalitātes departaments to veiksmÄ«gi pārbauda, ā€‹ā€‹tas nonāk ražoÅ”anā.

dapp

Visu aprakstÄ«to (izplatÄ«Å”anu, attēla montāžu, turpmāko apkopi) var Ä«stenot neatkarÄ«gi, izmantojot Bash skriptus un citus ā€œimprovizētusā€ rÄ«kus. Bet, ja jÅ«s to darāt, kādā brÄ«dÄ« ievieÅ”ana radÄ«s lielu sarežģītÄ«bu un sliktu vadāmÄ«bu. To saprotot, mēs izveidojām savu specializēto darbplÅ«smas utilÄ«tu CI/CD izveidei - dapp.

Tā pirmkods ir rakstÄ«ts Ruby, atvērtā koda valodā un publicēts GitHub. Diemžēl dokumentācija Å”obrÄ«d ir rÄ«ka vājākā vieta, taču mēs pie tās strādājam. Un par dappi rakstÄ«sim un runāsim ne reizi vien, jo... Mēs patiesi nevaram vien sagaidÄ«t, kad varēsim dalÄ«ties ar tā iespējām ar visu ieinteresēto kopienu, taču tikmēr sÅ«tiet savus jautājumus un pieprasiet pieprasÄ«jumus un/vai sekojiet lÄ«dzi projekta attÄ«stÄ«bai GitHub.

Atjaunināts 13. gada 2019. augustā: Å”obrÄ«d ir projekts dapp pārdēvēta par werf, tā kods ir pilnÄ«bā pārrakstÄ«ts programmā Go, un tā dokumentācija ir ievērojami uzlabota.

Kubernetes

Vēl viens gatavs atvērtā pirmkoda rÄ«ks, kas jau guvis ievērojamu atzinÄ«bu profesionālajā vidē, ir Kubernetes,Dokera pārvaldÄ«bas klasteris. Tēma par tā izmantoÅ”anu projektos, kas balstÄ«ti uz Docker, ir ārpus ziņojuma jomas, tāpēc prezentācija aprobežojas ar dažu interesantu funkciju pārskatu.

IzlaiŔanai Kubernetes piedāvā:

  • Readiness Probe ā€” jaunas lietojumprogrammas versijas gatavÄ«bas pārbaude (lai pārslēgtu uz to trafiku);
  • ritoÅ”ais atjauninājums - secÄ«ga attēla atjaunināŔana konteineru klasterÄ« (izslēgÅ”ana, atjaunināŔana, sagatavoÅ”ana palaiÅ”anai, satiksmes pārslēgÅ”ana);
  • sinhronā atjaunināŔana - attēla atjaunināŔana klasterÄ« ar atŔķirÄ«gu pieeju: vispirms uz pusi konteineru, tad uz pārējiem;
  • canary releases - jauna attēla palaiÅ”ana ierobežotā (nelielā) konteineru skaitā, lai uzraudzÄ«tu anomālijas.

Tā kā Continuous Delivery nav tikai jaunas versijas izlaiÅ”ana, Kubernetes ir vairākas iespējas turpmākai infrastruktÅ«ras uzturÄ“Å”anai: iebÅ«vēta visu konteineru uzraudzÄ«ba un reÄ£istrÄ“Å”ana, automātiska mērogoÅ”ana utt. Tas viss jau darbojas un tikai gaida pareizu darbÄ«bu. ievieÅ”anu savos procesos.

Galīgie ieteikumi

  1. Izmantojiet Docker.
  2. Izveidojiet Docker lietojumprogrammu attēlus visām jūsu vajadzībām.
  3. Ievērojiet principu ā€œInfrastruktÅ«ra ir kodsā€.
  4. Saistiet Git ar Docker.
  5. Regulējiet izlaiÅ”anas secÄ«bu.
  6. Izmantojiet gatavu platformu (Kubernetes vai citu).

Videoklipi un slaidi

Video no izrādes (apmēram stunda) publicēts vietnē YouTube (pats ziņojums sākas no 5. minÅ«tes - sekojiet saitei, lai spēlētu no Ŕī brīža).

Ziņojuma prezentācija:

PS

Citi ziņojumi par Å”o tēmu mÅ«su emuārā:

Avots: www.habr.com

Pievieno komentāru