Ni ĉe True Engineering starigis procezon por kontinua livero de ĝisdatigoj al klientserviloj kaj volas dividi ĉi tiun sperton.
Komence, ni evoluigis interretan sistemon por la kliento kaj deplojis ĝin en nia propra Kubernetes-grupo. Nun nia alta ŝarĝa solvo moviĝis al la platformo de la kliento, por kiu ni starigis plene aŭtomatan Daŭran Deplojon. Dank' al ĉi tio, ni akcelis la merkatan tempon - la liveron de ŝanĝoj al la produkta medio.
En ĉi tiu artikolo ni parolos pri ĉiuj etapoj de la Kontinua Deplojo (KD) procezo aŭ livero de ĝisdatigoj al la platformo de la kliento:
- Kiel komenciĝas ĉi tiu procezo?
- sinkronigado kun la Git-deponejo de la kliento,
- aro de backend kaj fasado,
- aŭtomata aplikaĵa deplojo en testa medio,
- aŭtomata deplojo al Prod.
Ni dividos la aranĝajn detalojn survoje.
1. Komencu KD
Daŭra Deplojo komenciĝas kiam la programisto puŝas ŝanĝojn al la eldona branĉo de nia Git-deponejo.
Nia aplikaĵo funkcias per mikroserva arkitekturo kaj ĉiuj ĝiaj komponantoj estas stokitaj en unu deponejo. Danke al ĉi tio, ĉiuj mikroservoj estas kolektitaj kaj instalitaj, eĉ se unu el ili ŝanĝiĝis.
Ni organizis laboron per unu deponejo pro pluraj kialoj:
- Facileco de disvolviĝo - la aplikaĵo aktive disvolviĝas, do vi povas labori kun la tuta kodo samtempe.
- Ununura CI/KD-dukto, kiu garantias, ke la aplikaĵo kiel ununura sistemo trapasas ĉiujn provojn kaj estas liverita al la produktadmedio de la kliento.
- Ni forigas konfuzon en versioj - ni ne devas stoki mapon de mikroservo-versioj kaj priskribi ĝian agordon por ĉiu mikroservo en Helm-skriptoj.
2. Sinkronigo kun la Git-deponejo de la fontkodo de la kliento
Ŝanĝoj faritaj estas aŭtomate sinkronigitaj kun la Git-deponejo de la kliento. Tie la aplikaĵo asembleo estas agordita, kiu estas lanĉita post ĝisdatigo de la branĉo, kaj deplojo al la daŭrigo. Ambaŭ procezoj originas en sia medio de Git-deponejo.
Ni ne povas labori kun la deponejo de la kliento rekte ĉar ni bezonas niajn proprajn mediojn por disvolviĝo kaj testado. Ni uzas nian Git-deponejon por ĉi tiuj celoj - ĝi estas sinkronigita kun ilia Git-deponejo. Tuj kiam programisto afiŝas ŝanĝojn al la taŭga branĉo de nia deponejo, GitLab tuj puŝas ĉi tiujn ŝanĝojn al la kliento.
Post ĉi tio vi devas fari la asembleon. Ĝi konsistas el pluraj etapoj: muntado de backend kaj fasado, testado kaj livero al produktado.
3. Kunmeti la backend kaj fasado
Konstrui la backend kaj fasado estas du paralelaj taskoj kiuj estas faritaj en la GitLab Runner sistemo. Ĝia origina kunigkonfiguracio situas en la sama deponejo.
.
GitLab Runner prenas la kodon el la bezonata deponejo, kunvenas ĝin per la komando de konstrua aplikaĵo de Java kaj sendas ĝin al la registro Docker. Ĉi tie ni kunvenas la backend kaj fasado, akiras Docker-bildojn, kiujn ni metas en deponejon flanke de la kliento. Por administri Docker-bildojn ni uzas .
Ni sinkronigas la versiojn de niaj bildoj kun la eldonversio, kiu estos publikigita en Docker. Por glata funkciado ni faris plurajn ĝustigojn:
1. Ujoj ne estas rekonstruitaj inter la testa medio kaj la produktadmedio. Ni faris parametrigojn por ke la sama ujo povu funkcii kun ĉiuj agordoj, mediovariabloj kaj servoj kaj en la testa medio kaj en produktado sen rekonstruado.
2. Por ĝisdatigi aplikaĵon per Helm, vi devas specifi ĝian version. Ni konstruas la backend, fasado kaj ĝisdatigas la aplikaĵon - ĉi tiuj estas tri malsamaj taskoj, do gravas uzi la saman version de la aplikaĵo ĉie. Por ĉi tiu tasko, ni uzas datumojn de Git-historio, ĉar nia K8S-grupo-agordo kaj aplikaĵoj estas en la sama Git-deponejo.
Ni ricevas la aplikaĵversion de la komandaj ekzekutrezultoj
git describe --tags --abbrev=7.
4. Aŭtomata deplojo de ĉiuj ŝanĝoj al la testa medio (UAT)
La sekva paŝo en ĉi tiu konstrua skripto estas aŭtomate ĝisdatigi la K8S-areton. Ĉi tio okazas kondiĉe ke la tuta aplikaĵo estas konstruita kaj ĉiuj artefaktoj estis publikigitaj al la Docker-Registro. Post tio komenciĝas la ĝisdatigo de la testa medio.
La cluster-ĝisdatigo estas komencita uzi . Se, kiel rezulto, io ne iris laŭplane, Helm aŭtomate kaj sendepende retroigos ĉiujn ĝiajn ŝanĝojn. Lia laboro ne bezonas esti kontrolita.
Ni provizas la agordon de la cluster K8S kune kun la asembleo. Sekve, la sekva paŝo estas ĝisdatigi ĝin: konfigMaps, deplojoj, servoj, sekretoj kaj iuj aliaj K8S-agordoj, kiujn ni ŝanĝis.
Helm tiam ruligas RollOut-ĝisdatigon de la aplikaĵo mem en la testa medio. Antaŭ ol la aplikaĵo estas deplojita al produktado. Ĉi tio estas farita por ke uzantoj povu mane testi la komercajn funkciojn, kiujn ni metas en la testan medion.
5. Aŭtomata deplojo de ĉiuj ŝanĝoj al Prod
Por deploji ĝisdatigon al la produktadmedio, vi nur bezonas alklaki unu butonon en GitLab - kaj la ujoj tuj estas liveritaj al la produktadmedio.
La sama aplikaĵo povas funkcii en malsamaj medioj—testo kaj produktado—sen rekonstruado. Ni uzas la samajn artefaktojn sen ŝanĝi ion ajn en la aplikaĵo, kaj ni fiksas la parametrojn ekstere.
Fleksebla parametrigo de aplikaĵagordoj dependas de la medio en kiu la aplikaĵo estos efektivigita. Ni movis ĉiujn medio-agordojn eksteren: ĉio estas parametrigita per la agordo K8S kaj Helm-parametroj. Kiam Helm deplojas aron al la testa medio, la testaj agordoj estas aplikataj al ĝi, kaj la produktaj agordoj estas aplikataj al la produktadmedio.
La plej malfacila afero estis parametrigi ĉiujn uzatajn servojn kaj variablojn, kiuj dependas de la medio, kaj traduki ilin en mediovariablojn kaj priskribo-agordojn de medio-parametroj por Helm.
Aplikaj agordoj uzas mediovariablojn. Iliaj valoroj estas fiksitaj en ujoj per K8S-konfigmapo, kiu estas ŝablono per Go-ŝablonoj. Ekzemple, agordi mediovariablon al la domajna nomo povas esti farita jene:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Valoroj.tutmonda.env – ĉi tiu variablo konservas la nomon de la medio (prod, scenejo, UAT).
.Values.app.properties.app_ekstera_domajno – en ĉi tiu variablo ni starigas la deziratan domajnon en la dosiero .Values.yaml
Kiam ĝi ĝisdatigas aplikaĵon, Helm kreas configmap.yaml-dosieron el ŝablonoj kaj plenigas la valoron APP_EXTERNAL_DOMAIN per la dezirata valoro depende de la medio en kiu komenciĝas la ĝisdatigo de la aplikaĵo. Ĉi tiu variablo jam estas agordita en la ujo. Ĝi estas alirebla de la aplikaĵo, do ĉiu aplikaĵa medio havos malsaman valoron por ĉi tiu variablo.
Relative lastatempe, K8S-subteno aperis en Spring Cloud, inkluzive de laboro kun configMaps: . Dum la projekto aktive disvolviĝas kaj ŝanĝas radikale, ni ne povas uzi ĝin en produktado. Sed ni aktive kontrolas ĝian kondiĉon kaj uzas ĝin en DEV-agordoj. Tuj kiam ĝi stabiligos, ni ŝanĝos de uzado de mediovariabloj al ĝi.
Tuta
Do, Daŭra Deplojo estas agordita kaj funkcianta. Ĉiuj ĝisdatigoj okazas per unu klavopremo. Livero de ŝanĝoj al la produkta medio estas aŭtomata. Kaj, grave, ĝisdatigoj ne haltigas la sistemon.
Estontaj planoj: aŭtomata datumbaza migrado
Ni pensis pri altgradigo de la datumbazo kaj la eblon retrorigi ĉi tiujn ŝanĝojn. Post ĉio, du malsamaj versioj de la aplikaĵo funkcias samtempe: la malnova funkcias, kaj la nova funkcias. Kaj ni malŝaltos la malnovan nur kiam ni estos certaj, ke la nova versio funkcias. La datumbaza migrado devus permesi vin labori kun ambaŭ versioj de la aplikaĵo.
Tial ni ne povas simple ŝanĝi la kolumnan nomon aŭ aliajn datumojn. Sed ni povas krei novan kolumnon, kopii datumojn de la malnova kolumno en ĝin kaj skribi ellasilon kiuj, ĝisdatigante la datumojn, samtempe kopios kaj ĝisdatigos ĝin en alia kolumno. Kaj post la sukcesa deplojo de la nova versio de la aplikaĵo, post la post-lanĉa subtena periodo, ni povos forigi la malnovan kolumnon kaj la ellasilon, kiu fariĝis nenecesa.
Se la nova versio de la aplikaĵo ne funkcias ĝuste, ni povas reveni al la antaŭa versio, inkluzive de la antaŭa versio de la datumbazo. Resume, niaj ŝanĝoj permesos al vi labori samtempe kun pluraj versioj de la aplikaĵo.
Ni planas aŭtomatigi datumbazan migradon per K8S-laboro, integrante ĝin en la KD-procezon. Kaj ni certe dividos ĉi tiun sperton ĉe Habré.
fonto: www.habr.com