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

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

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

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

ツール

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

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

ARM テンプレート

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

• ARM テンプレートとは

• ARM テンプレート - コードとしてのインフラストラクチャの概要

上腕二頭筋

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

このサンプル Bicep コードは、リソース グループのリージョンに Azure ストレージ アカウントをデプロイします。 標準_LRSの冗長性とStorageV2の種類が適用されます。 頻繁なデータ アクセスでは、アクセス層は "ホット" に設定されます。

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 に関する情報を確認します。

• Azure 上の Terraform の概要

• Terraform - コードとしてのインフラストラクチャの概要

Azure CLI（Azure コマンドライン インターフェイス）

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

• Azure コマンド ライン インターフェイス (CLI)

• Azure CLI - コードとしてのインフラストラクチャの概要

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

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

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

Bicep モジュール

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

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 を使用しており、精通している場合は、Terraform を使用して Azure ランディング ゾーンをデプロイすることを検討してください。

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

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

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

設計に関する推奨事項

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

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

  • Azure ネイティブ ツールのみを使用する必要があります。 組織には、以前の ARM または Bicep テンプレートのデプロイ エクスペリエンスがある場合があります。

  • 組織では、すべてのプレビューバージョンと GA バージョンの Azure サービスをすぐにサポートしたいと考えています。

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

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

  • 組織では、すべてのプレビューバージョンと GA バージョンの Azure サービスをすぐにサポートする必要はありません。

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

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

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

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

    • 評価するモジュール プロバイダーのサポート ステートメントを確認してください。

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

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

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

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