環境について
デプロイ ワークフローを使用すると、デプロイ プロセスのステップを自動化できます。 多くの場合、複数の異なる環境でステップを実行する必要があります。 あなたの玩具会社では、変更を運用環境にデプロイする前に、コードへの変更を確認する必要があります。
このユニットでは、GitHub Actions の環境が、どのように独自のプロセスのサポートに役立つかについて学習します。
複数の環境が必要な理由
デプロイ プロセスは、使用中のリソースも含む Azure リソースに対して変更を行います。 デプロイする変更が期待通りに動作するとは限らないため、リソースの変更にはリスクが伴います。 変更により、現在の設定が壊れるおそれすらあります。
問題のリスクを最小限に抑えるために、運用環境にデプロイする前に、安全な方法で変更を試してみるのは良いことです。 "非運用環境" に変更をデプロイすることでリスクを最小化します。
多くの組織は、運用環境にリリースする前に変更を積極的にデプロイする、複数の非運用環境を設定しています。 各非運用環境は特定の目的を果たし、多くの場合は次の環境に進む前に満たさなければならない特定の品質ゲートが定められています。 テストが失敗するなど、何かがうまくいかなかった場合はデプロイが停止します。 デプロイが各環境を通過していくことで、変更に対して自信を持つことができます。
一般的な環境には次のものがあります。
開発: 開発環境は通常、開発者が変更を試し、作業を迅速に繰り返すために使用します。
多くの場合開発環境は、チーム メンバーが簡単にアイデアを試せるようにするため、最小限の制限しかありません。 開発環境を使用することにより、リソースに対する特定の構成設定をテストしたり、バックエンド データベースを持つ新しい Web サイトを安全に設定する方法を確認したりすることができます。 成功しないアイデアは捨てられるので、このような変更や試行の多くはデプロイ プロセスまで進まないでしょう。
チームによっては、チーム メンバーそれぞれに対して別個の開発環境を設定することさえあります。そうすることで、新しい機能を試す際にお互いに妨害することを避けられるからです。
開発環境は、サンドボックス環境と呼ばれることもあります。
テスト: テスト環境は、変更に対して手動または自動のテストを実行することを目的としています。
テスト環境は、継続的インテグレーション プロセスで使用できます。 変更をテスト環境にデプロイしたら、変更に対して自動テストを実行できます。 すべての自動テストに合格したら、変更をプロジェクトのメイン ブランチに安全にマージできます。 自動テストでは一般的に、主要なシステム機能や、新しくデプロイされたリソースのポリシー違反などをチェックします。
また、パフォーマンスやセキュリティのテストなど、特定の種類のテスト専用の環境を作成することもできます。
統合: 統合環境では、他のシステムとの統合点をテストすることができます。
統合環境で、エンドツーエンドのトランザクションをシミュレートできます。 このようなテストは自動で実行されることが多いものの、多くの組織はこの環境に対して手動のテストも実施しています。
統合環境は、システム統合テスト (SIT) 環境と呼ばれることもあります。
ユーザー受け入れテスト: ユーザー受入テスト (UAT) 環境は、通常は開発者ではなくビジネス上の利害関係者により、手動の検証のために使用されます。 手動の検証では、誰かがソリューションを使用してみて、期待通りに動作すること、必須のビジネス要件を満たしていることを確認します。 その人が変更を承認すると、デプロイが継続されます。
実稼働前: 実稼働前環境は、多くの場合運用環境のミラーであり、同じリソース SKU や構成を持ちます。 変更の適用前と後で、運用環境デプロイがどのように動作するかを検証するための最終チェックとして使用されます。 運用環境デプロイでダウンタイムが発生するかどうかを検証するためにも使用されます。
実稼働前環境は、ステージング環境と呼ばれることもあります。
運用: 運用環境は、アプリケーションのエンド ユーザーが使用するものです。 できる限り保護し、稼働させ続けるべきライブ環境です。
組織によっては、運用環境が複数ある場合もあります。 例として、地理的に異なるリージョンに運用環境が設定されていたり、異なるグループの顧客にサービスを提供するための運用環境が設定されているかもしれません。
デモ: アプリケーションをエンド ユーザーに見せたり、トレーニングで使用したり、営業チームが特定の機能を潜在顧客に見せたりするために、デモンストレーション (デモ) 環境を作成することもできます。 さまざまな目的のために、複数のデモ環境を設定することも可能です。 デモ環境は多くの場合、仮の顧客データを持つ、運用環境を小型化したレプリカです。
組織内の環境
これらの環境をカスタマイズしたものが使用されることもあります。 ほんの少しの環境だけを使う組織もあれば、多くの環境を使用する組織もあるでしょう。 使用する環境の数と種類はデプロイするソリューション、ソリューションを構築しているチームの規模、ワークロードの重要性によって異なるでしょう。
ある場合には、単一の環境が、すでに説明した環境のいくつかの役割を担うこともあります。 またある場合には、複数の環境を、一部は並列、一部は直列にデプロイして、複雑なワークフローをデプロイすることもあるでしょう。 必要でなくなった環境の削除やプロビジョニング解除を自動で行い、将来必要になったときに再デプロイしている組織もあります。
組織がどのような環境を使用するにせよ、その目標は、変更がデプロイ ワークフローを経るにつれ、その変更に対する自信を深めることです。 変更が品質の要件を満たさない場合、後続の環境へのその変更のデプロイをやめることができます。
あなたの玩具会社では、Web サイトのためにいくつかの基本的な環境を使用することに決めました。 運用環境に加えて、Test という名前の 1 つの非運用環境を作成します。
Bicep コードをテスト環境にデプロイしていくつかの基本的なテストを実行するために、ワークフローを更新します。 この取り組みがうまくいけば、運用環境にデプロイします。
ワークフロー環境
GitHub Actions にも、環境の概念があります。 Azure にある環境を表すために、GitHub Actions 環境を作成します。 YAML ファイルでワークフローを定義すると、ジョブを特定の環境にリンクできます。 環境を使用することにより、ワークフローでいくつかの追加の機能を使用できます。
保護ルール
GitHub Actions の環境に保護ルールを構成できます。 ワークフロー内のジョブで環境が使用されるたび、GitHub Actions によって、ジョブの実行が開始される前にこれらのルールが満たされていることが確認されます。
たとえば、運用環境で手動のレビューを構成できます。 運用環境デプロイが開始される前に、指定されたレビュー担当者が通知を受け取ります。 その人は、デプロイが開始する前にポリシーとプロシージャの条件が満たされていることを手動で確認できます。 たとえば、デプロイを承認する前に、承認者はすべてが期待通りに動作することを実稼働前環境でチェックするかもしれません。
また、自動チェックを実行して、変更が発生しているブランチを確認できます。 変更がメイン ブランチに存在しない場合は、運用環境にデプロイされないように GitHub を構成できます。
シークレット
GitHub Actions を使用すると、特定の環境でのみ使用できるシークレットを格納できます。 シークレットの管理については、このモジュールで後ほど詳しく説明します。
デプロイ履歴
GitHub Actions では、環境へのデプロイの履歴が追跡されます。 この履歴により、時間の経過とともに環境で発生したことを簡単に追跡できるようになります。 リポジトリ内のコミットへのデプロイを追跡することもできます。 この機能は、デプロイで問題が発生し、問題の原因になった変更を特定する必要がある場合に役立ちます。
環境を作成する
GitHub Web インターフェイスを使用して環境を作成します。
存在しない環境をワークフローが参照している場合は、GitHub Actions によって環境が自動的に作成されます。 新しい環境には保護ルールが構成されないため、この機能は、GitHub リポジトリのセキュリティに影響を与える可能性があります。 セキュリティを完全に制御するには、GitHub Web インターフェイスを使用して環境を自分で作成する必要があります。
デプロイ ジョブを環境にリンクする
デプロイ ワークフロー定義では、environment プロパティを使用して環境を参照できます。
jobs:
deploy:
environment: Test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
この例では、deploy という名前のジョブが Test 環境にリンクされています。
環境と Azure への接続
複数の環境を使用する場合、それぞれの環境を他から独立させる必要があります。 たとえば、開発環境の Web サイトは運用環境内のデータベースにアクセスできるべきではありません。
同じ原則が、デプロイ ワークフローにも当てはまります。 環境ごとに個別のワークロード ID を使用する必要があります。 このプラクティスに従うことで、非運用環境デプロイが運用環境に影響を及ぼさないようにするための保護レイヤをもう一つ加えることができます。
ワークロード ID には、その環境で使用されるサブスクリプションとリソース グループにのみデプロイするための特定のアクセス許可を割り当てる必要があります。
重要
デプロイ先の環境ごとに別個のワークロード ID を使用してください。 ワークロード ID には、環境にデプロイするのに必要な最小限のアクセス許可だけを付与します。
Azure で環境を分離するのも良い方法です。 少なくとも、各環境に対して別個のリソース グループを作成する必要があります。 多くの場合、各環境に対して別個の Azure サブスクリプションを作成するとよいでしょう。 その後、各環境のサブスクリプション内で複数のリソース グループを作成できます。
アクセスする必要がある環境だけにユーザーとワークロード ID がアクセスできるように、Azure のロールの割り当てを適用します。 運用環境へのアクセスを、少数の人々と、その環境用のデプロイ ワークロード ID に制限するように注意してください。
環境のフェデレーション資格情報
ワークロード ID は、デプロイ ワークフローから Azure に接続するときに、"フェデレーション資格情報" を使用して、シークレットやキーなしでそれ自体を安全に認証します。 このラーニング パスの前のモジュールでは、Git リポジトリの main ブランチからデプロイするときにデプロイ ワークフローへのアクセスがフェデレーション資格情報により許可されました。
ワークフロー内の環境にデプロイする場合は、その環境にスコープを指定したフェデレーション資格情報を使用する必要があります。
このモジュールでは、ワークフローに複数のジョブが含まれており、その多くが Azure に接続し、デプロイされます。 一部のジョブでは環境を使用し、一部は使用しません。 そのため、ワークロード ID ごとに 2 つのフェデレーション資格情報を作成します。1 つは環境にスコープを指定し、1 つは main ブランチにスコープを指定します。