Me berê ji carekê zêdetir li ser amûra xweya GitOps axivî , û vê carê em dixwazin ezmûna xwe ya di berhevkirina malperê de bi belgeyên projeyê bixwe re parve bikin - (guhertoya wê ya rûsî ye ). Ev malperek statîk a asayî ye, lê meclîsa wê balkêş e ku ew bi karanîna hejmarek dînamîkî ya hunerî ve hatî çêkirin.
Herin nav hûrgelên avahiya malperê: ji bo hemî guhertoyan, rûpelên bi agahdariya der barê serbestberdanê, pêşekek hevpar çêbikin, hwd. - em nabin. Di şûna wê de, bila em li ser pirsgirêk û taybetmendiyên kombûna dînamîkî û hinekî li ser pêvajoyên pêvekirî yên CI/CD-ê bisekinin.
Destpêk: malper çawa dixebite
Ji bo destpêkê, belgeyên werf digel koda wê têne hilanîn. Ev hin hewcedariyên pêşkeftinê ferz dike ku bi gelemperî li derveyî çarçoweya vê gotarê ne, lê bi kêmanî dikare were gotin ku:
- Pêdivî ye ku fonksiyonên werfê yên nû bêyî nûvekirina belgeyan neyên berdan û berevajî vê, her guhertinek di belgenameyê de tê wateya berdana guhertoyek nû ya werfê;
- Proje xwedan pêşkeftinek berbiçav e: guhertoyên nû dikarin rojê çend caran werin berdan;
- Hemî operasyonên bi destan ên ji bo danîna malperek bi guhertoyek nû ya belgekirinê bi kêmî ve bêzar in;
- Proje nêzîkatiyek semantîkî qebûl dike , bi 5 kanalên aramiyê. Pêvajoya berdanê ji bo zêdekirina îstîqrarê di kanalan re derbasbûna rêzimanî ya guhertoyan vedihewîne: ji alfa berbi kevir-solid;
- Malper guhertoyek bi zimanê rûsî heye, ku "dijî û pêş dikeve" (ango, naveroka ku tê nûve kirin) bi guhertoya sereke (ango, bi zimanê îngilîzî) re paralel.
Ji bo ku em hemî vê "metbexa hundurîn" ji bikarhêner veşêrin, tiştek ku "tenê dixebite" pêşkêşî wî bikin, me kir amûra sazkirin û nûvekirina werfê veqetandî Ye . Hûn tenê hewce ne ku jimara berdanê û kanala aramiyê ya ku hûn amade ne bikar bînin diyar bikin, û multiwerf dê kontrol bike ka guhertoyek nû li ser kanalê heye û ger hewce bike wê dakêşîne.
Di menuya hilbijartina guhertoya malperê de, guhertoyên herî dawî yên werf di her kanalê de hene. Bi xwerû, bi navnîşan guhertoya kanala herî stabîl ji bo serbestberdana herî paşîn vedibe - ew jî ji hêla motorên lêgerînê ve tête navnîş kirin. Belgekirina kanalê li navnîşanên cihê hene (mînak, ji bo serbestberdana beta 1.0).
Bi tevahî, malperê guhertoyên jêrîn hene:
- root (ji hêla xwerû vedike),
- ji bo her kanalek nûvekirina çalak a her berdanê (mînak, ).
Ji bo afirandina guhertoyek taybetî ya malperek, bi gelemperî, berhevkirina wê bi karanîna bes e bi xebitandina di pelrêça /docs fermana têkildar depoya werf (jekyll build), piştî guheztina tagê Git ya guhertoya pêwîst.
Ew tenê dimîne ku lê zêde bike ku:
- amûr bixwe (werf) ji bo komkirinê tê bikaranîn;
- Pêvajoyên CI/CD li ser bingeha GitLab CI têne çêkirin;
- û ev hemî, bê guman, li Kubernetes dimeşe.
erkên
Naha werin em peywiran formul bikin ku hemî taybetmendiyên diyarkirî li ber çavan digirin:
- Piştî guhertina guhertoya werf li ser her kanalek nûvekirinê belgeyên li ser malperê divê bixweber bêne nûve kirin.
- Ji bo pêşveçûnê hûn hewce ne ku carinan carinan bikin guhertoyên pêşdîtinê yên malperê bibînin.
Pêdivî ye ku malper piştî guhertoya li ser her kanalek ji tagên Git-ê yên têkildar ji nû ve were berhev kirin, lê di pêvajoya avakirina wêneyê de em ê taybetmendiyên jêrîn bistînin:
- Ji ber ku navnîşa guhertoyên li ser kanalan diguhere, tenê hewce ye ku ji bo kanalên ku guhertoya wan guherî belge ji nû ve were çêkirin. Jixwe, ji nû ve avakirina her tiştî ne pir xweş e.
- Dibe ku komek kanalên ji bo serbestberdanê biguhere. Mînakî, di demek wextê de, dibe ku guhertoyek li ser kanalan ji serbestberdana zû-gihîştina 1.1-a domdartir tune be, lê bi demê re ew ê xuya bibin - di vê rewşê de, ma hûn ne hewce ne ku meclîsê bi destan biguhezînin?
Ew dizane ku civîn bi guhertina daneyên derveyî ve girêdayî ye.
Реализация
Hilbijartina Nêzîktêdayînekê
Alternatîf, hûn dikarin her guhertoya pêwîst wekî podek cihê di Kubernetes de bimeşînin. Ev vebijark tê wateya hejmareke mezintir ji hêmanên di komê de, ku dê bi zêdebûna hejmara berdanên werfê yên domdar re mezin bibin. Û ev, di encamê de, lênihêrîna tevlihevtir tê wateya: her guhertoyek servera xwe ya HTTP heye, û bi barek piçûk. Bê guman, ev jî lêçûnên çavkaniyê yên mezintir vedigire.
Me heman rê girt komkirina hemî guhertoyên pêwîst di yek wêneyê de. Statîkên berhevkirî yên hemî guhertoyên malperê di konteynirek bi NGINX-ê de cih digirin, û seyrûsefera Dabeşkirina têkildar bi navgîniya NGINX-ê tê. Avahiyek hêsan - serîlêdanek bêdewlet - dihêle hûn bi karanîna Kubernetes bixwe bi hêsanî Dabeşkirinê (li gorî barkirinê ve girêdayî) mezin bikin.
Ji bo ku bêtir rast be, em du wêneyan berhev dikin: yek ji bo çerxa hilberînê, ya duyemîn jî ji bo çerxa dev ê din e. Wêneyê pêvek tenê li ser çerxa dev bi hev re bi ya sereke re tê bikar anîn (destpêkirin) û guhertoya malperê ji commit vekolînê vedihewîne, û rêveçûna di navbera wan de bi karanîna çavkaniyên Ingress ve tête kirin.
werf vs git clone û berhemên
Wekî ku berê jî behs kir, ji bo ku hûn ji bo guhertoyek taybetî ya belgeyê statîkên malperê biafirînin, hûn hewce ne ku bi guheztina nîşana depoya guncan ava bikin. Di heman demê de hûn dikarin vê yekê bi klonkirina depoyê her gava ku hûn ava dikin bikin, ji navnîşek etîketên guncan hilbijêrin. Lêbelê, ev operasyonek pir çavkanî ye û ji bilî vê, pêdivî bi nivîsandina rêwerzên ne-tewre heye... Dezavantajek din a cidî ew e ku bi vê nêzîkbûnê re çu rê tune ku di dema berhevkirinê de tiştek were cache kirin.
Di vir de werf bi xwe tê alîkariya me, pêk tîne caching jîr û destûrê dide te ku bikar bîne . Bikaranîna werf ji bo lê zêdekirina kodê ji depoyê dê bi girîngî avahî bileztir bike, ji ber werf bi eslê xwe depoyê carekê klon dike û dûv re jî darve dike bi tenê fetch heke pêwîst be. Digel vê yekê, dema ku daneyên ji depoyê zêde dikin, em dikarin tenê pelrêçayên pêwîst hilbijêrin (di rewşa me de ev pelrêça ye docs), ku dê mîqdara daneyên zêdekirî bi girîngî kêm bike.
Ji ber ku Jekyll amûrek e ku ji bo berhevkirina daneyên statîk hatî çêkirin û di wêneya paşîn de ne hewce ye, ew ê mentiqî be ku meriv tê de berhev bike. , û di nav wêneya dawî de tenê encama berhevkirinê derxînin.
Em werf.yaml dinivîsin
Ji ber vê yekê, me biryar da ku em ê her guhertoyek di hunerek werfek cihê de berhev bikin. Lêbelê em em nizanin dê di dema kombûnê de çend ji van berheman hebin, ji ber vê yekê em nikanin mîhengek avahîsaziyek sabît binivîsin (bi hişkî, em hîn jî dikarin, lê ew ê bi tevahî bandor nebe).
werf destûrê dide te ku bikar bîne di pelê veavakirina we de (werf.yaml), û ev yek gengaz dike di firînê de konfigurasyonê biafirîne li gorî daneyên derveyî (ya ku hûn hewce ne!). Daneyên derveyî di doza me de agahdariya di derbarê guherto û serbestberdanê de ye, ku li ser bingeha wan em hêjmara pêdivî ya huneran berhev dikin û di encamê de em du wêneyan digirin: werf-doc и werf-dev ku li ser çerxên cûda bixebitin.
Daneyên derve di nav guhêrbarên hawîrdorê re derbas dibin. Li vir pêkhateya wan ev e:
-
RELEASES- xêzek bi navnîşek serbestberdanê û guhertoya heyî ya werfê ya têkildar, di forma navnîşek nirxan a cihê-veqetandî ya di formatê de<НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>... Mînak:1.0%v1.0.4-beta.20 -
CHANNELS- xêzek bi navnîşek kanalan û guhertoya heyî ya werfê ya têkildar, di forma navnîşek nirxan a cihê-veqetandî ya di formatê de<КАНАЛ>%<НОМЕР_ВЕРСИИ>... Mînak:1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22 -
ROOT_VERSION- Guhertoya serbestberdana werf ku ji hêla xwerû li ser malperê ve were xuyang kirin (her gav ne hewce ye ku belgeyan bi jimareya herî bilind a berdanê were xuyang kirin). Mînak:v1.0.4-beta.20 -
REVIEW_SHA- hash commita vekolînê ya ku hûn hewce ne ku guhertoya ji bo lûleya ceribandinê ava bikin.
Van guhêrbar dê di lûleya GitLab CI de bêne dagirtin, û bi rastî li jêr çawa hatî nivîsandin.
Berî her tiştî, ji bo rehetiyê, em di nav de diyar dikin werf.yaml Biçe guhêrbarên şablonê, ji guhêrbarên jîngehê nirxan bidin wan:
{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }} Danasîna hunerê ji bo berhevkirina guhertoya statîk a malperê bi gelemperî ji bo hemî dozên ku em hewce ne yek e (tevî çêkirina guhertoya root, û her weha guhertoya ji bo çerxa dev). Ji ber vê yekê, em ê wê bi karanîna fonksiyonê veguhezînin blokek cihê define - ji bo karanîna paşerojê ji nû ve include. Em ê argumanên jêrîn ji şablonê re derbas bikin:
-
Version- Guhertoya çêkirî (navê tagê); -
Channel- Navê kanala nûvekirinê ya ku jêhatî tê çêkirin; -
Commit- commit hash, heke artifact ji bo komîteya vekolînê hatî çêkirin; - hevgirêk.
Artifact Şablon Danasîna
{{- 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 }} Navê hunerê divê yekta be. Em dikarin vê yekê bi dest bixin, mînakî, bi lê zêdekirina navê kanalê (nirxa guhêrbar .Channel) wekî paşgira navê berhemê: artifact: doc-{{ .Channel }}. Lê hûn hewce ne ku fêm bikin ku dema ku hûn ji huneran vediguhezînin, hûn ê hewce bikin ku heman navan binav bikin.
Dema ku hunerek tê ravekirin, taybetmendiya werfê ya jêrîn tê bikar anîn: . Mountkirina pelrêça karûbarê destnîşan dike build_dir destûrê dide te ku cache Jekyll-ê di navbera gerîdeyên boriyê de hilîne, ku bi girîngî ji nû ve berhevkirinê lez dike.
Dibe ku we karanîna pelê jî dîtibe releases.yml pelek YAML ye ku daneyên berdanê jê tê xwestin (artifactek ku di dema darvekirina boriyekê de tête wergirtin). Di dema berhevkirina malperê de pêdivî ye, lê di çarçoveya gotarê de ew ji me re balkêş e ji ber ku ew bi rewşa wê ve girêdayî ye. veavakirina tenê yek hunerî - hunerek guhertoya root ya malperê (ew di hunerên din de ne hewce ye).
Ev bi karanîna şertê şertê pêk tê if Herin şablon û sêwiranan {{ $Root.Files.Get "releases.yml" | sha256sum }} di qonaxê de . Ew bi vî rengî dixebite: dema ku hunerek ji bo guhertoya root ava dike (guhêrbar .Channel wekhev e root) pelê haş releases.yml bandor li îmzeya tevahiya qonaxê dike, ji ber ku ew beşek ji navê peywira Ansible (parametre name). Bi vî awayî, dema ku guhertin dilşad dosî releases.yml hunera têkildar dê ji nû ve were berhev kirin.
Ji kerema xwe re jî bala xwe bidin xebata bi depoyek derveyî. Di wêneyê de hunerek ji , tenê pelrêç tê zêdekirin /docs, û li gorî pîvanên derbasbûyî ve girêdayî ye, daneyên tag an pejirandî ya pêwîst tavilê tê zêdekirin.
Ji bo ku em şablona hunerî bikar bînin da ku ravekirinek hunerî ya guhertoyên veguheztî yên kanal û belavokan çêbikin, em li ser guhêrbar lûkek organîze dikin. .WerfVersions в werf.yaml:
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}} Bo lûp dê gelek berheman çêbike (em hêvî dikin ku wusa), pêdivî ye ku meriv veqetandina di navbera wan de bihesibîne - rêzik --- (Ji bo bêtir agahdarî li ser hevoksaziya pelê veavakirinê, binêre ). Wekî ku berê hate diyar kirin, dema ku şablonek di lûkê de bang dikin, em pîvanên guhertoyê, URL û naveroka root derbas dikin.
Bi heman rengî, lê bêyî dorpêk, em ji şablonê hunerî re ji bo "halên taybetî" dibêjin: ji bo guhertoya root, û her weha guhertoya ji commita vekolînê:
{{ 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 }} Ji kerema xwe bala xwe bidin ku hunera ji bo vekolînê tenê heke guhêrbar were danîn dê were çêkirin .WerfReviewCommit.
Berhem amade ne - dem e ku meriv dest bi importkirinê bike!
Wêneyê paşîn, ku ji bo xebitandina Kubernetes-ê hatî çêkirin, NGINXek birêkûpêk e ku pelê veavakirina serverê lê hatî zêdekirin. nginx.conf û statîk ji berhemên. Ji bilî hunera guhertoya root ya malperê, pêdivî ye ku em lûkê li ser guhêrbar dubare bikin .WerfVersions ji bo veguheztina hunerên kanalê û guhertoyên berdan + qaîdeya navkirina hunerê ku me berê pejirandibû bişopînin. Ji ber ku her artifact guhertoyên malperê ji bo du zimanan diparêze, em wan vediguhezînin cîhên ku ji hêla veavakirinê ve hatine peyda kirin.
Danasîna wêneya dawî 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 -}}Wêneya pêvek, ku bi ya sereke re, li ser çerxa dev-ê hatî destpêkirin, tenê du guhertoyên malperê dihewîne: guhertoya ji komîta vekolînê û guhertoya bingehîn a malperê (malbatên gelemperî hene û, ger tê bîra we , daneyan berdan). Bi vî rengî, wêneyê zêde tenê di beşa importê de (û, bê guman, di nav de) ji ya sereke cûda dibe:
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 }} Wekî ku li jor hate destnîşan kirin, hunera ji bo peywira vekolînê tenê dema ku guhêrbara jîngehê ya sazkirî were xebitandin dê were afirandin. REVIEW_SHA. Heke guhêrbarek jîngehê tune be, dê gengaz be ku wêneya werf-dev bi tevahî neyê çêkirin REVIEW_SHA, lê ji bo ku Wêneyên Docker ên di werf de ji bo wêneya werf-dev xebitîn, em ê bihêlin ku ew tenê bi hunera guhertoya root re were çêkirin (ew her weha jixwe hatî çêkirin), da ku avahiya boriyê hêsan bike.
Meclîs amade ye! Ka em biçin ser CI/CD û nuwazeyên girîng.
Pipeline di GitLab CI de û taybetmendiyên avakirina dînamîk
Dema ku avakirinê dimeşîne divê em guhêrbarên jîngehê yên ku tê de têne bikar anîn saz bikin werf.yaml. Ev ji guhêrbara REVIEW_SHA re derbas nabe, ya ku em ê dema gazîkirina lûleyê ji qulika GitHub saz bikin.
Em ê di skrîptek Bash de daneyên derveyî yên pêwîst biafirînin generate_artifacts, ku dê du berhemên lûleya GitLab çêbike:
- pelê
releases.ymlbi daneyên berdanê, - pelê
common_envs.sh, guhêrbarên hawirdorê yên ku werin derxistin vedihewîne.
Naveroka pelê generate_artifacts hûn ê di me de bibînin . Wergirtina daneyan bi xwe ne mijara gotarê ye, lê pel e common_envs.sh ji bo me girîng e, ji ber karê werfê pê ve girêdayî ye. Mînakek naveroka wê:
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' Hûn dikarin encamek nivîsarek wusa bikar bînin, mînakî, fonksiyona Bash bikar bînin source.
Niha beşa kêfê tê. Ji bo ku hem çêkirin û hem jî danîna serîlêdanê rast bixebite, pêdivî ye ku meriv pê ewle bibe werf.yaml bû hemen kêmtirî di nav yek boriyê de. Ger ev merc pêk neyê, wê demê îmzeyên qonaxên ku werf di dema kombûnê de û wek nimûne, bicihkirinê dihejmêre, dê cûda bin. Ev ê bibe sedema xeletiyek bicîhkirinê, ji ber ku ... wêneya ku ji bo bicîhkirinê hewce ye dê winda bibe.
Bi gotinek din, heke di dema berhevkirina wêneya malperê de agahdariya der barê berdan û guhertoyan de yek be, û di dema bicîhkirinê de guhertoyek nû were berdan û guhêrbarên hawîrdorê xwediyê nirxên cûda bin, wê hingê veqetandin dê bi xeletiyek têk bibe: her tiştî, hunera guhertoya nû hîn nehatiye çêkirin.
Ger nifş werf.yaml bi daneyên derveyî ve girêdayî ye (mînakî, navnîşek guhertoyên heyî, wekî di doza me de), wê hingê pêdivî ye ku berhevok û nirxên van daneyan di hundurê boriyê de bêne tomar kirin. Ev bi taybetî girîng e ku heke pîvanên derveyî pir caran biguherînin.
Em ê bikin daneyên derveyî bistînin û tomar bikin di qonaxa yekem a boriyê de li GitLab (Prebuild) û wan di formê de bêtir bişînin Artifakta GitLab CI. Ev ê bihêle ku hûn bi heman veavakirinê re karên boriyê (avakirin, danîn, paqijkirin) bimeşînin û ji nû ve bidin destpêkirin. werf.yaml.
Naveroka qonaxê Prebuild dosî .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 weekPiştî ku hûn daneyên derveyî yên di hunerê de girtin, hûn dikarin bi karanîna qonaxên standard boriyê yên GitLab CI ava bikin û bicîh bikin: Avakirin û Damezrandin. Em xêza boriyê bixwe bi karanîna çengên ji depoya werf GitHub (ango gava ku di depoya GitHub de guhertin çêbibin) dest pê dikin. Daneyên ji bo wan di beşê de di taybetmendiyên projeya GitLab de têne dîtin Mîhengên CI/CD -> Pelên boriyê, û paşê di GitHub de Webhook-a têkildar biafirînin (Mîheng -> Webhooks).
Qonaxa avakirinê dê wiha xuya bike:
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 dê du huneran ji qonaxê li qonaxa çêkirinê zêde bike Prebuild, ji ber vê yekê em guhêrbaran bi daneyên têketina amadekirî bi karanîna çêkirinê hinarde dikin source common_envs.sh. Em di hemî rewşan de dest bi qonaxa avakirinê dikin, ji bilî destpêkirina boriyê li gorî bernameyek. Li gorî nexşeyê, em ê ji bo paqijkirinê boriyek bimeşînin - di vê rewşê de ne hewce ye ku meclîsê bikin.
Di qonaxa bicîhkirinê de, em ê du peywiran diyar bikin - ji hev cuda ji bo bicihkirina berbi hilberîn û çerxên dev, bi karanîna şablonek 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 Karên di bingeh de tenê di destnîşankirina çarçoweya komê de ku werf divê tê de bicîh bike (WERF_KUBE_CONTEXT), û danîna guhêrbarên hawîrdora loop (environment.name и environment.url), ku paşê di şablonên nexşeya Helm de têne bikar anîn. Em ê naveroka şablonan nedin, ji ber ku ... ji bo mijara di pirsê de tiştek balkêş tune, lê hûn dikarin wan tê de bibînin .
destana dawî
Ji ber ku guhertoyên werf pir caran têne berdan, wêneyên nû dê pir caran werin çêkirin, û Docker Registry dê bi domdarî mezin bibe. Ji ber vê yekê, pêdivî ye ku meriv li ser bingeha polîtîkayan paqijkirina wêneya otomatîkî mîheng bike. Pir hêsan e ku meriv bike.
Ji bo bicîhkirinê hûn ê hewce bibin:
- Pêvekek paqijkirinê lê zêde bike
.gitlab-ci.yml; - Pêkanîna periyodîk a peywirek paqijkirinê zêde bikin;
- Guherbarek jîngehê bi nîşanek gihîştina nivîsandinê saz bikin.
Zêdekirina qonaxek paqijkirinê .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
Me berê hema hema hemî ev hinekî bilindtir dîtiye - tenê ji bo paqijkirina wê hûn hewce ne ku hûn pêşî bi tokenek ku mafê jêbirina wêneyan di Registry Docker de heye têkevin qeyda Docker (nîşaneya peywirê ya GitLab CI-ê ku bixweber hatî derxistin nayê xwedî mafên wiha ne). Pêdivî ye ku nîşanek berê li GitLab were afirandin û nirxa wê divê di guhêrbara jîngehê de were destnîşan kirin WERF_IMAGES_CLEANUP_PASSWORD proje (Mîhengên CI/CD -> Guherbar).
Zêdekirina peywirek paqijkirinê bi nexşeya pêwîst re tê kirin CI/CD ->
Schedule.
Ew e: projeyek di Docker Registry de dê êdî bi domdarî ji wêneyên neyên bikar anîn mezin bibe.
Di dawiya beşa pratîkî de, bila ez ji we re bi bîr bînim ku navnîşên tevahî ji gotarê tê de hene :
- ;
- .
Di encama
- Me avahiyek meclîsê ya mentiqî wergirt: her guhertoyek yek huner.
- Civîn gerdûnî ye û dema ku guhertoyên nû yên werf têne berdan ne hewceyî guheztinên destan e: belgeyên li ser malperê bixweber têne nûve kirin.
- Du wêne ji bo konturên cûda têne berhev kirin.
- Ew zû dixebite, ji ber Caching bi qasî ku gengaz tê bikar anîn - gava ku guhertoyek nû ya werf tê berdan an çîçekek GitHub ji bo vekolînek tê gotin, tenê hunera têkildar bi guhertoya guhertî re ji nû ve tê çêkirin.
- Ne hewce ye ku hûn li ser jêbirina wêneyên neyên bikar anîn bifikirin: Paqijkirina li gorî polîtîkayên werf dê Registry Docker bi rêkûpêk bigire.
vebiguherin
- Bikaranîna werf dihêle ku meclîs zû bixebite ji ber cachkirina hem meclîsê bixwe û hem jî ji cachkirinê dema ku bi depoyên derveyî re dixebite.
- Karkirina bi depoyên Git-ê yên derveyî re hewcedariya klonkirina tevahiya depoyê her carê an jî çerxa bi mantiqa xweşbîniya xapînok ji nû ve îcad dike ji holê radike. werf cache bikar tîne û klonkirinê tenê carekê dike, û paşê bikar tîne
fetchû tenê dema ku pêwîst be. - Qabiliyeta bikaranîna şablonên Go di pelê veavakirina çêkirinê de
werf.yamldestûrê dide te ku hûn meclîsek ku encama wê bi daneyên derveyî ve girêdayî ye diyar bikin. - Bikaranîna mount di werf de berhevkirina berheman bi girîngî bileztir dike - ji ber cache, ku ji hemî lûleyan re hevpar e.
- werf mîhengkirina paqijkirinê hêsan dike, ku bi taybetî di dema avakirina dînamîkî de girîng e.
PS
Li ser bloga me jî bixwînin:
- «»;
- «»;
- «»;
- «".
Source: www.habr.com
