Important
この記事では、 継続的インテグレーションと継続的デプロイ (CI/CD) ベースライン アーキテクチャのバージョンについて説明します。 特に、Azure Pipelines を使用した Azure Kubernetes Service (AKS) アプリケーションのデプロイに重点を置いています。
Azure Pipelines は、反復可能なアプリケーション配信計画の一部として AKS へのデプロイ アクティビティを調整します。 ビルドとリリースのプロセスをパイプラインに統合して、人的エラーのリスクを軽減し、リリース サイクルを加速し、ソフトウェアの全体的な品質を向上させることができます。 この記事では、Azure Pipelines を使用して CI/CD を実装し、アプリケーションの更新を AKS クラスターにプッシュする方法について説明します。
Architecture
このアーキテクチャの Visio ファイル をダウンロードします。
データフロー
次のデータフローは、前の図に対応しています。
Azure Repos Git リポジトリまたは GitHub リポジトリへのプル要求 (PR) によって、PR パイプラインがトリガーされます。
このパイプラインでは、次の操作を含む品質チェックが実行されます。
- 依存関係管理システムから依存関係をプルする必要がある場合があるコードのビルド
- ツールを使用してコードを分析する (静的コード分析、リンティング、セキュリティ スキャンなど)
- 単体テストの実行
いずれかのチェックが失敗した場合、パイプラインの実行は終了し、開発者は必要な変更を行う必要があります。 すべてのチェックに合格した場合、パイプラインには PR レビューが必要です。 PR レビューが失敗した場合、パイプラインは終了し、開発者は必要な変更を行う必要があります。 パイプラインの実行が成功すると、PR マージが成功します。
Azure Repos Git へのマージによって CI パイプラインがトリガーされます。 このパイプラインは、PR パイプラインと同じタスクを実行し、統合テストを追加します。
統合テストに シークレットが必要な場合、パイプラインは、この環境の CI パイプライン専用のリソースである Azure Key Vault からそれらを取得します。
いずれかのチェックが失敗した場合、パイプラインは終了し、開発者は必要な変更を行う必要があります。
CI パイプラインの実行が成功すると、非運用環境の Azure コンテナー レジストリにコンテナー イメージが作成され、発行されます。 Defender for Containers は 、コンテナー イメージが Azure Container Registry にプッシュされたときにスキャンし、イメージの脆弱性を Microsoft Defender for Cloud に報告します。 必要に応じて、コンテナー イメージの整合性を確保するために、コンテナー イメージに 署名 できます。
CI パイプラインが完了すると 、CD パイプラインがトリガーされます。
CD パイプラインは、 Defender エージェントを含むステージング AKS 環境に YAML テンプレートをデプロイします。 このデプロイでは、プッシュ モデルが使用され、kubectl または Helm を介して実行されます。 テンプレートは、非運用レジストリからコンテナー イメージを参照します。
パイプラインは、ステージング環境に対して受け入れテストを実行してデプロイを検証します。 テストが成功した場合、パイプラインには、デプロイを検証してパイプラインを再開するための手動検証タスクが含まれる場合があります。 一部のワークロードは自動的にデプロイされます。 いずれかのチェックが失敗した場合、パイプラインは終了し、開発者は必要な変更を行う必要があります。
個々のユーザーが手動介入を再開すると、CD パイプラインによって、非運用環境の Azure コンテナー レジストリから運用レジストリにイメージが昇格されます。 Defender for Containers は、 コンテナー レジストリにプッシュされたときにコンテナー イメージをスキャンし、イメージの脆弱性を Microsoft Defender for Cloud に報告します。
CD パイプラインは、Defender エージェントを含む運用 AKS 環境に YAML テンプレートをデプロイします。 テンプレートは、運用レジストリのコンテナー イメージを指定します。
Prometheus 用 Azure Monitor マネージド サービス は、パフォーマンス メトリック、インベントリ データ、正常性状態情報をコンテナー ホストとコンテナーから Azure Monitor に定期的に転送します。
Log Analytics ワークスペースには、すべてのデータが格納されます。 Azure Monitor には、他の機能によって収集されたデータを分析するための複数のツールが用意されています。 さまざまな Grafana ダッシュボードは、 さまざまな Kubernetes テレメトリのセットを組み合わせたものです。 Application Insights は、トレースなどのアプリケーション固有の監視データを収集します。
Defender for Containers では、AKS で実行されるコンテナーと、コンテナー レジストリに格納されているコンテナー イメージの定期的なスキャンが実行されます。 Defender for Containers では、サポートされているコンテナー化された環境に対するリアルタイムの脅威保護も提供され、疑わしいアクティビティに対するアラートが生成されます。 この情報は、セキュリティの問題を特定し、コンテナーのセキュリティを向上させるために役立ちます。
Components
Azure Pipelines は Azure DevOps のコンポーネントであり、コードを自動的にビルドし、テストし、コンピューティング 先にデプロイします。 このアーキテクチャでは、コンテナー イメージを作成してテストし、Container Registry にアップロードして、AKS にデプロイします。
Prometheus 用の Azure Monitor マネージド サービス は、コンテナー化された環境の監視を提供する Azure 機能です。 このアーキテクチャでは、コンテナーからパフォーマンス メトリック、ログ、正常性データを収集し、分析とアラートのためにこの監視データを Azure Monitor に転送します。
Key Vault は、API キー、パスワード、証明書、暗号化キーなどのシークレットを格納およびアクセスするためのクラウド サービスです。 このアーキテクチャでは、パイプラインは Key Vault からコードをテストするために必要なシークレットを取得します。
Azure Monitor は、クラウドおよびオンプレミス環境からのテレメトリを収集、分析、応答する監視ソリューションです。 このアーキテクチャでは、AKS クラスターと CI/CD パイプライン操作の監視とアラートを提供する中央監視プラットフォームとして機能します。
Container Registry は、Azure 上のマネージドプライベート コンテナー レジストリ サービスです。 Container Registry には、プライベート コンテナー イメージが格納されます。 このアーキテクチャでは、コンピューティング プラットフォームは、Container Registry からアプリケーションのコンテナー イメージをプルします。
AKS は、Azure が正常性の監視やメンテナンスなどの重要なタスクを処理するマネージド Kubernetes サービスです。 このアーキテクチャでは、アプリケーションのコンピューティング プラットフォームとして機能します。
Microsoft Security DevOps Azure DevOps 拡張機能 を使用すると、CI/CD ワークフローにセキュリティ スキャンを直接埋め込むことができます。 このアーキテクチャでは、Microsoft Security DevOps は静的分析を実行し、AKS の開発とデプロイで複数のパイプラインにわたってセキュリティ体制を可視化します。 Microsoft Security DevOps は 、Microsoft Defender for Cloud DevOps セキュリティの一部であり、マルチクラウド環境全体で包括的な可視性、体制管理、脅威保護を提供します。
Alternatives
実装には以下の選択肢を考慮してください。
プルベース モデル (GitOps)
このシナリオでは、AKS にリソースをデプロイするためのプッシュベースのモデルを示します。 プッシュベースのデプロイは、クラスターに決定的な更新が必要な場合に最適です。 パイプラインは、デプロイをアクティブに開始し、成功を監視し、デプロイが失敗した場合は直接アクションを実行します。 このアプローチは、多くの場合、ワークロードにおける安全なデプロイ プラクティスの重要な特性です。 プッシュベースのデプロイは、1 つのクラスター内またはクラスター間で高度に制御されたロールアウト パターンが必要な、ブルーグリーン環境などの複数のデプロイ ターゲットにも適しています。
プル型のデプロイメントでは、クラスターが更新プログラムを取得して適用することで依存します。 このパターンでは、デプロイ ロジックをパイプラインから切り離します。これにより、個々のクラスターは、GitOps ワークフローの Git リポジトリやアーティファクト レジストリなどの中央の場所に格納されている目的の状態に対して調整できます。 プルベースのデプロイは、一貫性、監査可能性、自己復旧を優先する環境に最適です。 真実のソースは、多くの場合、バージョン管理されたシステムの外部に存在するため、クラスターは、この目的の状態に合わせて更新プログラムを継続的に監視して適用します。 このアプローチにより、ドリフトのリスクが軽減されます。 クラスターで障害が発生した場合、または使用できなくなった場合は、中央パイプラインからの再デプロイを必要とせずに、オンラインに戻った後に自己調整できます。
GitOps プル モデルでは、パイプラインがクラスターに直接アクセスしたり、関連付けられているデプロイ資格情報を使用したりする必要もなくなり、攻撃ベクトルが排除されます。 クラスターには、ソース リポジトリへの読み取り専用アクセスのみが必要です。 詳細については、 AKS の GitOps を参照してください。
GitHub Actions を使用してビルドされた CI/CD パイプライン
Azure Pipelines は 、AKS 用の GitHub Actions に置き換えることができます。 GitHub Actions は、ビルド、テスト、デプロイのパイプラインを自動化するために使用できる CI/CD プラットフォームです。 AKS の スターター ワークフロー の使用を検討し、CI/CD の要件に従ってカスタマイズします。
次のステップ
- Kubernetes インフラストラクチャおよびそれに依存するアプリケーションのさまざまなレイヤーの正常性とパフォーマンスを監視する Azure Monitor に基づくサービスの完全なセットについては、 Azure Monitor での Kubernetes の監視に関するページを参照してください。
- Azure Pipelines を使用する CI/CD ベースライン アーキテクチャ
- トレーニング: Azure での Kubernetes の概要