Ons by True Engineering het 'n proses opgestel vir deurlopende aflewering van opdaterings aan klantebedieners en wil hierdie ervaring deel.
Om mee te begin, het ons 'n aanlyn stelsel vir die kliënt ontwikkel en dit in ons eie Kubernetes-kluster ontplooi. Nou het ons hoëladingsoplossing na die kliënt se platform verskuif, waarvoor ons 'n ten volle outomatiese Deurlopende Ontplooiingsproses opgestel het. Danksy dit het ons die tyd-tot-mark versnel – die lewering van veranderinge aan die produkomgewing.
In hierdie artikel sal ons praat oor al die stadiums van die Deurlopende Ontplooiing (CD) proses of aflewering van opdaterings aan die kliënt se platform:
- Hoe begin hierdie proses?
- sinchronisasie met die kliënt se Git-bewaarplek,
- samestelling van backend en frontend,
- outomatiese toepassing ontplooiing in 'n toets omgewing,
- outomatiese ontplooiing na Prod.
Ons sal die opstellingbesonderhede langs die pad deel.
1. Begin CD
Deurlopende ontplooiing begin met die ontwikkelaar wat veranderinge aan die vrystellingtak van ons Git-bewaarplek stoot.
Ons toepassing loop op 'n mikrodiensargitektuur en al sy komponente word in een bewaarplek gestoor. Danksy dit word alle mikrodienste versamel en geïnstalleer, selfs al het een van hulle verander.
Ons het om verskeie redes werk deur een bewaarplek georganiseer:
- Gemak van ontwikkeling - die toepassing ontwikkel aktief, sodat u met al die kode gelyktydig kan werk.
- 'n Enkele CI/CD-pyplyn wat waarborg dat die toepassing as 'n enkele stelsel alle toetse slaag en aan die kliënt se produksie-omgewing gelewer word.
- Ons skakel verwarring in weergawes uit - ons hoef nie 'n kaart van mikrodiensweergawes te stoor en die konfigurasie daarvan vir elke mikrodiens in Helm-skrifte te beskryf nie.
2. Sinchronisasie met die Git-bewaarplek van die kliënt se bronkode
Veranderinge wat gemaak word, word outomaties gesinchroniseer met die kliënt se Git-bewaarplek. Daar word die toepassingsamestelling gekonfigureer, wat na die opdatering van die tak geloods word en na die voortsetting ontplooi word. Beide prosesse ontstaan in hul omgewing vanaf 'n Git-bewaarplek.
Ons kan nie direk met die kliënt se bewaarplek werk nie, want ons benodig ons eie omgewings vir ontwikkeling en toetsing. Ons gebruik ons Git-bewaarplek vir hierdie doeleindes - dit is gesinchroniseer met hul Git-bewaarplek. Sodra 'n ontwikkelaar veranderinge aan die toepaslike tak van ons bewaarplek plaas, stoot GitLab hierdie veranderinge onmiddellik na die kliënt.
Hierna moet jy die samestelling doen. Dit bestaan uit verskeie stadiums: backend- en frontend-samestelling, toetsing en aflewering na produksie.
3. Die samestelling van die agterkant en voorkant
Die bou van die agterkant en voorkant is twee parallelle take wat in die GitLab Runner-stelsel uitgevoer word. Die oorspronklike samestellingkonfigurasie daarvan is in dieselfde bewaarplek geleë.
.
GitLab Runner neem die kode uit die vereiste bewaarplek, stel dit saam met die Java-toepassingsbou-opdrag en stuur dit na die Docker-register. Hier stel ons die agterkant en voorkant bymekaar, kry Docker-beelde, wat ons in 'n bewaarplek aan die klant se kant plaas. Om Docker-beelde te bestuur wat ons gebruik .
Ons sinchroniseer die weergawes van ons beelde met die vrystellingweergawe wat in Docker gepubliseer sal word. Vir gladde werking het ons verskeie aanpassings gemaak:
1. Houers word nie tussen die toetsomgewing en die produksie-omgewing herbou nie. Ons het parametrisasies gemaak sodat dieselfde houer met alle instellings, omgewingsveranderlikes en dienste beide in die toetsomgewing en in produksie kon werk sonder om te herbou.
2. Om 'n toepassing via Helm op te dateer, moet jy die weergawe daarvan spesifiseer. Ons bou die agterkant, frontend en werk die toepassing op - dit is drie verskillende take, daarom is dit belangrik om oral dieselfde weergawe van die toepassing te gebruik. Vir hierdie taak gebruik ons data uit Git-geskiedenis, aangesien ons K8S-klusterkonfigurasie en toepassings in dieselfde Git-bewaarplek is.
Ons kry die toepassing weergawe van die opdrag uitvoering resultate
git describe --tags --abbrev=7.
4. Outomatiese ontplooiing van alle veranderinge aan die toetsomgewing (UAT)
Die volgende stap in hierdie bouskrif is om die K8S-kluster outomaties op te dateer. Dit gebeur mits die hele toepassing gebou is en alle artefakte na die Docker-register gepubliseer is. Hierna begin die toetsomgewingopdatering.
Die groepopdatering word begin gebruik . As iets gevolglik nie volgens plan verloop het nie, sal Helm outomaties en onafhanklik al sy veranderinge terugrol. Sy werk hoef nie beheer te word nie.
Ons verskaf die K8S-klusterkonfigurasie saam met die samestelling. Daarom is die volgende stap om dit op te dateer: configMaps, ontplooiings, dienste, geheime en enige ander K8S-konfigurasies wat ons verander het.
Helm voer dan 'n RollOut-opdatering van die toepassing self in die toetsomgewing uit. Voordat die toepassing na produksie ontplooi word. Dit word gedoen sodat gebruikers die besigheidskenmerke wat ons in die toetsomgewing plaas, handmatig kan toets.
5. Outomatiese ontplooiing van alle veranderinge aan Prod
Om 'n opdatering na die produksie-omgewing te ontplooi, hoef jy net een knoppie in GitLab te klik - en die houers word onmiddellik by die produksie-omgewing afgelewer.
Dieselfde toepassing kan in verskillende omgewings werk - toets en produksie - sonder om te herbou. Ons gebruik dieselfde artefakte sonder om iets in die toepassing te verander, en ons stel die parameters ekstern in.
Buigsame parameterisering van toepassingsinstellings hang af van die omgewing waarin die toepassing uitgevoer sal word. Ons het al die omgewingsinstellings ekstern geskuif: alles word geparameteriseer deur die K8S-konfigurasie en Helm-parameters. Wanneer Helm 'n samestelling na die toetsomgewing ontplooi, word die toetsinstellings daarop toegepas, en die produkinstellings word op die produksieomgewing toegepas.
Die moeilikste ding was om al die gebruikte dienste en veranderlikes wat afhanklik is van die omgewing te parameteriseer, en dit te vertaal in omgewingsveranderlikes en beskrywing-konfigurasies van omgewingsparameters vir Helm.
Toepassingsinstellings gebruik omgewingsveranderlikes. Hul waardes word in houers gestel met behulp van K8S configmap, wat met Go-sjablone gevorm is. Byvoorbeeld, die opstel van 'n omgewingsveranderlike vir die domeinnaam kan soos volg gedoen word:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Waardes.global.env – hierdie veranderlike stoor die naam van die omgewing (prod, stage, UAT).
.Values.app.properties.app_external_domain – in hierdie veranderlike stel ons die gewenste domein in die .Values.yaml lêer
Wanneer 'n toepassing opgedateer word, skep Helm 'n configmap.yaml-lêer vanaf sjablone en vul die APP_EXTERNAL_DOMAIN-waarde met die verlangde waarde, afhangende van die omgewing waarin die toepassing-opdatering begin. Hierdie veranderlike is reeds in die houer gestel. Dit kan vanaf die toepassing verkry word, so elke toepassingsomgewing sal 'n ander waarde vir hierdie veranderlike hê.
Betreklik onlangs het K8S-ondersteuning in Spring Cloud verskyn, insluitend werk met configMaps: . Terwyl die projek aktief ontwikkel en radikaal verander, kan ons dit nie in produksie gebruik nie. Maar ons monitor die toestand daarvan aktief en gebruik dit in DEV-konfigurasies. Sodra dit stabiliseer, sal ons oorskakel van die gebruik van omgewingsveranderlikes daarna.
In totaal
So, Deurlopende Ontplooiing is gekonfigureer en werk. Alle opdaterings vind plaas met een toetsaanslag. Die aflewering van veranderinge aan die produkomgewing is outomaties. En, belangriker, opdaterings stop nie die stelsel nie.
Toekomsplanne: outomatiese databasismigrasie
Ons het daaraan gedink om die databasis op te gradeer en die moontlikheid om hierdie veranderinge terug te rol. Twee verskillende weergawes van die toepassing loop immers op dieselfde tyd: die ou een loop, en die nuwe een is op. En ons sal die ou een net afskakel wanneer ons seker is dat die nuwe weergawe werk. Die databasismigrasie behoort jou in staat te stel om met beide weergawes van die toepassing te werk.
Daarom kan ons nie bloot die kolomnaam of ander data verander nie. Maar ons kan 'n nuwe kolom skep, data uit die ou kolom daarin kopieer en snellers skryf wat, wanneer die data opgedateer word, dit gelyktydig in 'n ander kolom sal kopieer en bywerk. En na die suksesvolle ontplooiing van die nuwe weergawe van die toepassing, na die ondersteuningsperiode na die bekendstelling, sal ons die ou kolom en die sneller wat onnodig geword het, kan uitvee.
As die nuwe weergawe van die toepassing nie reg werk nie, kan ons terugrol na die vorige weergawe, insluitend die vorige weergawe van die databasis. Kortom, ons veranderinge sal jou toelaat om gelyktydig met verskeie weergawes van die toepassing te werk.
Ons beplan om databasismigrasie via K8S-werk te outomatiseer en dit in die CD-proses te integreer. En ons sal beslis hierdie ervaring op Habré deel.
Bron: will.com