このガイドでは、Google Kubernetes Engine（GKE）への継続的インテグレーションと継続的デリバリー（CI / CD）に関するベスト プラクティスについて説明します。このような方法は、ソース管理からデプロイ戦略まで、幅広いトピックをカバーしています。これらは、GKE に固有のベスト プラクティスで、一般的な CI / CD のベスト プラクティスも引き続き適用されます。詳細については、DevOps 技術: 継続的インテグレーションと DevOps 技術: 継続的デリバリーをご覧ください。
継続的インテグレーション
継続的インテグレーション（CI）とは、デベロッパーがコードの変更をできるだけ頻繁にメインブランチに統合するための手法です。プロセスのできるだけ早い段階でコードを公開することで、問題をより早く検出できるようにします。CI パイプラインは通常、デベロッパーがコードの変更を push するとトリガーされます。パイプラインには、lint チェック、テスト、ビルドなど、変更を検証する手順が含まれています。CI パイプラインは通常、デプロイ プロセスの後の段階でデプロイできるアーティファクトを生成します。
高速イテレーションを可能にするパイプラインを作成する
デベロッパーがコードを変更してから、アプリケーションの実行バージョンが作成されるまでの時間は、できるだけ短くする必要があります。この速度は、デベロッパーが高速イテレーションを行う機能ブランチの開発時に特に重要です。CI パイプラインの実行時間は、10 分未満が理想です。それができない場合は、次の 2 種類の CI パイプラインを作成します。
高速パイプライン: 通常、これらのパイプラインの実行時間は 10 分以内です。このパイプラインは機能ブランチを対象としており、包括的ではありません。高速パイプラインでは、生成されるアーティファクトが不安定になる可能性があります。
完全パイプライン: このパイプラインの実行には 10 分以上かかることがあり、より包括的なテストとチェックが行われます。完全パイプラインは、マージ リクエストまたは pull リクエストで実行され、メインブランチに commit されます。
コンテナ イメージをテストする
CI パイプラインの一部として、コードで必要なすべてのテストを実行し、アーティファクトをビルドします。テストには、単体テスト、機能テスト、統合テスト、負荷テスト、パフォーマンス テストが含まれます。
また、構築したコンテナ イメージの構造をテストすることも重要です。構造をテストして、すべてのコマンドがコンテナ内で想定どおりに実行されることを確認します。また、テストにより、特定のファイルが正しい場所に配置され、内容が正しいことも確認できます。
コンテナ イメージをテストするには、コンテナ構造テスト フレームワークを使用します。
パイプラインのセキュリティを早期に確立する
開発ライフサイクルのできるだけ早い段階でセキュリティをチェックし、バランスをとります。アーティファクトをビルドまたはデプロイする前にセキュリティ リスクを見つけることで、これらのリスクに対処する時間とコストを削減できます。
早期検出を実現するには、次のセキュリティ対策をパイプラインで実施します。
該当する分野のエキスパートが、本番環境のリポジトリに統合するすべてのコードをレビューする。
パイプラインの早い段階で lint チェックと静的コード分析を実施する。このテストにより、入力のエスケープの未実行、SQL クエリの未加工入力データの受け入れ、コードの脆弱性などの弱点を確認できます。
構築されたコンテナ イメージの脆弱性を脆弱性スキャンで確認する。
脆弱性のあるイメージがクラスタにデプロイされないように、Binary Authorization を使用する。Binary Authorization を使用するには、GKE Enterprise サブスクリプションが必要です。生成されたイメージの信頼性を高めるため、Binary Authorization を使用して、さまざまなエンティティまたはシステムによる証明書を必須とすることもできます。たとえば、次のような証明書を要求できます。
- 脆弱性スキャンに合格
- QA テストに合格
- プロダクト オーナーからサインオフ
継続的デリバリー
継続的デリバリー（CD）を使用すると、いつでもコードをリリースできます。CD は、CI パイプラインによって生成されたアーティファクトで運用されます。CD パイプラインは、CI パイプラインよりもはるかに長く実行できます。特に、Blue/Green デプロイなど、より精密なデプロイ戦略を使用している場合は、長時間実行されます。
GitOps の手法を使用する
GitOps は、Git リポジトリに格納された宣言型インフラストラクチャと、そのインフラストラクチャを環境にデプロイする CI/CD ツールのコンセプトです。GitOps の手法を使用すると、アプリケーションとクラスタに対するすべての変更がソース リポジトリに格納され、常にアクセスできるようになります。
GitOps の手法を使用すると、次の利点があります。
- マージ リクエストまたは pull リクエストを使用して、デプロイ前に変更をレビューできます。
- 1 か所で、任意の時点でのアプリケーションとクラスタの状態を参照できます。
- クラスタとアプリケーションのスナップショットにより、障害発生時の復元が簡単になります。
GitOps の手法と、ソース リポジトリで使用できるさまざまなパターンの詳細については、GitOps のコンセプトをご覧ください。
宣言型インフラストラクチャに使用される一般的なツールとして、Hashicorp の Terraform と Google Cloud の Config Connector があります。GitOps などのツールを使用してインフラストラクチャを管理する演習については、Terraform、Cloud Build、GitOps を使用してインフラストラクチャをコードとして管理するのチュートリアルをお試しください。GitOps スタイルのアプリケーションを管理する方法については、Cloud Build を使用した GitOps スタイルの継続的デリバリーをご覧ください。
コンテナ イメージは再構築するのではなくプロモートする
コンテナ イメージは、CI / CD パイプラインのさまざまなステージを通過するときに再構築しないでください。再構築すると、コードブランチ間で小さな違いが生じる可能性があります。これらの違いにより、本番環境でアプリケーションが動作しなくなることや、テストされていないコードが本番環境のコンテナ イメージに誤って追加されることがあります。確実に、テストしたコンテナ イメージがデプロイされるようにするには、一度構築した後、環境全体でプロモートすることをおすすめします。このアドバイスは、環境固有の構成をパッケージとは別に保持していることを前提としています。
より高度なデプロイとテストパターンの使用を検討する
GKE では、いくつかのパターンを使用して、アプリケーションのデプロイとテストを柔軟に行うことができます。どのデプロイ パターンを選択するかは、ビジネスの目標に大きく依存します。たとえば、ダウンタイムなしで変更をデプロイする場合も、機能を一般提供する前に特定の環境または一部のユーザーにデプロイする場合もあります。
使用可能なデプロイ パターンには、次のようなものがあります。
デプロイの再作成: 新しいアプリケーション バージョンをスケールアップする前に、既存のアプリケーション バージョンを完全にスケールダウンします。
ローリング アップデート デプロイ: 実行中のすべてのアプリケーション インスタンスを一度に更新するのではなく、実行中のアプリケーション インスタンスのサブセットを更新します。その後、実行中のアプリケーション インスタンスをすべて更新するまで、段階的に更新していきます。
Blue/Green デプロイ: アップグレードされたバージョンのアプリケーションを使用して、既存の本番環境インスタンスに追加の並列インスタンス セットをデプロイします。デプロイの準備ができたら、トラフィックを新しいインスタンスに切り替えます。
こうした戦略の詳細については、アプリケーションのデプロイとテストの戦略をご覧ください。
環境ごとにクラスタを分離する
環境の分離は、デプロイのターゲットに関する重要な考慮事項です。理想的には、次の環境ごとに個別のクラスタを用意します。
開発環境: この環境では、デベロッパーがアプリケーションをデプロイして、テストと試験運用を行います。このようなデプロイでは、アプリケーションまたはシステムの他の部分（データベースなど）との統合が必要です。この環境のクラスタは通常、ゲートが少なく、デベロッパーがクラスタ構成を細かく制御できます。
本番前環境（ステージングまたは QA）: この環境は、できる限り本番環境に近いものにします。統合テスト、負荷テスト、パフォーマンス テスト、回帰テストなどの大規模な変更テストに使用します。
本番環境: この環境では、本番環境のワークロードとユーザー向けのアプリケーションとサービスが実行されます。
この環境の詳細については、Kubernetes と継続的ソフトウェア デリバリーの課題の環境セクションをご覧ください。
本番前環境は本番環境にできるだけ近づける
本番前クラスタと本番環境クラスタは同一であることが理想的ですが、コストの理由から、スケールダウンしたレプリカを本番前クラスタにすることもできます。クラスタを類似のものにすることで、本番環境と同じ条件または似た条件でテストを実行できます。本番前クラスタと本番環境クラスタが同等であれば、本番環境にデプロイするときに環境の違いにより予期しない障害が発生する可能性も低くなります。
宣言型インフラストラクチャと GitOps を使用すると、基盤となるクラスタの構成を簡単に複製できるので、より近く環境を類似させることができます。Config Sync などのツールを使用して、環境のポリシーと構成の条件を類似させることもできます。
本番環境の障害に備える
どれほどテストをしても、本番環境でアプリケーションが正しく動作することは保証できません。考慮していなかったデータによるエッジケースや、テストしていなかったユーザーのアクセス パターンによって、障害が発生する可能性はあります。本番環境でアプリケーションをモニタリングして、バグや障害に迅速に対応し、修正できるように、自動化されたロールバックとデプロイのメカニズムを用意しておくことが重要です。より堅牢なデプロイ戦略を使用することで、本番環境で問題が発生したときに、問題の大きさを軽減し、影響を受けるエンドユーザーの数を減らすことができます。
チェックリストの概要
次の表に、GKE で CI / CD パイプラインを使用する場合の推奨タスクを示します。
| 領域 | タスク |
|---|---|
| 継続的インテグレーション |
|
| 継続的デリバリー |
|
次のステップ
- エンタープライズ マルチテナンシーのベスト プラクティスを確認する。
- Google Cloud での CI / CD の詳細を確認する。