werf - Kubernetes の CI / CD 用ツール (概要とビデオレポート)

27月2019日、フェスティバルの一環として開催されたDevOpsConf XNUMXカンファレンスのメインホールにて RIT++ 2019では、「継続的デリバリー」セクションの一部として、「werf - Kubernetes の CI/CD 用ツール」に関するレポートが提供されました。 それらについて話します Kubernetes にデプロイするときに誰もが直面する問題と課題、すぐには気づかない可能性のあるニュアンスについても説明します。 考えられる解決策を分析し、これがオープンソース ツールでどのように実装されるかを示します。 ワーフ.

プレゼンテーション以来、私たちのユーティリティ (以前は dapp として知られていました) は、歴史的なマイルストーンに達しました。 GitHub 上の 1000 スター — ユーザーのコミュニティが成長することで、多くの DevOps エンジニアの作業が楽になることを願っています。

そこで、私たちが紹介するのは、 レポートのビデオ (約 47 分、記事よりもはるかに有益) とその主要な抜粋をテキスト形式で示します。 行く！

Kubernetes へのコードの配信

話はもはやワーフについてではなく、Kubernetes の CI/CD についてのものになります。これは、ソフトウェアが Docker コンテナにパッケージ化されていることを意味します。 (この件については、 2016年レポート)実稼働環境での実行には K8s が使用されます。 (これについて詳しくは、 2017年).

Kubernetes での配信はどのようになりますか?

• コードとそれを構築するための手順が記載された Git リポジトリがあります。 アプリケーションは Docker イメージに組み込まれ、Docker レジストリで公開されます。
• 同じリポジトリには、アプリケーションをデプロイして実行する方法に関する手順も含まれています。 デプロイメント段階では、これらの指示が Kubernetes に送信され、Kubernetes はレジストリから必要なイメージを受け取り、それを起動します。
• さらに、通常はテストもあります。 これらの一部は、画像を公開するときに実行できます。 また、(同じ手順に従って) アプリケーションのコピーを (別の K8s 名前空間または別のクラスターに) デプロイし、そこでテストを実行することもできます。
• 最後に、Git からイベント (またはボタンのクリック) を受け取り、指定されたすべての段階 (ビルド、公開、デプロイ、テスト) を呼び出す CI システムが必要です。

ここにはいくつかの重要な注意事項があります。

1. 不変のインフラストラクチャがあるため (不変のインフラストラクチャ)、すべての段階 (ステージング、本番など) で使用されるアプリケーション イメージ、 必ず XNUMX つあるはずです. これについて、例を挙げて詳しく説明しました。 ここで.
2. コードとしてのインフラストラクチャのアプローチに従っているため (IaC)、アプリケーションコード、それを組み立てて起動するための手順は次のとおりです。 正確に XNUMX つのリポジトリ内で. これについて詳しくは、次を参照してください。 同じレポート.
3. デリバリーチェーン （配達） 通常、アプリケーションはアセンブル、テスト、リリースされたと考えられます。 (リリース段階) それで終わりです - 配達が行われました。 しかし実際には、ユーザーはあなたが展開したものを受け取ります。 ノー それからあなたがそれをプロダクションに納品したとき、そして彼がそこに行くことができて、このプロダクションが機能したとき。 だからデリバリーチェーンは終わると思う 運用段階のみ （走る）、より正確には、コードが運用環境から削除された（新しいコードに置き換えられた）瞬間でもです。

Kubernetes の上記の配信スキームに戻りましょう。これは私たちだけでなく、文字通りこの問題に取り組んだすべての人によって発明されました。 実際、このパターンは現在 GitOps と呼ばれています (この用語とその背後にある考え方について詳しく読むことができます ここで)。 計画の段階を見てみましょう。

ビルドステージ

2019 年には、誰もが Dockerfile の作成方法と実行方法を知っているので、Docker イメージの構築について話すことができそうです。 docker build?.. ここで注意したいニュアンスは次のとおりです。

1. 画像の重み 重要なので、使用してください 多段階本当に動作に必要なアプリケーションだけをイメージに残します。
2. レイヤー数 のチェーンを組み合わせて最小化する必要があります RUN- 意味に応じたコマンド。
3. ただし、これにより問題が追加されます デバッグアセンブリがクラッシュすると、問題の原因となったチェーンから適切なコマンドを見つけなければならないからです。
4. ビルド速度 変更を迅速に展開して結果を確認したいため、重要です。 たとえば、アプリケーションを構築するたびに言語ライブラリの依存関係を再構築する必要はありません。
5. 多くの場合、必要な XNUMX つの Git リポジトリから たくさんの画像これは、一連の Dockerfile (または XNUMX つのファイル内の名前付きステージ) と、それらの順次アセンブリを含む Bash スクリプトによって解決できます。

これは誰もが直面する氷山の一角にすぎません。 しかし、他にも特に次の問題があります。

1. 多くの場合、組み立て段階で何かが必要になります マウント (たとえば、apt のようなコマンドの結果をサードパーティのディレクトリにキャッシュします)。
2. 欲しい Ansible シェルで書く代わりに。
3. 欲しい Docker なしでビルドする (コンテナーを実行できる Kubernetes クラスターがすでにあるのに、このためにすべてを構成する必要がある追加の仮想マシンがなぜ必要なのでしょうか?)。
4. 平行組立これは、Dockerfile からのさまざまなコマンド (マルチステージが使用されている場合)、同じリポジトリの複数のコミット、複数の Dockerfile など、さまざまな方法で理解できます。
5. 分散アセンブリ: 「一時的な」ものをポッドに収集したいと考えています。 キャッシュが消えるため、別の場所に保存する必要があります。
6. 最後に欲望の頂点に名前を付けた オートマジック: リポジトリに移動し、何らかのコマンドを入力して、何をどのように実行するかを正しく理解した上で組み立てられた既製のイメージを取得するのが理想的です。 ただし、個人的には、このようにすべてのニュアンスを予測できるかどうかはわかりません。

そして、ここにプロジェクトがあります:

• moby/ビルドキット — Docker Inc のビルダー (Docker の現在のバージョンにすでに統合されています)。これらすべての問題を解決しようとしています。
• かにこ — Docker なしでビルドできる Google のビルダー。
• Buildpacks.io — 自動魔法、特にレイヤーのリベースを使用した興味深いソリューションを作成しようとする CNCF の試み。
• などの他の多くのユーティリティ ビルダー, 本物のツール/img...

...GitHub でスターがいくつあるか見てみましょう。 つまり、一方では、 docker build 存在して何かができるが、実際には 問題は完全には解決されていない - これの証拠は、代替コレクターの並行開発であり、それぞれが問題の一部を解決します。

ヴェルフでの組み立て

そこで、私たちは次のようになりました ワーフ （以前 有名な ダップのように） — Flant 社が長年にわたって開発してきたオープンソース ユーティリティです。 すべては 5 年前、Dockerfile のアセンブリを最適化する Bash スクリプトから始まり、過去 3 年間、独自の Git リポジトリを備えた XNUMX つのプロジェクトの枠組み内で本格的な開発が行われてきました。 (最初は Ruby で、次に 書き直された Goに変更され、同時に名前が変更されました)。 wef ではどのようなアセンブリの問題が解決されますか?

青色の網掛けの問題はすでに実装されており、並列ビルドは同じホスト内で行われ、黄色で強調表示された問題は夏の終わりまでに完了する予定です。

レジストリへの公開の段階 (公開)

私たちはダイヤルしました docker push... - レジストリにイメージをアップロードする際に何が難しいでしょうか? そして、「画像にはどのようなタグを付けるべきでしょうか?」という疑問が生じます。 それは私たちが持っている理由から起こります ギットフロー (または他の Git 戦略) と Kubernetes を統合しており、業界は Kubernetes での出来事が Git での出来事に確実に従うよう努めています。 結局のところ、Git が唯一の真実の情報源です。

何がそんなに難しいのですか？ 再現性を確保する: 本質的に不変である Git のコミットから （不変）を Docker イメージに変換します。これは同じにしておく必要があります。

それは私たちにとっても重要です 起源を特定するなぜなら、Kubernetes で実行されているアプリケーションがどのコミットから構築されたのかを理解したいからです (その後、差分や同様のことが可能になります)。

タグ付け戦略

XNUMXつ目はシンプルです gitタグ。 というタグが付けられた画像を含むレジストリがあります。 1.0。 Kubernetes にはステージとプロダクションがあり、このイメージがアップロードされます。 Git ではコミットを行い、ある時点でタグを付けます。 2.0。 リポジトリからの指示に従って収集し、タグ付きでレジストリに配置します 2.0。 それをステージに展開し、すべてが順調であれば本番環境に展開します。

このアプローチの問題は、最初にタグを配置し、それからテストしてロールアウトすることだということです。 なぜ？ まず、これは単純に非論理的です。私たちはまだテストすらしていないバージョンのソフトウェアを発行しているのです (チェックするにはタグを付ける必要があるため、他の方法でテストすることはできません)。 次に、このパスは Gitflow と互換性がありません。

番目のオプション - gitコミット+タグ。 master ブランチにはタグがあります 1.0; レジストリ内のそれ - 運用環境にデプロイされたイメージ。 さらに、Kubernetes クラスターにはプレビューおよびステージングの輪郭があります。 次に、Gitflow に従います: 開発用のメイン ブランチ (develop) 新しい機能を作成し、その結果、識別子を使用したコミットが行われます。 #c1。 私たちはそれを収集し、この識別子を使用してレジストリに公開します (#c1）。 同じ識別子を使用してプレビューにロールアウトします。 コミットでも同じことを行います #c2 и #c3.

十分な機能があることに気付いたとき、すべてを安定化し始めます。 Git でブランチを作成する release_1.1 (ベースに #c3 の develop）。 このリリースを収集する必要はありません。なぜなら... これは前のステップで行われました。 したがって、単純にステージングにロールアウトできます。 バグを修正します #c4 そして同様にステージングにロールアウトします。 同時に開発も進んでいます develop、変更は定期的に取得されます。 release_1.1。 ある時点で、コミットがコンパイルされてステージングにアップロードされます。これで満足です (#c25).

次に、リリース ブランチを (早送りで) マージします (release_1.1) マスターで。 このコミットに新しいバージョンのタグを付けます (1.1）。 ただし、このイメージはすでにレジストリに収集されているため、再度収集されないように、既存のイメージに XNUMX 番目のタグを追加するだけです (レジストリにタグが追加されました) #c25 и 1.1）。 その後、本番環境に展開します。

ステージングにアップロードされる画像が XNUMX つだけであるという欠点があります (#c25）、本番環境では少し異なります（1.1)、しかし、これらは「物理的に」レジストリからの同じイメージであることがわかっています。

本当の欠点は、マージ コミットがサポートされていないため、早送りする必要があることです。

さらに進んでトリックを行うこともできます...単純な Dockerfile の例を見てみましょう。

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

次の原則に従って、そこからファイルを構築しましょう。

• 使用された画像の識別子から SHA256 (ruby:2.3 и nginx:alpine)、それらの内容のチェックサムです。
• すべてのチーム (RUN, CMD 等々。）;
• 追加されたファイルからの SHA256。

...そのようなファイルからチェックサム (やはり SHA256) を取得します。 これ サイン Docker イメージのコンテンツを定義するすべてのもの。

図に戻ってみましょう コミットの代わりにそのような署名を使用します、つまり画像に署名を付けます。

これで、たとえば、リリースからマスターへの変更をマージする必要がある場合、実際のマージ コミットを実行できます。識別子は異なりますが、署名は同じになります。 同じ識別子を使用して、イメージを実稼働環境にロールアウトします。

欠点は、どのような種類のコミットが本番環境にプッシュされたかを判断できないことです。チェックサムは一方向にしか機能しません。 この問題は、メタデータを含む追加レイヤーによって解決されます。詳しくは後ほど説明します。

werf でのタグ付け

werf ではさらに進んで、XNUMX つのマシンに保存されないキャッシュを使用して分散ビルドを実行する準備をしています... そこで、XNUMX 種類の Docker イメージをビルドしています。 ステージ и 画像.

werf Git リポジトリには、ビルドのさまざまな段階を説明するビルド固有の手順が保存されます (インストール前, install, セットアップ前, ）。 最初のステップのチェックサムとして定義された署名を持つ最初のステージのイメージを収集します。 次に、ソース コードを追加し、新しいステージ イメージのチェックサムを計算します。これらの操作がすべてのステージに対して繰り返され、その結果としてステージ イメージのセットが得られます。 次に、最終画像を作成します。これには、その起源に関するメタデータも含まれます。 そして、この画像にさまざまな方法でタグ付けします (詳細は後述)。

この後、アプリケーション コードのみが変更された新しいコミットが表示されたとします。 何が起こるか？ コード変更の場合はパッチを作成し、新たなステージイメージを用意します。 その署名は、古いステージ イメージと新しいパッチのチェックサムとして決定されます。 このイメージから新しい最終イメージが形成されます。 他のステージの変更でも同様の動作が発生します。

したがって、ステージ イメージは分散保存できるキャッシュであり、そこからすでに作成されたイメージは Docker レジストリにアップロードされます。

レジストリのクリーニング

タグを削除した後にハングしたままになったレイヤーを削除することについて話しているのではありません。これは Docker レジストリ自体の標準機能です。 ここで話しているのは、大量の Docker タグが蓄積され、その一部が不要になったことは理解しているものの、それらがスペースを占有する (および/またはその費用を支払う) という状況について話しています。

清掃戦略は何ですか?

1. 何もしないこともできます 掃除しないでください。 場合によっては、膨大なタグのもつれを解くよりも、少しお金を払って余分なスペースを確保する方がはるかに簡単な場合があります。 しかし、これはある時点までしか機能しません。
2. フルリセット。 すべてのイメージを削除し、CI システム内の現在のイメージのみを再構築すると、問題が発生する可能性があります。 実稼働環境でコンテナーが再起動されると、まだ誰もテストされていない新しいイメージがロードされます。 これにより、不変のインフラストラクチャという概念は無効になります。
3. 青緑。 XNUMX つのレジストリがオーバーフローし始めたので、イメージを別のレジストリにアップロードします。 前の方法と同じ問題: オーバーフローし始めたレジストリをどの時点でクリアできるか?
4. 時間によって。 1 か月以上前の画像をすべて削除しますか? でも、一ヶ月も更新されていないサービスは必ず存在します…。
5. 手動で すでに削除できるものを判断します。

本当に実行可能なオプションは XNUMX つあります。XNUMX つはクリーニングしない、または Blue-Green + 手動の組み合わせです。 後者の場合は、次のようなことについて話しています。レジストリをクリーンアップする時期が来たと理解したら、新しいレジストリを作成し、たとえば XNUMX か月かけて新しいイメージをすべてそれに追加します。 そして XNUMX か月後、Kubernetes 内のどのポッドがまだ古いレジストリを使用しているかを確認し、それらも新しいレジストリに転送します。

私たちは何に来たのか ワーフ? 私たちは以下を収集します:

1. Git ヘッド: すべてのタグ、すべてのブランチ - 画像内の Git でタグ付けされているすべてが必要であると仮定します (そうでない場合は、Git 自体で削除する必要があります)。
2. 現在 Kubernetes にポンプアウトされているすべてのポッド。
3. 古い ReplicaSet (最近リリースされたもの) のほか、Helm リリースをスキャンしてそこから最新のイメージを選択することも計画しています。

...そしてこのセットからホワイトリスト、つまり削除しない画像のリストを作成します。 他のものはすべて削除し、その後、孤立したステージ画像を見つけて削除します。

デプロイステージ

信頼できる宣言性

デプロイメントで注目したい最初の点は、宣言的に宣言された、更新されたリソース構成のロールアウトです。 Kubernetes リソースを説明する元の YAML ドキュメントは、クラスター内で実際に実行されている結果とは常に大きく異なります。 Kubernetes によって構成が追加されるため、次のようになります。

1. 識別子;
2. サービス情報。
3. 多くのデフォルト値。
4. 現在のステータスのセクション。
5. アドミッション Webhook の一部として行われた変更。
6. さまざまなコントローラー (およびスケジューラー) の作業の結果。

したがって、新しいリソース構成が表示されると (新製品)、現在の「ライブ」構成をそのまま取得して上書きすることはできません (ライブ）。 これを行うには、比較する必要があります 新製品 最後に適用された構成 (最後に適用された）そして転がってください ライブ パッチを受け取りました。

このアプローチはと呼ばれます 2方向のマージ。 たとえば Helm で使用されます。

もあります 3方向のマージ、次の点が異なります。

• 比較する 最後に適用された и 新製品、何が削除されたかを調べます。
• 比較する 新製品 и ライブ、何が追加または変更されたかを確認します。
• 合計されたパッチが適用される ライブ.

私たちは Helm を使用して 1000 以上のアプリケーションをデプロイしているため、実際には双方向のマージを使用しています。 ただし、Helm が正常に動作するのに役立つパッチで解決された多くの問題があります。

実際の展開状況

CI システムは次のイベントに基づいて Kubernetes の新しい構成を生成した後、それを送信して使用します。 （適用する） クラスターに - Helm または kubectl apply。 次に、すでに説明した N ウェイ マージが発生し、これに対して Kubernetes API が CI システムとそのユーザーに承認の応答を返します。

ただし、大きな問題があります。 アプリケーションの成功は展開の成功を意味するものではありません。 Kubernetes がどのような変更を適用する必要があるかを理解し、それを適用したとしても、結果がどうなるかはまだわかりません。 たとえば、フロントエンドでのポッドの更新と再起動は成功する可能性がありますが、バックエンドでは成功しないため、実行中のアプリケーション イメージの異なるバージョンが取得されます。

すべてを正しく実行するには、このスキームには追加のリンクが必要です。これは、Kubernetes API からステータス情報を受信し、実際の状態をさらに分析するためにそれを送信する特別なトラッカーです。 Go でオープンソース ライブラリを作成しました - キューブドッグ （発表を参照 ここで)、この問題を解決し、werf に組み込まれています。

werf レベルでのこのトラッカーの動作は、Deployment または StatefulSet に配置されたアノテーションを使用して構成されます。 主な注釈 - fail-mode - 次の意味を理解します。

• IgnoreAndContinueDeployProcess — このコンポーネントのロールアウトに関する問題を無視して、展開を続行します。
• FailWholeDeployProcessImmediately — このコンポーネントでエラーが発生すると、展開プロセスが停止します。
• HopeUntilEndOfDeployProcess — このコンポーネントが展開の終了までに機能することを願っています。

たとえば、リソースとアノテーション値のこの組み合わせは、 fail-mode:

初めてデプロイするときは、データベース (MongoDB) の準備がまだ整っていない可能性があり、デプロイは失敗します。 ただし、開始の瞬間を待つことができ、デプロイメントは引き続き行われます。

werf には kubedog のアノテーションがさらに XNUMX つあります。

• failures-allowed-per-replica — 各レプリカで許可される転倒の数。
• show-logs-until — werf がロールアウトされたすべてのポッドからのログを (stdout に) 表示するまでの時間を制御します。 デフォルトは PodIsReady (トラフィックがポッドに到達し始めたときにおそらく望ましくないメッセージを無視するため)、値も有効です。 ControllerIsReady и EndOfDeploy.

導入に他に何が必要ですか?

すでに説明した XNUMX つの点に加えて、次のことを要望します。

• 見るために ログ - すべてを連続してではなく、必要なものだけを選択します。
• 追跡 進捗ジョブが数分間「サイレント」にハングする場合、そこで何が起こっているのかを理解することが重要であるためです。
• иметь 自動ロールバック 何か問題が発生した場合に備えて (したがって、展開の実際のステータスを知ることが重要です)。 ロールアウトはアトミックである必要があります。つまり、最後まで実行されるか、すべてが前の状態に戻ります。

結果

私たち企業にとって、配信のさまざまな段階 (ビルド、公開、デプロイ) で説明されているすべてのニュアンスを実装するには、CI システムとユーティリティで十分です。 ワーフ.

結論の代わりに:

werf の助けにより、私たちは DevOps エンジニアの多くの問題を解決する上で大きな進歩を遂げてきました。より広範なコミュニティが少なくともこのユーティリティを実際に試してみてくれたら嬉しいです。 一緒に行動すると良い結果を達成しやすくなります。

ビデオとスライド

パフォーマンスのビデオ (約 47 分):

報告書のプレゼンテーション:

PS

Kubernetes に関するその他のレポートはブログにあります。

• «Kubernetes の自動スケーリングとリソース管理» （ドミトリー・ストリャロフ、27年2019月XNUMX日「ストライク」にて）;
• «Kubernetesの拡張と補完» (Andrey Polovov、8 年 2019 月 XNUMX 日、Saint HighLoad++);
• «データベースとKubernetes» (Dmitry Stolyarov、8 年 2018 月 XNUMX 日 HighLoad++);
• «モニタリングとKubernetes» (ドミトリー・ストリャロフ、28 年 2018 月 XNUMX 日、RootConf にて);
• «Kubernetes と GitLab を使用した CI/CD のベスト プラクティス» (Dmitry Stolyarov、7 年 2017 月 XNUMX 日 HighLoad++);
• «小規模プロジェクトにおける Kubernetes の経験» (ドミトリー・ストリャロフ、6 年 2017 月 XNUMX 日、RootConf にて).

出所： habr.com