KubernetesおよびGitLabを使用したCI / CDのベストプラクティス（レビューおよびビデオレポート）

11月7日、 HighLoad ++ 2017カンファレンスのDevOps and Operationsセクションで、「KubernetesとGitLabでのベストCI / CDプラクティス」というタイトルのレポートが発表されました。 その中で、これらのオープンソースソリューションに基づいて効果的なCI / CDプロセスを構築する際に生じる問題を解決する実践的な経験を共有しています。



伝統的に、私たちはレポート （約1時間、記事よりもはるかに有益）とテキスト形式での主な絞り込みのビデオを提示して喜んでいます。

CI / CDおよび主要な要件

CI / CD（継続的インテグレーション、継続的デリバリ、継続的デリバリ）により、Gitリポジトリから本番へのコード配信と、本番からの「削除」までのその後のメンテナンスのすべての段階を理解します。 CI / CDという用語の既存の解釈では、この最後の段階（運用操作）に対して異なる態度をとることができますが、私たちの経験では、CI / CDから除外すると多くの問題が発生します。



特定のプラクティスを説明する前に、CI / CDの複雑さに影響を与える主な要因をまとめました。

1. メインプロセスはどのように構築されますか？ 可能なオプション：1つ以上の環境、動的環境、複数の分散サイト。
2. テストはどのように行われますか？ コードアナライザーの実行、環境なしの（つまり、ランタイム依存性のない）ユニットテスト、環境での機能/統合/コンポーネントテスト、マイクロサービスの「完全な」環境でのテスト（エンドツーエンド、リグレッション）。
3. どのような権利の分離が必要ですか？ シンプル（コードの記述/特定のユーザー向けのロールアウトのみ）、環境内のさまざまな権限、マルチステージ承認（チームリーダーがステージ上でのロールアウトを可能にし、QA-本番環境で）、大学のソリューション。
4. アプリケーションのアーキテクチャは何ですか？ ステートレスサービス、ステートフルアプリケーション、マルチコンポーネントアプリケーション、マイクロサービスアーキテクチャ。

これらのオプションはすべて一般的なスケジュールにまとめられており、これらのニーズやその他のニーズをどのツールで解決できるかを示しています。







CI / CDの要件は、他にも-より一般的（ただし重要ではありません！）です：





最後に、CI / CDのシステムを実装および保守する会社として、使用する製品に追加要件があります。

• それらはオープンソースでなければなりません（これが私たちの「人生の展望」であり、問​​題の実際的な側面：コードの可用性、アプリケーションの制限がないこと）。
• 「 マルチスケール 」（製品が1人の開発者と50人の企業で等しく効果的に機能する必要があります）。
• 相互運用性 （ 相互互換性、機器サプライヤー、クラウドプロバイダーなどからの独立性）;
• 操作の単純さ 。
• 将来に焦点を当てます （製品が現在適切であるだけでなく、開発の見通しもあることを確認する必要があります）。

CI / CDソリューション

すべての要件を満たす製品のスタックには、次のものがあります。

• Gitlab
• Docker
• Kubernetes;
• Helm（Kubernetesでのパッケージ管理用）;
• dapp （ビルドおよび展開プロセスを簡素化/改善するためのオープンソースユーティリティ）。 2019年8月13日更新： dappプロジェクトの名前がwerfに変更され、そのコードがGoに書き換えられ、ドキュメントが大幅に改善されました。

上記のツールを使用したGitから操作までの一般的なCI / CDサイクルは次のようになります。

練習する

1番 Dockerイメージの構成

イメージには、アプリケーションが機能するために必要なすべてが含まれている必要があります。

2番 すべてを一目で

一度組み立てられたDockerイメージはどこでも使用する必要があります。 そうしないと、本番環境にポンプで送られる（別の時点で再組み立てされる）同じものが、検証のためにQAに届かない場合があります。



git branch



から一時的な画像を収集し、 git tag



から画像をリリースします：

番号3。 ロールアウトと移行

Kubernetesで説明されているさまざまなコンポーネントの動作（バックエンドはDeploymentとして、DBMSはStatefulSetとしてなど）は互いに依存します。 「直接的な」ロールアウトの場合、K8はコンポーネントを更新して再起動します（起動に失敗した場合）。







これらのすべてのイベントがコンポーネントによって正しく処理されたとしても（予測されるはずです）、Kubernetesのさまざまなタイムアウトにより合計ロールアウト時間が遅延し、他のサービスの開始を待機する必要があるためにトリガー（および累積）されます（たとえば、バックエンドは更新されたデータベースが利用可能になるのを待っています）つまり、移行あり）。



ロールアウト時間を短縮するには、コンポーネント間の明示的な依存関係（バックエンドがDBMSの利用を待機している）だけでなく、間接的な依存関係（移行前にバックエンドを更新しないでください）を考慮する（および規定する）必要があります。

番号4。 ブートストラップdb

DBMSには、2つの方法でデータが入力されます。完成したダンプを読み込むか、シード/フィクスチャを読み込むかです。 最初のケースのKubernetesでの方法は、DBMSの起動後にジョブを開始し、ダンプをロードすることです。 その後-移行の開始（間接的にダンプに依存）、そして-バックエンドの開始（間接的に移行に依存）。



sidの場合の起動シーケンスは変更され、次のようになります。1）DBMS、2）移行、3）sidのタスク、4）バックエンド（シードに依存しないため、sidと並行して実行できます）。







ブートストラップデータベースのさまざまなパスを通過した後、2つの最適性に到達しました。マスターからのシード/フィクスチャを含むナイトダンプとステージング用のナイトダンプです。

5番 ダウンタイムなしで展開

Kubernetesでアプリケーションの新しいバージョンを正しく展開しても、すべてのニュアンスが自動的に考慮されるわけではありません。 完全なダウンタイムを本当に保証するには：

• すべてのHTTPリクエストが正しく完了したことを忘れないでください。
• K8sで規定されているレディネスプローブを使用して、アプリケーション（オープンポート）の実際の可用性を確認します。
• 展開中の負荷をシミュレートします（すべての要求が完了したかどうかを確認します）。
• 展開中にインフラストラクチャで利用できる炉床の生産性のマージンを提供します。

No. 6。 「原子性」ロールアウト

インフラストラクチャのコンポーネントのアップグレード中にエラーが発生した場合（更新を展開できませんでした）、GitLabパイプラインに対応する通知がありますが、インフラストラクチャ自体は移行状態のままです。 GitLabが「考える」ように、問題のコンポーネントは元の（古い）バージョンを保存しませんが、新しいバージョンを完全にスキップすることはできません。



このようなエラーが発生した場合、組み込みのロールバック機能を使用して問題を解決します。 ほとんどの場合、これは本番環境でのみ提供されるべきです。 開発回路では、（問題の原因を理解するために）ほとんどの場合、遷移状態の問題コンポーネントを確認する必要があります。

番号7。 動的な環境

GitLabの組み込み機能により、すべてのブランチのgit push（完全​​なインフラストラクチャブートストラップのHelmチャートを使用）を使用して、すぐに使用できるアプリケーションインストール（同じネームスペース）をKubernetesにデプロイできます。 同様に、ブランチが削除されると、ネームスペースも削除されます。



ただし、この機会を積極的に活用することで、インフラストラクチャに必要なリソースが急速に増加しています。 したがって、動的環境を最適化するための推奨事項がいくつかあります。

番号8。 テスト

単純なテストの実装ですべてが単純な場合（環境を必要としない）、機能テストおよび統合テストでは、Helmを使用して動的環境を作成することをお勧めします。

まとめ

CI / CDの要件を備えた初期スケジュールに戻る...







オープンソース製品に基づいて説明されているプラ​​クティスにより、緑色でマークされた問題を解決できます。 バイオレットは、Flantが日々取り組んでいる問題の領域を強調しています。

ビデオとスライド

パフォーマンスのビデオ（約1時間）がYouTubeに公開されました 。



レポートのプレゼンテーション：

PS

ブログの他のレポート：

• " データベースとKubernetes "; （Dmitry Stolyarov; 2018年11月8日HighLoad ++） ;
• “ モニタリングとKubernetes ”; （Dmitry Stolyarov; 2018年5月28日RootConf） ;
• 「 小規模プロジェクトでのKubernetesでの経験（レビューとビデオレポート） 」; （Dmitry Stolyarov; 2017年6月6日RootConf） ;
• 「 CI / CDのDockerイメージをdappで迅速かつ便利に収集します 」 （Dmitry Stolyarov、2016年11月8日、HighLoad ++） 。
• 「 Dockerによる継続的デリバリーの実践 」 （Dmitry Stolyarov、2016年5月31日、RootConf） 。

次の出版物にも興味があるかもしれません。

• 「 WerfはKubernetesのCI / CDツールです（レビューおよびビデオレポート） 」 （Dmitry Stolyarov、2019年5月27日、DevOpsConf） 。
• 「 手頃な価格のサービスとしてKubernetesを使用したインフラストラクチャ 」
• “ GitLab CIにより、本番環境での継続的な統合と配信を実現します。 パート1：パイプライン '';
• “ GitLab CIにより、本番環境での継続的な統合と配信を実現します。 パート2：困難を克服する 。」