このドキュメントでは、Google Kubernetes Engine を使用するマルチチームのソフトウェア デリバリー プラットフォーム上で、最新の継続的インテグレーション / 継続的デリバリー（CI / CD）のプロセスを実装するフレームワークについて説明します。
開発と運用のパフォーマンス（リリース速度、プラットフォームの信頼性、障害時の復旧時間など）をさらに改善するために、プラットフォーム上でイテレーションできます。
このドキュメントはシリーズの一部です。
GKE を使用した最新の CI / CD: ソフトウェア デリバリー フレームワーク（このドキュメント）
GKE による最新の CI / CD: CI / CD システムをビルドする（リファレンス アーキテクチャ）
このドキュメントは、企業の設計者とアプリケーション デベロッパーのほか、IT セキュリティ、DevOps、サイト信頼性エンジニアリング チームを対象としています。自動化されたデプロイツールとプロセスについての経験は、このドキュメントのコンセプトを理解するうえで有効です。
最新の CI / CD ケース
CI / CD は、いくつかのツールと繰り返し可能なプロセスを使用して、ソフトウェア開発のビルド、テスト、デプロイの各フェーズを自動化するソフトウェア開発の手法です。
CI / CD の自動化に加えて、Kubernetes とコンテナにより、企業での開発とデプロイの速度をかつてないほど改善することが可能になりました。しかし、Kubernetes とコンテナの導入が拡大しても、多くの組織での CI / CD の使用方法では、Kubernetes を十分に活用していない、または運用やセキュリティに関する問題に対処していないため、多くの組織はリリース速度、安定性、運用効率上のメリットを完全には実現していません。
実際に最新の CI / CD の手法には、単に自動化だけではないものが含まれる必要があります。速度とセキュリティの改善を十分に実現し、Kubernetes とコンテナを活用するには、アプリケーションのオンボーディング、CI / CD の使用方法、運用プロセスを効率化する必要があります。
GKE プラットフォームに用意された一貫したインフラストラクチャ、統一された CI / CD メソッド、実装のベスト プラクティスを利用すると、組織において開発と運用に関する次のようなメリットが得られます。
変更のリード時間を短縮する。
運用チームとセキュリティ チームが、プラットフォーム全体のアプリケーションのプロビジョニングとポリシーのプロビジョニングのベスト プラクティスを作成、更新できるようになります。
組織のベスト プラクティスが組み込まれ、完全に機能して、デプロイ可能なスターター プロジェクトをチームに提供することで、アプリケーションのオンボーディングを簡略化します。
サービスの復元に必要な時間を短縮する。
監査、ロールバック、レビューを簡素化するために、GitOps を使用してすべての構成を宣言的に管理します。
組織全体でデプロイとモニタリングの手法を標準化することで、サービスに影響する問題の要因の特定に要する時間を短縮できます。
デプロイの頻度を増やす。
アプリケーション デベロッパーが、互いに干渉することなく、独自の開発サンドボックス（またはランディング ゾーン）で、個別に反復処理できるようにします。
GitOps を使用して、デプロイ、リリース管理の改善、変更トラッキングを行います。
サービスチームが頻繁にデプロイできる権限を持つように、ガードレールを実装します。
本番前環境全体で一貫したデプロイを行うことができるよう段階的なロールアウト プロセスを作成し、本番環境に変更をデプロイする際に必要な確証をデベロッパーが得られるようにします。
GKE と CI / CD でこれらの利点とコンセプトがどのように実現されるかを確認するには、このシリーズの他のドキュメントをご覧ください。
最新の手法の準備状況を評価する
GKE を使用して最新の CI / CD ツールとプロセスを実装する前に、組織とチームが新しいプラットフォームを導入するための準備を完了しているかどうかを確認する必要があります。
組織の特性
最新のプラットフォームを採用するには、企業のリーダーシップ チームと技術チームによる次のサポートが必要です。
リーダーシップ スポンサー。ソフトウェア デリバリー プラットフォームを採用するには、通常、複数の機能横断型チームによる取り組みが必要になります。このプロセスでは通常、ロールと責務のほか、ソフトウェア開発の実務も変わることになります。このようなツールと手法の導入を成功させるには、リーダーシップ チームのメンバーから、1 人以上の強力なサポートを得る必要があります。最も効果的なリーダーシップ スポンサーは、これらの変更を継続的な改善のプロセスとして考える人であり、チームを管理するのではなくチームの力を高めようとする人です。
技術戦略とビジネス戦略の調整。ビジネスチームと技術チームは、DevOps Research and Assessment（DORA）が定義するソフトウェア デリバリーの 4 つの重要な評価基準（変更のリードタイム、デプロイの頻度、サービスの復元時間、変更の失敗率）に沿って調整することをおすすめします。これらの評価基準に沿った調整により、ビジネスチームと技術チームは共通の目標を得ることができ、共同での費用対効果の計算、変更率の調整、投資レベルの変更が可能になります。
リソース。最新の CI / CD の手法を開発し、ツールチェーンを構築するチームが成功するには、必須のリソース（時間、人員、インフラストラクチャ）が必要です。これらのチームには、最適なプロセスとツールを試してテストする時間が必要です。このようなチームは、ソフトウェア配信プロセスにおける多くの異なる機能を表し、組織全体から他のリソースを取り込むことができるのが理想です。最後に、チームはクラウド リソースやソフトウェア ツールなどのインフラストラクチャをプロビジョニングできる必要があります。
新しいツールを導入することに対する開放性。最新の CI / CD ツールと手法には、多くの場合、新しいツールとプロセスが伴います。チームはこれらのプロセスやツールを試して、それらを進んで導入しようとする必要があります。フィードバック ループは、プラットフォーム チームが、プラットフォームを利用しているアプリケーション チーム、運用チーム、セキュリティ チームからの情報を得るために必要となります。
文化的な準備性GKE を使用した最新の CI / CD システムのデプロイと導入が成功するには、組織とシステムを開発する技術チームが、運用と連携の方法の変更に向けた準備をする必要があります。たとえば、開発チームと運用チームは、セキュリティに対する責任に、より前向きに取り組む必要があり、セキュリティ チームと運用チームは、変更の承認プロセスの合理化に前向きに取り組む必要があります。
技術に関する能力
最新の CI / CD 手法を導入するには、チームは以下の方法について、技術的な準備をする必要があります。
コンテナに関する経験。最新の CI / CD 手法を導入するチームには、コンテナに関する経験が必要です。この経験には、コンテナ イメージを構築し、コンテナを組み合わせて、より大きなシステムを構築する開発手法が含まれていることが理想的です。
継続的インテグレーション戦略。チームには、CI ツール（Jenkins、TeamCity、Bamboo、CircleCI など）を使用した経験があり、継続的インテグレーションと自動テストを実施した経験が必要です。組織は、これらの手法をさらに強化する方法を計画することをおすすめします。
デプロイの自動化。チームにはデプロイの自動化に関する経験が必要です。自動デプロイツールの例としては、基本的なシェル スクリプト、Terraform、Chef、Puppet があります。デプロイの合理化と自動化には、デプロイの自動化ツールとプロセスの基本知識があることは不可欠です。
サービス指向のアーキテクチャ。最新の CI / CD プロセスを導入するための前提条件ではありませんが、よりモジュール的でサービス指向なアーキテクチャを導入することは、GKE を使用した最新の CI / CD ツールと手法を導入したいと考える組織の長期的な目標であることが必要です。サービスベースのアーキテクチャによって、速度と信頼性が改善することが示されています。
最新のソース管理。Git のような最新のソース管理ツールを使用すると、トランクベース開発、機能ブランチ、マージ リクエストなどのワークフローを確立できます。
GKE で最新の CI / CD を設計する
このセクションでは、ソフトウェア デリバリー プラットフォームとそのコンポーネントについて説明します。ソフトウェア デリバリーのパフォーマンスを改善するには、チームが迅速にリリースして効率的に運用できるようにする、CI / CD およびその他の技術的なベスト プラクティスを実装する必要があります。
このセクションでは、ソフトウェア デリバリーのライフサイクルをサポートするために必要なインフラストラクチャと、GKE を使用してそのインフラストラクチャを一貫して管理する方法についても説明します。最後に、このセクションでは、ソフトウェア デリバリー ワークフローの例を示し、スターター リポジトリがオンボーディングとベスト プラクティスの実装を簡素化する例を示します。設計に関する以下の考慮事項を確認してください。
ソフトウェア デリバリー プラットフォーム。高速で信頼性の高いアプリケーション リリース プロセスの基盤を構成するフレームワークと技術的能力。
プラットフォーム インフラストラクチャ。プラットフォームの構築やアプリケーションの実行に必要なインフラストラクチャ コンポーネントと管理の考慮事項。
ソフトウェア デリバリー ワークフロー。チームが連携して効率的にコードの構築、テスト、デプロイを行う方法。
コード リポジトリ。実際のビジネス ロジック、アプリケーション固有の構成、インフラストラクチャを構築するためのコードの保存など、いくつかの機能を実行するリポジトリ。これらはまた、ベスト プラクティスの導入を促進し、自動プロセス全体での整合性の維持に役立つスターター リポジトリにもなります。
アプリケーションのランディング ゾーン。配置したガードレールを使用して、デベロッパーがアプリケーションに自律的にデプロイして反復処理できる論理エンティティ。
運用モデル。プラットフォームを構成するインフラストラクチャとアプリケーションを管理するための技術ツール、プロセス、メソッド。
ガバナンス。ソフトウェア デリバリー プラットフォームを維持、管理するために必要なプロセスと考慮事項。
ソフトウェア デリバリー プラットフォーム
ソフトウェア デリバリー プラットフォームはツールを統合し、アプリケーションの構築、デリバリー、デプロイ、運用に必要なプロセスを効率化します。
アプリケーションの構成、安定性、稼働時間、スケーリングを維持することについての責務は、運用担当者、セキュリティ、デベロッパーの各チーム間で異なりますが、すべてのコンポーネントとチームが連携してリリースをより迅速に行う必要があります。このドキュメントでは、ソース管理とアプリケーションのオブザーバビリティを改善する方法について説明しますが、主に継続的インテグレーション（CI）、継続的デリバリー（CD）、構成管理に重点を置いて説明します。
完全なソフトウェア デリバリー プラットフォームを構築するには、次の図の各コンポーネントが必要です。
各コンポーネントは、プラットフォーム上で稼働するシステムとアプリケーションに機能を提供します。
インフラストラクチャのモニタリング。Google Kubernetes Engine（GKE）クラスタ、仮想マシン（VM）インスタンス、アプリケーションの機能に必要なその他のインフラストラクチャが正しく機能していることを検証するために、プロビジョニング時に必要な基本レベルのモニタリング。
コンテナ オーケストレーション。コンテナベースのアプリケーションのデプロイとオペレーションを調整するプラットフォーム。コンテナ オーケストレーションのプラットフォームには、Kubernetes、GKE、GKE Enterprise などがあります。
Container Registry。コンテナ イメージのストレージとアクセス制御。
CI。デプロイ前に自動タスクをアプリケーションに適用するプロセス。CI タスクには、通常、構築、パッケージ化、テストが含まれます。タスクのタイプは、アプリケーションと組織によって異なります。
CD。高い頻度で高度に自動化され、適用されるデプロイ プロセス。手法の例として、手動承認、カナリア デプロイ、Blue/Green デプロイ、ローリング デプロイなどがあります。
ポリシー。運用チームとセキュリティ チームが定義し、プラットフォームによって継続的に適用され、強制されるセキュリティとインフラストラクチャの構成ポリシー。
ソースコード管理。たとえば、コード、構成ファイル、ポリシー定義のバージョンの管理されたストレージです。最近の CI / CD システムでは、ソースコード管理は通常 Git です。
構成管理。異なる環境でのアプリケーション構成の保存と適用に使用されるシステム。
アプリケーションのオブザーバビリティ。デベロッパー、運用担当者、セキュリティの各チームが、アプリケーションのトラブルシューティングと、適切な運用を検証するために使用する、アプリケーション レベルのロギング、モニタリング、アラート、トレース。
プラットフォーム インフラストラクチャ
スケーラブルなソフトウェア デリバリー プラットフォームを構築するには、開発環境、本番前環境、複数の本番環境クラスタ用に Kubernetes クラスタが必要です。クラスタは、さまざまな機能を提供します。
開発環境。これらのクラスタでは、デベロッパーはテストと試験運用のためにアプリケーションのアドホック デプロイを行います。
アプリケーション環境。
本番前環境。ワークフロー内の各本番前環境には、アプリケーションをホストするための Kubernetes クラスタが必要です。これらのクラスタは、本番環境クラスタと似たものになるため、環境間の差異を削減または排除して、デプロイの成功率を改善できます。
本番環境。 これらのクラスタは本番環境のワークロードを実行します。地理的に分散した複数のクラスタを使用する必要があります。これにより、インフラストラクチャの障害に対する信頼性が向上し、クラスタのアップグレードやスケーリングなどの 2 日目の運用に関する懸念事項が簡素化されます。
次の図は、アーキテクチャの概要を示しています。
このアーキテクチャでは、Config Sync を通じて各環境のクラスタを管理しています。整合性のあるクラスタ構成が不可欠であるのは、そうした構成によって、本番前環境と本番環境が同様に動作するという確証を、デベロッパー、運用担当者、セキュリティの各チームが得ることができるためです。Config Sync を使用すると、クラスタのフリート全体に共通の構成を保存して適用できます。クラスタ構成が標準化され、監査可能で、スケーラブルになると、ソフトウェア デリバリーのワークフローと、アプリケーションのオンボーディングとデプロイに集中できます。
アプリケーションの CI / CD パイプラインを通じて、開発クラスタ、ステージング クラスタ、本番環境クラスタへのデプロイを管理します。ソース コントロール管理は、アプリケーションのコードと構成の調整ポイントとして機能します。アプリケーションの CI / CD パイプラインとコンテナ イメージは、そのアプリケーションの環境に分離されます。スターター リポジトリと自動化ツールを使用して、アプリケーションと構成のリポジトリを初期化します。たとえば、Cloud Build で Terraform を実行すると、新しいアプリケーションを自動的にオンボーディングして初期化できます。
各クラスタ上の独自のランディング ゾーンにアプリケーションをデプロイし、アプリケーションがネットワークと ID で分離されるようにします。Config Sync を使用して、環境全体でアプリケーションのランディング ゾーンを初期化し、Cloud Service Mesh またはマルチクラスタ Ingress を使用して、多数のクラスタにまたがるネットワーク メッシュを作成することで、本番環境クラスタが 1 つのクラスタであるように見えるようにします。
ソフトウェア デリバリー ワークフロー
ソフトウェア配信プラットフォームの中核となるコンポーネントは、CI / CD システムです。プラットフォーム ビルダーで CI / CD プロセスの定義を開始する際には、各コンポーネントが標準化されたインターフェースに準拠したアーティファクトを生成または消費することを確認する必要があります。標準化されたインターフェースを使用することで、より優れた実装が市場にリリースされたときに、コンポーネントの置き換えが容易になります。
コンテナ化されたアプリケーション用のプラットフォームを作成する際は、コンポーネント間の 3 つの標準化されたインターフェース（Git リポジトリ、Docker イメージ、Kubernetes マニフェスト）を使用できます。これらのインターフェースを使用すると、次の図に示すように、開発、構築、リリースのワークフローで再利用可能な柔軟な CI / CD パイプラインを作成できます。
このワークフローは次のように動作します。
デベロッパーは、アプリケーション コードをコード リポジトリに commit します。
CI システムでコードをテストして Docker イメージ アーティファクトを作成し、イメージをレジストリに保存します。
アーティファクトをデプロイする準備が整うと、アーティファクトへの参照がアプリケーション構成に追加されます。
そのアプリケーション構成は、Kubernetes で読み取り可能な形式でレンダリングされ、コード リポジトリに保存されます。このリポジトリを更新すると、統合開発環境にアーティファクトをデプロイするデプロイ パイプラインがトリガーされます。
統合開発環境でのテストが完了したら、運用担当者が本番前環境へのデプロイをプロモートします。
アプリケーションが本番前環境で想定どおりに動作していることを確認したら、運用担当者はデプロイ パイプラインで承認を得て、本番環境へのリリースをプロモートします。
運用担当者が基本構成を変更すると、その変更が組織全体に適用されます。運用担当者はリポジトリに変更を commit すると、アプリケーション構成の更新（と後続のデプロイ）が自動的にトリガーされます。または、デベロッパーが次に変更をデプロイする際に、運用担当者の変更を受け取ることもできます。
同時に、セキュリティ エンジニアは、デプロイ可能な内容を定義するポリシーを実装して調整し、その後、それらのポリシーをポリシー リポジトリに commit できます。
GitOps の手法を使用すると、アプリケーションとクラスタに対する変更のために、宣言型のアプローチを要求できます。このアプローチを使用すると、すべての変更は、適用される前に監査と審査を行うことが条件となります。この宣言型モデルでは、構成ファイルを Git リポジトリに保存します。これにより、変更のログを維持することや、失敗したデプロイをロールバックすること、提案された変更によって生じる可能性がある影響を確認することが可能になります。
関連付けられたリファレンス アーキテクチャでは、kustomize を使用して、組織のアプリケーション構成を制御できます。kustomize ツールを使用すると、開発チームがベースにコードを追加または変更する必要がなく調整できる、いわゆるアプリケーション構成のベースを運用担当者が作成できます。プラットフォーム チームは、ベース構成を定義することで、組織のベスト プラクティスを作成して反復処理できます。運用担当者がセットアップしたベスト プラクティスをデベロッパーが適用することにより、運用担当者とデベロッパーは、デプロイにおいて独立して反復処理を実施できます。組織の新しいベスト プラクティスを、運用担当者が実装する必要がある場合は、運用担当者がベースで変更を行うと、その変更はデベロッパーの次回のデプロイに自動的に反映されます。
コード リポジトリ
ソースコード リポジトリは、CI / CD システムの基盤です。運用担当者、デベロッパー、セキュリティ エンジニアは、それぞれプラットフォームに変更を反映するための独自のリポジトリを保有しています。システム内のすべての変更のベースとして Git リポジトリを使用することには、いくつかの利点があります。
組み込みの監査可能性。commit には、システムをいつ、何について、誰が変更したかに関する情報が含まれます。
ロールバック プロセスの簡素化。Git の元に戻す機能は、システムの以前の状態にロールバックできます。
バージョニング。システムの状態のバージョンを示すために、Git commit にタグ付けできます。
トランザクション。変更を状態に統合する前に、状態の競合を明示的に解決し、確認する必要があります。
次の図は、それぞれのチームが、すべての変更のために一元化されたリポジトリと、どのようにやり取りするかを示しています。
以降のセクションでは、運用担当者、デベロッパー、セキュリティ エンジニアが、最新の CI / CD システムで Git リポジトリを使用する方法について説明します。
運用担当者リポジトリ
運用担当者管理のリポジトリには、CI / CD とアプリケーションの構成に関するベスト プラクティスが含まれており、最初から組織のベスト プラクティスを導入しながら、チームのアプリケーションをオンボーディングしやすくします。運用担当者が管理するリポジトリを使用することで、デベロッパーは、ワークフローに対する中断を可能な限り低減しつつ、組織のベスト プラクティスに対する更新を使用できます。
運用担当者は、組織のベスト プラクティスを 2 つのリポジトリにエンコードできます。最初のリポジトリでは、運用担当者が共有 CI / CD パイプラインのベスト プラクティスを維持します。このリポジトリで、運用担当者はパイプラインの構築に使用できる事前定義されたタスクのライブラリをデベロッパーに提供します。デベロッパーのアプリケーション リポジトリは、これらのタスクとタスクに含まれるロジックを自動的に継承するため、タスクを手動でコピーする必要はありません。組織全体で標準化できるタスクの例は次のとおりです。
アーティファクトの構築と保存
さまざまな言語のテスト方法
デプロイ手順
ポリシー チェック
セキュリティ スキャン
運用担当者が維持する 2 つ目のリポジトリには、アプリケーションの構成に関するベスト プラクティスが保存されています。GKE のコンテキストでは、ベスト プラクティスには、Kubernetes リソースモデルで宣言的なマニフェストを管理する方法を確保することが含まれています。これらのマニフェストでは、意図するアプリケーションの状態が記述されます。運用担当者は、さまざまな種類のアプリケーションの基本構成を作成し、組織のベスト プラクティスに従ってアプリをデプロイするための簡素化されたパスをデベロッパーに提供できます。
アプリケーション リポジトリ
アプリケーション リポジトリには、アプリケーションのビジネス ロジックと、アプリケーションが適切に動作するために必要とされる特化した構成が保存されます。
運用担当者が体系化された方法でベスト プラクティスを作成して維持するため、デベロッパーはそれらのベスト プラクティスを使用できます。これを行うために、デベロッパーは CI / CD のタスクと、運用担当者が独自のリポジトリで作成したアプリケーション ベースを参照します。デベロッパーが変更を行った後、運用担当者は、データベース URL やリソースラベルとアノテーションなどの環境固有の構成を追加することで、アプリケーションのデプロイをさらにカスタマイズできます。
アプリケーション リポジトリに保存できるアーティファクトの例は次のとおりです。
アプリケーションのソースコード
アプリケーションのビルド方法と実行方法を示す
DockerfileCI / CD パイプラインの定義
運用担当者が作成するアプリケーション構成ベースの拡張または変更
Infrastructure as Code リポジトリ
Infrastructure as Code リポジトリは、アプリケーションの実行に必要なインフラストラクチャを構築するためのコードを格納します。インフラストラクチャには、GKE などのネットワーキングとコンテナ オーケストレーション プラットフォームが含まれる場合があります。通常、インフラストラクチャ管理者はこれらのリポジトリを所有しています。オペレーターはベスト プラクティスを実装するためにそれらを更新できます。
アプリケーション リポジトリに保存できるアーティファクトの例は次のとおりです。
- インフラストラクチャ オブジェクトを表す宣言型言語コード（Terraform、Pulumi）。
宣言型 API 定義を補完するシェルまたは Python スクリプト。
インフラストラクチャ チームが作成したベース インフラストラクチャ テンプレートの拡張または変更。
構成リポジトリとポリシー リポジトリ
運用担当者とセキュリティ エンジニアのいずれにとっても、セキュリティが強化され、一貫性のあるプラットフォームを確保することが最優先事項です。
構成
一元化された構成を使用すると、構成の変更をシステム全体に反映できるようになります。一元管理できる一般的な構成項目には、次のものがあります。
Kubernetes Namespace
割り当て
ロールベースのアクセス制御（RBAC）
ネットワーク ポリシー
これらの種類の構成をクラスタ全体に一貫して適用して、アプリケーション チームがインフラストラクチャを不正使用や悪用しないようにする必要があります。Git リポジトリを使用して構成を保存することで、GitOps などのメソッドで監査や構成のデプロイなどのプロセスを強化できます。Config Sync などのツールを使用すると、インフラストラクチャ全体で構成を均一に適用するプロセスを簡素化できます。
ポリシー
デベロッパーは、運用担当者が作成したベース構成を拡張できるため、プラットフォームを構成するクラスタで作成されたリソースを制限する方法が必要です。場合によっては、デベロッパーが特定の要件を満たすリソースのみを作成できるようにするポリシーを作成することが必要な場合があります（外部負荷分散用に構成できない Kubernetes Service オブジェクトを作成する場合など）。
関連するリファレンス アーキテクチャでは、Policy Controller を使用してポリシーを適用します。
スターター リポジトリ
スターター リポジトリは、CI / CD の導入、インフラストラクチャ、プラットフォーム全体の開発のベスト プラクティスを支援します。スターター リポジトリによって、ベスト プラクティスの導入に関連する費用を大幅に削減できます。一方、ベスト プラクティスは、機能のスピード、信頼性、チームの生産性を改善するうえで有用です。関連するリファレンス アーキテクチャには、CI、CD、Kubernetes 構成、Go、Java、Python スターター アプリケーションとインフラストラクチャなど、複数のスターター リポジトリがあります。
継続的インテグレーション
組織には通常、CI 中にアプリケーションに適用される標準のタスクのセットがあります。たとえば、リファレンス実装では、CI ステージの基本セットはコードのコンパイルとコンテナ イメージのビルドです。これらのステージはスターター リポジトリで定義されるため、プラットフォーム全体で均一に適用されます。個別のアプリケーション チームがその他のステップを追加できます。
継続的デリバリー
CI と同様に、通常の CD のプロセスには、開発環境、本番前環境、本番環境を通して、アプリケーションをデプロイするための一連の標準的な手順があります。使用されているデプロイ方法に関係なく、スターター リポジトリを使用すると、プラットフォーム チームがアプリケーションと環境全体にこれらの手法を均一に適用できます。リファレンス実装では、デプロイ プロセスには、開発および本番前のデプロイのロールアウト、複数のクラスタにわたる本番環境デプロイ、Cloud Deploy を使用した本番環境デプロイの手動承認が含まれます。
アプリケーションの構成
ソフトウェア デリバリー プラットフォームを効果的に機能させるには、アプリケーション構成を適用する均一で一貫した方法が必要です。Kubernetes 構成に kustomize やスターター リポジトリなどのツールを使用することで、プラットフォームはアプリケーション構成に一貫した基盤を提供できます。たとえば、リファレンス実装では、kustomize 基本構成が、アプリケーション環境リポジトリを既知の正常な基本セットで初期化します。個別のアプリケーション チームは必要に応じて構成を変更できます。
スターター アプリケーション
スターター アプリケーションは、オブザーバビリティやコンテナのベスト プラクティスといった、導入するベスト プラクティスに関連するオーバーヘッドを削減するのに有用です。
オブザーバビリティ。アプリケーションを効率的に運用し、信頼性を確保するため、アプリケーションはロギング、指標、トレースを考慮する必要があります。スターター アプリケーションにより、オブザーバビリティを高めるフレームワークと戦略を組み込むことができます。
コンテナのベスト プラクティス。コンテナ化されたアプリケーションを構築する際は、小さな、かつクリーンなコンテナ イメージを構築する必要があります。コンテナのベスト プラクティスには、イメージに単一のアプリケーションをパッケージ化する、イメージから不要なツールを削除する、最小ベースイメージから小さなイメージを積極的に作成する、などがあります。詳細については、コンテナ構築のベスト プラクティスをご覧ください。
リファレンス アーキテクチャは、出発点として基本的な Go アプリ、基本的な Java アプリ、基本的な Python アプリを提供します。チームが開発した言語、技術スタック、アプリケーションの種類向けにカスタマイズされたスターター アプリケーションを追加する必要があります。
インフラストラクチャ スターター リポジトリ
インフラストラクチャ スターター リポジトリには、異なるインフラストラクチャ コンポーネントを作成するために必要なコードが事前に記述されています。これらのリポジトリは、インフラストラクチャ チームが決定した標準のテンプレートとモジュールを使用します。
たとえば、リファレンス実装では、platform-template に Google Cloud プロジェクト、Virtual Private Cloud、GKE クラスタを構築するためのスターター コードが含まれています。このテンプレートは通常、複数のアプリケーション チームが使用するインフラストラクチャをインフラストラクチャ チームが共有リソースとして管理するために使用されます。同様に、infra-template には、アプリケーションに必要な基本的なスターター インフラストラクチャ コード（たとえば、Cloud Storage や Spanner データベース）が含まれています。このテンプレートは通常、アプリケーション チームがアプリケーションのインフラストラクチャを管理するために使用します。
共有テンプレート リポジトリ
共有テンプレート リポジトリは、組織内の誰でも再利用できる標準のタスク テンプレートを提供します。たとえば、Terraform モジュールのような Infrastructure as Code モジュールは、ネットワークやコンピューティングなどのインフラストラクチャ リソースの作成に使用できます。
アプリケーションのランディング ゾーン
共有 CI / CD、共有アプリケーション構成、クラスタ全体で一貫したポリシーと構成を使用する場合は、これらの機能を連携させてアプリケーションのランディング ゾーンを作成できます。
ランディング ゾーンは、ロックダウンされたロジックのエンティティであり、デベロッパーがアプリケーションでデプロイと反復処理を行えるようにします。アプリケーションのランディング ゾーンでは、デベロッパーが自律的に操作できるように配置したガードレールが使用されます。アプリケーションごとに、各環境（本番、開発、ステージングなど）の Kubernetes Namespace を作成します。この整合性により、運用担当者が、時間の経過に伴う環境のデバッグと維持を行うことが容易になります。
次の図は、ランディング ゾーンのコンセプトを示しています。
運用モデル
最新の CI / CD でソフトウェア デリバリー プラットフォームを運用する場合は、環境、インフラストラクチャ、プロセスを一貫性のある最新の状態に保つことが重要です。そのため、プラットフォームのオペレーティング モデルを慎重に計画して選択する必要があります。サービスとしてのクラスタ、ブループリント、マルチテナント インフラストラクチャなど、さまざまなモデルから選択できます。
整合性のあるインフラストラクチャを維持し、不規則な広がりを制限して、チームがアプリのデリバリーに集中できるようにすることが重要なため、マルチテナント インフラストラクチャをデプロイすることをおすすめします。マルチテナント インフラストラクチャにアプリケーションをデプロイすると、アプリケーション チームはインフラストラクチャを管理する必要がなくなり、運用担当者チームとセキュリティ チームはインフラストラクチャの一貫性の維持に集中できます。
マルチテナント インフラストラクチャに関する考慮事項
マルチテナント ソフトウェア デリバリー プラットフォームを構築する場合、プラットフォームへの組み込みについて考慮することが必要な可能性があるいくつかの考慮事項が存在します。
ワークロードの分離。アプリケーションのランディング ゾーンのコンセプトは、ワークロードを分離するためのフレームワークを提供することです。ランディング ゾーンは、Namespace、ネットワーク ポリシー、RBAC を組み合わせたものです。これらのポリシーはすべて一元管理して、Config Sync を使用して適用する必要があります。
テナントの使用量のモニタリング。クラスタ内の個別の Namespace とラベルでコストの内訳を確認するには、GKE 使用量の測定を使用します。GKE 使用状況メータリングでは、クラスタのワークロードのリソース リクエストとリソース使用量に関する情報が追跡されます。これらの情報は、Namespace とラベルでさらにフィルタリングできます。マルチテナント クラスタで GKE 使用状況測定を有効にすると、リソースの使用量レコードが BigQuery テーブルに書き込まれます。テナント固有の指標を対応するテナント プロジェクトの BigQuery データセットにエクスポートして、監査担当者がそれらの指標を分析し、コストの内訳を確認できます。
リソースの割り当て。クラスタを共有するすべてのテナントがクラスタ リソースに公平にアクセスできるようにするには、リソースの割り当てを適用する必要があります。各テナントでデプロイする Pod の数と各 Pod に必要なメモリと CPU の量に基づいて、Namespace ごとにリソースの割り当てを作成します。
各環境に複数のクラスタがある場合。アプリケーションとプラットフォームの信頼性を改善するには、本番前環境と本番環境ごとに複数のクラスタを使用する必要があります。複数のクラスタを使用できる場合は、カナリアの検証の追加レベルのために、アプリケーションをクラスタに個別にロールアウトできます。さらに、複数のクラスタを用意することで、クラスタの管理とアップグレードのライフサイクルに関連する問題を軽減します。
テナント固有のロギングとモニタリング。アプリケーションの運用について調査するには、テナントがログと指標にアクセスする必要があります。マルチテナント環境では、ロギングとモニタリングはアプリケーション固有であることが必要です。指標とモニタリングには、Namespace ごとに Google Cloud Managed Service for Prometheus と Grafana を使用できます。ログについては、BigQuery データセットにログエントリをエクスポートするためにシンクを作成し、テナント Namespace でデータセットをフィルタリングする必要があります。テナントは BigQuery のエクスポートされたデータにアクセスできます。
マルチテナント インフラストラクチャの詳細については、エンタープライズ マルチテナンシーのベスト プラクティスをご覧ください。
分離境界
ソフトウェア デリバリー プラットフォームは複数のチームが構築して使用するため、プラットフォームの異なるコンポーネント間で適切な分離境界があることが重要です。分離境界は、次の特性を提供することで、堅牢なプラットフォームを構築するのに役立ちます。
責任の分離。各チームは、残りの部分を気にすることなく、分離境界内のリソースを管理します。たとえば、インフラストラクチャ チームは GKE クラスタのメンテナンスのみを担当します。オペレーターまたはデベロッパーは、CI / CD パイプラインとアプリケーション コードのメンテナンスのみを担当します。
きめ細かなアクセス制御リソースが分離境界によって分離されている場合は、きめ細かいアクセス制御を使用してアクセスを制限します。
影響を受ける領域を縮小。他のコンポーネントに影響を与えることなく、コンポーネントに個別に変更を加えることができます。
手動エラーを削減。アクセス制御が細分化されているため、開発環境から本番環境クラスタに誤ってデプロイするといった手動エラーを回避できます。
これらの分離境界は、異なるアプリケーション間、インフラストラクチャとアプリケーション間、さらにはアプリケーションの異なる環境間に存在できます。
ガバナンス
ソフトウェア デリバリー プラットフォームおよび最新の CI / CD システムの主な目的は、ソフトウェア デリバリー プロセス全体の効率性の改善です。プラットフォームの管理に関しては、アプリケーションのオンボーディング（一般的にはガバナンスのカテゴリに分類されます）と、プラットフォームについて進行中の開発と保守（プラットフォームをプロダクトと同様に扱うこと）という 2 つの主要な考慮事項が存在します。
アプリケーションのオンボーディングと管理
最新の CI / CD 手法とツールを導入する目的は、リリース プロセスと新しいサービスのオンボーディングを合理化することです。新しいアプリケーションのオンボーディングは、運用チームおよびセキュリティ チームによる最小限の入力で行える、簡単なプロセスにする必要があります。これは、運用チームとセキュリティ チームが関係せずに、デプロイとセキュリティの観点からの初期入力が、プロビジョニング プロセスによって自動的に処理されるという意味ではありません。オンボーディングされると、運用チームとセキュリティ チームは、統合リクエスト、ポリシーの更新、ベスト プラクティスの適用を通じて、リリース プロセスに自然に組み込まれます。
新しいアプリケーションをオンボーディングするための自動化を作成することをおすすめします。これには、コード リポジトリ、CI / CD パイプライン、ランディング ゾーン、アプリケーションに必要なインフラストラクチャの作成が含まれる場合があります。自動化により、開発チームの組織内の他のチームへの複雑な依存関係が分離され、デベロッパーはアプリケーションのセルフサービスを自律的に行うことができます。これにより、デベロッパーはアプリケーションのコードで非常にすばやく反復処理を開始でき、コードの作成以外の作業の実行に時間を費やさなくてよくなります。自動化により、デベロッパーはアプリケーションを開発環境で実行できるようになります。アプリケーションをより高度な環境に配置するためには、他のチームが関与してレビュー プロセスに従う必要があります。
関連するリファレンス アーキテクチャでは、この自動化をアプリケーション ファクトリと呼びます。
プロダクトとしてのプラットフォーム
CI / CD ワークフローはソフトウェア プロダクトです。ただし、プロダクトのユーザーは、開発、運用、セキュリティの各チームではありません。その点を考慮すると、プラットフォームには、プロダクト オーナー、マーケティング（内部向けであっても）、ユーザー フィードバック ループ、機能開発サイクルなど、同じソフトウェア開発のロールとプロセスが必要です。
GKE で CI / CD をデプロイする
GKE を使用して最新の CI / CD の組織へのデプロイを開始する場合は、最適なパイロット アプリケーションを選択することが重要です。開発チーム、運用チーム、セキュリティ チームは、作業を行う際に、他の要素も考慮する必要があります。このセクションではそれらの要素について説明します。
パイロット アプリケーションの選択
プラットフォームに移行する最初のアプリケーションの選択は、最初の困難な手順になる場合があります。パイロットにふさわしい候補は、データを処理またはリクエストを処理しますが、データは保存しないサービスです（キャッシュ レイヤ、ウェブ フロントエンド、イベントベースの処理アプリケーションなど）。通常、これらのアプリケーションは、新しいデプロイと構成管理手法で作業するときに、いつでも発生する可能性がある少量のダウンタイムやデプロイエラーに対する耐性がより高くなります。チームが CI / CD の経験を積み、信頼性と速度のメリットも得られるようになると、コアサービスのソフトウェア デリバリー プラットフォームへの移行を開始できるようになります。
デベロッパーに関する考慮事項
最新の CI / CD 開発プロセスで作業する場合は、機能、変更、デプロイがより高頻度かつ非同期的に発生する可能性があります。開発チームは、変更がダウンストリームや依存システムに与える影響と、その変更のテスト方法を理解する必要があります。開発チーム、運用チーム、セキュリティ チームの間の通信経路は、滑らかである必要があります。アプリケーションと、さまざまなサービスが通信を行う根拠となるデータ契約の両方について、より良いバージョニングの実施に投資することをおすすめします。通信方法とバージョニングの改善に加えて、小さな部分で機能を実装し、機能ブランチとフラグを活用することで、機能のテストとリリースの方法を改善できます。
運用担当者に関する考慮事項
ソフトウェア デリバリー プラットフォームでは、運用チームが開発チームと類似したより多くの機能を果たす必要があります。外部向け機能を構築する代わりに、外部向けアプリケーションの開発、デプロイ、運用に有用な内部ツールとプロセスを構築します。プラットフォーム ツールは、運用チーム自身だけでなく、開発チームやセキュリティ チームも利用できます。運用担当者は、アプリケーションの新しいバージョンの展開を支援するためのツールと、アプリケーション エラーまたはデプロイの失敗の場合に備えてロールバックするためのツールも構築する必要があります。運用担当者には、障害を積極的に検出し、それに応じてアラートするように、モニタリング システムとアラート システムの構築により重点を置くことも必要です。
セキュリティ チームに関する考慮事項
セキュリティ チームは、セキュリティ チーム自身と運用チームおよび開発チームとの間で、セキュリティに関する責任の共有を強化するための取り組みを行う必要があります。このパターンは一般的に、セキュリティのシフトレフトと呼ばれ、開発プロセスの初期段階で情報セキュリティ（InfoSec）が関与し、デベロッパーは事前に承認されたツールを使用して作業を行い、セキュリティ テストが自動化されます。これらの手法に加えて、Policy Controller を使用してプログラムでセキュリティ ポリシーを定義し、適用できます。手法とツールを組み合わせることで、より積極的な姿勢でセキュリティを適用できます。
次のステップ
この最新の CI / CD アーキテクチャの側面の実装を試してみる。
ID 連携の設定に関するベスト プラクティスの詳細を確認する。