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

  • [アーティクル]

この記事では、コードとしてのインフラストラクチャ (IaC) を使用して Azure ランディング ゾーンを更新する利点について説明します。 組織は、正しい構成を維持して変更が必要であればそれに対処できるように、ランディング ゾーンを更新する必要があります。

IaC はライフサイクル全体を管理でき、デプロイしたリソースの管理に優れています。 組織は、IaC を使用した Azure ランディング ゾーンのデプロイを計画する必要があります。 その一環として、既存の IaC 以外のリソースを、状態管理の対象となる IaC リソースと整合させる計画を立てます。 また、既存のリソースと望ましい状態の対応付けも必要です。

詳細については、「Azure ランディング ゾーンを最新の状態に保つ」を参照してください。

コードとしてのインフラストラクチャのしくみ

IaC とは、マシンで読み取り可能な定義ファイルを使用してインフラストラクチャ リソースのライフサイクルを管理するためのプラクティスとツールです。 インフラストラクチャの定義はパイプラインを通じて記述、バージョン管理、デプロイされたうえで、ワークロードのデプロイの一部になります。

IaC テクノロジは "宣言型" です。つまり、IaC を実行すると、現在の状態に関係なく、コードに記述された内容に構成が設定されます。 Azure CLI やAzure PowerShell などのスクリプトを使用してインフラストラクチャを構成する場合は、"命令型" です。 命令型のスクリプトは一連のアクションを実行し、その結果は現在の状態とアクション後の状態に依存します。

Azure リソースにコードとしてのインフラストラクチャが定義されている場合は、その定義を必要なだけ実行でき、次の場合にのみ変更が作成されます。

  • 新しいリソースの追加、以前にデプロイされたリソースの削除、または以前にデプロイされたリソースの変更を行うために定義が変更される場合。
  • 構成を定義された内容にリセットするために、デプロイされたリソースと構成のずれが生じている場合。

IaC を使用すると、不要になったリソースを削除し、多くの変更を加えてリソースのライフサイクルを管理できるため、状態を復元できます。

注意

IaC を使ってリソースを削除する具体的なメカニズムはさまざまです。 たとえば Azure Bicep では、スコープ外のリソースを修復するために complete のデプロイ タイプを使用する必要があります。 このコマンドは、特定のスコープでのみ機能します。 Terraform の場合、リソースには lifecycle メタ引数があり、これを使って Terraform がリソースを処理する方法の手順を指定します。

Azure ランディング ゾーンには、コードとしてのインフラストラクチャの主なオプションとして次の 2 つがあります。

コードとしてのインフラストラクチャを使用して ALZ を更新する利点

以下の利点は、なぜコードとしてインフラストラクチャを使用してランディング ゾーンを更新する必要があるのかを示しています。

労力の削減

コードとしてのインフラストラクチャを使用した更新は、手動による変更と比べて労力が少なくて済みます。 IaC デプロイは、次の疑問の解決に役立ちます。

  • リソースが現在どのように構成されているか
  • この更新によってリソースがどのように構成されるか
  • この更新に合わせてどのような変更が行われるか

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

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

エラーの削減

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

バージョン管理と履歴

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

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

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

テスト環境

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

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

構成のずれを検出する

IaC には、更新中の構成のずれを検出する独自のオプションが用意されています。 デプロイで定義ファイルの変更が検出され、リソース構成が定義と異なるインスタンスが表示されます。

IaC を使用したランディング ゾーンの更新は、こうした構成のずれを検出するのに役立ちます。また、コードを適切に更新したり、更新によってこれらの構成ミスに対処したり、別の方法で構成ミスに対処したりできます。

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

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

詳細については、「帯域外の変更」と「Terraform を使用した構成のずれの検出と管理」を参照してください。

ポータルで定義された変更を IaC に戻して実装する作業は手間がかかります。 現在の状態に一致するようにコードを更新する必要があり、通常は各リソースの変更を確認し、そのパラメーターを "現状のまま" の構成に一致するように更新する必要があります。

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

自動化とセキュリティの一般的なプラクティスについては、次の記事を参照してください。

次のステップ

次の記事で IaC ツールの概要を確認します。