翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Terraform モジュールについて
<a name="modules"></a>

Infrastructure as Code (IaC) の領域では、*モジュールは*自己完結型のコードブロックであり、再利用のために分離され、一緒にパッケージ化されています。モジュールの概念は、Terraform 開発の不可避の側面です。詳細については、Terraform ドキュメントの[「モジュール](https://developer.hashicorp.com/terraform/language/modules)」を参照してください。 はモジュール AWS CloudFormation もサポートしています。詳細については、 AWS クラウド運用と移行ブログの[「モジュールの導入 AWS CloudFormation](https://aws.amazon.com/blogs/mt/introducing-aws-cloudformation-modules/)」を参照してください。

Terraform と のモジュールの主な違いは、 CloudFormation モジュールは特別なリソースタイプ () を使用してインポートされること CloudFormation です`AWS::CloudFormation::ModuleVersion`。Terraform では、すべての設定にルートモジュール と呼ばれるモジュールが[少なくとも 1 ](https://developer.hashicorp.com/terraform/language/modules#the-root-module)つあります。**main.tf** ファイル内の Terraform リソース、または Terraform 設定ファイル内のファイルは、ルートモジュールにあると見なされます。その後、ルートモジュールはスタック内に含めるために他のモジュールを呼び出すことができます。次の例は、オープンソースの [eks ](https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest)モジュールを使用して Amazon Elastic Kubernetes Service (Amazon EKS) クラスターをプロビジョニングするルートモジュールを示しています。

```
terraform {
  required_providers {
    helm = {
      source  = "hashicorp/helm"
      version = "2.12.1"
    }
  }
  required_version = ">= 1.2.0"
}

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "20.2.1"
  vpc_id  = var.vpc_id
}

provider "helm" {
  kubernetes {
    host                   = module.eks.cluster_endpoint
    cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data)
  }
}
```

上記の設定ファイルにプロバイダーが含まれていないことに AWS 気付いたかもしれません。これは、モジュールが自己完結型で、独自のプロバイダーを含めることができるためです。Terraform プロバイダーはグローバルであるため、子モジュールのプロバイダーをルートモジュールで使用できます。ただし、これはすべてのモジュール値に当てはまるわけではありません。モジュール内の他の内部値は、デフォルトでそのモジュールのみにスコープされ、ルートモジュールでアクセスできるようにするには出力として宣言する必要があります。オープンソースモジュールを活用して、スタック内のリソース作成を簡素化できます。例えば、eks モジュールは EKS クラスターをプロビジョニングするだけでなく、完全に機能する Kubernetes 環境をプロビジョニングします。これを使用すると、eks モジュールの設定がニーズに合っている限り、数十行のコードを追加で書き込む必要がなくなります。

## モジュールを呼び出す
<a name="calling-modules"></a>

Terraform のデプロイ中に実行する主な Terraform CLI コマンドの 2 つは[、Terraform init](https://developer.hashicorp.com/terraform/cli/commands/init) と[Terraform apply ](https://developer.hashicorp.com/terraform/cli/commands/apply)です。`terraform init` コマンドが実行するデフォルトのステップの 1 つは、すべての子モジュールを検索し、依存関係として `.terraform/modules` ディレクトリにインポートすることです。開発中、外部ソースモジュールを追加するたびに、 `apply` コマンドを使用する前に を再初期化する必要があります。Terraform *モジュール *への参照が聞こえると、このディレクトリ内のパッケージが参照されます。厳密に言うと、コードで宣言するモジュールは*呼び出し元のモジュール*であるため、実際には、モジュールキーワードは実際のモジュールを呼び出し、依存関係として保存されます。

このようにして、呼び出し元のモジュールは、デプロイ時に置き換えられるモジュール全体のより簡潔な代表として機能します。このアイデアを活用するには、スタック内に独自のモジュールを作成して、任意の基準を使用してリソースを論理的に分離します。これを行う最終目標は、スタックの複雑さを軽減することであることに留意してください。モジュール間でデータを共有するには、モジュール内からそのデータを出力する必要があるため、モジュールに過度に依存すると、モノが過度に複雑になることがあります。

## ルートモジュール
<a name="the-root-module"></a>

すべての Terraform 設定には少なくとも 1 つのモジュールがあるため、最も対処するモジュールのモジュールプロパティであるルートモジュールを調べるのに役立ちます。Terraform プロジェクトで作業するたびに、ルートモジュールは最上位ディレクトリ内のすべての `.tf` (または `.tf.json`) ファイルで構成されます。その最上位ディレクトリ`terraform apply`で を実行すると、Terraform はそこで見つかったすべての`.tf`ファイルの実行を試みます。サブディレクトリ内のファイルは、これらの最上位設定ファイルの 1 つで呼び出されない限り、無視されます。

これにより、コードの構造に柔軟性がもたらされます。また、複数のファイルが 1 つのプロセスに関与している可能性があるため、Terraform デプロイをファイルとしてではなくモジュールとして参照する方が正確である理由でもあります。Terraform がベストプラクティスとして推奨する[標準のモジュール構造](https://developer.hashicorp.com/terraform/language/modules/develop/structure)があります。ただし、最上位ディレクトリに`.tf`ファイルを配置すると、残りのファイルとともに実行されます。実際には、モジュール内のすべての最上位`.tf`ファイルは、 の実行時にデプロイされます`terraform apply`。Terraform が最初に実行されるのはどのファイルですか？ この質問に対する回答は非常に重要です。

Terraform は、初期化後およびスタックデプロイ前に一連のステップを実行します。まず、既存の設定が分析され、次に[依存関係グラフ](https://developer.hashicorp.com/terraform/internals/graph)が作成されます。依存関係グラフは、どのリソースをどの順序で呼び出すかを決定します。例えば、他のリソースで参照されるプロパティを含むリソースは、依存リソースの前に処理されます。同様に、 `depends_on`パラメータを使用して依存関係を明示的に宣言するリソースは、指定したリソースの後に処理されます。Terraform は、可能な限り並列処理を実装し、非依存リソースを同時に処理できます。[terraform graph コマンドを使用して、デプロイ前に依存関係グラフ](https://developer.hashicorp.com/terraform/cli/commands/graph)を表示できます。

依存関係グラフが作成されると、Terraform はデプロイ中に何をする必要があるかを決定します。依存関係グラフを最新の状態ファイルと比較します。このプロセスの結果は*計画 *と呼ばれ、[変更セット ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets-create.html)と CloudFormation非常によく似ています。現在の計画は、[Terraform Plans](https://developer.hashicorp.com/terraform/cli/commands/plan) コマンドを使用して確認できます。

ベストプラクティスとして、標準モジュール構造にできるだけ近づけることをお勧めします。設定ファイルが長くなりすぎて効率的に管理できず、論理的な分離によって管理が簡素化される可能性がある場合は、コードを複数のファイルに分散できます。依存関係グラフと計画プロセスが、スタックをできるだけ効率的に実行するためにどのように機能するかに注意してください。