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

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

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

それでは紹介しましょう レポートのビデオ (約 47 分、記事よりもはるかに情報量が多い) とその主な要約をテキスト形式で提供します。さあ行こう！

Kubernetesへのコードの配信

レポートでは、werfではなくKubernetesのCI/CDについて主に取り上げます。つまり、私たちのソフトウェアはDockerコンテナにパッケージ化されているということです。 （これについては 2016年の報告書)本番環境での実行には K8s が使用されます。 （これについては 2017年).

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

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

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

1. 不変のインフラを持っているから （不変のインフラストラクチャ）すべての段階（ステージング、本番など）で使用されるアプリケーション イメージ。 一つは必ずある. これについて、さらに詳しく例を挙げて話しました。 ここで.
2. 私たちはインフラストラクチャ・アズ・コードアプローチを採用しているので （IaC）アプリケーションコード、そのアセンブリと起動の指示は、 1つのリポジトリに正確に. 詳細については、 同じ報告書の中で.
3. 配送チェーン （配達） 通常は次のように考えます。アプリケーションは組み立てられ、テストされ、リリースされます （リリース段階） これで配達が完了しました。しかし実際には、ユーザーはあなたが展開したものを受け取ります。 ノー 次に、それを本番環境に納品し、彼がそこに行って本番環境が機能したときです。つまり、サプライチェーンは終わりを迎えるのだと思います。 運用段階のみ （走る）もっと正確に言うと、コードが本番環境から削除された瞬間（新しいコードに置き換えられた瞬間）でも同様です。

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

ビルドステージ

2019 年現在、Dockerfile の記述方法と実行方法を誰もが知っているため、Docker イメージの構築については何も言うことはないようです。 docker build?.. ここで注目したいニュアンスは以下のとおりです。

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

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

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

プロジェクトは次のとおりです。

• moby/ビルドキット — これらすべての問題を解決しようとする Docker Inc のコレクター (Docker の現在のバージョンにすでに統合されています)。
• かにこ — Docker なしでビルドできる Google のビルダー。
• ビルドパック.io — CNCF による自動化の試み、特にレイヤーのリベースによる興味深いソリューション。
• その他にも、 ビルダー, 本物のツール/画像...

…そして、GitHub でどれだけのスターが付いているか見てみましょう。つまり、一方では、 docker build 何かできることはあるが、現実には 問題は完全に解決されていない その証拠として、代替アセンブラが並行して開発されており、それぞれが問題の一部を解決するようになっています。

埠頭での組み立て

そこで私たちは ワーフ （以前 有名な dappのように） — 私たちが長年かけて開発してきた「Flant」社のオープンソースユーティリティ。すべては約 5 年前、Dockerfiles のアセンブリを最適化する Bash スクリプトから始まり、過去 3 年間、独自の Git リポジトリを持つ XNUMX つのプロジェクトのフレームワーク内で本格的な開発が進行してきました。 （最初はRubyで、その後 書き直された Goで、同時に名前が変更されました）。 werf ではどのような組み立ての問題が解決されますか?

青色で強調表示されている問題はすでに実装されており、1 つのホスト内で並列アセンブリが実行されており、黄色で強調表示されている問題は夏の終わりまでに完了する予定です。

レジストリへの公開段階（公開）

募集しています docker push… — レジストリにイメージを読み込む際に、何が難しいのでしょうか?すると、「画像にはどのようなタグを付ければよいのか？」という疑問が生じます。それは私たちが持っているから起こるのです Gitflow (または別の Git 戦略) と Kubernetes があり、業界では Kubernetes で起きていることが Git で起きていることに追従することを推進しています。結局のところ、Git は私たちにとって唯一の真実の情報源です。

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

それは私たちにとっても重要です 起源を特定するKubernetes で実行されているアプリケーションがどのコミットからビルドされたかを理解したいからです (そうすれば、差分などを実行できます)。

タグ付け戦略

1つ目は簡単です gitタグ。次のようなタグが付けられた画像が登録されています 1.0。 Kubernetes には、このイメージがデプロイされるステージと本番環境があります。 Gitではコミットを行い、ある時点でタグを付けます 2.0。リポジトリの指示に従ってコンパイルし、タグを付けてレジストリに配置します。 2.0。それをステージに展開し、すべてが問題なければ本番環境に展開します。

このアプローチの問題点は、最初にタグを設定し、その後でテストして展開することです。なぜ？まず、これは単純に非論理的です。まだチェックもしていないバージョンのソフトウェアを発行することになります (チェックするにはタグを追加する必要があるため、それ以外の方法はありません)。第二に、このパスは Gitflow では機能しません。

番目のオプション - git コミット + タグ。マスターブランチにタグがあります 1.0;レジストリ内の彼用のイメージ - 本番環境にデプロイされたイメージ。さらに、Kubernetes クラスターにはプレビューとステージングの輪郭があります。次にGitflowに従います。メインの開発ブランチ（develop）新しい機能を追加すると、識別子を持つコミットが作成されます #c1。私たちはそれを収集し、この識別子を使用してレジストリに公開します（#c1）。同じ識別子を使用してプレビューを展開します。コミットでも同じことを行います。 #c2 и #c3.

十分な機能があることに気づいたとき、私たちはすべてを安定化させ始めました。 Gitではブランチを作成します release_1.1 (ベースに #c3 の develop）。前の手順ですでに実行されているため、このリリースをコンパイルする必要はありません。したがって、ステージングに展開するだけです。バグを修正しました #c4 同様にステージングにも展開します。同時に、 develop定期的に変更が行われる release_1.1。ある時点で、満足のいくコミットがビルドされ、ステージングにプッシュされます（#c25).

次にリリースブランチのマージ（fast-forwardを使用）を実行します（release_1.1）をマスターに追加します。このコミットに新しいバージョンのタグを付けました（1.1）。しかし、このイメージは既にレジストリにビルドされているので、再度ビルドしないようにするには、既存のイメージに2番目のタグを追加するだけです（これでレジストリにタグが付きます）。 #c25 и 1.1）。その後、本番環境に展開します。

ステージングにデプロイされるイメージは1つだけという欠点があります（#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

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

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

…そして、そのようなファイルからチェックサム (再び SHA256) を取得します。これ サイン Docker イメージの内容を定義するすべてのもの。

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

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

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

ワーフでのタグ付け

werfではさらに進んで、単一のマシンに保存されないキャッシュを使った分散ビルドを準備しています。そのため、2種類のDockerイメージを構築しています。 ステージ и 画像.

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

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

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

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

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

掃除の戦略は何ですか?

1. 何もしないでもいい 掃除しない。時には、大量のタグの絡まりを解くよりも、少しお金を払って余分なスペースを確保するほうが簡単なこともあります。しかし、これはある程度までしか機能しません。
2. 完全リセット。すべてのイメージを削除し、CI システム内の現在のイメージのみを再構築すると、問題が発生する可能性があります。コンテナが本番環境で再起動されると、まだ誰にもテストされていない新しいイメージがロードされます。これにより、不変のインフラストラクチャというアイデアが失われます。
3. 青緑。 1 つのレジストリがオーバーフローし始めたため、別のレジストリにイメージを読み込んでいます。前の方法と同じ問題: オーバーフローし始めたレジストリをどの時点でクリーンアップできますか?
4. 時間によって。 1 か月以上前の画像をすべて削除しますか?しかし、XNUMXか月間更新されていないサービスは間違いなく存在します...
5. 手動で すでに削除できるものを決定します。

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

一体どうなってしまったのでしょうか? ワーフ？収集する情報:

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

…そして、このセットからホワイトリスト（削除しない画像のリスト）を作成します。その他すべてをクリーンアップし、孤立したステージイメージを見つけてそれらも削除します。

展開段階

信頼できる宣言性

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

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

したがって、新しいリソース構成が表示されると（NEW）、それをそのまま現在の「ライブ」構成に上書きすることはできません（ライブ）。これを実行するには、比較する必要がある。 NEW 以前に適用された構成（最後に適用された）そして進む ライブ パッチを受け取りました。

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

もあります 双方向マージは、次の事実によって区別されます。

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

当社では 1000 以上のアプリケーションを Helm でデプロイしているため、基本的には 2 方向のマージを使用しています。ただし、Helm にはいくつかの問題があり、私たちのパッチで解決され、Helm が適切に動作するようになりました。

実際の展開状況

CIシステムが次のイベントのためにKubernetesの新しい構成を生成したら、それをアプリケーションに渡します。 （適用する） クラスターに - Helmまたは kubectl apply。次に、すでに説明した N 方向のマージが発生し、Kubernetes API が CI システムに承認応答し、CI システムがユーザーに応答します。

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

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

このトラッカーの werf レベルでの動作は、デプロイメントまたは StatefulSet に配置されたアノテーションを使用して構成されます。主な要約 - fail-mode — 以下の意味を理解します:

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

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

初めてデプロイする場合、データベース (MongoDB) の準備ができていない可能性があり、デプロイがクラッシュします。ただし、開始されるまで待つことができ、その場合もデプロイメントは実行されます。

werf には kubedog のアノテーションがあと 2 つあります。

• failures-allowed-per-replica — 各レプリカに許可される落下回数。
• show-logs-until — werf がデプロイされたすべてのポッドからのログを (stdout に) 表示する瞬間を制御します。デフォルトでは PodIsReady （ポッドがトラフィックを受信し始めたときにおそらく不要なメッセージを無視するため）しかし、値は ControllerIsReady и EndOfDeploy.

デプロイメントから他に何を望むでしょうか?

すでに説明した 2 つの点に加えて、次の点も考慮します。

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

結果

企業として、配信のさまざまな段階（ビルド、公開、展開）で説明したすべてのニュアンスを実装するには、CIシステムとユーティリティで十分です。 ワーフ.

結論の代わりに:

werf によって、DevOps エンジニアの多くの問題を解決する上で大きな進歩を遂げることができたので、より広範なコミュニティがこのユーティリティを実際に試していただければ幸いです。一緒にやれば良い結果が得やすくなります。

ビデオとスライド

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

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

PS

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

• «Kubernetes の自動スケーリングとリソース管理» （ドミトリー・ストリャロフ、27年2019月XNUMX日「Strachka」にて）;
• «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