ProHoster > Blog > İdarə > Versiyalaşdırılmış sənəd saytı nümunəsində werf ilə Docker şəkillərinin dinamik qurulması və yerləşdirilməsi

Versiyalaşdırılmış sənəd saytı nümunəsində werf ilə Docker şəkillərinin dinamik qurulması və yerləşdirilməsi

GitOps alətimiz haqqında artıq bir dəfədən çox danışmışıq. werf, və bu dəfə saytı layihənin özünün sənədləri ilə toplamaq təcrübəmizi bölüşmək istərdik - werf.io (onun rus versiyası en.werf.io). Bu, adi statik saytdır, lakin onun yığılması maraqlıdır ki, o, dinamik sayda artefaktlardan istifadə etməklə qurulur.

Versiyalaşdırılmış sənəd saytı nümunəsində werf ilə Docker şəkillərinin dinamik qurulması və yerləşdirilməsi

Sayt strukturunun nüanslarına keçin: bütün versiyalar üçün ümumi menyu yaratmaq, buraxılışlar haqqında məlumat olan səhifələr və s. - etməyəcəyik. Bunun əvəzinə, dinamik montajın məsələlərinə və xüsusiyyətlərinə və bir az da onu müşayiət edən CI/CD proseslərinə diqqət yetirək.

Giriş: sayt necə işləyir

Başlamaq üçün, werf sənədləri kodu ilə birlikdə saxlanılır. Bu, ümumiyyətlə bu məqalənin əhatə dairəsindən kənarda olan müəyyən inkişaf tələblərini qoyur, lakin ən azı belə demək olar:

  • Yeni werf funksiyaları sənədləri yeniləmədən buraxılmamalıdır və əksinə, sənədlərdə hər hansı dəyişiklik werf-in yeni versiyasının buraxılmasını nəzərdə tutur;
  • Layihə kifayət qədər intensiv inkişafa malikdir: yeni versiyalar gündə bir neçə dəfə buraxıla bilər;
  • Sənədlərin yeni versiyası ilə saytı yerləşdirmək üçün hər hansı əl əməliyyatları ən azı yorucudur;
  • Layihə semantik yanaşmanı qəbul edir versiyalaşdırma, 5 sabitlik kanalı ilə. Buraxılış prosesi sabitliyin artırılması üçün kanallar vasitəsilə versiyaların ardıcıl keçidini nəzərdə tutur: alfadan qaya kimi möhkəmliyə;
  • Saytın əsas (yəni ingilis dilli) versiyası ilə paralel olaraq "yaşayan və inkişaf edən" (yəni məzmunu yenilənən) rusdilli versiyası var.

Bütün bu "daxili mətbəxi" istifadəçidən gizlətmək üçün ona "sadəcə işləyən" bir şey təklif etdik ayrı werf quraşdırma və yeniləmə aləti - Mi multiwerf. Siz sadəcə olaraq buraxılış nömrəsini və istifadəyə hazır olduğunuz stabillik kanalını göstərməlisiniz və multiwerf kanalda yeni versiyanın olub-olmadığını yoxlayacaq və lazım gələrsə onu endirin.

Veb saytdakı versiya seçimi menyusunda werf-in ən son versiyaları hər bir kanalda mövcuddur. Varsayılan olaraq, ünvana görə werf.io/documentation ən son buraxılış üçün ən sabit kanalın versiyası açılır - o da axtarış motorları tərəfindən indekslənir. Kanal üçün sənədlər ayrı-ayrı ünvanlarda mövcuddur (məsələn, werf.io/v1.0-beta/documentation beta buraxılışı 1.0 üçün).

Ümumilikdə saytda aşağıdakı versiyalar mövcuddur:

  1. kök (standart olaraq açılır),
  2. hər buraxılışın hər bir aktiv yeniləmə kanalı üçün (məsələn, werf.io/v1.0-beta).

Bir saytın konkret versiyasını yaratmaq üçün, ümumiyyətlə, istifadə edərək tərtib etmək kifayətdir Jekyllkataloqda işləməklə /docs werf repository müvafiq əmri (jekyll build), tələb olunan versiyanın Git teqinə keçdikdən sonra.

Yalnız əlavə etmək qalır:

  • kommunal özü (werf) montaj üçün istifadə olunur;
  • CI/CD prosesləri GitLab CI əsasında qurulur;
  • və bütün bunlar, əlbəttə ki, Kubernetesdə işləyir.

vəzifələri

İndi bütün təsvir olunan xüsusiyyətləri nəzərə alan vəzifələri tərtib edək:

  1. İstənilən yeniləmə kanalında werf versiyasını dəyişdikdən sonra saytdakı sənədlər avtomatik olaraq yenilənməlidir.
  2. İnkişaf üçün bəzən bacarmalısan saytın önizləmə versiyalarına baxın.

Müvafiq Git teqlərindən istənilən kanaldakı versiyanı dəyişdirdikdən sonra sayt yenidən tərtib edilməlidir, lakin təsvirin qurulması prosesində biz aşağıdakı xüsusiyyətləri əldə edəcəyik:

  • Kanallardakı versiyaların siyahısı dəyişdiyindən, yalnız versiyanın dəyişdiyi kanallar üçün sənədləri yenidən qurmaq lazımdır. Axı, hər şeyi yenidən qurmaq çox xoş deyil.
  • Buraxılışlar üçün kanallar dəsti dəyişə bilər. Məsələn, bir anda kanallarda erkən giriş 1.1 buraxılışından daha sabit versiya olmaya bilər, lakin zaman keçdikcə onlar görünəcək - bu halda montajı əl ilə dəyişməli deyilsiniz?

O çıxır ki, montaj xarici məlumatların dəyişdirilməsindən asılıdır.

Tətbiq

Bir yanaşmanın seçilməsi

Alternativ olaraq, hər bir tələb olunan versiyanı Kubernetes-də ayrıca pod kimi işlədə bilərsiniz. Bu seçim klasterdə sabit werf buraxılışlarının sayının artması ilə artacaq daha çox sayda obyekti nəzərdə tutur. Və bu, öz növbəsində, daha mürəkkəb texniki xidmət göstərir: hər versiyanın öz HTTP serveri var və kiçik bir yüklə. Təbii ki, bu da daha böyük resurs xərclərini nəzərdə tutur.

Eyni yolu tutduq bütün lazımi versiyaları bir görüntüdə toplamaq. Saytın bütün versiyalarının tərtib edilmiş statikası NGINX ilə konteynerdə yerləşir və müvafiq Yerləşdirməyə trafik NGINX Ingress vasitəsilə gəlir. Sadə bir quruluş - vətəndaşlığı olmayan proqram - Kubernetes-in özündən istifadə edərək Yerləşdirməni (yükdən asılı olaraq) asanlıqla miqyaslandırmağa imkan verir.

Daha dəqiq desək, iki şəkil toplayırıq: biri istehsal sxemi üçün, ikincisi isə inkişaf dövrəsi üçün əlavədir. Əlavə şəkil əsas ilə birlikdə yalnız dev sxemində istifadə olunur (başa salınır) və baxışdan alınan saytın versiyasını ehtiva edir və onlar arasında marşrutlaşdırma Ingress resurslarından istifadə etməklə həyata keçirilir.

werf vs git klonu və artefaktları

Artıq qeyd edildiyi kimi, sənədlərin müəyyən bir versiyası üçün sayt statikası yaratmaq üçün müvafiq depo etiketinə keçərək qurmalısınız. Bunu, hər dəfə qurduğunuzda anbarı klonlaşdırmaqla, siyahıdan müvafiq teqləri seçməklə də edə bilərsiniz. Bununla belə, bu, kifayət qədər resurs tələb edən bir əməliyyatdır və üstəlik, qeyri-trivial təlimatların yazılmasını tələb edir... Başqa bir ciddi çatışmazlıq budur ki, bu yanaşma ilə montaj zamanı nəyisə keş etmək imkanı yoxdur.

Burada werf yardım proqramının özü həyata keçirərək köməyimizə gəlir smart caching və istifadə etməyə imkan verir xarici depolar. Repozitoriyadan kod əlavə etmək üçün werf-dən istifadə tikintini əhəmiyyətli dərəcədə sürətləndirəcək, çünki werf mahiyyətcə deponu bir dəfə klonlayır və sonra icra edir yalnız fetch zəruridirsə. Bundan əlavə, depodan məlumat əlavə edərkən biz yalnız lazımi qovluqları seçə bilərik (bizim vəziyyətimizdə bu kataloqdur docs), bu, əlavə məlumatların miqdarını əhəmiyyətli dərəcədə azaldacaq.

Jekyll statik məlumatların tərtibi üçün nəzərdə tutulmuş bir alət olduğundan və son görüntüdə lazım olmadığından, burada tərtib etmək məntiqli olardı. werf artefaktı, və son görüntüyə daxil olun yalnız kompilyasiya nəticəsini idxal edin.

werf.yaml yazırıq

Beləliklə, hər bir versiyanı ayrıca bir werf artefaktında tərtib etməyə qərar verdik. Bununla belə biz montaj zamanı bu artefaktlardan nə qədərinin olacağını bilmirik, buna görə də biz sabit konfiqurasiya yaza bilmirik (doğru desək, hələ də edə bilərik, lakin bu, tamamilə effektiv olmayacaq).

werf istifadə etməyə imkan verir Şablonlara keçin konfiqurasiya faylınızda (werf.yaml) və bu, mümkün edir konfiqurasiyanı tez yaradın xarici məlumatlardan asılı olaraq (sizə nə lazımdır!). Bizim vəziyyətimizdə xarici məlumatlar versiyalar və buraxılışlar haqqında məlumatdır, bunun əsasında lazımi sayda artefakt toplayırıq və nəticədə iki şəkil əldə edirik: werf-doc и werf-dev müxtəlif dövrələrdə işləmək.

Xarici məlumatlar mühit dəyişənləri vasitəsilə ötürülür. Budur onların tərkibi:

  • RELEASES - formatda boşluqla ayrılmış dəyərlər siyahısı şəklində buraxılışların siyahısı və werf-in müvafiq cari versiyası olan bir xətt <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. Nümunə: 1.0%v1.0.4-beta.20
  • CHANNELS - formatda boşluqla ayrılmış dəyərlər siyahısı şəklində kanalların siyahısı və werf-in müvafiq cari versiyası olan bir xətt <КАНАЛ>%<НОМЕР_ВЕРСИИ>. Nümunə: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
  • ROOT_VERSION — werf buraxılış versiyası standart olaraq saytda göstərilməlidir (sənədləri ən yüksək buraxılış nömrəsi ilə göstərmək həmişə lazım deyil). Misal: v1.0.4-beta.20
  • REVIEW_SHA — sınaq dövrəsinin versiyasını qurmaq üçün lazım olan baxış öhdəliyinin hashı.

Bu dəyişənlər GitLab CI boru kəmərində doldurulacaq və aşağıda dəqiq necə yazılacaq.

Hər şeydən əvvəl, rahatlıq üçün biz müəyyən edirik werf.yaml Şablon dəyişənlərinə keçin, onlara mühit dəyişənlərindən dəyərlər təyin edin:

{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }}

Saytın statik versiyasını tərtib etmək üçün artefaktın təsviri ümumiyyətlə ehtiyac duyduğumuz bütün hallar üçün eynidır (o cümlədən kök versiyasını yaratmaq, həmçinin inkişaf dövrəsi üçün versiya). Buna görə də, funksiyadan istifadə edərək onu ayrı bir bloka köçürəcəyik define - sonradan təkrar istifadə üçün include. Aşağıdakı arqumentləri şablona ötürəcəyik:

  • Version — yaradılan versiya (teq adı);
  • Channel — artefaktın yaradıldığı yeniləmə kanalının adı;
  • Commit — artefakt nəzərdən keçirmək üçün yaradılıbsa, hash tətbiq edin;
  • Kontekst.

Artefakt Şablon 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: "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 }}

Artefakt adı unikal olmalıdır. Buna, məsələn, kanal adını (dəyişənin dəyərini) əlavə etməklə nail ola bilərik .Channel) artefaktın adına şəkilçi olaraq: artifact: doc-{{ .Channel }}. Ancaq başa düşməlisiniz ki, artefaktlardan idxal edərkən eyni adlara müraciət etməlisiniz.

Artefaktı təsvir edərkən aşağıdakı werf xüsusiyyətindən istifadə olunur: montaj. Xidmət kataloqunu göstərən montaj build_dir boru kəmərləri arasında Jekyll keşini saxlamağa imkan verir yenidən yığılmasını əhəmiyyətli dərəcədə sürətləndirir.

Faylın istifadəsinə də diqqət yetirmiş ola bilərsiniz releases.yml buraxılış məlumatları tələb olunan YAML faylıdır Github.com (boru kəmərinin icrası zamanı əldə edilən artefakt). Saytı tərtib edərkən lazımdır, lakin məqalənin kontekstində vəziyyətindən asılı olduğu üçün bizim üçün maraqlıdır yalnız bir artefaktın yenidən yığılması — saytın kök versiyasının artefaktı (digər artefaktlarda buna ehtiyac yoxdur).

Bu şərti ifadədən istifadə etməklə həyata keçirilir if Şablonlara və dizaynlara keçin {{ $Root.Files.Get "releases.yml" | sha256sum }} mərhələdə mərhələləri. Bu aşağıdakı kimi işləyir: kök versiyası üçün artefakt qurarkən (dəyişən .Channel bərabərdir root) fayl hash releases.yml Ansible tapşırığının adının bir hissəsi olduğu üçün bütün mərhələnin imzasına təsir göstərir (parametr name). Beləliklə, dəyişdirərkən məzmun fayl releases.yml müvafiq artefakt yenidən yığılacaq.

Xahiş edirəm xarici repozitoriya ilə işləməyə də diqqət yetirin. Bir artefakt şəklində werf deposu, yalnız kataloq əlavə olunur /docs, və keçən parametrlərdən asılı olaraq, tələb olunan etiket və ya nəzərdən keçirmə öhdəliyinin məlumatları dərhal əlavə edilir.

Kanalların və buraxılışların köçürülmüş versiyalarının artefaktının təsvirini yaratmaq üçün artefakt şablonundan istifadə etmək üçün dəyişən üzərində dövrə təşkil edirik. .WerfVersions в werf.yaml:

{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}}

Çünki döngə bir neçə artefakt yaradacaq (ümid edirik), onların arasındakı ayırıcını - ardıcıllığı nəzərə almaq lazımdır --- (Konfiqurasiya faylının sintaksisi haqqında ətraflı məlumat üçün bax sənədləşdirmə). Daha əvvəl müəyyən edildiyi kimi, şablonu dövrədə çağırarkən biz versiya parametrlərini, URL və kök kontekstini ötürürük.

Eynilə, lakin döngə olmadan, biz “xüsusi hallar” üçün artefakt şablonunu çağırırıq: kök versiya üçün, eləcə də nəzərdən keçirilən 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 }}

Nəzərdən keçirmə öhdəliyi üçün artefaktın yalnız dəyişən təyin edildikdə qurulacağını unutmayın .WerfReviewCommit.

Artefaktlar hazırdır - idxal etməyə başlamağın vaxtıdır!

Kubernetes-də işləmək üçün hazırlanmış son şəkil server konfiqurasiya faylı əlavə edilmiş adi NGINX-dir. nginx.conf və artefaktlardan statik. Saytın kök versiyasının artefaktına əlavə olaraq, dəyişəndəki döngəni təkrarlamalıyıq .WerfVersions kanal artefaktlarını idxal etmək və versiyaları buraxmaq + əvvəllər qəbul etdiyimiz artefakt adlandırma qaydasına əməl edin. Hər bir artefakt saytın iki dil üçün versiyalarını saxladığından, biz onları konfiqurasiyanın təmin etdiyi yerlərə idxal edirik.

Son təsvirin təsviri 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 -}}

Əsas ilə birlikdə dev sxemində işə salınan əlavə şəkil saytın yalnız iki versiyasını ehtiva edir: baxışdan alınan versiya və saytın kök versiyası (ümumi aktivlər var və xatırlayırsınızsa , buraxılış məlumatları). Beləliklə, əlavə şəkil əsasdan yalnız idxal bölməsində (və təbii ki, adda) fərqlənəcək:

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 }}

Yuxarıda qeyd edildiyi kimi, nəzərdən keçirmə öhdəliyi üçün artefakt yalnız müəyyən edilmiş mühit dəyişəni işə salındıqda yaradılacaq. REVIEW_SHA. Heç bir mühit dəyişəni olmasa, werf-dev şəklini ümumiyyətlə yaratmamaq mümkün olardı REVIEW_SHA, lakin etmək üçün siyasətlə təmizləmə Werf-dəki Docker şəkilləri werf-dev təsviri üçün işlədi, biz onu yalnız kök versiya artefaktı ilə (hər halda qurulub) ilə tikilməyə buraxacağıq, boru kəmərinin strukturunu sadələşdirmək üçün.

Məclis hazırdır! CI/CD və mühüm nüanslara keçək.

GitLab CI-də boru kəməri və dinamik quruluşun xüsusiyyətləri

Quraşdırmanı işləyərkən istifadə olunan mühit dəyişənlərini təyin etməliyik werf.yaml. Bu, GitHub çəngəlindən boru xəttinə zəng edərkən təyin edəcəyimiz REVIEW_SHA dəyişəninə aid deyil.

Biz Bash skriptində lazımi xarici məlumatları yaradacağıq generate_artifacts, iki GitLab boru kəməri artefaktını yaradacaq:

  • fayl releases.yml buraxılış məlumatları ilə,
  • fayl common_envs.sh, ixrac ediləcək mühit dəyişənlərini ehtiva edir.

Fayl məzmunu generate_artifacts bizdə tapa bilərsiniz nümunələri ilə depolar. Məlumatların qəbulu məqalənin mövzusu deyil, fayldır common_envs.sh bizim üçün vacibdir, çünki werf-in işi ondan asılıdır. Onun məzmununa bir nümunə:

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ışından, məsələn, Bash funksiyasından istifadə edə bilərsiniz source.

İndi əyləncə hissəsi gəlir. Tətbiqin həm qurulması, həm də yerləşdirilməsinin düzgün işləməsi üçün bunu təmin etmək lazımdır werf.yaml oldu eyni heç olmasa bir boru kəməri daxilində. Bu şərt yerinə yetirilməzsə, o zaman werf-in montaj və məsələn, yerləşdirmə zamanı hesabladığı mərhələlərin imzaları fərqli olacaq. Bu, yerləşdirmə xətasına səbəb olacaq, çünki... yerləşdirmə üçün tələb olunan şəkil itkin olacaq.

Başqa sözlə, əgər sayt şəklinin yığılması zamanı buraxılışlar və versiyalar haqqında məlumat eyni olarsa və yerləşdirmə zamanı yeni versiya buraxılırsa və ətraf mühit dəyişənləri fərqli dəyərlərə malikdirsə, onda yerləşdirmə xəta ilə uğursuz olacaq: axı yeni versiyanın artefaktı hələ qurulmayıb.

Əgər nəsil werf.yaml xarici məlumatlardan asılıdır (məsələn, bizim vəziyyətimizdə olduğu kimi cari versiyaların siyahısı), onda belə məlumatların tərkibi və dəyərləri boru kəməri daxilində qeyd edilməlidir. Xarici parametrlər olduqca tez-tez dəyişirsə, bu xüsusilə vacibdir.

Biz edəcəyik xarici məlumatları qəbul etmək və qeyd etmək GitLab-da boru kəmərinin birinci mərhələsində (Əvvəlcədən qurulma) və onları formada daha da ötürün GitLab CI artefaktı. Bu, sizə eyni konfiqurasiya ilə boru kəməri işlərini (qurma, yerləşdirmə, təmizləmə) yerinə yetirməyə və yenidən başlamağa imkan verəcək. werf.yaml.

Səhnənin məzmunu Əvvəlcədən qurulma 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 week

Artefaktdakı xarici məlumatları ələ keçirdikdən sonra standart GitLab CI boru kəməri mərhələlərindən istifadə edərək qura və yerləşdirə bilərsiniz: Qurmaq və Yerləşdirmək. Biz werf GitHub repozitoriyasındakı qarmaqlardan istifadə edərək (yəni, GitHub deposunda dəyişikliklər olduqda) boru kəmərinin özünü işə salırıq. Onlar üçün məlumatları bölmədəki GitLab layihəsinin xüsusiyyətlərində tapa bilərsiniz CI/CD Parametrləri -> Boru kəməri tetikleyicileri, və sonra GitHub-da müvafiq Webhook yaradın (Parametrlər -> Webhooks).

Quraşdırma mərhələsi bu 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 səhnədən tikinti mərhələsinə iki artefakt əlavə edəcək Əvvəlcədən qurulma, buna görə də konstruksiyadan istifadə edərək hazırlanmış giriş məlumatları ilə dəyişənləri ixrac edirik source common_envs.sh. Boru kəmərinin qrafikə uyğun işə salınması istisna olmaqla, biz bütün hallarda tikinti mərhələsinə başlayırıq. Cədvələ uyğun olaraq, təmizləmə üçün bir boru kəməri çəkəcəyik - bu halda montaj yerinə yetirməyə ehtiyac yoxdur.

Yerləşdirmə mərhələsində biz iki tapşırığı təsvir edəcəyik - ayrıca YAML şablonundan istifadə edərək istehsal və inkişaf sxemlərinə yerləşdirmə üçün:

.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

Tapşırıqlar yalnız werf-in yerləşdirməni yerinə yetirməli olduğu klaster kontekstini göstərməklə əsaslı şəkildə fərqlənir (WERF_KUBE_CONTEXT) və dövrə mühiti dəyişənlərinin təyin edilməsi (environment.name и environment.url), daha sonra Helm diaqram şablonlarında istifadə olunur. Şablonların məzmununu təqdim etməyəcəyik, çünki... orada sözügedən mövzu üçün maraqlı heç nə yoxdur, lakin siz onları burada tapa bilərsiniz məqalə üçün depolar.

Final toxunuşu

Werf versiyaları tez-tez buraxıldığından, tez-tez yeni şəkillər qurulacaq və Docker Registry daim böyüyəcəkdir. Buna görə də, siyasətlərə əsaslanaraq avtomatik təsvirin təmizlənməsini konfiqurasiya etmək vacibdir. Bunu etmək çox asandır.

Həyata keçirmək üçün sizə lazım olacaq:

  • Təmizləmə addımını əlavə edin .gitlab-ci.yml;
  • Təmizləmə tapşırığının dövri icrasını əlavə edin;
  • Yazma giriş nişanı ilə mühit dəyişənini qurun.

Təmizləmə mərhələsinin əlavə edilməsi .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

Demək olar ki, bunların hamısını bir az daha yüksək görmüşük - yalnız onu təmizləmək üçün əvvəlcə Docker Reyestrində şəkilləri silmək hüququna malik olan bir işarə ilə Docker Reyestrinə daxil olmalısınız (avtomatik olaraq buraxılmış GitLab CI tapşırıq nişanı yoxdur. belə hüquqlara malikdir). Token əvvəlcədən GitLab-da yaradılmalı və onun dəyəri mühit dəyişənində göstərilməlidir WERF_IMAGES_CLEANUP_PASSWORD Layihə (CI/CD Parametrləri -> Dəyişənlər).

Tələb olunan cədvəllə təmizlik tapşırığı əlavə edilir CI/CD ->
Cədvəllər.

Budur: Docker Registry-dəki bir layihə artıq istifadə olunmamış şəkillərdən daim inkişaf etməyəcək.

Praktiki hissənin sonunda sizə xatırlatmaq istəyirəm ki, məqalənin tam siyahıları burada mövcuddur get:

Nəticə

  1. Məntiqi montaj strukturu əldə etdik: hər versiya üçün bir artefakt.
  2. Montaj universaldır və werf-in yeni versiyaları buraxıldıqda əl ilə dəyişikliklər tələb etmir: veb-saytdakı sənədlər avtomatik olaraq yenilənir.
  3. Müxtəlif konturlar üçün iki şəkil yığılmışdır.
  4. Tez işləyir, çünki Mümkün qədər keşləmə istifadə olunur - werf-in yeni versiyası buraxıldıqda və ya GitHub çəngəl nəzərdən keçirməyə çağırıldıqda, yalnız dəyişdirilmiş versiya ilə uyğun artefakt yenidən qurulur.
  5. İstifadə edilməmiş şəkilləri silmək barədə düşünməyə ehtiyac yoxdur: werf siyasətlərinə uyğun təmizləmə Docker Registry-ni qaydasında saxlayacaq.

Tapıntılar

  • Werf-dən istifadə həm montajın özünün keşləşdirilməsi, həm də xarici depolarla işləyərkən keşləşdirilməsi sayəsində montajın tez işləməsinə imkan verir.
  • Xarici Git repozitoriyaları ilə işləmək hər dəfə bütün repozitoriyanın klonlanması və ya çətin optimallaşdırma məntiqi ilə çarxı yenidən kəşf etmək ehtiyacını aradan qaldırır. werf keşdən istifadə edir və klonlaşdırmanı yalnız bir dəfə edir və sonra istifadə edir fetch və yalnız lazım olduqda.
  • Quraşdırma konfiqurasiya faylında Go şablonlarından istifadə etmək imkanı werf.yaml nəticəsi xarici məlumatlardan asılı olan montajı təsvir etməyə imkan verir.
  • Werf-də montajdan istifadə, bütün boru kəmərləri üçün ümumi olan önbellek sayəsində artefaktların yığılmasını əhəmiyyətli dərəcədə sürətləndirir.
  • werf təmizləməni konfiqurasiya etməyi asanlaşdırır, bu xüsusilə dinamik şəkildə qurarkən vacibdir.

PS

Bloqumuzda da oxuyun:

Mənbə: www.habr.com

Добавить комментарий