werf 1.1 リリース: 現在のビルダーの改善と将来の計画

ワーフ は、アプリケーションを構築して Kubernetes に配信するためのオープンソース GitOps CLI ユーティリティです。 約束通り、 バージョンv1.0のリリース これは、werf への新機能の追加と従来のアプローチの見直しの始まりとなりました。 この度、リリース v1.1 を発表できることを嬉しく思います。これは開発における大きな一歩であり、将来の基盤となります。 コレクタ ワーフ。 現在このバージョンは次の場所で利用可能です チャンネル 1.1 EA.

このリリースの基礎は、ステージ ストレージの新しいアーキテクチャと、両方のコレクター (Stapel と Dockerfile) の作業の最適化です。 新しいストレージ アーキテクチャにより、複数のホストから分散アセンブリを実装したり、同じホスト上で並列アセンブリを実装したりできる可能性が広がります。

作業の最適化には、ステージ署名を計算する段階で不要な計算を削除したり、ファイルのチェックサムを計算するメカニズムをより効率的なものに変更したりすることが含まれます。 この最適化により、werf を使用したプロジェクトのビルドの平均時間が短縮されます。 すべてのステージがキャッシュ内に存在する場合のアイドル ビルド ステージ-ストレージ、本当に速くなりました。 ほとんどの場合、ビルドの再開には 1 秒もかかりません。 これは、チームの作業プロセスの段階を検証する手順にも当てはまります。 werf deploy и werf run.

また、このリリースでは、コンテンツごとに画像をタグ付けする戦略が登場しました - コンテンツベースのタグ付け、現在デフォルトで有効になっており、唯一推奨されるものです。

werf v1.1 の主な革新を詳しく見ていき、同時に将来の計画についてもお話しましょう。

werf v1.1 では何が変わりましたか?

キャッシュからステージを選択するための新しいステージ命名形式とアルゴリズム

新しい芸名の生成ルール。 各ステージ ビルドは、署名 (v2 の場合と同様) と一意の一時識別子の 1.0 つの部分で構成される一意のステージ名を生成するようになりました。

たとえば、完全なステージ イメージ名は次のようになります。

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

...または一般的に:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

ここに：

• SIGNATURE ステージ署名です。ステージ コンテンツの識別子を表し、このコンテンツを作成した Git での編集履歴に依存します。
• TIMESTAMP_MILLISEC 新しいイメージの構築時に生成される、保証された一意のイメージ識別子です。

キャッシュからステージを選択するアルゴリズムは、Git コミットの関係のチェックに基づいています。

1. Werf は特定のステージのシグネチャを計算します。
2. В ステージ-ストレージ 特定の署名には複数の段階がある場合があります。 Werf は、署名に一致するすべてのステージを選択します。
3. 現在のステージが Git (git-archive、Git パッチを含むカスタム ステージ) にリンクされている場合: install, beforeSetup, setup; または git-latest-patch)、その後、werf は、現在のコミット (ビルドが呼び出される) の祖先であるコミットに関連付けられたステージのみを選択します。
4. 残りの適切なステージから、作成日が最も古いステージが XNUMX つ選択されます。

異なる Git ブランチのステージに同じ署名を付けることができます。 ただし、werf は、たとえ署名が一致したとしても、異なるブランチに関連付けられたキャッシュがこれらのブランチ間で使用されることを防ぎます。

→ ドキュメント.

ステージストレージにステージを作成および保存するための新しいアルゴリズム

キャッシュからステージを選択するときに、werf が適切なステージを見つけられない場合、新しいステージを組み立てるプロセスが開始されます。

複数のプロセス (XNUMX つ以上のホスト上) がほぼ同時に同じステージの構築を開始できることに注意してください。 Werf は楽観的なブロック アルゴリズムを使用します ステージ-ストレージ 新しく収集した画像を保存した瞬間 ステージ-ストレージ。 このようにして、新しいステージのビルドの準備ができたら、werf ブロックが ステージ-ストレージ 適切な画像が存在しない場合にのみ、新たに収集した画像をそこに保存します。 (署名およびその他のパラメータによる - キャッシュからステージを選択するための新しいアルゴリズムを参照してください).

新しく組み立てられたイメージは、次の方法によって一意の識別子を持つことが保証されます。 TIMESTAMP_MILLISEC (新しいステージの命名形式を参照)。 場合に応じて ステージ-ストレージ 適切なイメージが見つかると、werf は新しくコンパイルされたイメージを破棄し、キャッシュからのイメージを使用します。

言い換えれば、イメージの構築を完了する最初のプロセス (最速のプロセス) が、それをステージ ストレージに保存する権利を取得します (そして、この単一のイメージがすべてのビルドに使用されます)。 遅いビルド プロセスによって、より高速なプロセスが現在のステージのビルド結果を保存して次のビルドに進むことが妨げられることはありません。

→ ドキュメント.

Dockerfile ビルダーのパフォーマンスの向上

現時点では、Dockerfile から構築されたイメージのステージのパイプラインは XNUMX つのステージで構成されています。 dockerfile。 署名を計算するときに、ファイルのチェックサムが計算されます context、組み立て時に使用します。 この改善が行われる前は、werf はすべてのファイルを再帰的に調べ、各ファイルのコンテキストとモードを合計することでチェックサムを取得していました。 v1.1 以降、werf は Git リポジトリに保存されている計算されたチェックサムを使用できるようになりました。

アルゴリズムは以下に基づいています git ls-tree。 このアルゴリズムでは、次のレコードが考慮されます。 .dockerignore 必要な場合にのみファイル ツリーを再帰的に走査します。 したがって、ファイル システムの読み取りと、アルゴリズムのサイズへの依存を切り離しました。 context 重要ではありません。

このアルゴリズムは追跡されていないファイルもチェックし、必要に応じてチェックサムにそれらのファイルを考慮します。

ファイルインポート時のパフォーマンスの向上

werf v1.1 のバージョンは、次の場合に rsync サーバーを使用します。 アーティファクトとイメージからのファイルのインポート。 以前は、インポートはホスト システムからのディレクトリ マウントを使用して XNUMX つの手順で行われていました。

macOS でのインポートのパフォーマンスは Docker ボリュームによって制限されなくなり、インポートは Linux や Windows と同じ時間で完了します。

コンテンツベースのタグ付け

Werf v1.1 は、画像コンテンツによるいわゆるタグ付けをサポートしています - コンテンツベースのタグ付け。 結果として得られる Docker イメージのタグは、それらのイメージの内容によって異なります。

コマンドを実行するとき werf publish --tags-by-stages-signature または werf ci-env --tagging-strategy=stages-signature いわゆる、公開された画像 ステージサイン 画像。 各画像には、この画像のステージの独自の署名がタグ付けされています。署名は、各ステージの通常の署名と同じルールに従って個別に計算されますが、画像の一般的な識別子です。

画像ステージの署名は次の要素によって決まります。

1. この画像の内容。
2. このコンテンツにつながる Git の変更履歴。

Git リポジトリには、イメージ ファイルの内容を変更しないダミー コミットが常に存在します。 たとえば、コメントのみを含むコミットやマージ コミット、またはイメージにインポートされない Git 内のファイルを変更するコミットなどです。

コンテンツベースのタグ付けを使用すると、イメージの内容が変更されていなくても、イメージ名の変更による Kubernetes のアプリケーション ポッドの不必要な再起動の問題が解決されます。 ちなみに、これが、XNUMX つのアプリケーションの多数のマイクロサービスを XNUMX つの Git リポジトリに保存できない理由の XNUMX つです。

また、コンテンツベースのタグ付けは、Git ブランチでのタグ付けよりも信頼性の高いタグ付け方法です。これは、結果として得られるイメージのコンテンツが、同じブランチの複数のコミットをアセンブルするために CI システムでパイプラインが実行される順序に依存しないためです。

それが重要だ：これから始める ステージ署名 - です 唯一推奨されるタグ付け戦略。 コマンドでデフォルトで使用されます。 werf ci-env (別のタグ付けスキームを明示的に指定しない限り)。

→ ドキュメント。 この機能については、別の出版物でも取り上げる予定です。 更新しました (3 月 XNUMX 日): 詳細記事 出版された.

ロギングレベル

ユーザーは出力を制御し、ログレベルを設定し、デバッグ情報を操作できるようになりました。 オプションを追加しました --log-quiet, --log-verbose, --log-debug.

デフォルトでは、出力には最小限の情報が含まれます。

詳細な出力を使用する場合 (--log-verbose) werf がどのように機能するかを確認できます。

詳細な出力 (--log-debug) には、werf デバッグ情報に加えて、使用されたライブラリのログも含まれています。 たとえば、Docker レジストリとの対話がどのように行われるかを確認し、かなりの時間が費やされた場所を記録することもできます。

さらなる計画

警告！ 以下で説明するオプションにはマークが付いています v1.1 このバージョンでは、その多くが近い将来に利用可能になる予定です。 アップデートは自動アップデートによって行われます マルチワーフ使用時。 これらの機能は、v1.1 機能の安定した部分には影響しません。これらの機能の外観には、既存の構成にユーザーが手動で介入する必要はありません。

さまざまな Docker レジストリ実装の完全なサポート (新規)

• バージョン: v1.1
• 日程: XNUMX月
• 問題

目標は、ユーザーが werf を使用するときに制限なくカスタム実装を使用できるようにすることです。

現在、完全なサポートを保証する次の一連のソリューションを特定しています。

• デフォルト (ライブラリ/レジストリ)*、
• AWS ECR
• アズール*、
• ドッカーハブ
• GCR*、
• GitHub パッケージ
• GitLab レジストリ*、
• 港*、
• 岸壁。

現在 werf によって完全にサポートされているソリューションにはアスタリスクが付いています。 他の人にはサポートがありますが、制限があります。

XNUMX つの主な問題が特定できます。

• 一部のソリューションは Docker Registry API を使用したタグの削除をサポートしていないため、ユーザーは werf の自動クリーンアップを使用できません。 これは、AWS ECR、Docker Hub、および GitHub パッケージに当てはまります。
• 一部のソリューションは、いわゆるネストされたリポジトリ (Docker Hub、GitHub パッケージ、Quay) をサポートしていないか、サポートしていますが、ユーザーは UI または API (AWS ECR) を使用して手動で作成する必要があります。

これらの問題やその他の問題を、ソリューションのネイティブ API を使用して解決していきます。 このタスクには、ワーフ操作の全サイクルをそれぞれのテストでカバーすることも含まれます。

配布イメージビルド(↑)

• バージョン: v1.2 v1.1 (この機能の実装の優先順位が上がりました)
• 日程：XNUMX月～XNUMX月
• 問題

現時点では、werf v1.0 と v1.1 は、イメージの構築と公開、およびアプリケーションの Kubernetes へのデプロイの操作に XNUMX つの専用ホストでのみ使用できます。

werf の分散作業の可能性を広げるには、Kubernetes でのアプリケーションのビルドとデプロイメントが複数の任意のホストで起動され、これらのホストがビルド (一時ランナー) 間で状態を保存しない場合、werf は次の機能を実装する必要があります。ステージ ストアとしての Docker レジストリ。

以前、werf プロジェクトがまだ dapp と呼ばれていたとき、そのような機会がありました。 ただし、この機能を werf に実装するときに考慮する必要がある多くの問題に遭遇しました。

注意。 この機能では、コレクターが Kubernetes ポッド内で動作する必要はありません。 これを行うには、ローカル Docker サーバーへの依存を取り除く必要があります (Kubernetes ポッドでは、プロセス自体がコンテナー内で実行されており、werf はサポートしていないため、ローカル Docker サーバーにアクセスできません)。ネットワーク経由で Docker サーバーと連携します)。 Kubernetes の実行のサポートは別途実装されます。

GitHub Actions の正式サポート (新規)

• バージョン: v1.1
• 日程: XNUMX月
• 問題

werf ドキュメントが含まれています (セクション 参照 и ガイド)、および werf を操作するための公式 GitHub アクション。

さらに、werf が一時的なランナーに対して動作できるようになります。

CI システムとのユーザー対話の仕組みは、プル リクエストにラベルを配置して、アプリケーションを構築/ロールアウトするための特定のアクションを開始することに基づいています。

wef を使用したアプリケーションのローカル開発とデプロイメント (↓)

• バージョン: v1.1
• 日程：XNUMX月～XNUMX月
• 問題

主な目標は、複雑なアクションを必要とせずに、アプリケーションをローカルと運用環境の両方にデプロイするための単一の統合された構成をすぐに実現できるようにすることです。

werf には、アプリケーション コードを編集し、デバッグのために実行中のアプリケーションから即座にフィードバックを受け取るのに便利な動作モードが必要です。

新しいクリーニングアルゴリズム (NEW)

• バージョン: v1.1
• 日程: XNUMX月
• 問題

現在のバージョンの werf v1.1 の手順では cleanup コンテンツベースのタグ付けスキームのイメージをクリーニングする機能はありません。これらのイメージは蓄積されます。

また、現在のバージョンの werf (v1.0 および v1.1) は、タグ付けスキーム (Git ブランチ、Git タグ、または Git コミット) で公開されたイメージに対して異なるクリーンアップ ポリシーを使用します。

Git でのコミット履歴に基づいてイメージをクリーニングするための、すべてのタグ付けスキームに統一された新しいアルゴリズムが発明されました。

• 各 git HEAD (ブランチとタグ) に対して、N1 個の最新のコミットに関連付けられた N2 個以上のイメージを保持しないでください。
• 各 git HEAD (ブランチとタグ) の N1 個の最新コミットに関連付けられた N2 個のステージ イメージを保存してください。
• Kubernetes クラスター リソースで使用されるすべてのイメージを保存します (構成ファイルと名前空間のすべての kube コンテキストがスキャンされます。特別なオプションを使用してこの動作を制限できます)。
• Helm リリースに保存されたリソース構成マニフェストで使用されるすべてのイメージを保存します。
• イメージが git のどの HEAD にも関連付けられておらず (たとえば、対応する HEAD 自体が削除されたため)、Kubernetes クラスターおよび Helm リリースのマニフェストで使用されていない場合、イメージを削除できます。

並列イメージ構築（↓）

• バージョン: v1.1
• 日程: XNUMX月～XNUMX月 XNUMX月*

werf の現在のバージョンは、で説明されているイメージとアーティファクトを収集します。 werf.yaml、順次。 便利で有益な出力を提供するだけでなく、画像とアーティファクトの独立した段階を組み立てるプロセスを並列化する必要があります。

* 注: 分散アセンブリの実装の優先度が高まったため、期限は変更されました。これにより、水平スケーリング機能が追加され、GitHub Actions での werf の使用が可能になります。 並列アセンブリは次の最適化ステップであり、XNUMX つのプロジェクトを組み立てるときに垂直方向のスケーラビリティを提供します。

Helm 3 への移行 (↓)

• バージョン: v1.2
• 日程: XNUMX月～XNUMX月 XNUMX月*

新しいコードベースへの移行を含む ヘルム3 既存のインストールを移行する実証済みの便利な方法です。

* 注: Helm 3 の主要な機能 (3-way マージとティラーなし) はすべて werf にすでに実装されているため、Helm 3 に切り替えても重要な機能は werf に追加されません。 さらに、ヴェルフには、 追加機能 示されているものに加えて。 ただし、この移行は計画に残っており、実行される予定です。

Kubernetesの構成を記述するためのJsonnet（↓）

• バージョン: v1.2
• 日程: XNUMX月～XNUMX月 XNUMX月～XNUMX月

Werf は、Jsonnet 形式での Kubernetes の構成記述をサポートします。 同時に、werf は Helm との互換性を維持し、記述形式を選択できるようになります。

その理由は、多くの人によると、Go テンプレートには参入障壁が高く、これらのテンプレートのコードの理解性も損なわれているためです。

他の Kubernetes 構成記述システム (KusTOMize など) を導入する可能性も検討されています。

Kubernetes 内での作業 (↓)

• バージョン: v1.2
• 日程: XNUMX月～XNUMX月 XNUMX月～XNUMX月

目標: Kubernetes のランナーを使用してイメージが構築され、アプリケーションが配信されるようにします。 それらの。 新しいイメージは、Kubernetes ポッドから直接構築、公開、クリーンアップ、デプロイできます。

この機能を実装するには、まず分散イメージを構築できる必要があります。 (上記の点を参照).

また、Docker サーバーを使用しないビルダーの動作モード (つまり、Kaniko のようなビルドまたはユーザー空間でのビルド) のサポートも必要です。

Werf は、Dockerfile だけでなく、増分リビルドを備えた Stapel ビルダーや Ansible を使用した Kubernetes での構築もサポートします。

オープン開発への一歩

私たちはコミュニティを愛しています (GitHubの, Telegram) そして私たちは、より多くの人が werf の改善に協力し、私たちが進んでいる方向性を理解し、開発に参加してほしいと考えています。

ごく最近に切り替えることが決まりました GitHub プロジェクト ボード 私たちのチームの作業プロセスを明らかにするため。 これで、当面の計画と、次の分野での現在の作業を確認できるようになります。

• ドキュメントとサイト;
• テスト;
• バグと悪いUX;
• 1.1.

以下の問題に対して多くの作業が行われてきました。

• 関係のないものは削除しました。
• 既存のものは、十分な数の詳細と詳細を備えた単一の形式にまとめられています。
• アイデアや提案を含む新しい問題が追加されました。

バージョンv1.1を有効にする方法

現在このバージョンは次の場所で利用可能です チャンネル 1.1 EA (チャンネル内で 安定した и 堅実 安定化が進むとリリースが表示されますが、 ea それ自体はすでに十分に安定して使用できるため、 チャネルを通過しました アルファ и ベータ）。 アクティブ化された マルチワーフ経由 次の方法で:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

まとめ

新しいステージ ストレージ アーキテクチャと、Stapel および Dockerfile ビルダーのビルダー最適化により、werf で分散ビルドと並列ビルドを実装できる可能性が広がります。 これらの機能は間もなく同じ v1.1 リリースに追加され、自動更新メカニズム (ユーザー向け) を通じて自動的に利用可能になります。 マルチワーフ).

このリリースでは、画像コンテンツに基づいたタグ付け戦略が追加されました。 コンテンツベースのタグ付け、これがデフォルトの戦略となっています。 メインのコマンド ログも書き直されました。 werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

次の重要なステップは、分散アセンブリを追加することです。 分散ビルドは、v1.0 以降、並列ビルドよりも優先度が高くなりました。これは、ビルダーの垂直スケーリングと、さまざまな CI/CD システムでの一時的なビルダーのサポート、および GitHub Actions の公式サポートを行う機能など、werf により多くの価値を追加するためです。 。 したがって、並行アセンブリの実装期限が変更されました。 ただし、私たちは両方の可能性をできるだけ早く実装できるよう取り組んでいます。

ニュースをフォローしてください！ ぜひお越しください。 GitHubの問題を作成したり、既存の問題を見つけてプラスを追加したり、PR を作成したり、単にプロジェクトの発展を観察したりすることができます。

PS

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

• «werf 1.0 安定版の紹介: GitOps とそれとの関係、ステータス、計画»
• «werf - Kubernetes の CI / CD 用ツール (概要とビデオレポート)";
• werf のイノベーションに関する一連のメモ:
  • «werf への 3 方向マージ: Helm を「強力に」使用した Kubernetes へのデプロイメント";
  • «wef を使用して複雑な Helm チャートを展開する";
  • «werf でのモノリポジトリとマルチリポジトリのサポートと、Docker レジストリはそれと何の関係がありますか";
  • «通常の Dockerfile を使用して、werf で Docker イメージを構築できるようになりました'。

出所： habr.com