Sisi katika Uhandisi wa Kweli tumeanzisha mchakato wa utoaji wa masasisho mfululizo kwa seva za wateja na tunataka kushiriki matumizi haya.
Kuanza, tulitengeneza mfumo wa mtandaoni kwa ajili ya mteja na kuusambaza katika kundi letu la Kubernetes. Sasa suluhisho letu la upakiaji wa juu limehamia kwenye jukwaa la mteja, ambalo tumeanzisha mchakato wa Usambazaji Unaoendelea wa kiotomatiki. Shukrani kwa hili, tuliongeza kasi ya muda hadi soko - utoaji wa mabadiliko kwa mazingira ya bidhaa.
Katika nakala hii tutazungumza juu ya hatua zote za mchakato wa Usambazaji Unaoendelea (CD) au uwasilishaji wa sasisho kwenye jukwaa la mteja:
- Je, mchakato huu unaanzaje?
- maingiliano na hazina ya Git ya mteja,
- mkusanyiko wa backend na frontend,
- uwekaji wa programu otomatiki katika mazingira ya jaribio,
- kupelekwa kiotomatiki kwa Prod.
Tutashiriki maelezo ya usanidi njiani.
1. Anzisha CD
Usambazaji Unaoendelea huanza na msanidi programu kusukuma mabadiliko kwenye tawi la toleo la hazina yetu ya Git.
Programu yetu inaendesha usanifu wa huduma ndogo na vipengele vyake vyote huhifadhiwa kwenye hifadhi moja. Shukrani kwa hili, microservices zote zinakusanywa na kusakinishwa, hata ikiwa mmoja wao amebadilika.
Tulipanga kazi kupitia hazina moja kwa sababu kadhaa:
- Urahisi wa maendeleo - programu inaendelezwa kikamilifu, hivyo unaweza kufanya kazi na msimbo wote mara moja.
- Bomba moja la CI/CD ambalo huhakikisha kwamba programu kama mfumo mmoja hupita majaribio yote na kuwasilishwa kwa mazingira ya uzalishaji ya mteja.
- Tunaondoa mkanganyiko katika matoleo - sio lazima kuhifadhi ramani ya matoleo ya huduma ndogo na kuelezea usanidi wake kwa kila huduma ndogo kwenye hati za Helm.
2. Usawazishaji na hazina ya Git ya msimbo wa chanzo wa mteja
Mabadiliko yaliyofanywa yanasawazishwa kiotomatiki na hazina ya Git ya mteja. Huko mkusanyiko wa maombi umeundwa, ambayo huzinduliwa baada ya uppdatering tawi, na kupelekwa kwa kuendelea. Taratibu zote mbili hutoka katika mazingira yao kutoka kwa hazina ya Git.
Hatuwezi kufanya kazi na hazina ya mteja moja kwa moja kwa sababu tunahitaji mazingira yetu wenyewe kwa maendeleo na majaribio. Tunatumia hazina yetu ya Git kwa madhumuni haya - imesawazishwa na hazina yao ya Git. Mara tu machapisho ya msanidi yanapobadilika hadi tawi linalofaa la hazina yetu, GitLab husukuma mara moja mabadiliko haya kwa mteja.
Baada ya hayo, unahitaji kufanya mkusanyiko. Inajumuisha hatua kadhaa: mkusanyiko wa nyuma na wa mbele, kupima na utoaji kwa uzalishaji.
3. Kukusanya backend na frontend
Kuunda mazingira ya nyuma na ya mbele ni kazi mbili zinazofanana ambazo hufanywa katika mfumo wa GitLab Runner. Configuration yake ya awali ya mkusanyiko iko kwenye hifadhi sawa.
.
GitLab Runner inachukua nambari kutoka kwa hazina inayohitajika, inakusanya na amri ya ujenzi wa programu ya Java na kuituma kwa sajili ya Docker. Hapa tunakusanya sehemu ya nyuma na ya mbele, tunapata picha za Docker, ambazo tunaweka kwenye ghala kwa upande wa mteja. Ili kudhibiti picha za Docker tunazotumia .
Tunasawazisha matoleo ya picha zetu na toleo la toleo ambalo litachapishwa katika Docker. Kwa operesheni laini, tumefanya marekebisho kadhaa:
1. Vyombo havijajengwa upya kati ya mazingira ya majaribio na mazingira ya uzalishaji. Tulifanya vipimo ili kontena lile lile lifanye kazi na mipangilio yote, anuwai ya mazingira na huduma katika mazingira ya majaribio na katika uzalishaji bila kujengwa upya.
2. Ili kusasisha programu kupitia Helm, lazima ubainishe toleo lake. Tunaunda mazingira ya nyuma, ya mbele na kusasisha programu - hizi ni kazi tatu tofauti, kwa hivyo ni muhimu kutumia toleo sawa la programu kila mahali. Kwa kazi hii, tunatumia data kutoka kwa historia ya Git, kwa kuwa usanidi wetu wa nguzo ya K8S na programu ziko kwenye hazina sawa ya Git.
Tunapata toleo la programu kutoka kwa matokeo ya utekelezaji wa amri
git describe --tags --abbrev=7.
4. Usambazaji otomatiki wa mabadiliko yote kwenye mazingira ya majaribio (UAT)
Hatua inayofuata katika hati hii ya ujenzi ni kusasisha kiotomatiki nguzo ya K8S. Hii hutokea mradi tu programu nzima imejengwa na vizalia vyote vimechapishwa kwenye Usajili wa Docker. Baada ya hayo, sasisho la mazingira ya mtihani huanza.
Usasishaji wa nguzo umeanza kutumia . Ikiwa, kama matokeo, kitu hakikuenda kulingana na mpango, Helm itarudisha moja kwa moja na kwa uhuru mabadiliko yake yote. Kazi yake haihitaji kudhibitiwa.
Tunatoa usanidi wa nguzo ya K8S pamoja na mkusanyiko. Kwa hivyo, hatua inayofuata ni kuisasisha: configMaps, uwekaji, huduma, siri na usanidi mwingine wowote wa K8S ambao tumebadilisha.
Helm kisha huendesha sasisho la Utoaji wa programu yenyewe katika mazingira ya majaribio. Kabla ya maombi kupelekwa kwa uzalishaji. Hii inafanywa ili watumiaji waweze kujaribu wenyewe vipengele vya biashara ambavyo tunaweka katika mazingira ya majaribio.
5. Usambazaji wa kiotomatiki wa mabadiliko yote kwa Prod
Ili kupeleka sasisho kwa mazingira ya uzalishaji, unahitaji tu kubofya kitufe kimoja kwenye GitLab - na vyombo huwasilishwa mara moja kwa mazingira ya uzalishaji.
Utumizi sawa unaweza kufanya kazi katika mazingira tofauti-jaribio na uzalishaji-bila kujenga upya. Tunatumia mabaki sawa bila kubadilisha chochote katika programu, na tunaweka vigezo nje.
Parameta inayobadilika ya mipangilio ya programu inategemea mazingira ambayo programu itatekelezwa. Tumehamisha mipangilio yote ya mazingira nje: kila kitu kimewekwa kwa vigezo kupitia usanidi wa K8S na vigezo vya Helm. Wakati Helm inapeleka mkusanyiko kwa mazingira ya jaribio, mipangilio ya jaribio inatumika kwake, na mipangilio ya bidhaa inatumika kwa mazingira ya uzalishaji.
Jambo gumu zaidi lilikuwa kuainisha huduma na vigeu vyote vilivyotumika ambavyo vinategemea mazingira, na kuzitafsiri kuwa anuwai za mazingira na usanidi wa maelezo ya vigezo vya mazingira kwa Helm.
Mipangilio ya programu hutumia anuwai ya mazingira. Thamani zao zimewekwa katika vyombo kwa kutumia usanidi wa K8S, ambao umeonyeshwa kwa kutumia violezo vya Go. Kwa mfano, kuweka utaftaji wa mazingira kwa jina la kikoa kunaweza kufanywa kama hii:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env - tofauti hii huhifadhi jina la mazingira (prod, hatua, UAT).
.Values.app.properties.app_external_domain - katika kigezo hiki tunaweka kikoa kinachohitajika katika faili ya .Values.yaml
Wakati wa kusasisha programu, Helm huunda faili ya configmap.yaml kutoka kwa violezo na kujaza thamani ya APP_EXTERNAL_DOMAIN na thamani inayotakiwa kulingana na mazingira ambayo sasisho la programu huanza. Tofauti hii tayari imewekwa kwenye chombo. Inaweza kufikiwa kutoka kwa programu, kwa hivyo kila mazingira ya programu yatakuwa na thamani tofauti ya utaftaji huu.
Hivi majuzi, msaada wa K8S ulionekana katika Wingu la Spring, pamoja na kufanya kazi na configMaps: . Ingawa mradi unaendelezwa kikamilifu na kubadilika kwa kiasi kikubwa, hatuwezi kuutumia katika uzalishaji. Lakini tunafuatilia kikamilifu hali yake na kuitumia katika usanidi wa DEV. Mara tu itakapotulia, tutabadilika kutoka kwa kutumia vigeu vya mazingira kwenda kwayo.
Katika jumla ya
Kwa hivyo, Usambazaji Unaoendelea umesanidiwa na kufanya kazi. Masasisho yote hutokea kwa kibonye kimoja. Uwasilishaji wa mabadiliko kwa mazingira ya bidhaa ni moja kwa moja. Na, muhimu, sasisho hazizuii mfumo.
Mipango ya siku zijazo: uhamiaji wa hifadhidata otomatiki
Tulifikiria kuhusu kuboresha hifadhidata na uwezekano wa kurejesha mabadiliko haya. Baada ya yote, matoleo mawili tofauti ya programu yanaendesha kwa wakati mmoja: ya zamani inaendesha, na mpya iko. Na tutazima ile ya zamani tu wakati tuna hakika kuwa toleo jipya linafanya kazi. Uhamishaji wa hifadhidata unapaswa kukuruhusu kufanya kazi na matoleo yote mawili ya programu.
Kwa hivyo, hatuwezi kubadilisha tu jina la safu wima au data nyingine. Lakini tunaweza kuunda safu mpya, kunakili data kutoka kwa safu ya zamani ndani yake na kuandika vichochezi ambavyo, wakati wa kusasisha data, itanakili wakati huo huo na kuisasisha kwenye safu nyingine. Na baada ya kupelekwa kwa mafanikio kwa toleo jipya la programu, baada ya kipindi cha usaidizi cha uzinduzi wa chapisho, tutaweza kufuta safu ya zamani na kichochezi ambacho kimekuwa kisichohitajika.
Ikiwa toleo jipya la programu haifanyi kazi ipasavyo, tunaweza kurudi kwenye toleo la awali, ikiwa ni pamoja na toleo la awali la hifadhidata. Kwa kifupi, mabadiliko yetu yatakuwezesha kufanya kazi wakati huo huo na matoleo kadhaa ya programu.
Tunapanga kugeuza uhamishaji wa hifadhidata kiotomatiki kupitia kazi ya K8S, kuijumuisha katika mchakato wa CD. Na bila shaka tutashiriki tukio hili kwenye Habre.
Chanzo: mapenzi.com