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

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

사이트 구조의 미묘한 부분을 설명하겠습니다. 모든 버전에 대한 공통 메뉴 생성, 릴리스에 대한 정보가 있는 페이지 등. 자세한 내용은 설명하지 않겠습니다. 대신, 동적 빌드의 문제점과 세부 사항, 그리고 관련 CI/CD 프로세스에 대해 간략히 살펴보겠습니다.

소개: 사이트 작동 방식

먼저, werf에 대한 설명서가 코드와 함께 저장되어 있다는 사실부터 살펴보겠습니다. 여기에는 일반적으로 이 기사의 범위를 벗어나는 특정 디자인 요구 사항이 제시되지만 최소한 다음과 같이 말할 수 있습니다.

• 새로운 werf 기능은 문서를 업데이트하지 않고는 출시되어서는 안 되며, 반대로 문서가 변경되면 새로운 버전의 werf가 출시된다는 것을 의미합니다.
• 이 프로젝트는 매우 집중적으로 개발되었습니다. 하루에 여러 번 새로운 버전이 출시될 수 있습니다.
• 새로운 버전의 문서를 사이트에 배포하기 위한 수동 작업은 적어도 지루한 작업입니다.
• 이 프로젝트는 의미론적 접근 방식을 채택합니다. 버전 관리, 5개의 안정성 채널이 있습니다. 방출 과정에는 안정성이 높아지는 순서대로 채널을 통해 버전을 순차적으로 전달하는 과정이 포함됩니다. 알파에서 암석처럼 단단한 것까지.
• 이 사이트에는 러시아어 버전이 있는데, 이 버전은 주 버전(즉, 영어)과 동시에 "생존하고 발전"(즉, 콘텐츠가 업데이트)합니다.

사용자에게 이 모든 "내부 작동"을 숨기고 "그냥 작동하는" 것을 제공하기 위해 우리는 만들었습니다. werf 설치 및 업데이트를 위한 별도 도구 -가요 멀티워프. 사용하려는 릴리스 번호와 안정화 채널을 지정하기만 하면 multiwerf가 해당 채널에 새로운 버전이 있는지 확인하고 필요한 경우 다운로드합니다.

최신 버전의 werf는 사이트의 버전 선택 메뉴에서 각 채널에서 사용할 수 있습니다. 기본적으로 주소에서 werf.io/문서 최신 릴리스에 대한 가장 안정적인 채널 버전이 오픈되었으며, 검색 엔진에서도 인덱싱됩니다. 채널에 대한 문서는 별도의 주소에서 제공됩니다(예: werf.io/v1.0-beta/documentation 베타 릴리스 1.0의 경우).

전체적으로 이 사이트에는 다음과 같은 버전이 있습니다.

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

일반적으로 사이트의 특정 버전을 생성하려면 다음을 사용하여 컴파일하면 됩니다. 지킬디렉토리에서 실행 중 /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은 정적 파일을 컴파일하도록 설계된 도구이며 최종 이미지에는 필요하지 않으므로 다음을 컴파일하는 것이 논리적입니다. 아티팩트 워프, 그리고 최종 이미지에서 컴파일 결과만 가져오기.

우리는 werf.yaml을 작성합니다

그래서 우리는 각 버전을 별도의 werf 아티팩트로 컴파일하기로 결정했습니다. 그러나 우리는 우리는 조립 중에 이러한 유물이 얼마나 많이 있을지 모릅니다.따라서 고정된 빌드 구성을 작성할 수 없습니다(엄밀히 말하면 작성할 수는 있지만 그다지 효율적이지 않습니다).

werf를 사용하면 다음을 사용할 수 있습니다. Go 템플릿 구성 파일에서 (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 환경 변수에서 값을 할당하여 Go 템플릿 변수를 만듭니다.

{{ $_ := 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 Go 템플릿 및 구성 요소 {{ $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 Registry 프로젝트가 더 이상 사용되지 않는 이미지에서 계속 커지지 않습니다.

실제적인 부분을 마무리하면서 기사의 전체 목록이 다음에서 제공된다는 점을 상기시켜 드리고 싶습니다. 힘내:

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

결과

1. 우리는 논리적인 조립 구조를 얻었습니다. 버전당 하나의 아티팩트입니다.
2. 이 어셈블리는 보편적이며 werf의 새로운 버전이 출시될 때 수동으로 변경할 필요가 없습니다. 사이트의 문서는 자동으로 업데이트됩니다.
3. 서로 다른 윤곽선에 대해 두 개의 이미지가 수집되었습니다.
4. 캐싱을 최대한 활용하기 때문에 빠르게 작동합니다. werf의 새 버전이 출시되거나 GitHub 후크에서 검토 커밋을 요청하면 수정된 버전이 포함된 해당 아티팩트만 다시 빌드됩니다.
5. 사용하지 않는 이미지를 삭제하는 것에 대해 걱정할 필요가 없습니다. werf 정책 기반 정리를 통해 Docker 레지스트리를 깔끔하게 유지할 수 있습니다.

조사 결과

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

PS

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

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

출처 : habr.com