インフラストラクチャをコードとして使用してAzureランディング ゾーンを更新する

この記事では、コードとしてのインフラストラクチャ (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 つのオプションがあります。

Infrastructure as Code を使用して Azure ランディング ゾーン (ALZ) を更新する利点

次の利点は、ランディング ゾーンを更新するためにコードとしてインフラストラクチャを使用する必要がある理由を示しています。

労力を削減する

手動で変更する場合と比較して、更新を実行するためのコードとしてインフラストラクチャを使用する手間が少なくなります。 IaC デプロイは、次の質問に答えるのに役立ちます。

  • リソースは現在どのように構成されていますか?
  • この更新プログラムによってリソースはどのように変更されますか?

コード ツールセットとしてのインフラストラクチャを実行すると、変更の比較または "差分" 読み取り結果を生成できます。 環境に変更をコミットする前に、この読み取り値を確認してください。

ツールセットは、オペレーターやエンジニアではなく、変更の情報をコンパイルできます。

エラーを減らす

デプロイのプログラム上の性質により、コードとしてのインフラストラクチャは、変更を加える間に人為的なエラーを減らします。 定義されている内容のみが変更され、プレビュー オプションがあるため、失敗または不完全な変更によって引き起こされる停止が軽減されます。 また、テスト オプションも改善されています。

バージョン管理と履歴

コード展開としてのインフラストラクチャは定義ファイルによってサポートされるため、ソース管理を使用して定義のバージョンを管理できます。 使用する IaC の方法に応じて、Azure for Bicep のデプロイまたは Terraform の状態ファイルを参照して、以前のデプロイの履歴を確認できます。

ソース管理プラクティスを使用すると、IaC の新しいブランチが作成され、変更とリビジョンが追加されます。 ソース管理システムのブランチの履歴は、イテレーションと変更をキャプチャします。 これを使用して、変更をマージして運用環境にデプロイする準備ができるまで、変更をテスト環境にデプロイできます。 詳細については、Azure ランディング ゾーンのテスト アプローチをご覧ください。 このサイクル全体を通して、デプロイ レコードは、使用されているバージョンとデプロイされているリソースをキャプチャします。これにより、非常に目に見える履歴が提供されます。

これらのテスト方法は、一般的なテスト目的で Bicep と共に使用します。 これらのメソッドを使用すると、コードをデプロイする前にテストを実行できます。また、ブランチから非運用環境でテストすることもできます。

セキュリティを強化する

セキュリティに関する考慮事項の記事で、コードデプロイ ID としてインフラストラクチャをセキュリティで保護するためのガイダンスに従ってください。

特に、コードデプロイとしてのインフラストラクチャの場合は、セキュリティを強化するために次の方法を検討してください。

  • 継続的デリバリー パイプラインを常に使用して、コードとしてインフラストラクチャをデプロイします。 ローカルの開発者マシンやその他のアンマネージド デバイスからのデプロイは実行しないでください。
  • Terraform のプランおよび Bicep の what-if 操作と、適用およびデプロイ操作には、別々の ID を使用してください。 プランと What-If 操作には読み取りアクセス権のみが必要ですが、適用操作とデプロイ操作には書き込みアクセス権が必要です。
  • 運用環境の適用/デプロイ ステージには、人間の承認ゲートを使用します。 自動チェックだけに依存しないでください。 運用環境に変更を適用する前に、誰かが Terraform プランまたは Bicep what-if 出力を確認していることを確認します。
  • 中央の場所に格納および管理されるテンプレートを指定して、管理パイプラインを使用します。 この方法により、すべてのデプロイが同じセキュリティとコンプライアンスのガードレールに従います。

テスト環境

IaC デプロイは繰り返し可能であるため、同じ定義を使用して、デプロイに基づいて 2 つ目 (またはそれ以上) の環境をデプロイできます。 この方法は、変更をテストする際に重要です。

たとえば、Premium SKU を使用して Azure Firewall を置き換える場合は、運用環境を変更せずにテスト環境をデプロイし、変更を検証できます。

リポジトリ構造

運用環境以外の環境にデプロイしてテストする内容が、運用環境にデプロイするのと同じであることを確信する必要があります。 このプラクティスをサポートするリポジトリ構造を使用します。

  • トランクベースの開発と機能ブランチを使用して、環境にデプロイする前にすべての変更がメイン ブランチにマージされるようにします。
  • すべての環境で同じコードを使用します。 変数と変数ファイルを使用して、環境を区別します。
  • フォルダーまたはブランチ間でコードをコピーして貼り付け、異なる環境を更新しないでください。 この方法により、構成の誤差と環境間の相違が発生します。
  • Pull Request (PR) 内で、運用環境を含むすべての環境に対して Terraform プランまたは Bicep what-if を実行し、変更を main にマージする前に検証できます。 個別の読み取り専用 ID を使用することで、この方法を安全に行えるのです。

構成の誤差をキャッチする

IaC には、更新中の構成の誤差をキャッチする固有のオプションが用意されています。 デプロイでは、定義ファイルへの変更がキャッチされ、リソース構成が定義と異なるインスタンスが表示されます。

IaC を使用したランディング ゾーンの更新は、この構成の誤差をキャッチし、コードを適切に更新したり、更新プログラムを使用してこれらの構成ミスに対処したり、別の方法で対処したりするのに役立ちます。

ポータル、CLI、または IaC 以外のメソッドを使用してリソースを変更すると、変更が実装されます。 次に IaC を使用してデプロイを実行するときに、what-if 関数またはプラン関数を使用して、コード定義状態とポータルの実際の状態の比較にフラグを設定します。 このメソッドを使用して、コード ファイルの外部で環境が変更されているかどうかを識別します。

不整合が特定されたら、IaC を実行して、デプロイを定義に合わせることができます。 この方法を使用して、問題を特定し、問題の性質、実行の性質、および変更がどのように行われたかに応じてシナリオを修復します。 たとえば、Terraform はデプロイしたリソースへのベースラインの復元を試み、Bicep の Complete モードのデプロイでは、定義に含まれていないリソース グループ内のリソースが削除されます。 これらのツールは構成の誤差を検出して修復しますが、すべての問題に対処できない場合があります。

詳細については、「帯域外の変更の と、Terraform を使用したドリフトの検出と管理を参照してください。

ポータルで定義されている変更は、IaC に戻って実装するのが面倒です。 現在の状態と一致するようにコードを更新する必要があります。多くの場合、各リソースの変更を確認し、そのパラメーターを "そのまま" の構成に一致するように更新する必要があります。

IaC を使用してランディング ゾーンまたはその他のリソースを管理する場合は、緊急時にのみ IaC の外部で変更を行う必要があります。 Privileged Identity Management など、変更を直接行うアクセス権を持つアカウントに対する予防措置を講じてください。

次の記事で、一般的な自動化とセキュリティのプラクティスを確認します。

次の手順

次の記事で、IaC ツールの概要について説明します。

  • 最終更新: