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

  • [アーティクル]

コードとしてのインフラストラクチャ (IaC) は、記述型モデルでのインフラストラクチャ (ネットワーク、コンピューティング サービス、データベース、ストレージ、接続トポロジなど) の管理を伴う主な DevOps プラクティスです。 IaC を使用すると、チームは変更をより迅速かつ確実に開発してリリースできます。 IaC の利点は次のとおりです。

  • デプロイにおける信頼性の向上
  • 複数の環境を管理する機能
  • インフラストラクチャの状態に関する理解の向上

コードとしてのインフラストラクチャを使用する利点の詳細については、「反復可能なインフラストラクチャ」を参照してください。

ツール

コードとしてのインフラストラクチャを実装する場合は、次の 2 つの方法を使用できます。

  • 命令型のコードとしてのインフラストラクチャには、Bash や PowerShell などの言語でスクリプトを記述する必要があります。 目的の結果を出すために実行されるコマンドを明示的に指定します。 命令型デプロイを使用する場合は、必要に応じて依存関係の順序付け、エラー制御、リソースの更新を管理できます。
  • 宣言型のコードとしてのインフラストラクチャには、環境の外観を指定する定義を記述する必要があります。 この定義では、目的の結果を実現する方法ではなく、目的の結果を指定します。 ツールでは、現在の状態を調べて対象の状態と比較し、その違いを適用することで、結果を実現する方法を示します。

ARM テンプレート

Azure Resource Manager テンプレート (ARM テンプレート) に関する情報をレビューします。

Bicep

Bicep は、宣言型の構文を使用して Azure リソースをデプロイするドメイン固有言語 (DSL) です。 Bicep ファイルでは、デプロイするインフラストラクチャとそのプロパティを定義します。 ARM テンプレートと比較すると、Bicep ファイルは簡潔な構文を使用するため、開発者以外の対象ユーザーには読み取りと書き込みが容易になります。

param location string = resourceGroup().location
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}'
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

Terraform

Terraform に関する情報を確認します。

Azure CLI

Azure CLI に関する情報を確認します。

コードとしてのインフラストラクチャ モジュール

コードを使用してインフラストラクチャをデプロイする目的の 1 つは、作業が重複したり、同じ目的または同様の目的で複数のテンプレートを作成したりしないようにすることです。 インフラストラクチャ モジュールは再利用可能で柔軟であり、明確な目的を持つ必要があります。

モジュールは独立したファイルであり、通常、一緒にデプロイされるリソースのセットが含まれています。 モジュールを使用すると、複雑なテンプレートをより小さく、より管理しやすいコード セットに分割できます。 モジュールごとに特定のタスクに重点的に取り組み、すべてのモジュールが複数のデプロイとワークロードに再利用可能であることを確認できます。

Bicep モジュール

Bicep を使用すると、モジュールを作成して呼び出すことができます。 モジュールが作成されたら、他の Bicep テンプレートから使用できます。 高品質の Bicep モジュールでは、複数の関連リソースを定義する必要があります。 たとえば、Azure 関数を定義する場合、通常、特定のアプリケーション、そのアプリケーションのホスティング プラン、そのアプリケーションのメタデータのストレージ アカウントをデプロイします。 これらのコンポーネントは個別に定義されますが、リソースの論理グループを形成するため、それらを 1 つのモジュールとして一緒に定義することを検討する必要があります。

Bicep モジュールでは一般的に以下のものを使用します。

  • 呼び出し側モジュールから値を受け取るためのパラメーター。
  • 呼び出し側モジュールに結果を返すための出力値。
  • 管理するモジュールに 1 つ以上のインフラストラクチャ オブジェクトを定義するためのリソース。

Bicep モジュールを発行する

Bicep モジュールの発行と共有には、複数のオプションがあります。

  • パブリック レジストリ: パブリック モジュール レジストリは、Microsoft コンテナー レジストリ (MCR) にホストされます。 そのソース コードと含まれているモジュールは、GitHub に格納されます。
  • プライベート レジストリ: Azure コンテナー レジストリを使用して、プライベート レジストリにモジュールを発行できます。 CI/CD パイプライン内のレジストリにモジュールを発行する方法については、Bicep と GitHub Actions に関するページ、または必要に応じて Bicep と Azure Pipelines に関するページを参照してください。
  • テンプレート スペック:テンプレート スペックを使用して Bicep モジュールを発行できます。 テンプレート スペックは完全なテンプレートであるように作られていますが、Bicep ではモジュールのデプロイにテンプレート スペックを使用できます。
  • バージョン管理システム: GitHub や Azure DevOps などのバージョン管理ツールからモジュールを直接読み込むことができます。

Terraform モジュール

Terraform を使用すると、モジュールを作成して呼び出すことができます。 各 Terraform 構成には、"ルート モジュール" と呼ばれるモジュールが少なくとも 1 つあり、メイン作業ディレクトリ内の .tf ファイルで定義されたリソースで構成されます。 各モジュールは他のモジュールを呼び出すことができます。これにより、メイン構成ファイルに子モジュールを含めることができます。 また、モジュールは、同じ構成内または異なる構成から複数回呼び出すこともできます。

モジュールは、同じ構成言語のすべての概念で定義されます。 最も一般的に使用するのは次のとおりです。

  • 呼び出し側モジュールから値を受け取るための入力変数。
  • 呼び出し側モジュールに結果を返すための出力値。
  • 管理するモジュールに 1 つ以上のインフラストラクチャ オブジェクトを定義するためのリソース。

Terraform モジュールの発行

Terraform モジュールの発行と共有には、複数のオプションがあります。

  • パブリック レジストリ: HashiCorp には、共有可能な Terraform モジュールをユーザーが生成できるようにする独自の Terraform モジュール レジストリがあります。 現在、Terraform モジュール レジストリで発行されている Azure モジュールが複数あります。
  • プライベート レジストリ: Terraform モジュールは、Terraform Cloud Private Registry や Azure Container Registry などのプライベート リポジトリにシームレスに発行できます。
  • バージョン管理システム: GitHub などのバージョン管理ツールからプライベート モジュールを直接読み込むことができます。 サポートされているソースについては、Terraform モジュール　ソースに関するページを参照してください。

設計上の考慮事項

  • ランディング ゾーン リソースを Azure にデプロイする場合は、IaC の使用を検討してください。 IaC は、デプロイの最適化を完全に実現し、構成作業を削減し、環境全体のデプロイを自動化します。

  • 命令型または宣言型のどちらの IaC アプローチを採用するかを決定してください。

    • 命令型アプローチを採用する場合は、目的の結果を出すコマンドの実行を明示的に指定します。

    • 宣言型アプローチを採用する場合は、実行する方法ではなく、目的の結果を指定します。

  • デプロイのスコープを検討します。 Azure 管理レベルと階層を十分に理解してください。 各 IaC デプロイでは、Azure リソースがデプロイされるスコープを認識している必要があります。

  • Azure ネイティブまたは Azure 非ネイティブのどちらの IaC ツールを使用するかを決定します。 考慮すべき点:

    • Azure CLI、ARM テンプレート、Bicep などの Azure ネイティブ ツールは、Microsoft によって完全にサポートされているため、新機能をより迅速に統合できます。

    • Terraform のような非ネイティブ ツールを使用すると、AWS や GCP などの複数のクラウド プロバイダー間でコードとしてのインフラストラクチャを管理できます。 ただし、新しい Azure 機能が非ネイティブに含まれるには、少し時間がかかる場合があります。 組織がマルチクラウドであるか、組織が Terraform を既に使用し、精通している場合は、Azure ランディング ゾーンのデプロイに Terraform を使用することを検討してください。

  • モジュールを使用すると、複雑なテンプレートをより小さなコード セットに分割できるため、通常は一緒にデプロイされるリソースに IaC モジュールを使用することを検討してください。 各モジュールが特定のタスクに重点的に取り組み、複数のデプロイとワークロードに再利用可能であることを確認できます。

  • パブリック レジストリ、プライベート レジストリ、または Git リポジトリなどのバージョン管理システムの中から選択して、IaC モジュールの発行方針の採用を検討してください。

  • IaC デプロイに CI/CD パイプラインを使用することを検討してください。 パイプラインによって、設定した再利用可能なプロセスが適用され、デプロイと Azure 環境の品質が保証されます。

設計の推奨事項

  • Azure ランディング ゾーン デプロイのデプロイ、管理、サポートの IaC アプローチを採用します。

  • 次のシナリオでは、IaC に Azure ネイティブ ツールを使用します。

    • Azure ネイティブ ツールのみを使用する必要があります。 組織で、以前に ARM または Bicep テンプレートでデプロイした経験があるかもしれない。

    • 組織は、すべてのプレビュー バージョンと GA バージョンの Azure サービスに対する即時サポートを必要としています。

  • 次のシナリオでは、IaC に非 Azure ネイティブ ツールを使用します。

    • 現在、組織は Terraform を使用して、AWS や GCP などの他のクラウドにインフラストラクチャをデプロイしています。

    • 組織は、すべてのプレビュー バージョンと GA バージョンの Azure サービスに対する即時サポートを必要としていません。

  • 反復作業を回避するために、再利用可能な IaC モジュールを使用します。 モジュールを組織全体で共有して、複数のプロジェクトまたはワークロードをデプロイし、それほど複雑でないコードを管理できます。

  • 次のシナリオでは、パブリック レジストリから IaC モジュールを発行して使用します。

    • パブリック レジストリに既に発行されているモジュールを Azure ランディング ゾーンに使用する必要があります。 詳しくは、「Azure ランディング ゾーン Terraform モジュール」をご覧ください。

    • Microsoft、Terraform、またはその他のモジュール プロバイダーによって保守、更新、およびサポートされているモジュールを使用する必要があります。

      • 評価するモジュール プロバイダーからのサポート ステートメントを必ずチェックしてください。

  • 次のシナリオでは、プライベート レジストリまたはバージョン管理システムから IaC モジュールを発行して使用します。

    • 組織の要件に基づいて独自のモジュールを作成する必要があります。

    • すべての機能を完全に制御し、新しいバージョンのモジュールを保守、更新、発行する必要があります。

  • CI/CD パイプラインを使用して IaC 成果物をデプロイし、デプロイと Azure 環境の品質を確保します。