この記事では、コードとしてのインフラストラクチャ (IaC) を使用して Azure ランディング ゾーンを更新する利点について説明します。 組織は、運用時にランディング ゾーンを更新して、構成が正しいことを確認し、変更の必要性に対応する必要があります。
IaC はライフサイクル全体を管理でき、デプロイするリソースの管理に優れています。 組織は、IaC を使用して Azure ランディング ゾーンをデプロイすることを計画する必要があります。 既存の IaC 以外のリソースを、状態管理でサポートされている IaC リソースに合わせることを計画する必要があります。 既存のリソースを目的の状態にマップする必要があります。
詳細については、「Azure ランディング ゾーンを最新のに保つ」を参照してください。
コードとしてのインフラストラクチャのしくみ
IaC とは、マシンが読み取り可能な定義ファイルを使用してインフラストラクチャ リソースのライフサイクルを管理するためのプラクティスとツールを指します。 インフラストラクチャの定義は、パイプラインを介して書き込まれ、バージョン管理され、デプロイされ、ワークロードのデプロイの一部になります。
IaC テクノロジは宣言型 。つまり、IaC を実行すると、現在の状態に関係なく、コードで記述されている内容に構成が設定されます。 Azure CLI や Azure PowerShell などのスクリプトを使用してインフラストラクチャを構成する場合は、不可欠なです。 命令型スクリプトは一連のアクションを実行します。結果は、現在の状態とアクションの後の状態によって異なります。
そのため、Azure リソースのコード定義としてのインフラストラクチャがある場合は、その定義を必要な頻度で実行でき、次の場合にのみ変更が作成されます。
- 定義は、新しいリソースの追加、以前にデプロイされたリソースの削除、または以前にデプロイされたリソースの変更を行うために変更されます。
- デプロイされたリソースが構成から外れている場合、構成を定義済みのものにリセットします。
IaC を使用して状態を復元するには、不要になったリソースを削除し、多くの変更を通じてリソースのライフサイクルを管理します。
手記
IaC を使用してリソースを削除する具体的なメカニズムは異なります。 たとえば、Azure Bicep では、スコープ外のリソースを修復するために、complete デプロイの種類を使用する必要があります。 このコマンドは、特定のスコープでのみ機能します。 Terraform の場合、リソースには、Terraform でリソースを処理する方法を示す lifecycle メタ引数があります。
Azure ランディング ゾーンの場合、コードとしてのインフラストラクチャには主に次の 2 つのオプションがあります。
- Azure Bicep は、Microsoft が開発した Azure リソースのデプロイに使用されるドメイン固有の言語です。 詳細については、「Azure ランディング ゾーン - Bicep モジュールの設計に関する考慮事項」を参照してください。
- クラウドとオンプレミスにインフラストラクチャをデプロイするために、Hashicorp によって生成された製品である Terraform。 Terraform には、Azure リソースのデプロイ用に Microsoft が作成した特定のリソース プロバイダーがあります。 詳細については、「Azure ランディング ゾーン - Terraform モジュールの設計上の考慮事項」を参照してください。
コードとしてのインフラストラクチャを使用して ALZ を更新する利点
次の利点は、ランディング ゾーンを更新するためにコードとしてインフラストラクチャを使用する必要がある理由を示しています。
労力を削減する
手動で変更する場合と比較して、更新を実行するためのコードとしてインフラストラクチャを使用する手間が少なくなります。 IaC デプロイは、次の質問に答えるのに役立ちます。
- リソースは現在どのように構成されていますか?
- この更新プログラムはどのように構成されますか?
- この更新プログラムに合わせてどのような変更が行われますか?
コード ツールセットとしてのインフラストラクチャを実行すると、変更の比較または "差分" 読み取り結果を生成できます。 環境に変更をコミットする前に、この読み取り値を確認してください。
ツールセットは、オペレーターやエンジニアではなく、変更の情報をコンパイルできます。
エラーを減らす
デプロイのプログラム上の性質により、コードとしてのインフラストラクチャは、変更を加える間に人為的なエラーを減らします。 定義されている内容のみが変更され、プレビュー オプションがあるため、失敗または不完全な変更によって引き起こされる停止が軽減されます。 また、テスト オプションも改善されています。
バージョン管理と履歴
コード展開としてのインフラストラクチャは定義ファイルによってサポートされるため、ソース管理を使用して定義のバージョンを管理できます。 使用する IaC の方法に応じて、Azure for Bicep のデプロイまたは Terraform の状態ファイルを参照して、以前のデプロイの履歴を確認できます。
ソース管理プラクティスを使用すると、IaC の新しいブランチが作成され、変更とリビジョンが追加されます。 ソース管理システムのブランチの履歴は、イテレーションと変更をキャプチャします。 これを使用して、変更をマージして運用環境にデプロイする準備ができるまで、変更をテスト環境にデプロイできます。 詳細については、「Azure ランディング ゾーンのテスト アプローチ」を参照してください。 このサイクル全体を通して、デプロイ レコードは、使用されているバージョンとデプロイされているリソースをキャプチャします。これにより、非常に目に見える履歴が提供されます。
これらのテスト方法は、一般的なテスト目的で Bicep と共に使用します。 これらのメソッドを使用すると、コードをデプロイする前にテストを実行できます。また、ブランチから非運用環境でテストすることもできます。
テスト環境
IaC デプロイは繰り返し可能であるため、同じ定義を使用して、デプロイに基づいて 2 つ目 (またはそれ以上) の環境をデプロイできます。 この方法は、変更をテストする際に重要です。
たとえば、Premium SKU を使用して Azure Firewall を置き換える場合は、運用環境を変更せずにテスト環境をデプロイし、変更を検証できます。
構成の誤差をキャッチする
IaC には、更新中の構成の誤差をキャッチする固有のオプションが用意されています。 デプロイでは、定義ファイルへの変更がキャッチされ、リソース構成が定義と異なるインスタンスが表示されます。
IaC を使用したランディング ゾーンの更新は、この構成の誤差をキャッチし、コードを適切に更新したり、更新プログラムを使用してこれらの構成ミスに対処したり、別の方法で対処したりするのに役立ちます。
ポータル、CLI、または IaC 以外のメソッドを使用してリソースを変更すると、変更が実装されます。 次に IaC を使用してデプロイを実行するときに、what-if 関数またはプラン関数を使用して、コード定義状態とポータルの実際の状態の比較にフラグを設定します。 このメソッドを使用して、コード ファイルの外部で環境が変更されているかどうかを識別します。
不整合が特定されたら、IaC を実行して、デプロイを定義に合わせることができます。 この方法を使用して、問題を特定し、問題の性質、実行の性質、および変更がどのように行われたかに応じてシナリオを修復します。 たとえば、Terraform はデプロイしたリソースへのベースラインの復元を試み、Bicep の Complete モードのデプロイでは、定義に含まれていないリソース グループ内のリソースが削除されます。 これらのツールは構成の誤差を検出して修復しますが、すべての問題に対処できない場合があります。
詳細については、「帯域外の変更の と、Terraform を使用したドリフトの検出と管理を参照してください。
ポータルで定義されている変更は、IaC に戻って実装するのが面倒です。 現在の状態と一致するようにコードを更新する必要があります。多くの場合、各リソースの変更を確認し、そのパラメーターを "そのまま" の構成に一致するように更新する必要があります。
IaC を使用してランディング ゾーンまたはその他のリソースを管理する場合は、緊急時にのみ IaC の外部で変更を行う必要があります。 Privileged Identity Management など、変更を直接行うアクセス権を持つアカウントに対する予防措置を講じてください。
次の記事で、一般的な自動化とセキュリティのプラクティスを確認します。
次の手順
次の記事で、IaC ツールの概要について説明します。