環境を計画する
Azure 資産は、基本構成、組織全体のリソースと設定、アプリケーション ワークロードなど、多くのコンポーネントで構成されています。 また、それぞれ目的が異なる複数の環境に資産を分散している可能性もあります。
このユニットでは、すべてのデプロイと構成にコードを一貫して使用する利点について学習します。 その後、各環境に適用できる制御と自動化のレベルを検討します。 また、デプロイ プロセスの各ステージを通じて変更がどのように進行するか、選択したデプロイ戦略をサポートするために必要な制御とガバナンスの種類についても検討します。
インフラストラクチャをコードとして定義する
Azure のデプロイと構成は、アプリケーション、仮想マシン、ストレージ サービス、ネットワークよりもはるかに多くをカバーします。 たとえば、次の各項目は、対応する Azure リソースを含む構成の形式です。
- リソース グループ、サブスクリプション、管理グループを作成してリソースを整理する。
- Azure Policy 定義、イニシアチブ、割り当てを定義して適用し、他のリソースの構成方法を制御する。
- ユーザー、グループ、ワークロード ID による Azure リソースへのアクセスを許可するためにロールを割り当てる。
- Azure リソースが想定どおりに動作していることを確かめるために、アラートなどの監視を構成する。
コードとしてのインフラストラクチャの定義を初めて開始するときに、項目のすべてがテンプレートまたは定義で定義できることに気付かない場合があります。 ただし、自動化の利用について成熟してきたら、環境に関するあらゆるものをコードとして定義することをお勧めします。 そうすると、"すべて" の Azure 構成に対して、一貫した、テスト済みの承認されたプロセスを使用できます。 また、コードは Git リポジトリでバージョン管理および追跡されるため、Azure 環境が時間の経過とともにどのように変化したかを確認できます。 Git リポジトリを使用して、各変更の履歴をトレースできます。
たとえば、Azure Monitor アラートを構成する必要があるとします。 最初は、自動化を使用してアラートをデプロイすることは意味をなさないと思うかもしれません。 しかし、アラートは Azure 構成の重要な部分です。 アラートが正しく作成されていない場合は、重要な運用上の問題の通知を見逃す可能性があります。 コードでアラートを定義すると、次のようになります。
- チーム メンバーがアラートとその構成を確認できます。
- 最初に非運用環境にアラートをデプロイして、テストすることができます。
- Azure 構成に対する変更の完全な追跡可能性がもたらされます。
環境
インフラストラクチャを自動的にデプロイする予定がある場合は、使用する予定の環境を一覧表示すると便利です。 多くの組織には、それぞれ異なる特性を持つさまざまな種類の環境があります。 次に例を示します。
- 運用コードを実行する環境もあれば、おそらく異なる構成を使用して同じコードの非運用バージョンを実行するものもあります。
- 環境には、存続期間が長く、削除される予定のないものがあります。 "エフェメラル" なものもあります。つまり、自動的に作成され、使われなくなると破棄されます。
- 一部の環境は、インフラストラクチャまたはソフトウェア開発チームによって使用されます。 その他は、見込み顧客に製品のデモを行う必要があるときに、セキュリティ チームや、さらには営業チームによって使用されます。
玩具会社が Web サイト用に使用する可能性がある環境について考えてみます。
アプリケーションまたはインフラストラクチャに変更を加えてコミットすると、パイプラインで一連の非運用環境 (開発、テスト、ステージング) を経て変更がデプロイされます。 また、デプロイを続行する前に、定義済みのチーム メンバーが構成を確認したり、パイプライン ログを確認したりできるように、特定の時点に手動の承認手順を含めることもできます。 その後、最終的にパイプラインによって変更が運用環境にデプロイされます。
これらの環境に加えて、営業チームには、顧客との商談に使用する独自の "デモ" 環境があります。 営業チームは、運用環境のコピーを受け取ってデモ環境を作成します。 セキュリティ チームとテスト チームは、侵入テストとパフォーマンス テストのために、それぞれ運用環境の一時的なコピーを作成することがあります。
開発チームにも独自の環境セットがあります。 それには、開発チーム メンバーが新しい機能を探索したり、Azure サービスを試したりするときに使用できる "サンドボックス" が用意されています。 また、開発チームは、レビューとマージを行う GitHub pull request ごとに PR レビュー環境を作成します。
制御された環境
これらの環境の一部では、変更をレビューして適用するための正式なプロセスを要求することが理にかなっています。 この種の環境は ''制御された環境'' と呼ばれます。 運用環境は常に制御される必要があります。 一部の非運用環境にも制御を適用することをお勧めします。 そうすると、運用環境のデプロイの前に確実に、制御によって課される制限が十分に理解され、テストされるようになります。
これに対し、"制御されていない" 環境には、正式な制御が多くないか、まったくありません。 他の環境と同じコードおよび類似した構成がありますが、より多くの実験とアドホックな構成変更が可能です。 制御されていない環境では、ユーザーは Azure portal を使用するか、Azure CLI または Azure PowerShell コマンドを直接実行して、構成を変更できる場合があります。 また、組織の承認されたプロセスを使用せずにリソースを作成できる場合もあります。 制御されていない環境で行われた変更は、運用環境のように制御された環境に適用を開始する前に、コードで捕捉する必要があります。
Note
場合によっては、1 つの "環境" が実際には複数の物理環境またはデプロイを表すことがあります。 たとえば、pull request レビュー用のエフェメラル環境を作成する場合、チームで複数の pull request が処理中であるときは、複数の異なる環境が同時にアクティブになる可能性があります。 しかし、それらには同じ特性と制御が設定されているため、環境を計画する目的では、それらを同等と見なすことができます。
チームと話し合った後、制御される環境と制御されない環境を指定します。 また、各環境を所有するユーザーを決定します。
| 環境名 | 説明 | 所有者 | 有効期間 | コントロールのレベル |
|---|---|---|---|---|
| 開発 | 複数の開発者からの変更を 1 つの環境に統合します。 | 運用チーム | 存続効期間が長い | 制御 |
| テスト | 変更に対して手動および自動のテストを実行するための環境。 | 運用チーム | 存続効期間が長い | 制御 |
| ステージング | 運用の前に、運用環境に似た構成を使用して変更がデプロイされる最終的な非運用環境。 | 運用チーム | 存続効期間が長い | 制御 |
| Production | 運用ワークロードを実行します。 | 運用チーム | 存続効期間が長い | 制御 |
| デモ | 営業チームが新しい顧客に製品のデモを行うために使用します。 | 営業チーム | 存続効期間が長い | 制御されない |
| パフォーマンス テスト | パフォーマンスとストレスのテストを実行するために、運用環境の複製として動的に作成され、その後はテストが完了したときに削除されます。 | テスト チーム | 存続期間が短い | 制御されない |
| 侵入テスト | 侵入とセキュリティのテストを実行するために、運用環境の複製として動的に作成され、その後はテストが完了したときに削除されます。 | セキュリティ チーム | 存続期間が短い | 制御されない |
| PR レビュー | チーム メンバーがアプリケーションまたはインフラストラクチャを変更するために作成する pull request ごとに動的に作成されます。 環境は、pull request が閉じられたときに削除されます。 | 開発チーム | 存続期間が短い | 制御されない |
| 開発サンドボックス | 開発チーム メンバーが実験または探索を行うために作成し、不要になったら削除します。 | 開発チーム | 存続期間が短い | 制御されない |
上記の環境の一覧は、単なる例です。 ご自身の組織で使用する環境、適切な存続期間、各環境に必要な制御レベルを決定する必要があります。
ヒント
インフラストラクチャ コードのリント、テスト、レビューをデプロイで早期に適用すると、これらのプロセスは非常に簡単になります。このようにしないで、それらを後から追加すると、壊れたコードを多数修正しなくてはなりません。
同様に、セキュリティ制御が最初から存在している場合や、非運用環境の一部にも適用されている場合は、セキュリティ制御の処理がはるかに簡単になります。 そうすることで、チームは制御された環境内での作業に慣れていきます。
ラーニング パスの全体を通して、このような考え方の一部を段階を追って紹介してきました。 多くの場合、これらの要素をできるだけ早期にデプロイ プロセスに追加することをお勧めします。
各環境の分離
各環境を分離し、可能な限り自己完結型にすることが重要です。 環境ごとに専用の Azure サブスクリプションを使用すると役立ちますが、それでも環境を分離した状態に保つように注意を払う必要があります。
ある環境から別の環境に接続することは避けてください。 たとえば、運用環境の仮想ネットワークを非運用環境の仮想ネットワークとピアリングしないでください。 それを行うと、非運用環境内から誰かが誤って運用データを変更することや、機密性の高い運用データを非運用環境に漏えいさせることが容易になります。
チェックとゲート
デプロイ プロセスの進行が進むのにつれて、一連のチェックを実行して、デプロイに対する信頼度を高める必要があります。 デプロイが進行する環境ごとに意味のあるチェックを決定する必要があります。
インフラストラクチャのチェックには、多くの場合、次のものが含まれます。
- コード レビュー。
- 一時的な環境へのインレビュー コードのデプロイと、環境に対する自動テストまたは手動テストの実行。
- リンティング。
- プレフライト検証。
- 手動テスト。
- 手動での承認。
- 自動機能テスト。
- 自動スモーク テスト。
- 前の環境からの正常性シグナルを待機してから、次の環境に進みます。
これらのチェックの一部は、制御された各環境に対してなど、デプロイ プロセス内で複数回実行される場合があります。
ヒント
デプロイ プロセスを設計するときは、どんなに小さいものや明白なものでも、実行する必要があるすべての手順の一覧を作成します。 できるだけ詳細なものにします。 最初はすべてを自動化することを選択しないかもしれませんが、この方法に従うと、将来の自動デプロイ プロセスのブループリントを作成するのに役立ちます。
"ゲート" は、デプロイを続行するために正常に完了する必要がある自動または手動のチェックです。
手動介入
コード レビューとデプロイ プロセス中のチェックをできるだけ多く自動化することをお勧めします。 ただし、組織では、運用環境またはその他の制御された環境へのデプロイに対して手動の承認が必要になる場合があります。
デプロイに手動承認ゲートを使用する場合は、次の推奨プラクティスに従います。
- デプロイを承認することが許可されるユーザーを明確に定義します。 個々のユーザーを指定するのではなく Microsoft Entra グループを使用して、承認者を定義します。 今後、承認者の一覧を簡単に変更できます。
- 緊急デプロイのプロセスを用意します。 通常の承認者が連絡可能でない場合に、誰がデプロイを承認できるかを計画します。 緊急デプロイは、深夜または休暇中に行うことが必要になる可能性があります。
- 人間の介入をデプロイの承認または拒否のみに制限します。 自動化できない手順がなければ、デプロイ操作の実行に人間を必要とすることは避けてください。
ガバナンス
Azure には、次のような環境の管理に役立つツールと機能が用意されています。
- Azure Policy は、組織の要件に適合しない方法で構成されたリソースを検出するためのものです。 また、リソースがコンプライアンス違反になる方法で作成または再構成されることを防ぐのにも役立ちます。
- ロックは、重要なリソースに対する変更または削除を防ぐためのものです。
- 管理グループは、Azure サブスクリプションを整理し、ロールベースのアクセス制御とポリシーを環境全体で一貫して構成するのに役立つものです。
- Azure Monitor は、リソースからのメトリックとログを記録してダッシュボードに表示し、想定される値から逸脱したときに自動的にアラートを生成するためのものです。
Azure 資産を構築するときは、"Azure ランディング ゾーン" の使用を検討してください。 ランディング ゾーンを使用すると、最初から環境にガバナンスを構築できます。 多くのランディング ゾーンには、環境の構成に役立つ事前構築済みの Bicep および Terraform ファイルが含まれています。 概要の詳細情報へリンクします。