バージョン管理されたドキュメント サイトの例を使用した、werf を使用した Docker イメージの動的なアセンブリとデプロイメント

GitOps ツールについてはすでに何度か話しました。 ワーフそして今回は、プロジェクト自体のドキュメントを使用してサイトを組み立てた経験を共有したいと思います。 ワーフアイオ (ロシア語版は en.werf.io）。これは通常の静的サイトですが、動的な多数のアーティファクトを使用して構築されているという点で、そのアセンブリは興味深いものです。

サイト構造の微妙な違いに踏み込みます。すべてのバージョンに共通のメニュー、リリースに関する情報を含むページなどを生成します。 - 我々はしません。代わりに、動的アセンブリの問題と機能、およびそれに付随する CI/CD プロセスに少し焦点を当てましょう。

はじめに: サイトの仕組み

まず、werf ドキュメントはコードとともに保存されます。これにより、一般にこの記事の範囲を超える特定の開発要件が課せられますが、少なくとも次のことが言えます。

• 新しい werf 関数はドキュメントを更新せずにリリースすべきではありません。逆に、ドキュメントの変更は werf の新しいバージョンのリリースを意味します。
• このプロジェクトはかなり集中的な開発を行っています。新しいバージョンは 1 日に数回リリースされることがあります。
• 新しいバージョンのドキュメントを使用してサイトを展開するための手動操作は、少なくとも面倒です。
• プロジェクトはセマンティックなアプローチを採用しています バージョン管理、5つの安定性チャンネルを備えています。リリース プロセスでは、安定性が高まる順にチャネルを介してバージョンを順次通過させます。つまり、アルファ版から盤石版までです。
• このサイトにはロシア語版があり、メイン (英語) バージョンと並行して「存続および発展」しています (つまり、コンテンツが更新されています)。

この「インナーキッチン」をすべてユーザーから隠し、「ちょうどいい」ものを提供するために、私たちは次のことを行いました。 別個の werf インストールおよび更新ツール - です マルチワーフ。使用する準備ができているリリース番号と安定性チャネルを指定するだけで、multiwerf がチャネルに新しいバージョンがあるかどうかを確認し、必要に応じてダウンロードします。

Web サイトのバージョン選択メニューでは、各チャネルの werf の最新バージョンが入手可能です。デフォルトでは、アドレスによって werf.io/ドキュメント 最新リリースの最も安定したチャネルのバージョンが開きます。これは検索エンジンによってもインデックス付けされます。チャネルのドキュメントは別のアドレスから入手できます (たとえば、 werf.io/v1.0-beta/ドキュメント ベータ リリース 1.0 の場合）。

合計すると、このサイトでは次のバージョンが利用可能です。

1. root (デフォルトで開きます)、
2. 各リリースのアクティブな更新チャネルごとに (たとえば、 werf.io/v1.0-ベータ).

サイトの特定のバージョンを生成するには、通常、次のようにコンパイルするだけで十分です。 ジキルディレクトリ内で実行することで /docs werfリポジトリ対応コマンド(jekyll build)、必要なバージョンの Git タグに切り替えた後。

あとは次のことを付け加えるだけです。

• ユーティリティ自体 (werf) がアセンブリに使用されます。
• CI/CD プロセスは GitLab CI に基づいて構築されています。
• もちろん、これらはすべて Kubernetes で実行されます。

タスク

ここで、説明されているすべての詳細を考慮してタスクを作成しましょう。

1. 更新チャネルで wef バージョンを変更した後 サイト上のドキュメントは自動的に更新される必要があります.
2. 開発のためには、次のことができる必要があります。 サイトのプレビュー バージョンを表示する.

対応する Git タグから任意のチャネルのバージョンを変更した後、サイトを再コンパイルする必要がありますが、イメージを構築する過程で次の機能が得られます。

• チャネル上のバージョンのリストは変更されるため、バージョンが変更されたチャネルのドキュメントを再構築するだけで済みます。結局のところ、すべてを再構築するのはあまり良いことではありません。
• リリースのチャネルのセットは変更される場合があります。たとえば、ある時点では、早期アクセス 1.1 リリースよりも安定したバージョンがチャネル上に存在しない可能性がありますが、時間の経過とともにそれらが表示されるようになります。この場合、アセンブリを手動で変更する必要はありませんか?

これは、ことが判明 アセンブリは外部データの変更に依存します.

具現化

アプローチの選択

あるいは、必要な各バージョンを Kubernetes の個別のポッドとして実行できます。このオプションは、クラスター内のオブジェクトの数が増えることを意味し、安定した werf リリースの数が増えるにつれて増加します。そして、これは、より複雑なメンテナンスを意味します。各バージョンには独自の HTTP サーバーがあり、負荷はわずかです。もちろん、これにはより多くのリソースコストもかかります。

私たちは同じ道をたどりました 必要なすべてのバージョンを 1 つのイメージにまとめます。サイトのすべてのバージョンのコンパイルされた静的情報は NGINX のコンテナーに配置され、対応するデプロイメントへのトラフィックは NGINX Ingress 経由で送信されます。シンプルな構造 (ステートレス アプリケーション) により、Kubernetes 自体を使用して (負荷に応じて) デプロイメントを簡単にスケールできます。

より正確には、2 つのイメージを収集しています。1 つは実稼働回路用で、2 番目は開発回路用の追加イメージです。追加のイメージは、メインのイメージとともに開発回線でのみ使用 (起動) され、レビュー コミットからのサイトのバージョンが含まれており、それらの間のルーティングは Ingress リソースを使用して実行されます。

werf vs git クローンとアーティファクト

すでに述べたように、ドキュメントの特定のバージョンのサイト静的情報を生成するには、適切なリポジトリ タグに切り替えてビルドする必要があります。ビルドするたびにリポジトリのクローンを作成し、リストから適切なタグを選択することによってこれを行うこともできます。ただし、これはかなりリソースを大量に消費する操作であり、さらに、重要な命令を記述する必要があります...もう 1 つの重大な欠点は、このアプローチではアセンブリ中に何かをキャッシュする方法がないことです。

ここでは、werf ユーティリティ自体が役に立ち、以下を実装します。 スマートキャッシング そしてあなたに使用を許可します 外部リポジトリ。 werf を使用してリポジトリからコードを追加すると、ビルドが大幅に高速化されます。 werf は基本的にリポジトリのクローンを 1 回作成してから実行します。 のみ fetch 必要であれば。さらに、リポジトリからデータを追加するときに、必要なディレクトリのみを選択できます (この場合、これはディレクトリです) docs）、追加されるデータの量が大幅に削減されます。

Jekyll は静的データをコンパイルするために設計されたツールであり、最終イメージには必要ないため、でコンパイルするのが論理的です。 ワーフアーティファクト、そして最終的な画像に コンパイル結果のみをインポートする.

werf.yaml を書きます

そこで、各バージョンを個別の werf アーティファクトにコンパイルすることにしました。しかし、私たちは 組み立て中にこれらのアーティファクトがどれだけ発生するかはわかりませんそのため、固定のビルド構成を作成することはできません (厳密に言えば、まだ作成できますが、完全に効果があるわけではありません)。

werf を使用すると、 Go テンプレート 設定ファイル内 (werf.yaml)、これにより可能になります オンザフライで構成を生成する 外部データ（必要なもの）に応じて。この場合の外部データは、バージョンとリリースに関する情報であり、これに基づいて必要な数のアーティファクトを収集し、その結果、次の 2 つのイメージを取得します。 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 (パイプラインの実行時に取得されるアーティファクト)。これはサイトをコンパイルするときに必要ですが、記事のコンテキストでは、その状態に依存するため興味深いものです。 1 つのアーティファクトのみの再組み立て — サイトのルート バージョンのアーティファクト (他のアーティファクトでは必要ありません)。

これは条件文を使用して実装されます if Go のテンプレートとデザイン {{ $Root.Files.Get "releases.yml" | sha256sum }} ステージで ステージ。次のように動作します: ルート バージョン (変数) のアーティファクトをビルドするとき .Channel 等しい root) ファイルハッシュ releases.yml Ansible タスクの名前の一部であるため、ステージ全体の署名に影響します (パラメーター name）。したがって、変更するときは、 コンテンツ ファイル releases.yml 対応するアーティファクトが再組み立てされます。

外部リポジトリの操作にも注意してください。からのアーティファクトのイメージで ワーフリポジトリ、ディレクトリのみが追加されます /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 チャネルおよびリリース バージョンのアーティファクトをインポートし、以前に採用したアーティファクトの命名規則に従います。各アーティファクトには 2 つの言語のサイトのバージョンが保存されているため、それらを構成で指定された場所にインポートします。

最終イメージの説明 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 -}}

追加のイメージは、メインのイメージとともに開発回路上で起動されますが、サイトの 2 つのバージョンのみが含まれています。レビュー コミットからのバージョンと、サイトのルート バージョンです (一般的なアセットと、覚えているのであれば、 、リリースデータ）。したがって、追加のイメージはインポート セクション (そしてもちろん名前) がメインのイメージと異なります。

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これにより、2 つの 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 それでした 同じ 少なくとも 1 つのパイプライン内で。この条件が満たされない場合、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 パイプライン ステージであるビルドとデプロイを使用してビルドとデプロイを行うことができます。 GitHub werf リポジトリからのフックを使用してパイプライン自体を起動します (つまり、GitHub 上のリポジトリに変更があった場合)。それらのデータは、セクションの GitLab プロジェクト プロパティにあります。 CI/CD 設定 -> パイプライン トリガー、次に、対応する Webhook を 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 はステージからビルドステージに 2 つのアーティファクトを追加します プリビルドしたがって、次の構成を使用して、準備された入力データを含む変数をエクスポートします。 source common_envs.sh。スケジュールに従ってパイプラインを起動する場合を除き、すべてのケースでビルド ステージを開始します。スケジュールに従って、クリーニング用のパイプラインを実行します。この場合、組み立てを行う必要はありません。

デプロイメント段階では、YAML テンプレートを使用して、運用回線と開発回線へのデプロイメントに分けて 2 つのタスクを説明します。

.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 レジストリ内のプロジェクトは、未使用のイメージから継続的に成長することがなくなります。

実践的な部分の最後に、この記事の完全なリストは次のリンクから入手できることを思い出してください。 Gitの:

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

結果

1. バージョンごとに 1 つのアーティファクトという論理アセンブリ構造を受け取りました。
2. アセンブリはユニバーサルであり、werf の新しいバージョンがリリースされたときに手動で変更する必要はありません。Web サイト上のドキュメントは自動的に更新されます。
3. 2 つの画像が異なる輪郭に対して組み立てられています。
4. 作業が早いので、キャッシュは可能な限り使用されます。werf の新しいバージョンがリリースされるか、レビュー コミットのために GitHub フックが呼び出されるとき、変更されたバージョンの対応するアーティファクトのみが再構築されます。
5. 未使用のイメージの削除について考える必要はありません。werf ポリシーに従ってクリーニングすると、Docker レジストリが正常に保たれます。

所見

• werf を使用すると、アセンブリ自体のキャッシュと外部リポジトリを操作するときのキャッシュの両方により、アセンブリを迅速に動作させることができます。
• 外部 Git リポジトリを使用すると、毎回リポジトリ全体のクローンを作成したり、難しい最適化ロジックを使用して車輪を再発明したりする必要がなくなります。 werf はキャッシュを使用してクローン作成を 1 回だけ実行し、その後、 fetch そして必要な場合にのみ。
• ビルド構成ファイルで Go テンプレートを使用する機能 werf.yaml 結果が外部データに依存するアセンブリを記述することができます。
• werf でマウントを使用すると、すべてのパイプラインに共通のキャッシュにより、アーティファクトの収集が大幅に高速化されます。
• wef を使用すると、クリーンアップの構成が簡単になります。これは、動的に構築する場合に特に重要です。

PS

私たちのブログもお読みください:

• «新しいアプリケーション リリースを Kubernetes に配信する際のコマンドの実行";
• «werf と GitLab CI を使用して同じタイプのマイクロサービスを構築してデプロイする";
• «wef を使用して複雑な Helm チャートを展開する";
• «werf 1.0 安定版の紹介: GitOps とそれとの関係、ステータス、計画'。

出所： habr.com