ProHoster > Blogs > Administrācija > Mūsu nepārtrauktās izvietoŔanas ievieŔana klienta platformā

Mūsu nepārtrauktās izvietoŔanas ievieŔana klienta platformā

Mēs, True Engineering, esam izveidojuÅ”i procesu nepārtrauktai atjauninājumu piegādei klientu serveriem, un vēlamies dalÄ«ties ar Å”o pieredzi.

Sākumā mēs izstrādājām tieÅ”saistes sistēmu klientam un izvietojām to savā Kubernetes klasterÄ«. Tagad mÅ«su augstas slodzes risinājums ir pārvietots uz klienta platformu, kurai esam iestatÄ«juÅ”i pilnÄ«bā automātisku nepārtrauktas ievieÅ”anas procesu. Pateicoties tam, mēs paātrinājām laiku lÄ«dz tirgum - izmaiņu piegādi produktu vidē.

Å ajā rakstā mēs runāsim par visiem nepārtrauktas izvietoÅ”anas (CD) procesa posmiem vai atjauninājumu piegādi klienta platformai:

  1. Kā Ŕis process sākas?
  2. sinhronizācija ar klienta Git repozitoriju,
  3. aizmugursistēmas un priekÅ”gala montāža,
  4. automātiska lietojumprogrammu izvietoÅ”ana testa vidē,
  5. automātiska izvietoŔana uz Prod.

Mēs dalÄ«simies ar iestatÄ«Å”anas informāciju.

Mūsu nepārtrauktās izvietoŔanas ievieŔana klienta platformā

1. Sāciet CD

Nepārtraukta izvietoÅ”ana sākas ar to, ka izstrādātājs veic izmaiņas mÅ«su Git repozitorija izlaiduma filiālē.

Mūsu lietojumprogramma darbojas mikropakalpojumu arhitektūrā, un visas tās sastāvdaļas tiek glabātas vienā repozitorijā. Pateicoties tam, tiek apkopoti un instalēti visi mikropakalpojumi, pat ja kāds no tiem ir mainījies.

Mēs organizējām darbu caur vienu repozitoriju vairāku iemeslu dēļ:

  • Izstrādes vienkārŔība - lietojumprogramma aktÄ«vi attÄ«stās, lai jÅ«s varētu strādāt ar visu kodu vienlaikus.
  • Viens CI/CD cauruļvads, kas garantē, ka lietojumprogramma kā viena sistēma iztur visus testus un tiek piegādāta klienta ražoÅ”anas vidē.
  • Mēs novērÅ”am neskaidrÄ«bas versijās - mums nav jāuzglabā mikropakalpojumu versiju karte un jāapraksta tās konfigurācija katram mikropakalpojumam Helm skriptos.

2. Sinhronizācija ar klienta avota koda Git repozitoriju

Veiktās izmaiņas tiek automātiski sinhronizētas ar klienta Git repozitoriju. Tur tiek konfigurēts lietojumprogrammas komplekts, kas tiek palaists pēc filiāles atjaunināŔanas un izvietoÅ”anas uz turpinājumu. Abi procesi rodas savā vidē no Git repozitorija.

Mēs nevaram strādāt tieÅ”i ar klienta repozitoriju, jo mums ir nepiecieÅ”ama mÅ«su paÅ”u vide izstrādei un testÄ“Å”anai. Å iem nolÅ«kiem mēs izmantojam savu Git repozitoriju ā€” tas ir sinhronizēts ar viņu Git repozitoriju. TiklÄ«dz izstrādātājs ievieto izmaiņas attiecÄ«gajā mÅ«su repozitorija filiālē, GitLab nekavējoties nosÅ«ta Ŕīs izmaiņas klientam.

Mūsu nepārtrauktās izvietoŔanas ievieŔana klienta platformā

Pēc tam jums jāveic montāža. Tas sastāv no vairākiem posmiem: backend un frontend montāža, testÄ“Å”ana un piegāde uz ražoÅ”anu.

3. Aizmugursistēmas un priekÅ”gala salikÅ”ana

Aizmugursistēmas un priekÅ”gala izveide ir divi paralēli uzdevumi, kas tiek veikti GitLab Runner sistēmā. Tās sākotnējā montāžas konfigurācija atrodas tajā paŔā repozitorijā.

Pamācība YAML skripta rakstīŔanai izveidei GitLab.

GitLab Runner paņem kodu no vajadzÄ«gā repozitorija, saliek to ar Java lietojumprogrammas veidoÅ”anas komandu un nosÅ«ta to Docker reÄ£istram. Å eit mēs saliekam aizmuguri un priekÅ”galu, iegÅ«stam Docker attēlus, kurus ievietojam repozitorijā klienta pusē. Lai pārvaldÄ«tu Docker attēlus, mēs izmantojam Gradle spraudnis.

Mēs sinhronizējam mÅ«su attēlu versijas ar izlaiduma versiju, kas tiks publicēta pakalpojumā Docker. Lai nodroÅ”inātu vienmērÄ«gu darbÄ«bu, esam veikuÅ”i vairākus pielāgojumus:

1. Konteineri netiek pārbÅ«vēti starp testa vidi un ražoÅ”anas vidi. Mēs veicām parametrizāciju, lai viens un tas pats konteiners varētu strādāt ar visiem iestatÄ«jumiem, vides mainÄ«gajiem un pakalpojumiem gan testa vidē, gan ražoÅ”anā bez pārbÅ«ves.

2. Lai atjauninātu lietojumprogrammu, izmantojot Helm, jānorāda tās versija. Mēs veidojam backend, frontend un atjauninām lietojumprogrammu ā€“ tie ir trÄ«s dažādi uzdevumi, tāpēc ir svarÄ«gi visur izmantot vienu un to paÅ”u aplikācijas versiju. Å im uzdevumam mēs izmantojam datus no Git vēstures, jo mÅ«su K8S klastera konfigurācija un lietojumprogrammas atrodas tajā paŔā Git repozitorijā.

Mēs iegūstam lietojumprogrammas versiju no komandas izpildes rezultātiem
git describe --tags --abbrev=7.

4. Automātiska visu izmaiņu izvietoÅ”ana testa vidē (UAT)

Nākamais solis Å”ajā bÅ«vÄ“Å”anas skriptā ir automātiski atjaunināt K8S klasteru. Tas notiek ar nosacÄ«jumu, ka visa lietojumprogramma ir izveidota un visi artefakti ir publicēti Docker reÄ£istrā. Pēc tam sākas testa vides atjaunināŔana.

Tiek sākta klastera atjaunināŔana StÅ«res atjauninājums. Ja rezultātā kaut kas nenotiek saskaņā ar plānu, Helm automātiski un neatkarÄ«gi atsauks visas izmaiņas. Viņa darbs nav jākontrolē.

Mēs piegādājam K8S klastera konfigurāciju kopā ar montāžu. Tāpēc nākamais solis ir tā atjaunināŔana: konfigurācijas kartes, izvietoÅ”ana, pakalpojumi, noslēpumi un visas citas K8S konfigurācijas, kuras esam mainÄ«juÅ”i.

Pēc tam Helm testa vidē palaiž paÅ”as lietojumprogrammas RollOut atjauninājumu. Pirms lietojumprogrammas izvietoÅ”anas ražoÅ”anā. Tas tiek darÄ«ts, lai lietotāji varētu manuāli pārbaudÄ«t biznesa funkcijas, kuras mēs ievietojam testa vidē.

5. Automātiska visu Prod izmaiņu izvietoÅ”ana

Lai izvietotu atjauninājumu ražoÅ”anas vidē, jums vienkārÅ”i jānoklikŔķina uz vienas pogas GitLab ā€” un konteineri nekavējoties tiek piegādāti ražoÅ”anas vidē.

Viena un tā pati lietojumprogramma var darboties dažādās vidēs ā€” testÄ“Å”anas un ražoÅ”anas vidē ā€” bez pārbÅ«ves. Mēs izmantojam tos paÅ”us artefaktus, neko nemainot lietojumprogrammā, un parametrus iestatām ārēji.

ElastÄ«ga lietojumprogrammas iestatÄ«jumu parametru noteikÅ”ana ir atkarÄ«ga no vides, kurā programma tiks izpildÄ«ta. Mēs esam pārvietojuÅ”i visus vides iestatÄ«jumus ārēji: viss tiek parametrizēts, izmantojot K8S konfigurāciju un Helm parametrus. Kad Helm testÄ“Å”anas vidē izvieto komplektu, tai tiek lietoti testa iestatÄ«jumi un produkta iestatÄ«jumi tiek lietoti ražoÅ”anas videi.

Sarežģītākais bija parametrizēt visus izmantotos pakalpojumus un mainīgos, kas ir atkarīgi no vides, un pārvērst tos vides mainīgajos un vides parametru aprakstos-konfigurācijās Helm.

Lietojumprogrammu iestatÄ«jumos tiek izmantoti vides mainÄ«gie. To vērtÄ«bas tiek iestatÄ«tas konteineros, izmantojot K8S konfigurācijas karti, kas tiek veidota, izmantojot Go veidnes. Piemēram, vides mainÄ«gā iestatÄ«Å”anu domēna nosaukumam var izdarÄ«t Ŕādi:

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.Values.global.env ā€“ Å”is mainÄ«gais saglabā vides nosaukumu (prod, stage, UAT).
.Values.app.properties.app_external_domain ā€“ Å”ajā mainÄ«gajā mēs iestatām vēlamo domēnu .Values.yaml failā

Atjauninot lietojumprogrammu, Helm no veidnēm izveido failu configmap.yaml un aizpilda APP_EXTERNAL_DOMAIN vērtÄ«bu ar vēlamo vērtÄ«bu atkarÄ«bā no vides, kurā sākas lietojumprogrammas atjaunināŔana. Å is mainÄ«gais jau ir iestatÄ«ts konteinerā. Tam var piekļūt no lietojumprogrammas, tāpēc katrai lietojumprogrammas videi Å”im mainÄ«gajam bÅ«s atŔķirÄ«ga vērtÄ«ba.

SalÄ«dzinoÅ”i nesen Spring Cloud parādÄ«jās K8S atbalsts, tostarp darbs ar configMaps: Pavasara mākonis Kubernetes. Kamēr projekts aktÄ«vi attÄ«stās un radikāli mainās, mēs to nevaram izmantot ražoÅ”anā. Bet mēs aktÄ«vi uzraugām tā stāvokli un izmantojam to DEV konfigurācijās. TiklÄ«dz tas stabilizējas, mēs pārslēgsimies no vides mainÄ«go izmantoÅ”anas uz to.

Kopā

Tātad nepārtrauktā izvietoÅ”ana ir konfigurēta un darbojas. Visi atjauninājumi notiek ar vienu taustiņu. Izmaiņu piegāde produkta vidē notiek automātiski. Un, kas ir svarÄ«gi, atjauninājumi neaptur sistēmu.

Mūsu nepārtrauktās izvietoŔanas ievieŔana klienta platformā

Nākotnes plāni: automātiska datu bāzes migrācija

Mēs domājām par datu bāzes jaunināŔanu un iespēju Ŕīs izmaiņas atsaukt. Galu galā vienlaikus darbojas divas dažādas lietojumprogrammas versijas: darbojas vecā, un jaunā ir izveidota. Un mēs izslēgsim veco tikai tad, kad bÅ«sim pārliecināti, ka jaunā versija darbojas. Datu bāzes migrācijai jāļauj strādāt ar abām lietojumprogrammas versijām.

Tāpēc mēs nevaram vienkārÅ”i mainÄ«t kolonnas nosaukumu vai citus datus. Bet mēs varam izveidot jaunu kolonnu, iekopēt tajā datus no vecās kolonnas un ierakstÄ«t trigerus, kas, atjauninot datus, vienlaikus tos kopēs un atjauninās citā kolonnā. Un pēc veiksmÄ«gas jaunās lietojumprogrammas versijas izvietoÅ”anas, pēc palaiÅ”anas atbalsta perioda, mēs varēsim izdzēst veco kolonnu un aktivizētāju, kas ir kļuvis nevajadzÄ«gs.

Ja jaunā lietojumprogrammas versija nedarbojas pareizi, mēs varam atgriezties pie iepriekŔējās versijas, ieskaitot iepriekŔējo datu bāzes versiju. ÄŖsāk sakot, mÅ«su veiktās izmaiņas ļaus jums strādāt vienlaikus ar vairākām lietojumprogrammas versijām.

Plānojam automatizēt datu bāzes migrāciju caur K8S darbu, integrējot to CD procesā. Un mēs noteikti dalÄ«simies Å”ajā pieredzē HabrĆ©.

Avots: www.habr.com

Pievieno komentāru