バージョン管理されたドキュメントサイトの例を使用して、werf で Docker イメージを動的にビルドおよびデプロイする

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

すべてのバージョンに共通のメニューやリリースに関する情報を含むページなどの生成といったサイト構造のニュアンスについては説明しません。代わりに、動的アセンブリの問題と機能、および付随する CI/CD プロセスについて少し焦点を当てます。

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

まず、werfのドキュメントがコードと一緒に保存されるという事実から始めましょう。これは開発に一定の要件を課しますが、この記事の範囲外であることは概ね理解できますが、少なくとも以下の点を指摘できます。

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

この「内部の仕組み」をユーザーから隠して、「ただ動作する」ものを提供するために、私たちは werfのインストールとアップデートのための別のツール - です マルチワーフ使用するリリース番号と安定性チャネルを指定するだけで、multiwerf はチャネルに新しいバージョンがあるかどうかを確認し、必要に応じてダウンロードします。

werfの最新バージョンは、サイトのバージョン選択メニューの各チャンネルで利用可能です。デフォルトでは、 werf.io/ドキュメント 最新リリースの最も安定したチャンネルバージョンが公開され、検索エンジンにもインデックスされます。チャンネルのドキュメントは別のアドレス（例： werf.io/v1.0-beta/ドキュメント (ベータリリース 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 内で必要なバージョンごとに個別のポッドとして実行することもできます。このオプションでは、クラスター内のオブジェクト数が増加し、安定した werf リリースの数が増えるにつれてオブジェクト数も増加します。また、これはメンテナンスの複雑化を招きます。各バージョンにはそれぞれ負荷の小さい HTTP サーバーが用意されるためです。当然、リソースコストも増加します。

私たちは同じ道を行きました 必要なすべてのバージョンを 1 つのイメージにビルドしますサイトの全バージョンの統計データはNGINXコンテナに格納され、対応するデプロイメントへのトラフィックはNGINX Ingressを介して送信されます。ステートレスアプリケーションというシンプルな構造により、Kubernetes自体を使用して、負荷に応じてデプロイメントを簡単にスケールできます。

より正確に言うと、2つのイメージを構築します。1つは本番環境用、もう1つは開発環境用の追加イメージです。追加イメージは、メインイメージと共に開発環境用でのみ使用（実行）され、レビューコミットのサイトバージョンを含みます。これらのイメージ間のルーティングはIngressリソースを使用して実行されます。

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

前述の通り、特定のバージョンのドキュメントのサイト統計情報を生成するには、対応するリポジトリタグに切り替えてビルドする必要があります。また、ビルドのたびにリポジトリをクローンし、リストから対応するタグを選択することもできます。ただし、これはかなりリソースを消費する操作であり、さらに複雑な命令を記述する必要もあります。さらに、このアプローチではビルド中に何もキャッシュできないという大きな欠点もあります。

ここでwerfユーティリティ自体が私たちを助け、実装します スマートキャッシュ そして、あなたは 外部リポジトリwerfを使ってリポジトリからコードを追加すると、werfは基本的にリポジトリを一度クローンしてから実行するので、ビルド速度が大幅に向上します。 のみ 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 （パイプライン実行時に得られる成果物）。これはサイトをコンパイルする際に必要となるが、この記事の文脈では、その状態が以下の要素に依存するため、興味深い。 たった一つの遺物の再構成 — サイトのルート バージョンのアーティファクト (他のアーティファクトでは必要ありません)。

これは条件演算子を使用して実装されます。 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 チャンネルとリリースバージョンのアーティファクトをインポートし、先ほど採用したアーティファクトの命名規則に従います。各アーティファクトには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パイプラインの標準ステージであるビルドとデプロイを使ってビルドとデプロイを行うことができます。パイプライン自体は、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はステージからビルドステージに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 Chartテンプレートで使用されます。テンプレートの内容はここでは提供しませんが、ここでは以下のリンクから参照できます。 記事のリポジトリ.

最後の仕上げ

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 Registry内のイメージを削除する権限を持つトークンでDocker Registryにログインする必要があります（GitLab CIタスクで自動的に発行されるトークンにはそのような権限はありません）。トークンは事前にGitLabで作成し、その値を環境変数に指定する必要があります。 WERF_IMAGES_CLEANUP_PASSWORD プロジェクト （CI/CD設定 -> 変数）.

必要なスケジュールで清掃タスクを追加するには、 CI/CD ->
日程.

これで完了です。Docker Registry プロジェクトは、未使用のイメージから継続的に拡大することはなくなります。

実践的な部分の結論として、この記事の完全なリストは以下で入手可能であることをお知らせしたいと思います。 Gitの:

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

結果

1. 論理アセンブリ構造（バージョンごとに 1 つのアーティファクト）が得られました。
2. アセンブリは汎用的であり、werf の新しいバージョンがリリースされても手動での変更は必要ありません。サイト上のドキュメントは自動的に更新されます。
3. 異なる輪郭に対して 2 つの画像が収集されます。
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安定版のご紹介: GitOpsとは何の関係があるのか​​、現状と計画'。

出所： habr.com