ProHoster > Блог > Захиргаа > Хувилбарын баримтжуулалтын сайтын жишээг ашиглан werf-тэй Docker зургуудыг динамик угсрах, байршуулах

Хувилбарын баримтжуулалтын сайтын жишээг ашиглан werf-тэй Docker зургуудыг динамик угсрах, байршуулах

Бид GitOps хэрэгслийнхээ талаар нэгээс олон удаа ярьсан. верф, мөн энэ удаад бид уг сайтыг угсрах туршлагаа төслийн баримт бичигтэй хуваалцахыг хүсч байна - werf.io (түүний орос хувилбар en.werf.io). Энэ бол ердийн статик сайт боловч түүний угсралт нь динамик тооны олдворуудыг ашиглан баригдсанаараа сонирхолтой юм.

Хувилбарын баримтжуулалтын сайтын жишээг ашиглан werf-тэй Docker зургуудыг динамик угсрах, байршуулах

Сайтын бүтцийн нарийн ширийн зүйлийг анхаарч үзээрэй: бүх хувилбарт зориулсан нийтлэг цэс, хувилбаруудын талаархи мэдээлэл бүхий хуудас гэх мэт. - бид тэгэхгүй. Үүний оронд динамик угсралтын асуудал, онцлогууд дээр анхаарлаа хандуулж, дагалдах CI/CD процессуудад бага зэрэг анхаарлаа хандуулцгаая.

Танилцуулга: сайт хэрхэн ажилладаг

Эхлэхийн тулд werf баримт бичгийг кодын хамт хадгалдаг. Энэ нь ерөнхийдөө энэ зүйлийн хамрах хүрээнээс гадуур тодорхой хөгжлийн шаардлагуудыг тавьдаг боловч наад зах нь дараахь зүйлийг хэлж болно.

  • Баримт бичгийг шинэчлэхгүйгээр шинэ werf функцуудыг гаргах ёсгүй бөгөөд эсрэгээр, баримт бичигт гарсан аливаа өөрчлөлт нь werf-ийн шинэ хувилбарыг гаргах гэсэн үг юм;
  • Төсөл нь нэлээд эрчимтэй хөгжиж байна: шинэ хувилбаруудыг өдөрт хэд хэдэн удаа гаргах боломжтой;
  • Баримт бичгийн шинэ хувилбар бүхий сайтыг байрлуулах аливаа гар ажиллагаа нь ядаж уйтгартай байдаг;
  • Төсөл нь семантик аргыг ашигладаг хувилбар гаргах, 5 тогтвортой байдлын сувагтай. Хувилбарын үйл явц нь тогтвортой байдлыг нэмэгдүүлэхийн тулд сувгаар дамжуулан хувилбаруудыг дараалан дамжуулдаг: альфагаас чулуулаг хүртэл;
  • Энэ сайт нь үндсэн (өөрөөр хэлбэл англи хэл дээрх) хувилбартай зэрэгцэн "амьдарч, хөгжиж" (өөрөөр хэлбэл агуулга нь шинэчлэгдсэн) орос хэл дээрх хувилбартай.

Энэ бүх "дотоод гал тогоо"-ыг хэрэглэгчээс нуухын тулд түүнд "зүгээр л ажилладаг" зүйлийг санал болгов тусдаа werf суулгах, шинэчлэх хэрэгсэл Байна уу multiwerf. Та зүгээр л ашиглахад бэлэн байгаа хувилбарын дугаар болон тогтвортой байдлын сувгийг зааж өгөх хэрэгтэй бөгөөд multiwerf суваг дээр шинэ хувилбар байгаа эсэхийг шалгаж, шаардлагатай бол татаж авах болно.

Вэбсайт дээрх хувилбар сонгох цэсэнд werf-ийн хамгийн сүүлийн хувилбарууд суваг бүрт байдаг. Анхдагч байдлаар, хаягаар werf.io/documentation Хамгийн сүүлийн үеийн хувилбарын хамгийн тогтвортой сувгийн хувилбар нээгдэв - үүнийг хайлтын системүүд бас индексжүүлдэг. Сувгийн бичиг баримтыг тусдаа хаягаар авах боломжтой (жишээлбэл, werf.io/v1.0-beta/documentation бета хувилбар 1.0).

Нийтдээ сайтад дараах хувилбарууд бий.

  1. root (өгөгдмөлөөр нээгддэг),
  2. хувилбар бүрийн идэвхтэй шинэчлэх суваг бүрийн хувьд (жишээлбэл, werf.io/v1.0-бета).

Сайтын тодорхой хувилбарыг бий болгохын тулд ерөнхийдөө үүнийг ашиглан хөрвүүлэхэд хангалттай Jekyllдиректорт ажиллуулснаар /docs werf репозитортой харгалзах тушаал (jekyll build), шаардлагатай хувилбарын Git таг руу шилжсэний дараа.

Үүнийг нэмэхэд л үлдлээ:

  • угсралтад уг хэрэгсэл өөрөө (werf) ашиглагддаг;
  • CI/CD процессууд нь GitLab CI-ийн үндсэн дээр бүтээгдсэн;
  • Мэдээжийн хэрэг энэ бүхэн Кубернетес дээр явагддаг.

үүрэг

Одоо тайлбарласан бүх онцлогийг харгалзан даалгавруудыг томъёолъё.

  1. Аливаа шинэчлэлтийн суваг дээр werf хувилбарыг өөрчилсний дараа сайт дээрх баримт бичиг автоматаар шинэчлэгдэх ёстой.
  2. Хөгжүүлэхийн тулд та заримдаа чадвартай байх хэрэгтэй сайтын урьдчилан харах хувилбаруудыг үзэх.

Харгалзах Git хаягуудаас аль ч суваг дээрх хувилбарыг өөрчилсний дараа сайтыг дахин эмхэтгэх ёстой боловч зураг бүтээх явцад бид дараах боломжуудыг авах болно.

  • Сувгууд дээрх хувилбаруудын жагсаалт өөрчлөгдөж байгаа тул зөвхөн хувилбар нь өөрчлөгдсөн сувгуудын баримт бичгийг дахин бүтээх шаардлагатай. Эцсийн эцэст, бүх зүйлийг дахин сэргээх нь тийм ч таатай биш юм.
  • Гаргах сувгийн багц өөрчлөгдөж магадгүй. Хэзээ нэгэн цагт, жишээлбэл, сувгууд дээр эрт хандалттай 1.1 хувилбараас илүү тогтвортой хувилбар байхгүй байж болох ч цаг хугацаа өнгөрөхөд тэдгээр нь гарч ирэх болно - энэ тохиолдолд та угсралтыг гараар өөрчлөх хэрэгтэй биш үү?

Энэ нь угсралт нь гадаад өгөгдлийг өөрчлөхөөс хамаарна.

Реализация

Арга барилыг сонгох

Эсвэл та шаардлагатай хувилбар бүрийг Kubernetes-д тусдаа pod хэлбэрээр ажиллуулж болно. Энэ сонголт нь кластер дахь илүү олон тооны объектуудыг агуулдаг бөгөөд энэ нь тогтвортой werf хувилбаруудын тоо нэмэгдэхийн хэрээр өсөх болно. Энэ нь эргээд илүү төвөгтэй засвар үйлчилгээ шаарддаг: хувилбар бүр өөрийн гэсэн HTTP сервертэй бөгөөд бага ачаалалтай байдаг. Мэдээжийн хэрэг, энэ нь илүү их нөөцийн зардлыг шаарддаг.

Бид ижил замаар явсан шаардлагатай бүх хувилбаруудыг нэг зураг дээр цуглуулах. Сайтын бүх хувилбаруудын эмхэтгэсэн статикууд нь NGINX-тэй контейнерт байрладаг бөгөөд холбогдох байршуулалт руу чиглэсэн урсгал NGINX Ingress-ээр дамжин ирдэг. Энгийн бүтэц - харьяалалгүй програм нь Kubernetes-ийг ашиглан Байршуулах ажлыг (ачаалалаас хамааран) хялбархан масштаблах боломжийг олгодог.

Илүү нарийвчлалтай болгохын тулд бид хоёр зураг цуглуулж байна: нэг нь үйлдвэрлэлийн хэлхээнд зориулагдсан, хоёр дахь нь төхөөрөмжийн хэлхээний нэмэлт зураг юм. Нэмэлт зургийг зөвхөн үндсэн зурагтай хамт хөгжүүлэлтийн хэлхээнд ашигладаг (эхэлсэн) бөгөөд хянан шалгах комиссоос сайтын хувилбарыг агуулдаг бөгөөд тэдгээрийн хоорондох чиглүүлэлт нь Ingress нөөцийг ашиглан хийгддэг.

werf vs git клон болон олдворууд

Өмнө дурьдсанчлан, баримт бичгийн тодорхой хувилбарт зориулж сайтын статикийг бий болгохын тулд та тохирох хадгалах хаяг руу шилжих замаар бүтээх хэрэгтэй. Та үүнийг хийх бүртээ хадгалах газрыг клончилж, жагсаалтаас тохирох хаягуудыг сонгож болно. Гэсэн хэдий ч, энэ нь нэлээд их нөөц шаарддаг үйл ажиллагаа бөгөөд үүнээс гадна энгийн бус зааварчилгаа бичихийг шаарддаг ... Өөр нэг ноцтой сул тал бол угсрах явцад ямар нэгэн зүйлийг кэш хийх боломжгүй юм.

Энд werf хэрэгсэл өөрөө хэрэгжиж, бидний тусламжид ирдэг ухаалаг кэш мөн ашиглах боломжийг танд олгоно гадаад агуулахууд. Репозитороос код нэмэхийн тулд werf ашиглах нь угсралтын ажлыг ихээхэн хурдасгах болно, учир нь werf нь үндсэндээ репозиторыг нэг удаа хувилж дараа нь ажиллуулдаг зөвхөн fetch Хэрэв шаардлагатай бол. Нэмж дурдахад, репозитороос өгөгдөл нэмэхдээ бид зөвхөн шаардлагатай сангуудыг сонгох боломжтой (бидний тохиолдолд энэ нь лавлах юм. docs), энэ нь нэмсэн өгөгдлийн хэмжээг мэдэгдэхүйц бууруулах болно.

Jekyll нь статик өгөгдлийг эмхэтгэх зориулалттай хэрэгсэл бөгөөд эцсийн зураг дээр шаардлагагүй тул эмхэтгэх нь логик юм. верфийн олдвор, мөн эцсийн зураг руу орно зөвхөн эмхэтгэлийн үр дүнг импортлох.

Бид werf.yaml гэж бичдэг

Тиймээс бид хувилбар бүрийг тусдаа werf олдвор болгон эмхэтгэхээр шийдсэн. Гэсэн хэдий ч бид угсралтын үеэр эдгээр олдворуудын хэд нь байгааг бид мэдэхгүй, тиймээс бид тогтсон бүтээх тохиргоог бичиж чадахгүй (хатуухан хэлэхэд бид чадна, гэхдээ энэ нь бүрэн үр дүнтэй биш байх болно).

werf нь танд ашиглах боломжийг олгодог Загварууд руу оч таны тохиргооны файлд (werf.yaml), энэ нь боломжтой болгодог тохиргоог шууд үүсгэх гадаад өгөгдлөөс хамааран (таньд юу хэрэгтэй вэ!). Манай тохиолдолд гадаад мэдээлэл нь хувилбар, хувилбаруудын талаархи мэдээлэл бөгөөд үүний үндсэн дээр бид шаардлагатай тооны олдворуудыг цуглуулж, үр дүнд нь хоёр зургийг олж авдаг. werf-doc и werf-dev өөр өөр хэлхээнүүд дээр ажиллах.

Гадаад өгөгдөл нь орчны хувьсагчаар дамждаг. Тэдний найрлага энд байна:

  • RELEASES - хувилбаруудын жагсаалт болон werf-ийн холбогдох одоогийн хувилбар бүхий мөр, формат дахь утгуудын зайгаар тусгаарлагдсан жагсаалт хэлбэрээр. <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>Байна. Жишээ нь: 1.0%v1.0.4-beta.20
  • CHANNELS - форматын зайгаар тусгаарлагдсан утгуудын жагсаалт хэлбэрээр сувгийн жагсаалт ба werf-ийн холбогдох хувилбар бүхий мөр. <КАНАЛ>%<НОМЕР_ВЕРСИИ>Байна. Жишээ нь: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
  • ROOT_VERSION — werf хувилбарыг сайт дээр анхдагч байдлаар харуулах (баримт бичгийг хамгийн өндөр хувилбарын дугаараар харуулах шаардлагагүй). Жишээ: v1.0.4-beta.20
  • REVIEW_SHA - туршилтын давталтын хувилбарыг бүтээх шаардлагатай хянан шалгах үүргийн хэш.

Эдгээр хувьсагчдыг GitLab CI хоолойд бөглөх бөгөөд доор яг хэрхэн бичсэнийг бичсэн болно.

Юуны өмнө, тав тухтай байдлыг хангах үүднээс бид үүнийг тодорхойлдог werf.yaml Загвар хувьсагч руу орж, орчны хувьсагчдаас утгыг онооно уу:

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

Сайтын статик хувилбарыг эмхэтгэхэд зориулсан олдворын тайлбар нь бидэнд шаардлагатай бүх тохиолдолд ерөнхийдөө ижил байна (үүнд үндсэн хувилбарыг үүсгэх, түүнчлэн хөгжүүлэлтийн хэлхээний хувилбар гэх мэт). Тиймээс бид функцийг ашиглан тусдаа блок руу шилжүүлнэ define - дараа дахин ашиглах зорилгоор include. Бид загварт дараах аргументуудыг дамжуулах болно.

  • Version - үүсгэсэн хувилбар (шошго нэр);
  • Channel — олдвор үүсгэсэн шинэчлэх сувгийн нэр;
  • Commit - хэрэв олдворыг хянан шалгах зорилгоор үүсгэсэн бол хэш хийх;
  • контекст.

Олдворын загварын тайлбар

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

Олдворын нэр өвөрмөц байх ёстой. Бид үүнд, жишээлбэл, сувгийн нэрийг (хувьсагчийн утга) нэмэх замаар хүрч чадна .Channel) олдворын нэрний дагавар болгон: artifact: doc-{{ .Channel }}. Гэхдээ та олдвороос импортлохдоо ижил нэрсийг дурдах хэрэгтэй гэдгийг ойлгох хэрэгтэй.

Олдворыг дүрслэхдээ дараах werf функцийг ашигладаг. угсралт. Үйлчилгээний лавлахыг харуулсан угсралт build_dir дамжуулах хоолойн хооронд Jekyll кэшийг хадгалах боломжийг танд олгоно дахин угсрах ажлыг ихээхэн хурдасгадаг.

Та мөн файлын хэрэглээг анзаарсан байх releases.yml -аас хүссэн хувилбарын өгөгдөл бүхий YAML файл юм Github.com (шугам хоолойг гүйцэтгэх үед олж авсан олдвор). Энэ нь сайтыг эмхэтгэх үед шаардлагатай байдаг, гэхдээ нийтлэлийн хувьд энэ нь түүний төлөв байдлаас хамаардаг тул бидэнд сонирхолтой юм. зөвхөн нэг олдворыг дахин угсрах - сайтын эх хувилбарын олдвор (энэ нь бусад олдворуудад шаардлагагүй).

Үүнийг нөхцөлт мэдэгдлийг ашиглан хэрэгжүүлдэг if Загвар болон дизайн руу яв {{ $Root.Files.Get "releases.yml" | sha256sum }} шатанд үе шатууд. Энэ нь дараах байдлаар ажиллана: үндсэн хувилбарт зориулж олдвор бүтээх үед (хувьсагч .Channel тэнцүү байна root) файлын хэш releases.yml Энэ нь Ansible даалгаврын нэрний нэг хэсэг учраас бүх шатны гарын үсэгт нөлөөлдөг (параметр name). Тиймээс өөрчлөх үед агуулга файл releases.yml холбогдох олдворыг дахин угсарна.

Мөн гадаад репозитортой ажиллахад анхаарлаа хандуулна уу. -аас олдворын дүрс дээр werf хадгалах газар, зөвхөн лавлахыг нэмсэн /docs, мөн дамжуулсан параметрүүдээс хамааран шаардлагатай шошго эсвэл хянан шалгах үүргийн өгөгдлийг нэн даруй нэмнэ.

Суваг болон хувилбаруудын шилжүүлсэн хувилбаруудын олдворын тайлбарыг үүсгэхийн тулд олдворын загварыг ашиглахын тулд бид хувьсагч дээр гогцоо зохион байгуулдаг. .WerfVersions в werf.yaml:

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

Учир нь гогцоо нь хэд хэдэн олдвор үүсгэх болно (бид тийм гэж найдаж байна), тэдгээрийн хоорондох тусгаарлагчийг харгалзан үзэх шаардлагатай - дараалал --- (Тохиргооны файлын синтаксийн талаар дэлгэрэнгүй мэдээллийг үзнэ үү баримт бичиг). Өмнө дурьдсанчлан, загварыг давталтаар дуудахдаа бид хувилбарын параметрүүд, URL болон үндсэн контекстийг дамжуулдаг.

Үүний нэгэн адил, гэхдээ гогцоогүйгээр бид олдворын загварыг "онцгой тохиолдлууд" гэж нэрлэдэг: үндсэн хувилбарын хувьд, мөн хянан шалгах хувилбарын хувьд:

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

Хувьсагчийг тохируулсан тохиолдолд л хянан шалгах олдворыг бүтээх болно гэдгийг анхаарна уу .WerfReviewCommit.

Олдворууд бэлэн боллоо - импортлох цаг боллоо!

Kubernetes дээр ажиллахад зориулагдсан эцсийн зураг нь серверийн тохиргооны файлыг нэмсэн ердийн NGINX юм. nginx.conf болон олдворуудаас статик. Сайтын эх хувилбарын олдвороос гадна бид хувьсагч дээрх гогцоог давтах хэрэгтэй .WerfVersions сувгийн олдворуудыг импортлох, хувилбаруудыг гаргах + бидний өмнө нь баталсан олдворыг нэрлэх дүрмийг дагаж мөрдөх. Олдвор бүр сайтын хоёр хэл дээрх хувилбаруудыг хадгалдаг тул бид тэдгээрийг тохиргоонд заасан газруудад импортолдог.

Эцсийн зургийн тайлбар 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 -}}

Нэмэлт зураг нь үндсэн зурагтай хамт хөгжүүлэлтийн хэлхээнд нээгдсэн бөгөөд энэ нь сайтын зөвхөн хоёр хувилбарыг агуулдаг: хянан шалгах хувилбар ба сайтын үндсэн хувилбар (ерөнхий хөрөнгө байгаа бөгөөд хэрэв та санаж байгаа бол). , мэдээлэл гаргах). Тиймээс нэмэлт зураг нь зөвхөн импортын хэсэгт (мөн мэдээжийн хэрэг нэрээр) үндсэн зургаас ялгаатай байх болно.

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

Дээр дурьдсанчлан, хянан шалгах комисст зориулсан олдвор нь зөвхөн тохируулсан орчны хувьсагчийг ажиллуулах үед л үүсгэгдэнэ. REVIEW_SHA. Хэрэв орчны хувьсагч байхгүй бол werf-dev дүрсийг огт үүсгэхгүй байх боломжтой REVIEW_SHA, гэхдээ тулд бодлогоор цэвэрлэх Werf дахь Docker зургууд нь werf-dev дүрс дээр ажилласан тул дамжуулах хоолойн бүтцийг хялбарчлахын тулд бид үүнийг зөвхөн эх хувилбарын олдвороор (ямар ч байсан аль хэдийн бүтээгдсэн) бүтээхээр үлдээх болно.

Чуулган бэлэн боллоо! CI/CD болон чухал нюансууд руу шилжье.

GitLab CI дахь дамжуулах хоолой ба динамик бүтээцийн онцлог

Бүтэцийг ажиллуулахдаа бид ашигласан орчны хувьсагчдыг тохируулах хэрэгтэй werf.yaml. Энэ нь GitHub дэгээнээс дамжуулах шугамыг дуудах үед бидний тохируулах REVIEW_SHA хувьсагчдад хамаарахгүй.

Бид Bash скрипт дээр шаардлагатай гадаад өгөгдлийг үүсгэх болно generate_artifacts, энэ нь GitLab дамжуулах хоолойн хоёр олдворыг үүсгэх болно:

  • файл releases.yml хувилбарын өгөгдөлтэй,
  • файл common_envs.sh, экспортлох орчны хувьсагчдыг агуулсан.

Файлын агуулга generate_artifacts та манайхаас олох болно жишээ бүхий агуулахууд. Мэдээллийг хүлээн авах нь өөрөө нийтлэлийн сэдэв биш, харин файл юм common_envs.sh бидний хувьд чухал, учир нь werf-ийн ажил үүнээс хамаарна. Түүний агуулгын жишээ:

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'

Та ийм скриптийн гаралтыг ашиглаж болно, жишээлбэл, Bash функцийг ашиглан source.

Одоо хөгжилтэй хэсэг ирлээ. Аппликешныг бүтээх, байршуулах аль аль нь зөв ажиллахын тулд үүнийг баталгаажуулах шаардлагатай werf.yaml байсан адилхан хамгийн бага нэг дамжуулах хоолой дотор. Хэрэв энэ нөхцөл хангагдаагүй бол угсрах, жишээлбэл, байршуулах явцад werf-ийн тооцоолсон үе шатуудын гарын үсэг өөр байх болно. Энэ нь байршуулалтын алдаа гарахад хүргэнэ, учир нь... байршуулахад шаардлагатай зураг байхгүй болно.

Өөрөөр хэлбэл, сайтын дүрсийг угсрах явцад хувилбарууд болон хувилбаруудын талаарх мэдээлэл ижил байвал, байршуулах үед шинэ хувилбар гарч, орчны хувьсагчид өөр өөр утгатай байвал байршуулалт нь алдаа гарна: Эцсийн эцэст шинэ хувилбарын олдвор хараахан баригдаагүй байна.

Хэрэв үе werf.yaml гадаад өгөгдлөөс хамаарна (жишээлбэл, одоогийн хувилбаруудын жагсаалт, манай тохиолдолд), ийм өгөгдлийн найрлага, утгыг дамжуулах хоолойд бүртгэх ёстой. Гадны параметрүүд байнга өөрчлөгддөг бол энэ нь ялангуяа чухал юм.

Бид ... болно гадаад өгөгдлийг хүлээн авах, бүртгэх GitLab дахь дамжуулах хоолойн эхний шатанд (Урьдчилан бүтээх) хэлбэрээр цааш нь дамжуулна GitLab CI олдвор. Энэ нь танд ижил тохиргоотой шугам хоолойн ажлуудыг (барих, байрлуулах, цэвэрлэх) ажиллуулах, дахин эхлүүлэх боломжийг олгоно. werf.yaml.

Тайзны агуулга Урьдчилан бүтээх файл .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

Олдвор доторх гадаад өгөгдлийг авсны дараа та стандарт GitLab CI дамжуулах хоолойн үе шатуудыг ашиглан бүтээж, байрлуулж болно: Бүтээх ба Байрлуулах. Бид werf GitHub репозиторын дэгээ ашиглан дамжуулах хоолойг өөрөө эхлүүлдэг (жишээ нь, GitHub репозиторт өөрчлөлт гарсан үед). Тэдгээрийн өгөгдлийг GitLab төслийн шинж чанаруудаас олж болно CI/CD тохиргоо -> Дамжуулах хоолойн гох, дараа нь GitHub дээр харгалзах Webhook үүсгэнэ үү (Тохиргоо -> Webhooks).

Барилгын үе шат дараах байдлаар харагдах болно.

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 нь тайзнаас бүтээх үе шатанд хоёр олдвор нэмнэ Урьдчилан бүтээх, тиймээс бид бүтээцийг ашиглан бэлтгэсэн оролтын өгөгдөл бүхий хувьсагчдыг экспортлодог source common_envs.sh. Хуваарийн дагуу дамжуулах хоолойг эхлүүлэхээс бусад тохиолдолд бид барилгын үе шатыг эхлүүлдэг. Хуваарийн дагуу бид цэвэрлэх шугам хоолойг ажиллуулна - энэ тохиолдолд угсралт хийх шаардлагагүй болно.

Байршуулах үе шатанд бид 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

Даалгаврууд нь зөвхөн werf-ийн байршуулалтыг гүйцэтгэх ёстой кластерийн контекстийг зааж өгөхдөө үндсэндээ ялгаатай байна (WERF_KUBE_CONTEXT) болон давталтын орчны хувьсагчдыг тохируулах (environment.name и environment.url), дараа нь Helm диаграмын загварт ашигладаг. Бид загваруудын агуулгыг өгөхгүй, учир нь... Энэ сэдэвт сонирхолтой зүйл байхгүй, гэхдээ та тэдгээрийг эндээс олж болно нийтлэлийн агуулахууд.

эцсийн мэдрэгч

Werf хувилбарууд байнга гардаг тул шинэ зургууд байнга баригдах бөгөөд Docker Registry байнга өсөх болно. Тиймээс, бодлогод үндэслэн зураг автоматаар цэвэрлэх тохиргоог хийх нь зайлшгүй шаардлагатай. Үүнийг хийхэд маш хялбар.

Хэрэгжүүлэхийн тулд танд хэрэгтэй болно:

  • Цэвэрлэх алхам нэмнэ үү .gitlab-ci.yml;
  • Цэвэрлэх ажлын үе үе гүйцэтгэлийг нэмэх;
  • Бичих хандалтын токен бүхий орчны хувьсагчийг тохируулна уу.

Цэвэрлэх үе шатыг нэмж байна .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

Энэ бүгдийг бид аль хэдийн бага зэрэг өндөр түвшинд харсан - зөвхөн үүнийг цэвэрлэхийн тулд та эхлээд Docker Бүртгэлд байгаа зургийг устгах эрхтэй жетоноор Docker Registry руу нэвтрэх хэрэгтэй (автоматаар гаргасан GitLab CI даалгаврын токен нь тийм биш юм. ийм эрхтэй). Токеныг GitLab дээр урьдчилан үүсгэсэн байх ёстой бөгөөд түүний утгыг орчны хувьсагч дээр зааж өгөх ёстой WERF_IMAGES_CLEANUP_PASSWORD төсөл (CI/CD тохиргоо -> Хувьсагч).

Шаардлагатай хуваарийн дагуу цэвэрлэгээний ажлыг нэмж оруулав CI/CD ->
Жагсаалт.

Энэ бол: Docker Registry дахь төсөл ашиглагдаагүй зургуудаас байнга өсөхгүй.

Практик хэсгийн төгсгөлд нийтлэлийн бүрэн жагсаалтыг эндээс авах боломжтой гэдгийг сануулъя явах:

үр дүн

  1. Бид логик угсралтын бүтцийг хүлээн авсан: хувилбар бүрт нэг олдвор.
  2. Угсралт нь бүх нийтийнх бөгөөд werf-ийн шинэ хувилбарууд гарах үед гараар өөрчлөх шаардлагагүй: вэбсайт дээрх баримт бичиг автоматаар шинэчлэгддэг.
  3. Хоёр зургийг өөр өөр контурын хувьд угсарсан.
  4. Энэ нь хурдан ажилладаг, учир нь Кэшийг аль болох их ашигладаг - werf-ийн шинэ хувилбар гарах эсвэл GitHub дэгээг шалгахаар дуудах үед зөвхөн өөрчилсөн хувилбартай харгалзах олдворыг дахин бүтээдэг.
  5. Ашиглагдаагүй зургуудыг устгах талаар бодох шаардлагагүй: werf бодлогын дагуу цэвэрлэх нь Docker Registry-г эмх цэгцтэй байлгах болно.

үр дүн нь

  • Werf-ийг ашиглах нь угсралт өөрөө болон гадаад репозитортой ажиллах үед кэш хийснээр угсралт хурдан ажиллах боломжийг олгодог.
  • Гадны Git репозиторуудтай ажиллах нь репозиторийг бүхэлд нь хувилах эсвэл дугуйг оновчлох төвөгтэй логикоор дахин зохион бүтээх хэрэгцээг арилгадаг. werf нь кэш ашигладаг бөгөөд клончлолыг зөвхөн нэг удаа хийж, дараа нь ашигладаг fetch мөн шаардлагатай үед л.
  • Барилгын тохиргооны файлд Go загваруудыг ашиглах чадвар werf.yaml үр дүн нь гадны өгөгдлөөс хамаарах угсралтыг тайлбарлах боломжийг танд олгоно.
  • Werf-д mount ашиглах нь олдворуудыг цуглуулах ажлыг ихээхэн хурдасгадаг - кэшийн улмаас бүх дамжуулах хоолойд нийтлэг байдаг.
  • werf нь цэвэрлэх тохиргоог хялбар болгодог бөгөөд энэ нь динамикаар барьж байгуулахад онцгой ач холбогдолтой юм.

PS

Мөн манай блог дээрээс уншина уу:

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх