Biz GitOps alətimiz haqqında bir neçə dəfə məlumat vermişik , amma bu dəfə layihənin öz sənədləri ilə veb saytın qurulması təcrübəmizlə bölüşmək istərdik — (onun rus dilindəki versiyası — ). Bu adi statik bir saytdır, lakin onun qurulması dinamik artefaktlar istifadə edilməsi baxımından maraqlıdır.
Saytın strukturu üzrə incələməyə, hər versiya üçün ümumi menyunun yaradılması, buraxılış məlumatlarının səhifələri və s. — girməyəcəyik. Bunun əvəzinə, dinamik qurma ilə bağlı məsələlərə və bir az CI/CD-yə aid proseslərə fokuslanacağıq.
Giriş: sayt necə işləyir
İlk növbədə, werf sənədləri onun kodu ilə birgə saxlanılır. Bu, inkişaf üçün müəyyən tələblər ortaya qoyur ki, bunlar ümumi olaraq bu məqalənin çərçivələrini aşır, amma ən azı deyə bilərik ki:
- Yeni werf funksiyaları sənəd olmadan təqdim edilməməlidir və əksinə, sənəddəki hər hansı bir dəyişiklik yeni werf versiyasının çıxmasını nəzərdə tutur;
- Proyektin inkişaf prosesi xeyli intensivdir: yeni versiyalar gündə bir neçə dəfə çıxa bilər;
- Saytı yeni sənəd versiyası ilə əllə yerləşdirməkdən hər halda yorucu olacağını qeyd etmək olar;
- Layihədə semantik yanaşma qəbul edilmişdir , 5 stabillik kanalı ilə. Buraxılış prosesi versiyaların stabilliyin artırılması məqsədilə ardıcıllıqla kanallardan keçməsini nəzərdə tutur: alpha-dan rock-solid-ə;
- Saytda rus dilində bir versiya var ki, bu da „yaşayır və inkişaf edir“ (yəni məzmunu yenilənir) əsas (yəni ingilis dilindəki) versiya ilə параллельно.
İstifadəçiyə bu „daxili mətbəxi“ gizlətmək üçün, ona „sadəcə işləyən“ bir şey təklif edərək, biz werf-in quraşdırılması və yenilənməsi üçün ayrıca bir alət — bu yaratdıq. İstədiyiniz buraxılış nömrəsini və stabillik kanalını göstərmək kifayətdir ki, multiwerf yeni versiyanın olub-olmadığını yoxlayıb, lazım olduqda onu yükləyəcək.
Saytdakı versiya seçim menyusunda hər kanal üzrə son werf versiyaları mövcuddur. Varsayılan olaraq, ünvan ən son buraxılış üçün ən stabil kanalın versiyasını açır — bu da axtarış mühərrikləri tərəfindən indekslənir. Kanal üçün sənəd ayrı ünvanlarla (məsələn, 1.0 beta buraxılışı üçün) mövcuddur.
Nəticə olaraq, saytda aşağıdakı versiyalar var:
- köklü (varsayılan olaraq açılır),
- hər buraxılışın hər aktiv yeniləmə kanalı üçün (məsələn, ).
Saytın konkret versiyasını yaratmaq üçün, ümumi halda, onun tərtib edilməsini təmin etmək lazımdır , werf repositoriyasında müvafiq əmri ( /docs jekyll build) yerinə yetirərək, lazım olan versiyanın Git etiketinə keçid etməklə.Sadəcə olaraq, əlavə etmək qalır ki:
tərtibat üçün öz utilitindən (werf) istifadə olunur;
- quraşdırma üçün öz utilitindən (werf) istifadə olunur;
- CI/CD prosesləri GitLab CI əsasında qurulub;
- və bütün bunlar, əlbəttə ki, Kubernetes-də işləyir.
Vəzifələr
İndi bütün təsvir olunan spesifikaları nəzərə alaraq tapşırıqları müəyyənləşdirək:
- werf versiyası hər hansı bir yeniləmə kanalında dəyişdikdən sonra saytdakı sənədləşmə avtomatik olaraq yenilənməlidir.
- İnkişaf üçün bəzən saytın əvvəlki versiyalarını baxmaq imkanı olmalıdır.
Saytı yenidən kompilyasiya etmək, müvafiq Git etiketi üzrə versiya dəyişdikdən sonra həyata keçirilməlidir, lakin görüntü yaradılması prosesi zamanı aşağıdakı xüsusiyyətləri əldə edəcəyik:
- Versiya listi kanallarda dəyişdikcə, yalnız versiyasının dəyişdiyi kanallar üçün sənədləşməni yenidən kompilyasiya etmək lazımdır. Axı, hər şeyi yenidən toplamaq çox gözəl deyil.
- Buradakı buraxılış kanalları dəstinin özü də dəyişə bilər. Məsələn, müəyyən bir zamanda, bəlkə də, early-access 1.1 versiyası üçün daha sabit kanallarda versiya olmayacaq, amma zamanla onlar ortaya çıxacaq - əlbəttə ki, bu halda toplama əllə dəyişməməlidir?
Yani toplama dəyişən xarici məlumatlardan asılıdır.
Həyata keçirmə
Yanaşma seçimi
Bir variant olaraq, hər lazım olan versiyanı Kubernetes-də ayrı pod kimi işə salmaq mümkündür. Bu variant, etibarlı werf buraxılışlarının sayı artdıqca, daha çox obyektin klasterdə olmasını nəzərdə tutur. Bu, müvafiq olaraq, daha mürəkkəb xidmət tələb edir: hər bir versiya üçün öz HTTP serveri yaranır, bununla yanaşı, yüngül yük vardır. Əlbəttə ki, bu, daha çox resurs xərclənməsinə gətirib çıxarır.
Biz bu yolla getdik bütün lazım olan versiyaları bir görüntüdə toplamaq. Bütün versiyaların tərtib olunmuş statikası NGINX ilə konteynerdə yerləşir, müvafiq Yerləşdirməyə trafikin yönləndirilməsi NGINX Ingress vasitəsilə həyata keçirilir. Sadə struktur - state-less proqram - Yerləşdirilməni (yükə görə) Kubernetes-in öz vasitələri ilə asanlıqla genişləndirməyə imkan verir.
Daha dəqiq desək, biz iki görüntü toplayırıq: biri - istehsal konturu üçün, digəri - dev konturu üçün əlavə bir görüntü. Əlavə görüntü yalnız əsasla birlikdə dev konturunda istifadə olunur (işə salınır) və review-şərhindən sayt versiyasını ehtiva edir, onların arasında yönləndirmə Ingress resursları vasitəsilə həyata keçirilir.
werf vs git clone və artefaktlar
Artıq qeyd edildiyi kimi, müəyyən bir sənəd versiyası üçün saytın statikasını yaratmaq üçün uyğun depozitorun etiketi üzrə keçid edərək toplama icra edilməlidir. Eyni zamanda, hər dəfə toplayarkən depozitoru klonlamaq və uyğun etiketləri siyahıdan seçmək də olardı. Lakin bu, olduqca resurs tələb edən bir əməliyyaddır və əlavə olaraq qeyri-adi təlimatların yazılmasını tələb edir... Bu yanaşmanın başqa bir ciddi mənfi cəhəti - toplama zamanı bir şeyi ön yaddaşa almaq imkanı olmamasıdır.
Burada bizə werf utilitəsi kömək edir, hansı ki, ağıllı ön yaddaşlama təmin edir və istifadə etməyə imkan tanıyır . Werf-dan depozitorun kodunun əlavə edilməsi, werf-in bir dəfə depozitini klonladığı üçün prosesi əhəmiyyətli dərəcədə sürətləndirir, sonra isə kontrol plitəsi üçün vermək istəmədim. Buna görə pi-control düyünündən avtomatik əlavə edilən 'taint'ı sökmək üçün aşağıdakı əmri yerinə yetirdim: fetch lazım olduğu halda. Depozitdən məlumat əlavə edərkən yalnız lazım olan qovluqları seçə bilərik (bu halda bu kataloq docs), bu da əlavə edilən məlumatların miqdarını əhəmiyyətli dərəcədə azaldır.
Jekyll-in statik tərtibat üçün nəzərdə tutulmuş bir alət olması və son görüntüdə lazım olmaması səbəbi ilə, mümkün olan daha məqsədəuyğun olan tərtibatı , son görüntüyə yalnız tərtibatın nəticəsini idxal etmək.
werf.yaml yazırıq
Beləliklə, hər versiyanı fərqli werf artefaktında tərtib edəcəyimizə qərar verdik. Ancaq biz neçə artefaktın yığılacağını bilmirik, buna görə də sabit tərtibat konfiqurasiyası yaza bilmirik (həqiqətən yaza bilərik, amma bu o qədər də effektiv olmayacaq).
werf, konfiqurasiya faylında (werf.yaml) istifadə etməyə imkan verir, bu da konfini «anında» yaratmağa xarici verilərə əsasən imkan tanıyır (bu, lazım olan!). Bizim vəziyyətimizdə xarici verilər, lazım olan artefaktların sayını müvafiq versiyalarda və buraxılışlarda yığırıq və iki görüntü əldə edirik: werf-doc və werf-dev fərqli konteynerlərdə yükləmək üçün.
Xarici verilər mühit dəyişənləri vasitəsilə ötürülür. Onların tərkibi belədir:
-
RELEASES— buraxılışların siyahısı və müvafiq werf-in cari versiyası, boşluqla ayrılmış dəyərlərdən ibarətdır%. Nümunə:1.0%v1.0.4-beta.20 -
CHANNELS— kanalların siyahısı və müvafiq werf-in cari versiyası, boşluqla ayrılmış dəyərlərdən ibarətdir%. Nümunə:1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22 -
ROOT_VERSION— vebsaytda default olaraq göstəriləcək werf buraxılış versiyası (həmişə ən yüksək buraxılış nömrəsini göstərmək lazım deyil). Nümunə:v1.0.4-beta.20 -
REVIEW_SHA— test konturuna versiya yığmaq üçün lazım olan review commit-in hash'i.
Bu dəyişənlər GitLab CI pipeline-də doldurulacaq, necə olduğu aşağıda qeyd olunub.
İlk növbədə, rahatlıq üçün, werf.yaml Go şablonları üçün dəyişənləri müəyyən edərək, mühit dəyişənlərindən dəyərləri təyin edəcəyik:
{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }} Vebsaytın statik versiyasını tərtib etmək üçün artefaktın təsviri bütün lazım olan hallarda demək olar ki, eynidir (həmçinin kök versiyanın, eləcə də dev konturu üçün versiyanı tərtib edərkən). Ona görə də, bunun üçün ayrıca bir blokda istifadə edərək define - gələcək istifadə üçün include. Şablona aşağıdakı arqumentləri verəcəyik:
-
Yüzde- yaradılacaq versiya (etiket adı); -
Kanala— yenilənmə kanalı adı, artefaktın yaradılması üçün; -
Commit— əgər artefakt review-commit üçün yaradılırsa, commit hash-i; - bağlam.
Artefakt şablonunun təsviri
{{- 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: "Asılılıqları Yükle"
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 }} Artefaktın adı unikal olmalıdır. Bunu, məsələn, kanalın adını (dəyişən dəyərin .Channel) artefaktın adının əlavəsi kimi əlavə etməklə əldə edə bilərik: artifact: doc-{{ .Channel }}. Ancaq anlamalıyıq ki, artefaktlardan idxal edilərkən eyni adlarla müraciət etmək lazım olacaq.
Artefaktın təsvirində werf-in təqdim etdiyi bir imkan, . İdarəetmə direktoriyası ilə montaj build_dir Jekyll-in keçidini saxlayaraq pipeline-lar arasında sürətlənməyə imkan verir, bu yenidənqurma prosesini xeyli sürətləndirir.
Bu qədər siz, yəqin ki, releases.yml — bu, YAML formatında olan bir fayldır, pipeline icra edilərkən əldə edilir. O, saytın tərtibi zamanı istifadə olunur, lakin məqalənin kontekstində bizi maraqlandırır ki, onun vəziyyəti yalnız bir artefaktın — kök versiyası saytının artefaktı (digər artefaktlarda lazım deyil) yenidən qurulması üzərində təsir edir.
Bu, Bütün kubelet’lərdə Go şablonları və {{ $Root.Files.Get "releases.yml" | sha256sum }} tətbiqinin . Bu, belə işləyir: kök versiyasının artefaktı yaradıldığı zaman (dəyişən .Channel bərabərdir root) faylın hash-i bütün mərhələnin imzasına təsir edir, çünki bu, Ansible tapşırığının adının bir hissəsidir (parametr releases.yml ). Beləliklə, Lisenziya, inkişaf etdiricilər və versiya idarəetmə sisteminin məlumatlarının mövcudluğuməzmun dəyişdikdə, müvafiq artefakt yenidən qurulacaq. faylı releases.yml müvafiq artefakt yenidən qurulacaq.
Eyni zamanda xarici depo ile çalışmanıza da diqqət yetirin. Artezaktın şəkli yalnız bir kataloq əlavə edilir /docsvə verilmiş parametrlərdən asılı olaraq, yalnız lazımi etiketin və ya review-committerin məlumatları əlavə edilir.
Verilmiş kanalların versiyaları üçün artefakt təsvirini yaratmaq üçün artefakt şablonundan istifadə edərək, dəyişərli üzrə döngü təşkil edəcəyik .WerfVersions daxilindədir. werf.yaml:
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}} Döngü bir neçə artefakt yaradacağı üçün (bunun olmasını ümid edirik), aralarındakı ayrıcı olan ardıcıllığı nəzərə almaq lazımdır --- (konfiqurasiya faylının sintaksisi haqqında daha ətraflı məlumat üçün baxın ). Daha əvvəl müəyyən etdiyimiz kimi, döngü içərisində şablonu çağırdığımızda, versiya, URL və kök kontekst параметrlərini ötürürük.
Eynilə, lakin döngü olmadan, xüsusi hallar üçün artefakt şablonunu çağırırıq: kök versiyası və review-committer olan versiya üçü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 }} Diqqət yetirin ki, review-committer üçün artefakt yalnız aşağıda verilmiş dəyişən {{.WerfReviewCommit}} təyin edilmişsə yığılacaq. .WerfReviewCommit.
Artefaktlar hazırdır — idxalatla məşğul olmaq vaxtıdır!
Kubernetes-də işə salmaq üçün nəzərdə tutulan son görüntü adi NGINX-dir, bunun içərisində server konfiqurasiya faylı əlavə edilir nginx.conf və artefaktlardan statikalar. Saytın kök versiyasının artefaktından əlavə, kanalların versiyaları və buraxılışları üçün artefaktların idxali üçün .WerfVersions döngünü təkrarlamalıyıq + daha əvvəl qəbul etdiyimiz artefakt adlandırma qaydasına riayət etməliyik. Hər bir artefakt iki dil üçün sayt versiyalarını saxladığından, bunları konfiqurasiya əsasında nəzərdə tutulan yerlərə idxal edəcəyik.
werf-doc son görüntüsü haqqında təsvir
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 -}}Əlavə görüntü, əsas ilə birlikdə dev-sahəsində işə salınır, yalnız iki sayt versiyasını ehtiva edir: review-committer-dən olan versiya və saytın kök versiyası (orada ümumi resurslar var və, əgər yadımdadırsa, buraxılışlar üzrə məlumatlar). Beləliklə, əlavə görüntü yalnız idxal bölməsi ilə (və əlbəttə ki, adı ilə) əsasdan fərqlənəcəkdir.
şəkil: werf-dev
...
idxal:
- artefakt: doc-root
əlavə et: /app/_main_site
bura: /app/main_site
əvvəl: qurulum
- artefakt: doc-root
əlavə et: /app/_ru_site
bura: /app/ru_site
əvvəl: qurulum
{{- if .WerfReviewCommit }}
- artefakt: doc-review
əlavə et: /app/_main_site
bura: /app/main_site/review
əvvəl: qurulum
- artefakt: doc-review
əlavə et: /app/_ru_site
bura: /app/ru_site/review
əvvəl: qurulum
{{- end }} Yuxarıda qeyd edildiyi kimi, review-commit üçün artefakt yalnızca müəyyən edilmiş ətraf mühit dəyişənləri işə salındıqda yaradıla bilər. REVIEW_SHA. Heç olmasa ətraf mühit dəyişəni yoxdursa, werf-dev obrazını ümumiyyətlə yaratmamaq olardı REVIEW_SHA, amma bunun üçün Docker obrazlarının werf-da werf-dev üçün işləməsi üçün, onu yalnız kök versiyasının artefaktı ilə yığmağı saxlayacağıq (nəticədə o artıq yığılmışdır), pipeline strukturunu sadələşdirmək üçün.
Yığım hazırdır! CI/CD-yə və vacib nüanslara keçirik.
GitLab CI-də pipeline və dinamik yığmanın xüsusiyyətləri
Yığımı işə salarkən ətraf mühit dəyişənlərini qurmağımız lazımdır, werf.yamlbu, GitHub-dan pipelineni çağırdığımız zaman qurulacaq REVIEW_SHA dəyişəninə aid deyil.
Lazım olan xarici məlumatların formalaşdırılmasını Bash skriptinə ayıracağıq generate_artifacts, bu, iki GitLab pipeline artefaktını yaradacaq:
- faylımı əlavə etdim
releases.ymlburaxılışlarla bağlı məlumatlarla, - faylımı əlavə etdim
common_envs.sh, ixrac üçün ətraf mühit dəyişənlərini ehtiva edir.
Faylın məzmununu generate_artifacts bizim . Məlumatların əldə edilməsi məqalənin mövzusu deyil, lakin fayl common_envs.sh bizim üçün önəmlidir, çünki werf-in işini məhz ondan asılıdır. Məzmununun nümunəsi:
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' Belə bir skriptin çıxışını, məsələn, Bash funksiyası vasitəsilə istifadə edə bilərsiniz mənbə.
Və indi ən maraqlısı. Həm yığım, həm də tətbiqin yerləşdirilməsi düzgün işləməsi üçün, bu şəkildə olmalıdır ki, werf.yaml eyni ən azı bir pipeline daxilində . Bu şərti yerinə yetirməsək, werf-in yığma və yerləşdirmə zamanı hesabladığı mərhələlərin imzaları fərqli olacaq. Bu, yerləşdirmə səhvini gətirəcək, çünki yerləşdirmə üçün lazımlı olan obraz olmaya bilər.Başqa sözlə, əgər saytın obrazı yığılarkən buraxılış və versiya məlumatları biri olarsa, lakin yerləşdirmə zamanı yeni versiya çıxarsa və ətraf mühit dəyişənləri fərqli dəyərlərə sahib olarsa, yerləşdirmə səhvlə nəticələnəcək: axı yeni versiyanın artefaktı hələ yığılmayıb.
Əgər generasiya
xarici məlumatlardan asılıdırsa (məsələn, aktual versiyalar siyahısı, bizim vəziyyətimizdə olduğu kimi), o zaman bu cür məlumatların tərkibi və dəyərləri pipeline daxilində qeydə alınmalıdır. Bu, xarici parametrlərin tez-tez dəyişdiyi zaman xüsusilə vacibdir. werf.yaml Biz
xarici məlumatları alıb qeydə alacağıq pipeline-in ilk mərhələsində GitLab-da ( Prebuild) və bunları daha sonraGitLab CI artefaktı şəklində ötürəcəyik.. Bu, həm yığımlar, həm də yerləşdirmələr, təmizləmələr üçün eyni konfiqurasiya ilə pipeline işlərini işə salmağa və yenidən işə salmağa imkan verəcək werf.yaml.
Mərhələnin məzmunu ) və bunları daha sonra faylı .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 həftəXarici məlumatları artefaktlarda sabitləşdirərək, GitLab CI-nin standart mərhələlərindən istifadə edərək tikinti və yerləşdirmə icra edə bilərsiniz: Build və Deploy. Biz bu boru xəttini GitHub depozitindən (yəni, GitHub-da depozitdəki dəyişikliklərdə) hücumlarla işə salırıq. Onlar üçün məlumatları GitLab layihəsi xüsusiyyətlərindən götürə bilərsiniz. CI / CD Parametrləri -> Boru xətti tetikleyicilər, sonra GitHub-da müvafiq Webhook yaradacağıq (Tənzimləmələr -> Webhooklar).
Tikinti mərhələsi aşağıdakı kimi görünəcək:
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 tikinti mərhələsinə iki artefakt əlavə edəcək. ) və bunları daha sonra, beləliklə biz dəyişənləri hazırlanmış giriş verilənləri ilə bazaya ixrac edəcəyik. source common_envs.sh. Tikinti mərhələsini, boru xəttini cədvəl üzrə işə salmaqdan başqa, hər bir halda icra edirik. Cədvəl üzrə biz təmizləmə boru xəttini işə salacağıq - bu halda tikinti aparmaq lazım deyil.
Yerləşdirmə mərhələsində iki tapşırıq müstəqil olaraq istehsal və dev mühitləri üçün qeyd ediləcək, YAML şablonundan istifadə edərək:
.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
Yerləşdirmə istehsala:
<<: *base_deploy
variables:
WERF_KUBE_CONTEXT: prod
environment:
name: production
url: werf.io
only:
refs:
- master
except:
variables:
- $REVIEW_SHA
refs:
- schedules
Yerləşdirmə Test:
<<: *base_deploy
variables:
WERF_KUBE_CONTEXT: dev
environment:
name: test
url: werf.test.flant.com
except:
refs:
- schedules
only:
variables:
- $REVIEW_SHA Tapşırıqlar əslində yalnız werf-in yerləşdirmə aparmalı olduğu klaster kontekstini göstərməkdən ibarətdir (WERF_KUBE_CONTEXT), və kontur mühitinin dəyişənlərini (environment.name və environment.url) müəyyən etməkdir, bunlar daha sonra Helm chart şablonlarında istifadə olunur. Şablonların içeriğini gətirməyəcəyik, çünki burada nəzərdən keçirilən mövzu üçün heç bir maraqlı şey yoxdur, amma onları .
Son toxunuş
Çünki werf versiyaları tez-tez çıxır, yeni görüntülər də tez-tez yaradılacaq və Docker Registry daim artacaq. Buna görə, mütləq görüntülərin siyasətlər üzrə avtomatik təmizlənməsini ayarlamaq lazımdır. Bunu etmək çox asandır.
Bunun həyata keçirilməsi üçün lazımdır:
- Təmizləmə mərhələsini əlavə edin
.gitlab-ci.yml; - Təmizləmə işinin müntəzəm icrasını əlavə edin;
- Yazma üçün giriş tokeni ilə mühit dəyişənini ayarlayın.
Təmizləmə mərhələsini əlavə edirik .gitlab-ci.yml:
Təmizləmə:
mərhələ: təmizləmə
skript:
- tip multiwerf && . $(multiwerf use 1.0 alpha --as-file)
- tip 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
yalnız:
refs:
- cədvəllər
Demək olar ki, bunların hamısını yuxarıda gördük - yalnız təmizləmə üçün əvvəlcə Docker Registry-yə təsdiq edilməlidir, bu da Docker Registry-də şəkilləri silmək hüququna malik bir token tələb edir (GitLab CI işləri üçün avtomatik verilən token bu hüquqlara malik deyil). Tokenin əvvəlcədən GitLab-da yaradılması və onun dəyərinin mühit dəyişkənində göstərilməsi lazımdır. WERF_IMAGES_CLEANUP_PASSWORD liberated-systemd 261 (CI/CD Parametrləri -> Dəyişkənlər).
Təmizləmə işinin lazımi cədvəllə əlavə edilməsi CI/CD ->
Cədvəllər.
Hər şey: layihə Docker Registry-də bitməmiş şəkillərdən dolayı daima böyüməyəcək.
Praktiki hissənin sonunda xatırlatmaq istəyirəm ki, məqalədən tam siyahılar :
- ;
- .
Nəticə
- Açıq və aydın bir toplama strukturu əldə etdik: bir versiya üçün bir artefakt.
- Toplama universal və yeni werf versiyaları çıxdıqda əllə dəyişiklik etməyi tələb etmir: sənədlər avtomatik olaraq veb saytda yenilənir.
- Fərqli mühitlər üçün iki şəkil yığılır.
- Tez işləyir, çünki maksimum dərəcədə keşdən istifadə olunur - yeni werf versiyası çıxdıqda və ya review-commit üçün GitHub köməyinə çağırıldıqda yalnız dəyişən versiyaya aid müvafiq artefakt yenidən toplanır.
- İstifadəsiz şəkillərin silinməsi barədə düşünməyə ehtiyac yoxdur: werf siyasətləri ilə təmizləmə Docker Registry-də nizamı qoruyacaq.
Sonuçlar
- Werf istifadə edərək, toplama tez keşa, həmçinin xarici repozitoriyalarla işləmə zamanı keşa görə sürətlənir.
- Xarici Git-repozitoriyaları ilə işləmək, repozitoriyanı hər dəfə tamamilə klonlamaq və ya mürəkkəb optimizasiya məntiqini icad etmək zərurətindən azad edir. Werf keşdən istifadə edir və yalnız bir dəfə klonlama edir, daha sonra yalnız zərurət olduqda istifadə edir
fetchvə yalnız lazım olduqda. - Toplamanın konfiqurasiya faylında Go şablonlarının istifadəsi
werf.yamlxarici məlumatlardan asılı olan bir toplama təsvir etməyə imkan verir. - Werf-də montajların istifadəsi artefaktların toplanmasını xeyli sürətləndirir - bütün pipeline üçün ortaq olan keşa görə.
- Werf təmizləməni asanlıqla konfiqurasiya etməyə imkan verir, bu da dinamik toplama zamanı xüsusilə aktualdır.
P.S.
Blogumuzda oxuyun:
- «»;
- «»;
- «»;
- «».
Mənbə: habr.com
