버전이 지정된 문서 사이트의 예를 사용하여 Werf를 사용한 Docker 이미지의 동적 어셈블리 및 배포

우리는 이미 GitOps 도구에 대해 두 번 이상 이야기했습니다. 워프, 이번에는 프로젝트 자체의 문서와 함께 사이트를 구성한 경험을 공유하고 싶습니다. werf.io (러시아어 버전은 en.werf.io). 이것은 일반적인 정적 사이트이지만 동적 수의 아티팩트를 사용하여 구축된다는 점에서 그 어셈블리가 흥미롭습니다.

사이트 구조의 미묘한 차이를 살펴보세요. 모든 버전에 대한 공통 메뉴, 릴리스 정보가 포함된 페이지 등을 생성합니다. - 우리는하지 않습니다. 대신 동적 어셈블리의 문제와 기능에 초점을 맞추고 그에 수반되는 CI/CD 프로세스에 대해 조금 살펴보겠습니다.

소개: 사이트 작동 방식

우선 werf 문서는 해당 코드와 함께 저장됩니다. 이는 일반적으로 이 기사의 범위를 벗어나는 특정 개발 요구 사항을 부과하지만 최소한 다음과 같이 말할 수 있습니다.

• 새로운 werf 기능은 문서를 업데이트하지 않고 출시해서는 안 되며, 반대로 문서의 변경 사항은 werf의 새 버전 출시를 의미합니다.
• 이 프로젝트는 상당히 집중적으로 개발되었습니다. 새 버전은 하루에 여러 번 출시될 수 있습니다.
• 새로운 버전의 문서가 포함된 사이트를 배포하는 수동 작업은 적어도 지루합니다.
• 이 프로젝트는 의미론적 접근 방식을 채택합니다. 버전 관리, 5개의 안정성 채널이 있습니다. 릴리스 프로세스에는 안정성을 높이기 위해 채널을 통해 버전을 순차적으로 전달하는 작업이 포함됩니다. 알파에서 견고한 버전으로;
• 이 사이트에는 기본(즉, 영어) 버전과 병행하여 "살아 있고 발전하는"(즉, 내용이 업데이트되는) 러시아어 버전이 있습니다.

이 모든 "내부 주방"을 사용자에게 숨기고 사용자에게 "작동하는" 것을 제공하기 위해 우리는 그렇게 했습니다. 별도의 werf 설치 및 업데이트 도구 -가요 다인종. 사용할 준비가 된 릴리스 번호와 안정성 채널을 지정하기만 하면 multiwerf가 채널에 새 버전이 있는지 확인하고 필요한 경우 다운로드합니다.

홈페이지 버전 선택 메뉴에서는 각 채널별 최신 버전의 werf를 보실 수 있습니다. 기본적으로 주소로 werf.io/documentation 최신 릴리스에 대해 가장 안정적인 채널 버전이 열립니다. 검색 엔진에서도 색인이 생성됩니다. 채널에 대한 문서는 별도의 주소(예: werf.io/v1.0-beta/documentation 베타 릴리스 1.0의 경우).

전체적으로 사이트에는 다음 버전이 제공됩니다.

1. 루트(기본적으로 열림),
2. 각 릴리스의 각 활성 업데이트 채널에 대해(예: werf.io/v1.0-beta).

특정 버전의 사이트를 생성하려면 일반적으로 다음을 사용하여 컴파일하면 충분합니다. 지킬디렉토리에서 실행하여 /docs werf 저장소 해당 명령(jekyll build), 필요한 버전의 Git 태그로 전환한 후.

다음을 추가하는 일만 남았습니다.

• 유틸리티 자체(werf)가 조립에 사용됩니다.
• CI/CD 프로세스는 GitLab CI를 기반으로 구축되었습니다.
• 물론 이 모든 것은 Kubernetes에서 실행됩니다.

작업

이제 설명된 모든 세부 사항을 고려하는 작업을 공식화해 보겠습니다.

1. 업데이트 채널에서 werf 버전을 변경한 후 사이트의 문서는 자동으로 업데이트되어야 합니다..
2. 개발을 위해서는 때때로 다음을 수행할 수 있어야 합니다. 사이트의 미리보기 버전 보기.

해당 Git 태그에서 채널의 버전을 변경한 후 사이트를 다시 컴파일해야 하지만 이미지를 빌드하는 과정에서 다음 기능을 얻게 됩니다.

• 채널의 버전 목록이 변경되므로 버전이 변경된 채널에 대한 문서를 다시 작성하기만 하면 됩니다. 결국, 모든 것을 다시 재건하는 것은 그리 좋은 일이 아닙니다.
• 릴리스 채널 세트는 변경될 수 있습니다. 예를 들어, 어느 시점에서는 초기 액세스 1.1 릴리스보다 더 안정적인 버전이 채널에 없을 수 있지만 시간이 지남에 따라 나타날 것입니다. 이 경우 어셈블리를 수동으로 변경해야 하지 않습니까?

그것은 밝혀 그 어셈블리는 외부 데이터 변경에 따라 달라집니다..

Реализация

접근법 선택

또는 필요한 각 버전을 Kubernetes에서 별도의 Pod로 실행할 수 있습니다. 이 옵션은 안정적인 Werf 릴리스 수가 증가함에 따라 클러스터의 개체 수가 더 많아진다는 것을 의미합니다. 이는 결국 더 복잡한 유지 관리를 의미합니다. 각 버전에는 자체 HTTP 서버가 있고 로드가 적습니다. 물론 이는 더 많은 자원 비용을 수반합니다.

우리는 같은 길을 택했어요 필요한 모든 버전을 하나의 이미지로 모으기. 사이트의 모든 버전에 대해 컴파일된 통계는 NGINX가 있는 컨테이너에 있으며 해당 배포에 대한 트래픽은 NGINX Ingress를 통해 전달됩니다. 상태 비저장 애플리케이션인 간단한 구조를 통해 Kubernetes 자체를 사용하여 배포(로드에 따라)를 쉽게 확장할 수 있습니다.

더 정확하게 말하면 우리는 두 개의 이미지를 수집하고 있습니다. 하나는 생산 회로용이고 다른 하나는 개발 회로용 추가 이미지입니다. 추가 이미지는 기본 이미지와 함께 개발 회로에서만 사용(실행)되고 검토 커밋의 사이트 버전을 포함하며 이들 사이의 라우팅은 Ingress 리소스를 사용하여 수행됩니다.

werf 대 git 클론 및 아티팩트

이미 언급했듯이 특정 버전의 문서에 대한 사이트 정적을 생성하려면 적절한 저장소 태그로 전환하여 빌드해야 합니다. 또한 빌드할 때마다 저장소를 복제하고 목록에서 적절한 태그를 선택하여 이 작업을 수행할 수도 있습니다. 그러나 이는 리소스를 많이 사용하는 작업이며 더욱이 사소한 지침을 작성해야 합니다. 또 다른 심각한 단점은 이 접근 방식을 사용하면 조립 중에 항목을 캐시할 방법이 없다는 것입니다.

여기서는 werf 유틸리티 자체가 우리를 도와서 구현합니다. 스마트 캐싱 그리고 당신이 사용할 수 있도록 외부 저장소. Werf를 사용하여 저장소에서 코드를 추가하면 빌드 속도가 크게 향상됩니다. werf는 기본적으로 저장소를 한 번 복제한 다음 실행합니다. 만 fetch 필요하다면. 또한 저장소에서 데이터를 추가할 때 필요한 디렉터리만 선택할 수 있습니다. docs), 추가되는 데이터의 양이 크게 줄어듭니다.

Jekyll은 정적 데이터를 컴파일하기 위해 설계된 도구이고 최종 이미지에는 필요하지 않으므로 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를 생성합니다(설정 -> 웹훅).

빌드 단계는 다음과 같습니다.

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 레지스트리가 지속적으로 성장합니다. 따라서 정책에 따라 자동 이미지 정리를 구성하는 것이 필수적입니다. 매우 쉽습니다.

구현하려면 다음이 필요합니다.

• 청소 단계를 추가하세요. .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 레지스트리에 로그인해야 합니다(자동으로 발행된 GitLab CI 작업 토큰은 그렇지 않습니다). 그러한 권리를 갖습니다). 토큰은 GitLab에서 미리 생성되어 있어야 하며 환경 변수에 그 값을 지정해야 합니다. WERF_IMAGES_CLEANUP_PASSWORD 계획 (CI/CD 설정 -> 변수).

필요한 일정에 따라 청소 작업을 추가하는 작업은 다음에서 수행됩니다. CI/CD ->
일정.

그게 다입니다. Docker 레지스트리의 프로젝트는 더 이상 사용되지 않은 이미지로 인해 지속적으로 증가하지 않습니다.

실제 부분이 끝나면 기사의 전체 목록이 다음에서 제공된다는 점을 상기시켜 드리겠습니다. 힘내:

• .gitlab-ci.yml;
• werf.yaml.

결과

1. 버전당 하나의 아티팩트인 논리적 어셈블리 구조를 받았습니다.
2. 어셈블리는 보편적이며 werf의 새 버전이 출시될 때 수동으로 변경할 필요가 없습니다. 웹 사이트의 문서는 자동으로 업데이트됩니다.
3. 서로 다른 윤곽을 위해 두 개의 이미지가 조합됩니다.
4. 효과가 빨리 나오거든요. 캐싱은 가능한 한 많이 사용됩니다. werf의 새 버전이 출시되거나 검토 커밋을 위해 GitHub 후크가 호출되면 변경된 버전이 있는 해당 아티팩트만 다시 빌드됩니다.
5. 사용하지 않는 이미지 삭제에 대해 생각할 필요가 없습니다. werf 정책에 따라 정리하면 Docker 레지스트리가 순서대로 유지됩니다.

조사 결과

• werf를 사용하면 어셈블리 자체의 캐싱과 외부 저장소로 작업할 때의 캐싱으로 인해 어셈블리가 빠르게 작동할 수 있습니다.
• 외부 Git 리포지토리를 사용하면 매번 전체 리포지토리를 복제하거나 까다로운 최적화 논리를 사용하여 바퀴를 다시 만들 필요가 없습니다. werf는 캐시를 사용하고 복제를 한 번만 수행한 다음 다음을 사용합니다. fetch 필요할 때만.
• 빌드 구성 파일에서 Go 템플릿을 사용하는 기능 werf.yaml 결과가 외부 데이터에 따라 달라지는 어셈블리를 설명할 수 있습니다.
• mount in werf를 사용하면 모든 파이프라인에 공통적인 캐시로 인해 아티팩트 수집 속도가 크게 향상됩니다.
• werf를 사용하면 정리를 쉽게 구성할 수 있으며 이는 동적으로 구축할 때 특히 중요합니다.

PS

블로그에서도 읽어보세요.

• «Kubernetes에 새 애플리케이션 릴리스를 제공하는 동안 명령 실행";
• «werf 및 GitLab CI를 사용하여 동일한 유형의 마이크로서비스 구축 및 배포";
• «Werf를 사용하여 복잡한 Helm 차트 출시";
• «werf 1.0 stable 소개: GitOps는 그것과 어떤 관련이 있으며, 상태 및 계획은 무엇입니까?".

출처 : habr.com