Tayari tumezungumza juu ya zana yetu ya GitOps zaidi ya mara moja. , na wakati huu tungependa kushiriki uzoefu wetu katika kukusanya tovuti na nyaraka za mradi wenyewe - (toleo lake la Kirusi ni ) Hii ni tovuti ya kawaida tuli, lakini mkusanyiko wake unavutia kwa kuwa umejengwa kwa kutumia idadi ya nguvu ya mabaki.
Nenda kwenye nuances ya muundo wa tovuti: kuzalisha orodha ya kawaida kwa matoleo yote, kurasa zilizo na habari kuhusu matoleo, nk. - hatutafanya. Badala yake, hebu tuzingatie masuala na vipengele vya mkusanyiko wa nguvu na kidogo juu ya michakato inayoambatana ya CI/CD.
Utangulizi: jinsi tovuti inavyofanya kazi
Kuanza, nyaraka za werf huhifadhiwa pamoja na msimbo wake. Hii inaweka mahitaji fulani ya maendeleo ambayo kwa ujumla ni zaidi ya upeo wa kifungu hiki, lakini kwa kiwango cha chini inaweza kusemwa kuwa:
- Vitendaji vipya vya werf havipaswi kutolewa bila kusasisha hati na, kinyume chake, mabadiliko yoyote katika hati yanamaanisha kutolewa kwa toleo jipya la werf;
- Mradi huo una maendeleo ya kutosha: matoleo mapya yanaweza kutolewa mara kadhaa kwa siku;
- Shughuli zozote za mikono za kupeleka tovuti yenye toleo jipya la uhifadhi ni angalau za kuchosha;
- Mradi unachukua mbinu ya kisemantiki , yenye njia 5 za uthabiti. Mchakato wa kuachilia unahusisha upitishaji mfuatano wa matoleo kupitia chaneli ili kuongeza uthabiti: kutoka alpha hadi mwamba-imara;
- Tovuti ina toleo la lugha ya Kirusi, ambayo "huishi na kuendeleza" (yaani, maudhui ambayo yanasasishwa) sambamba na toleo kuu (yaani, lugha ya Kiingereza).
Ili kuficha "jikoni ya ndani" hii yote kutoka kwa mtumiaji, kumpa kitu ambacho "hufanya kazi tu", tulifanya tofauti ya usakinishaji wa werf na zana ya kusasisha - Je, . Unahitaji tu kutaja nambari ya kutolewa na kituo cha utulivu ambacho uko tayari kutumia, na multiwerf itaangalia ikiwa kuna toleo jipya kwenye kituo na kuipakua ikiwa ni lazima.
Katika menyu ya uteuzi wa matoleo kwenye tovuti, matoleo mapya zaidi ya werf yanapatikana katika kila chaneli. Kwa chaguo-msingi, kwa anwani toleo la chaneli thabiti zaidi kwa toleo la hivi karibuni linafungua - pia linaonyeshwa na injini za utaftaji. Hati za kituo zinapatikana katika anwani tofauti (kwa mfano, kwa toleo la beta 1.0).
Kwa jumla, tovuti ina matoleo yafuatayo yanayopatikana:
- mzizi (hufungua kwa msingi),
- kwa kila chaneli inayoendelea ya sasisho ya kila toleo (kwa mfano, ).
Ili kuzalisha toleo maalum la tovuti, kwa ujumla, inatosha kuikusanya kwa kutumia kwa kukimbia kwenye saraka /docs amri inayolingana ya hazina ya werf (jekyll build), baada ya kubadili lebo ya Git ya toleo linalohitajika.
Inabakia tu kuongeza kwamba:
- matumizi yenyewe (werf) hutumiwa kwa mkusanyiko;
- Michakato ya CI/CD imejengwa kwa misingi ya GitLab CI;
- na haya yote, kwa kweli, yanaendesha Kubernetes.
kazi
Sasa hebu tutengeneze kazi zinazozingatia maelezo yote yaliyoelezwa:
- Baada ya kubadilisha toleo la werf kwenye kituo chochote cha sasisho nyaraka kwenye tovuti zinapaswa kusasishwa kiotomatiki.
- Kwa maendeleo unahitaji kuwa na wakati mwingine tazama matoleo ya hakiki ya tovuti.
Tovuti lazima irudishwe baada ya kubadilisha toleo kwenye chaneli yoyote kutoka kwa vitambulisho vya Git vinavyolingana, lakini katika mchakato wa kujenga picha tutapata vipengele vifuatavyo:
- Kwa kuwa orodha ya matoleo kwenye vituo hubadilika, ni muhimu tu kujenga upya nyaraka za vituo ambapo toleo limebadilika. Baada ya yote, kujenga tena kila kitu sio nzuri sana.
- Seti ya vituo vya matoleo inaweza kubadilika. Wakati fulani kwa wakati, kwa mfano, kunaweza kusiwe na toleo kwenye chaneli thabiti zaidi kuliko toleo la ufikiaji wa mapema la 1.1, lakini baada ya muda zitaonekana - katika kesi hii, haupaswi kubadilisha kusanyiko kwa mikono?
Ni zinageuka kuwa mkusanyiko inategemea kubadilisha data ya nje.
Utekelezaji
Kuchagua Mbinu
Vinginevyo, unaweza kuendesha kila toleo linalohitajika kama ganda tofauti katika Kubernetes. Chaguo hili linamaanisha idadi kubwa ya vitu kwenye nguzo, ambayo itakua na ongezeko la idadi ya matoleo thabiti ya werf. Na hii, kwa upande wake, inamaanisha matengenezo magumu zaidi: kila toleo lina seva yake ya HTTP, na kwa mzigo mdogo. Bila shaka, hii pia inajumuisha gharama kubwa za rasilimali.
Tulichukua njia sawa kukusanya matoleo yote muhimu katika picha moja. Takwimu zilizokusanywa za matoleo yote ya tovuti ziko kwenye chombo kilicho na NGINX, na trafiki kwa Upelekaji sambamba huja kupitia NGINX Ingress. Muundo rahisi - programu isiyo na uraia - hukuruhusu kuongeza kwa urahisi Upelekaji (kulingana na mzigo) kwa kutumia Kubernetes yenyewe.
Ili kuwa sahihi zaidi, tunakusanya picha mbili: moja kwa mzunguko wa uzalishaji, ya pili ni ya ziada kwa mzunguko wa dev. Picha ya ziada inatumika (iliyozinduliwa) tu kwenye mzunguko wa dev pamoja na ile kuu na ina toleo la tovuti kutoka kwa ahadi ya ukaguzi, na uelekezaji kati yao unafanywa kwa kutumia rasilimali za Ingress.
werf dhidi ya git clone na mabaki
Kama ilivyoelezwa tayari, ili kutoa statics ya tovuti kwa toleo maalum la nyaraka, unahitaji kujenga kwa kubadili tag sahihi ya hifadhi. Unaweza pia kufanya hivyo kwa kuunda hazina kila wakati unapounda, kuchagua lebo zinazofaa kutoka kwenye orodha. Hata hivyo, hii ni operesheni kubwa ya rasilimali na, zaidi ya hayo, inahitaji kuandika maagizo yasiyo ya kawaida ... Hasara nyingine kubwa ni kwamba kwa njia hii hakuna njia ya cache kitu wakati wa kusanyiko.
Hapa shirika la werf lenyewe linakuja kwa msaada wetu, kutekeleza smart caching na kukuruhusu kutumia . Kutumia werf kuongeza nambari kutoka kwa hazina kutaongeza kasi ya ujenzi, kwa sababu werf kimsingi huiga hazina mara moja na kisha kutekeleza tu fetch kama ni lazima. Kwa kuongezea, wakati wa kuongeza data kutoka kwa hazina, tunaweza kuchagua saraka muhimu tu (kwa upande wetu hii ndio saraka. docs), ambayo itapunguza kwa kiasi kikubwa kiasi cha data iliyoongezwa.
Kwa kuwa Jekyll ni chombo kilichoundwa kwa ajili ya kukusanya data tuli na haihitajiki katika picha ya mwisho, itakuwa jambo la busara kukusanya , na kwenye picha ya mwisho ingiza tu matokeo ya mkusanyiko.
Tunaandika werf.yaml
Kwa hivyo, tuliamua kwamba tutakusanya kila toleo katika vizalia vya programu tofauti vya werf. Hata hivyo sisi hatujui ni ngapi kati ya hizi mabaki kutakuwa na wakati wa kusanyiko, kwa hiyo hatuwezi kuandika usanidi uliowekwa wa kujenga (kwa kusema, bado tunaweza, lakini haitakuwa na ufanisi kabisa).
werf hukuruhusu kutumia kwenye faili yako ya usanidi (werf.yaml), na hii inafanya iwezekanavyo toa usanidi kwenye kuruka kulingana na data ya nje (unachohitaji!). Data ya nje kwa upande wetu ni habari kuhusu matoleo na matoleo, kwa msingi ambao tunakusanya idadi inayohitajika ya vizalia vya programu na matokeo yake tunapata picha mbili: werf-doc и werf-dev kukimbia kwenye mizunguko tofauti.
Data ya nje hupitishwa kupitia vigezo vya mazingira. Huu hapa ni muundo wao:
-
RELEASES- mstari ulio na orodha ya matoleo na toleo linalolingana la sasa la werf, katika mfumo wa orodha iliyotengwa na nafasi ya maadili katika umbizo.<НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. Mfano:1.0%v1.0.4-beta.20 -
CHANNELS- mstari ulio na orodha ya chaneli na toleo linalolingana la sasa la werf, katika mfumo wa orodha iliyotengwa na nafasi ya maadili katika umbizo.<КАНАЛ>%<НОМЕР_ВЕРСИИ>. Mfano:1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22 -
ROOT_VERSION— toleo la toleo la werf kuonyeshwa kwa chaguo-msingi kwenye tovuti (sio lazima kila wakati kuonyesha hati kwa nambari ya juu zaidi ya kutolewa). Mfano:v1.0.4-beta.20 -
REVIEW_SHA- heshi ya ahadi ya ukaguzi ambayo unahitaji kuunda toleo la kitanzi cha majaribio.
Vigezo hivi vitajazwa kwenye bomba la GitLab CI, na jinsi ilivyoandikwa hapa chini.
Kwanza kabisa, kwa urahisi, tunafafanua ndani werf.yaml Nenda vigezo vya template, ukizipa maadili kutoka kwa anuwai ya mazingira:
{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }} Maelezo ya vizalia vya programu kwa ajili ya kuandaa toleo tuli la tovuti kwa ujumla ni sawa kwa matukio yote tunayohitaji (ikiwa ni pamoja na kuzalisha toleo la mizizi, pamoja na toleo la mzunguko wa dev). Kwa hiyo, tutaiingiza kwenye kizuizi tofauti kwa kutumia kazi define - kwa kutumia tena baadae include. Tutapitisha hoja zifuatazo kwa kiolezo:
-
Version- toleo linalotengenezwa (jina la lebo); -
Channel- jina la chaneli ya sasisho ambayo kisanii hutengenezwa; -
Commit- tuma heshi, ikiwa vizalia vya programu vimetolewa kwa ahadi ya ukaguzi; - muktadha.
Maelezo ya Kiolezo cha Vizalia
{{- define "doc_artifact" -}}
{{- $Root := index . "Root" -}}
artifact: doc-{{ .Channel }}
from: jekyll/builder:3
mount:
- from: build_dir
to: /usr/local/bundle
ansible:
install:
- shell: |
export PATH=/usr/jekyll/bin/:$PATH
- name: "Install Dependencies"
shell: bundle install
args:
executable: /bin/bash
chdir: /app/docs
beforeSetup:
{{- if .Commit }}
- shell: echo "Review SHA - {{ .Commit }}."
{{- end }}
{{- if eq .Channel "root" }}
- name: "releases.yml HASH: {{ $Root.Files.Get "releases.yml" | sha256sum }}"
copy:
content: |
{{ $Root.Files.Get "releases.yml" | indent 8 }}
dest: /app/docs/_data/releases.yml
{{- else }}
- file:
path: /app/docs/_data/releases.yml
state: touch
{{- end }}
- file:
path: "{{`{{ item }}`}}"
state: directory
mode: 0777
with_items:
- /app/main_site/
- /app/ru_site/
- file:
dest: /app/docs/pages_ru/cli
state: link
src: /app/docs/pages/cli
- shell: |
echo -e "werfVersion: {{ .Version }}nwerfChannel: {{ .Channel }}" > /tmp/_config_additional.yml
export PATH=/usr/jekyll/bin/:$PATH
{{- if and (ne .Version "review") (ne .Channel "root") }}
{{- $_ := set . "BaseURL" ( printf "v%s" .Channel ) }}
{{- else if ne .Channel "root" }}
{{- $_ := set . "BaseURL" .Channel }}
{{- end }}
jekyll build -s /app/docs -d /app/_main_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/tmp/_config_additional.yml
jekyll build -s /app/docs -d /app/_ru_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/app/docs/_config_ru.yml,/tmp/_config_additional.yml
args:
executable: /bin/bash
chdir: /app/docs
git:
- url: https://github.com/flant/werf.git
to: /app/
owner: jekyll
group: jekyll
{{- if .Commit }}
commit: {{ .Commit }}
{{- else }}
tag: {{ .Version }}
{{- end }}
stageDependencies:
install: ['docs/Gemfile','docs/Gemfile.lock']
beforeSetup: '**/*'
includePaths: 'docs'
excludePaths: '**/*.sh'
{{- end }} Jina la vizalia vya programu lazima liwe la kipekee. Tunaweza kufikia hili, kwa mfano, kwa kuongeza jina la kituo (thamani ya kutofautisha .Channel) kama kiambishi tamati kwa jina la vizalia vya programu: artifact: doc-{{ .Channel }}. Lakini unahitaji kuelewa kwamba wakati wa kuagiza kutoka kwa mabaki, utahitaji kutaja majina sawa.
Wakati wa kuelezea vizalia vya programu, kipengele kifuatacho cha werf kinatumika: . Kuweka kuashiria saraka ya huduma build_dir hukuruhusu kuokoa kashe ya Jekyll kati ya uendeshaji wa bomba, ambayo kwa kiasi kikubwa kuongeza kasi ya kuunganisha tena.
Huenda pia umeona matumizi ya faili releases.yml ni faili ya YAML yenye data ya kutolewa iliyoombwa kutoka (kibaki kilichopatikana wakati wa kutekeleza bomba). Inahitajika wakati wa kuandaa tovuti, lakini katika muktadha wa kifungu hicho ni ya kuvutia kwetu kwa sababu inategemea hali yake kuunganishwa tena kwa vizalia moja tu - artifact ya toleo la mizizi ya tovuti (haihitajiki katika mabaki mengine).
Hii inatekelezwa kwa kutumia taarifa ya masharti if Nenda violezo na miundo {{ $Root.Files.Get "releases.yml" | sha256sum }} katika hatua . Inafanya kazi kama ifuatavyo: wakati wa kuunda kisanii cha toleo la mizizi (variable .Channel ni sawa na root) faili hash releases.yml inathiri saini ya hatua nzima, kwani ni sehemu ya jina la kazi inayostahili (parameter name) Kwa hivyo, wakati wa kubadilisha maudhui faili releases.yml kisanii kinacholingana kitaunganishwa tena.
Tafadhali pia makini na kufanya kazi na hazina ya nje. Katika picha ya mabaki kutoka , saraka pekee ndio imeongezwa /docs, na kulingana na vigezo vilivyopitishwa, data ya lebo inayohitajika au ahadi ya ukaguzi huongezwa mara moja.
Ili kutumia kiolezo cha vizalia vya programu kutoa maelezo ya vizalia vya programu vya matoleo yaliyohamishwa ya vituo na matoleo, tunapanga kitanzi kwenye kigezo. .WerfVersions в werf.yaml:
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}} Kwa sababu kitanzi kitatoa mabaki kadhaa (tunatumai hivyo), ni muhimu kuzingatia kitenganishi kati yao - mlolongo --- (Kwa habari zaidi juu ya syntax ya faili ya usanidi, ona ) Kama ilivyoelezwa hapo awali, tunapoita kiolezo kwa kitanzi, tunapitisha vigezo vya toleo, URL na muktadha wa mizizi.
Vile vile, lakini bila kitanzi, tunaita kiolezo cha vizalia vya programu kwa "kesi maalum": kwa toleo la mizizi, na pia toleo kutoka kwa ahadi ya ukaguzi:
{{ dict "Version" .WerfRootVersion "Channel" "root" "Root" $Root | include "doc_artifact" }}
---
{{- if .WerfReviewCommit }}
{{ dict "Version" "review" "Channel" "review" "Commit" .WerfReviewCommit "Root" $Root | include "doc_artifact" }}
{{- end }} Tafadhali kumbuka kuwa vizalia vya programu vya ahadi ya ukaguzi vitajengwa tu ikiwa utofauti umewekwa .WerfReviewCommit.
Vizalia vya programu viko tayari - ni wakati wa kuanza kuagiza!
Picha ya mwisho, iliyoundwa kufanya kazi kwenye Kubernetes, ni NGINX ya kawaida na faili ya usanidi wa seva imeongezwa. nginx.conf na tuli kutoka kwa mabaki. Mbali na artifact ya toleo la mizizi ya tovuti, tunahitaji kurudia kitanzi kwenye kutofautiana .WerfVersions ili kuleta vizalia vya programu vya matoleo na matoleo + kufuata kanuni ya majina ya vizalia vya programu ambayo tulipitisha hapo awali. Kwa kuwa kila vizalia vya programu huhifadhi matoleo ya tovuti kwa lugha mbili, tunayaingiza katika maeneo yaliyotolewa na usanidi.
Maelezo ya picha ya mwisho werf-doc
image: werf-doc
from: nginx:stable-alpine
ansible:
setup:
- name: "Setup /etc/nginx/nginx.conf"
copy:
content: |
{{ .Files.Get ".werf/nginx.conf" | indent 8 }}
dest: /etc/nginx/nginx.conf
- file:
path: "{{`{{ item }}`}}"
state: directory
mode: 0777
with_items:
- /app/main_site/assets
- /app/ru_site/assets
import:
- artifact: doc-root
add: /app/_main_site
to: /app/main_site
before: setup
- artifact: doc-root
add: /app/_ru_site
to: /app/ru_site
before: setup
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
add: /app/_main_site
to: /app/main_site/v{{ $Channel }}
before: setup
{{ end -}}
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
add: /app/_ru_site
to: /app/ru_site/v{{ $Channel }}
before: setup
{{ end -}}Picha ya ziada, ambayo, pamoja na ile kuu, imezinduliwa kwenye mzunguko wa dev, ina matoleo mawili tu ya tovuti: toleo kutoka kwa ahadi ya ukaguzi na toleo la mizizi ya tovuti (kuna mali ya jumla na, ikiwa unakumbuka. , data ya kutolewa). Kwa hivyo, picha ya ziada itatofautiana na ile kuu tu katika sehemu ya uingizaji (na, bila shaka, kwa jina):
image: werf-dev
...
import:
- artifact: doc-root
add: /app/_main_site
to: /app/main_site
before: setup
- artifact: doc-root
add: /app/_ru_site
to: /app/ru_site
before: setup
{{- if .WerfReviewCommit }}
- artifact: doc-review
add: /app/_main_site
to: /app/main_site/review
before: setup
- artifact: doc-review
add: /app/_ru_site
to: /app/ru_site/review
before: setup
{{- end }} Kama ilivyoonyeshwa hapo juu, kisanii cha ahadi ya ukaguzi kitatolewa tu wakati utofauti wa mazingira uliowekwa unaendeshwa REVIEW_SHA. Itawezekana kutotoa picha ya werf-dev hata kidogo ikiwa hakuna mabadiliko ya mazingira REVIEW_SHA, lakini ili Picha za docker kwenye werf zilifanya kazi kwa picha ya werf-dev, tutaiacha iundwe tu na vizalia vya toleo la mizizi (tayari imejengwa hata hivyo), ili kurahisisha muundo wa bomba.
Mkutano uko tayari! Wacha tuendelee kwenye CI / CD na nuances muhimu.
Bomba katika GitLab CI na vipengele vya muundo wa nguvu
Wakati wa kuendesha ujenzi tunahitaji kuweka anuwai za mazingira zinazotumiwa ndani werf.yaml. Hii haitumiki kwa utofauti wa REVIEW_SHA, ambao tutaweka wakati wa kupiga bomba kutoka kwa ndoano ya GitHub.
Tutatoa data muhimu ya nje katika hati ya Bash generate_artifacts, ambayo itatoa mabaki mawili ya bomba la GitLab:
- faili
releases.ymlna data ya kutolewa, - faili
common_envs.sh, iliyo na anuwai ya mazingira ya kusafirishwa.
Yaliyomo kwenye faili generate_artifacts utapata katika yetu . Kupokea data yenyewe sio mada ya kifungu, lakini faili common_envs.sh ni muhimu kwetu, kwa sababu kazi ya werf inategemea. Mfano wa yaliyomo:
export RELEASES='1.0%v1.0.6-4'
export CHANNELS='1.0-alpha%v1.0.7-1 1.0-beta%v1.0.7-1 1.0-ea%v1.0.6-4 1.0-stable%v1.0.6-4 1.0-rock-solid%v1.0.6-4'
export ROOT_VERSION='v1.0.6-4' Unaweza kutumia matokeo ya hati kama hiyo, kwa mfano, kwa kutumia kazi ya Bash source.
Sasa inakuja sehemu ya kufurahisha. Ili ujenzi na upelekaji wa programu kufanya kazi kwa usahihi, ni muhimu kuhakikisha kuwa werf.yaml ilikuwa sawa angalau ndani ya bomba moja. Ikiwa hali hii haijafikiwa, basi saini za hatua ambazo werf huhesabu wakati wa kusanyiko na, kwa mfano, kupelekwa, zitakuwa tofauti. Hii itasababisha hitilafu ya kupeleka, kwa sababu... picha inayohitajika kwa ajili ya kupelekwa itakosekana.
Kwa maneno mengine, ikiwa wakati wa mkusanyiko wa picha ya tovuti habari kuhusu matoleo na matoleo ni sawa, na wakati wa kupeleka toleo jipya linatolewa na vigezo vya mazingira vina maadili tofauti, basi kupelekwa kutashindwa na kosa: baada ya yote, artifact ya toleo jipya bado haijajengwa.
Ikiwa kizazi werf.yaml inategemea data ya nje (kwa mfano, orodha ya matoleo ya sasa, kama ilivyo kwetu), basi muundo na maadili ya data kama hiyo inapaswa kurekodiwa ndani ya bomba. Hii ni muhimu sana ikiwa vigezo vya nje vinabadilika mara nyingi.
Tutafanya hivyo kupokea na kurekodi data ya nje katika hatua ya kwanza ya bomba huko GitLab (Unda mapema) na kuzisambaza zaidi katika fomu Vizalia vya GitLab CI. Hii itakuruhusu kuendesha na kuanza tena kazi za bomba (kujenga, kupeleka, kusafisha) na usanidi sawa katika werf.yaml.
Yaliyomo kwenye jukwaa Unda mapema faili .gitlab-ci.yml:
Prebuild:
stage: prebuild
script:
- bash ./generate_artifacts 1> common_envs.sh
- cat ./common_envs.sh
artifacts:
paths:
- releases.yml
- common_envs.sh
expire_in: 2 weekBaada ya kunasa data ya nje kwenye vizalia vya programu, unaweza kuunda na kusambaza kwa kutumia hatua za kawaida za bomba la GitLab CI: Jenga na Upeleke. Tunazindua bomba lenyewe kwa kutumia ndoano kutoka kwa hazina ya werf GitHub (yaani, wakati kuna mabadiliko kwenye hazina ya GitHub). Data kwao inaweza kupatikana katika mali ya mradi wa GitLab kwenye sehemu hiyo Mipangilio ya CI/CD -> Vichochezi vya bomba, na kisha unda Webhook inayolingana katika GitHub (Mipangilio -> Webhooks).
Hatua ya ujenzi itaonekana kama hii:
Build:
stage: build
script:
- type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
- type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
- source common_envs.sh
- werf build-and-publish --stages-storage :local
except:
refs:
- schedules
dependencies:
- Prebuild GitLab itaongeza mabaki mawili kutoka kwa hatua hadi hatua ya ujenzi Unda mapema, kwa hivyo tunahamisha vigeu vilivyo na data ya uingizaji iliyotayarishwa kwa kutumia muundo source common_envs.sh. Tunaanza hatua ya kujenga katika hali zote, isipokuwa kwa kuzindua bomba kulingana na ratiba. Kwa mujibu wa ratiba, tutaendesha bomba la kusafisha - katika kesi hii hakuna haja ya kufanya mkutano.
Katika hatua ya kupeleka, tutaelezea kazi mbili - kando kwa ajili ya kupelekwa kwa saketi za uzalishaji na dev, kwa kutumia kiolezo cha YAML:
.base_deploy: &base_deploy
stage: deploy
script:
- type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
- type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
- source common_envs.sh
- werf deploy --stages-storage :local
dependencies:
- Prebuild
except:
refs:
- schedules
Deploy to Production:
<<: *base_deploy
variables:
WERF_KUBE_CONTEXT: prod
environment:
name: production
url: werf.io
only:
refs:
- master
except:
variables:
- $REVIEW_SHA
refs:
- schedules
Deploy to Test:
<<: *base_deploy
variables:
WERF_KUBE_CONTEXT: dev
environment:
name: test
url: werf.test.flant.com
except:
refs:
- schedules
only:
variables:
- $REVIEW_SHA Kazi kimsingi hutofautiana tu katika kuonyesha muktadha wa nguzo ambayo werf inapaswa kutekeleza utumaji (WERF_KUBE_CONTEXT), na kuweka vigezo vya mazingira ya kitanzi (environment.name и environment.url), ambazo hutumika katika violezo vya chati ya Helm. Hatutatoa yaliyomo kwenye violezo, kwa sababu... hakuna kitu cha kufurahisha hapo kwa mada inayohusika, lakini unaweza kuipata ndani .
mguso wa mwisho
Kwa kuwa matoleo ya werf hutolewa mara nyingi, picha mpya zitajengwa mara kwa mara, na Usajili wa Docker utakua daima. Kwa hivyo, ni muhimu kusanidi usafishaji wa picha kiotomatiki kulingana na sera. Ni rahisi sana kufanya.
Ili kutekeleza utahitaji:
- Ongeza hatua ya kusafisha
.gitlab-ci.yml; - Ongeza utekelezaji wa mara kwa mara wa kazi ya kusafisha;
- Sanidi mabadiliko ya mazingira na tokeni ya ufikiaji wa kuandika.
Kuongeza hatua ya kusafisha .gitlab-ci.yml:
Cleanup:
stage: cleanup
script:
- type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
- type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
- source common_envs.sh
- docker login -u nobody -p ${WERF_IMAGES_CLEANUP_PASSWORD} ${WERF_IMAGES_REPO}
- werf cleanup --stages-storage :local
only:
refs:
- schedules
Tayari tumeona karibu haya yote juu kidogo - ili tu kuitakasa unahitaji kwanza kuingia kwenye Usajili wa Docker na ishara ambayo ina haki ya kufuta picha kwenye Usajili wa Docker (ishara ya kazi ya GitLab CI iliyotolewa moja kwa moja haifanyi. kuwa na haki kama hizo). Tokeni lazima iundwe katika GitLab mapema na thamani yake lazima ibainishwe katika utofauti wa mazingira WERF_IMAGES_CLEANUP_PASSWORD ya mradi huo (Mipangilio ya CI/CD -> Vigezo).
Kuongeza kazi ya kusafisha na ratiba inayohitajika inafanywa ndani CI/CD ->
Mipango.
Hiyo ndiyo yote: mradi katika Usajili wa Docker hautakua tena kutoka kwa picha ambazo hazijatumiwa.
Mwishoni mwa sehemu ya vitendo, wacha nikukumbushe kwamba orodha kamili kutoka kwa kifungu zinapatikana ndani :
- ;
- .
Matokeo
- Tulipokea muundo wa kusanyiko wa kimantiki: vizalia vya programu moja kwa kila toleo.
- Mkutano ni wa ulimwengu wote na hauhitaji mabadiliko ya mwongozo wakati matoleo mapya ya werf yanatolewa: nyaraka kwenye tovuti zinasasishwa kiotomatiki.
- Picha mbili zimekusanywa kwa contours tofauti.
- Inafanya kazi haraka, kwa sababu Uakibishaji hutumiwa kadri inavyowezekana - toleo jipya la werf linapotolewa au ndoano ya GitHub inapoitwa kwa ajili ya kufanya ukaguzi, ni vizalia vya programu vinavyolingana tu na toleo lililobadilishwa hujengwa upya.
- Hakuna haja ya kufikiria juu ya kufuta picha ambazo hazijatumiwa: kusafisha kulingana na sera za werf kutaweka Usajili wa Docker katika mpangilio.
Matokeo
- Kutumia werf huruhusu kusanyiko kufanya kazi haraka kwa sababu ya uhifadhi wa kusanyiko lenyewe na uhifadhi wakati wa kufanya kazi na hazina za nje.
- Kufanya kazi na hazina za Git za nje huondoa hitaji la kuunda hazina nzima kila wakati au kuunda tena gurudumu kwa mantiki ya ujanja ya utoshelezaji. werf hutumia kache na hufanya cloning mara moja tu, na kisha hutumia
fetchna pale tu inapobidi. - Uwezo wa kutumia violezo vya Go katika faili ya usanidi wa muundo
werf.yamlhukuruhusu kuelezea mkusanyiko ambao matokeo yake yanategemea data ya nje. - Kutumia mlima katika werf kwa kiasi kikubwa huongeza kasi ya mkusanyiko wa mabaki - kutokana na cache, ambayo ni ya kawaida kwa mabomba yote.
- werf hurahisisha kusanidi usafishaji, ambao ni muhimu sana wakati wa kujenga kwa nguvu.
PS
Soma pia kwenye blogi yetu:
- «";
- «";
- «";
- «'.
Chanzo: mapenzi.com
