Við hjá True Engineering höfum sett upp ferli fyrir stöðuga afhendingu á uppfærslum á netþjóna viðskiptavina og viljum deila þessari reynslu.
Til að byrja með þróuðum við netkerfi fyrir viðskiptavininn og settum það upp í okkar eigin Kubernetes klasa. Nú hefur háálagslausnin okkar færst yfir á vettvang viðskiptavinarins, fyrir það höfum við sett upp fullsjálfvirkt stöðugt dreifingarferli. Þökk sé þessu flýttum við tíma til markaðar - afhendingu breytinga á vöruumhverfi.
Í þessari grein munum við tala um öll stig stöðugrar dreifingar (CD) ferlisins eða afhendingu uppfærslur á vettvang viðskiptavinarins:
- Hvernig byrjar þetta ferli?
- samstillingu við Git geymslu viðskiptavinarins,
- samsetning bakenda og framenda,
- sjálfvirk dreifing forrita í prófunarumhverfi,
- sjálfvirk dreifing á Prod.
Við munum deila uppsetningarupplýsingunum í leiðinni.
1. Ræstu geisladisk
Stöðug uppsetning hefst með því að verktaki ýtir undir breytingar á útgáfugrein Git geymslunnar okkar.
Forritið okkar keyrir á örþjónustuarkitektúr og allir íhlutir þess eru geymdir í einni geymslu. Þökk sé þessu er öllum örþjónustum safnað og sett upp, jafnvel þótt ein þeirra hafi breyst.
Við skipulögðum vinnu í gegnum eina geymslu af nokkrum ástæðum:
- Auðveld þróun - forritið er í virkri þróun, svo þú getur unnið með allan kóðann í einu.
- Ein CI/CD leiðsla sem tryggir að forritið sem eitt kerfi standist allar prófanir og sé afhent framleiðsluumhverfi viðskiptavinarins.
- Við útrýmum ruglingi í útgáfum - við þurfum ekki að geyma kort af smáþjónustuútgáfum og lýsa uppsetningu þess fyrir hverja örþjónustu í Helm skriftum.
2. Samstilling við Git geymslu frumkóða viðskiptavinarins
Breytingar sem gerðar eru eru sjálfkrafa samstilltar við Git geymslu viðskiptavinarins. Þar er forritasamsetningin stillt, sem er hleypt af stokkunum eftir uppfærslu útibúsins og dreifing í framhaldið. Bæði ferlarnir eiga uppruna sinn í umhverfi sínu frá Git geymslu.
Við getum ekki unnið beint með geymslu viðskiptavinarins vegna þess að við þurfum okkar eigið umhverfi fyrir þróun og prófun. Við notum Git geymsluna okkar í þessum tilgangi - hún er samstillt við Git geymsluna þeirra. Um leið og þróunaraðili birtir breytingar á viðeigandi útibúi geymslunnar okkar, ýtir GitLab þessum breytingum strax til viðskiptavinarins.
Eftir þetta þarftu að gera samsetninguna. Það samanstendur af nokkrum stigum: bakenda og framenda samsetningu, prófun og afhendingu til framleiðslu.
3. Samsetning bakenda og framenda
Að byggja upp bakenda og framenda eru tvö samhliða verkefni sem eru unnin í GitLab Runner kerfinu. Upprunaleg samsetningarstilling hennar er staðsett í sömu geymslu.
.
GitLab Runner tekur kóðann úr nauðsynlegri geymslu, setur hann saman með Java forritinu build skipuninni og sendir hann til Docker skrárinnar. Hér setjum við saman bakendann og framendann, fáum Docker myndir, sem við setjum í geymslu á hlið viðskiptavinarins. Til að stjórna Docker myndum sem við notum .
Við samstillum útgáfur myndanna okkar við útgáfuútgáfuna sem verður birt í Docker. Fyrir sléttan rekstur höfum við gert nokkrar breytingar:
1. Gámar eru ekki endurbyggðir á milli prófunarumhverfis og framleiðsluumhverfis. Við gerðum breytur þannig að sami gámurinn gæti unnið með allar stillingar, umhverfisbreytur og þjónustu bæði í prófunarumhverfinu og í framleiðslu án þess að endurbyggja.
2. Til að uppfæra forrit í gegnum Helm verður þú að tilgreina útgáfu þess. Við smíðum bakendann, framendann og uppfærum forritið - þetta eru þrjú mismunandi verkefni og því mikilvægt að nota sömu útgáfuna af forritinu alls staðar. Fyrir þetta verkefni notum við gögn úr Git sögu, þar sem K8S klasastillingar okkar og forrit eru í sömu Git geymslunni.
Við fáum forritaútgáfuna frá niðurstöðum stjórnunarframkvæmda
git describe --tags --abbrev=7.
4. Sjálfvirk uppsetning allra breytinga á prófunarumhverfinu (UAT)
Næsta skref í þessu byggingarhandriti er að uppfæra K8S þyrpinguna sjálfkrafa. Þetta gerist að því tilskildu að allt forritið hafi verið smíðað og allir gripir hafi verið birtir í Docker Registry. Eftir þetta byrjar uppfærsla prófumhverfisins.
Uppfærslan á klasanum er byrjuð að nota . Ef, þar af leiðandi, eitthvað fór ekki samkvæmt áætlun mun Helm sjálfkrafa og sjálfstætt draga til baka allar breytingar sínar. Það þarf ekki að stjórna verkum hans.
Við útvegum K8S klasauppsetninguna ásamt samsetningunni. Þess vegna er næsta skref að uppfæra það: configMaps, uppsetningar, þjónustur, leyndarmál og allar aðrar K8S stillingar sem við höfum breytt.
Helm keyrir síðan RollOut uppfærslu á forritinu sjálfu í prófunarumhverfinu. Áður en forritið er sent til framleiðslu. Þetta er gert til að notendur geti handvirkt prófað viðskiptaeiginleikana sem við setjum inn í prófunarumhverfið.
5. Sjálfvirk uppsetning allra breytinga á Prod
Til að dreifa uppfærslu á framleiðsluumhverfið þarftu bara að smella á einn hnapp í GitLab - og gámarnir eru strax afhentir í framleiðsluumhverfið.
Sama forritið getur unnið í mismunandi umhverfi—prófun og framleiðslu—án þess að endurbyggja. Við notum sömu gripina án þess að breyta neinu í forritinu og við stillum færibreyturnar að utan.
Sveigjanleg breytustilling forritsstillinga fer eftir því umhverfi sem forritið verður keyrt í. Við höfum fært allar umhverfisstillingar að utan: allt er stillt í gegnum K8S stillingar og Helm færibreytur. Þegar Helm setur samsetningu í prófunarumhverfið er prófunarstillingunum beitt á það og vörustillingunum beitt á framleiðsluumhverfið.
Erfiðast var að stilla allar notaðar þjónustur og breytur sem eru háðar umhverfinu og þýða þær yfir í umhverfisbreytur og lýsingar-stillingar á umhverfisbreytum fyrir Helm.
Stillingar forrita nota umhverfisbreytur. Gildi þeirra eru stillt í gámum með K8S configmap, sem er sniðmát með Go sniðmátum. Til dæmis er hægt að setja umhverfisbreytu á lénið á þennan hátt:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – þessi breyta geymir heiti umhverfisins (prod, stage, UAT).
.Values.app.properties.app_ytra_lén – í þessari breytu setjum við æskilegt lén í .Values.yaml skrána
Þegar forrit er uppfært, býr Helm til configmap.yaml skrá úr sniðmátum og fyllir APP_EXTERNAL_DOMAIN gildið með æskilegu gildi eftir því í hvaða umhverfi forritsuppfærslan byrjar. Þessi breyta er þegar stillt í gámnum. Það er hægt að nálgast það úr forritinu, þannig að hvert forritsumhverfi mun hafa mismunandi gildi fyrir þessa breytu.
Tiltölulega nýlega birtist K8S stuðningur í Spring Cloud, þar á meðal vinna með configMaps: . Þó verkefnið sé í virkri þróun og róttækum breytingum getum við ekki notað það í framleiðslu. En við fylgjumst virkan með ástandi þess og notum það í DEV stillingum. Um leið og það er komið á stöðugleika munum við skipta úr því að nota umhverfisbreytur yfir í það.
Alls
Svo, Stöðug dreifing er stillt og virkar. Allar uppfærslur eiga sér stað með einum áslátt. Afhending breytinga á vöruumhverfi er sjálfvirk. Og, mikilvægur, uppfærslur stöðva ekki kerfið.
Framtíðaráætlanir: sjálfvirk flutningur gagnagrunns
Við hugsuðum um að uppfæra gagnagrunninn og möguleikann á að afturkalla þessar breytingar. Þegar öllu er á botninn hvolft eru tvær mismunandi útgáfur af forritinu í gangi á sama tíma: sú gamla er í gangi og sú nýja er í gangi. Og við munum slökkva á gömlu aðeins þegar við erum viss um að nýja útgáfan virkar. Gagnagrunnsflutningurinn ætti að gera þér kleift að vinna með báðar útgáfur forritsins.
Þess vegna getum við ekki einfaldlega breytt dálknafninu eða öðrum gögnum. En við getum búið til nýjan dálk, afritað gögn úr gamla dálknum inn í hann og skrifað triggers sem, þegar gögnin eru uppfærð, munu samtímis afrita og uppfæra þau í öðrum dálki. Og eftir árangursríka dreifingu á nýju útgáfunni af forritinu, eftir stuðningstímabilið eftir ræsingu, munum við geta eytt gamla dálknum og kveikjunni sem er orðin óþörf.
Ef nýja útgáfan af forritinu virkar ekki rétt getum við snúið aftur í fyrri útgáfu, þar á meðal fyrri útgáfu gagnagrunnsins. Í stuttu máli, breytingar okkar gera þér kleift að vinna samtímis með nokkrum útgáfum af forritinu.
Við ætlum að gera sjálfvirkan flutning gagnagrunns í gegnum K8S starf, samþætta það inn í geisladiskferlið. Og við munum örugglega deila þessari reynslu á Habré.
Heimild: www.habr.com