🦔

Terraform入門〜概要とチュートリアル〜

2024/12/27に公開

Terraform

はじめに

フリーランスエンジニアのオーリアです。

現在の案件では Terraform を使用しています。しかし、筆者は4年前に勉強した以降まったく使うことがなく、すべての知識を忘れてしまいました。何もわからん状態になっているため、再入門しようと思います。

本記事では、最初に Terrafrom の概要をつかみ、次にチュートリアルを通して開発の流れを見ていきます。手元で動かしながら、Terrafrom の肌感を掴んでみてください。

ぜひ、一緒に Terrafrom に入門しましょう。

Terrafrom とは何か

まずは、Terraform の概要について説明します。

HashiCorp Terraform とは
- Infrastructure as Code (IaC) ツールである
  - クラウドとオンプレミスのリソースを、人間が読める設定ファイルで定義する
  - インフラのリソースをバージョン管理、再利用、共有することができる
インフラのプロビジョニングと管理
- 一貫したワークフローを使用し、ライフサイクルを通して管理できる
- 低レベルから高レベルのコンポーネントまですべて管理できる
  - 低レベル: コンピュート、ストレージ、ネットワークリソース、など
  - 高レベル: DNSエントリ、SaaS機能、など
様々なクラウドプロバイダに対応
- AWS
- Azure
- GCP
- Oracl Cluod Insrastructure
- Docker

どのように機能するのか

API アクセス
- API を通じて、クラウドプラットフォームやその他のサービス上のリソースを作成・管理する

ライフサイクル

コアとなるワークフロー
- Write
  - ユーザーがコードを書く
  - 設定ファイルにクラウドプロバイダーのリソースを定義する
- Plan
  - Terrafrom が実行計画を作成する
  - 既存のインフラと設定ファイルに基づき、クラウドのどのリソースを作成・更新・破棄するか決める
- Apply
  - Terrafrom が計画を実行する
  - リソースの依存関係を整理し、正しい順序でリソースを作成する

Terrafrom の書き方

概要がわかったところで、どのように記述するのか見ていきます。

記述するもの
- Terraform にインストールすべきプラグイン
- 作成すべきインフラ
- 取得すべきデータ

Terraform Language の概要

主な目的
- インフラストラクチャオブジェクトを表すリソースを宣言すること

resource "aws_vpc" "main" {
  cidr_block = var.base_cidr_block
}

# ブロック
<BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {
  # ブロックのボディ
  <IDENTIFIER> = <EXPRESSION> # 引数
}

ブロック
- 他のコンテンツのためのコンテナである
  - 通常は、リソースのような何らかのオブジェクトの設定を表す
- 以下のような構造である
  - ブロックタイプを持つ
  - 0個以上のラベルを持つ
  - ボディを持つ
    - 任意の数の引数を含む
    - ネストされたブロックを含む
宣言的な記述
- Terraform 言語は宣言的であり、ゴールに到達するためのステップではなく、意図するゴールを記述する
- Terraform は操作の順序を決定する際に、リソース間の暗黙的・明示的な関係のみを考慮する

Terraform Language のサンプル

以下は、Amazon Web Servicesのシンプルなネットワークトポロジーである。

変数の定義と参照
オブジェクトの参照とリソースの依存関係
組み込み関数と演算子

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 1.0.4"
    }
  }
}

variable "aws_region" {}

variable "base_cidr_block" {
  description = "A /16 CIDR range definition, such as 10.1.0.0/16, that the VPC will use"
  default = "10.1.0.0/16"
}

variable "availability_zones" {
  description = "A list of availability zones in which to create subnets"
  type = list(string)
}

provider "aws" {
  region = var.aws_region
}

resource "aws_vpc" "main" {
  # base_cidr_block 変数を参照することで、構成を変更せずに cidr_block 引数の値を可変にしている
  cidr_block = var.base_cidr_block
}

resource "aws_subnet" "az" {
  # 指定されたアベイラビティゾーンごとに、1 つのサブネットを作成する
  count = length(var.availability_zones)

  # サブネットごとに、指定されたアベイラビリティ ゾーンの 1 つを使用する
  availability_zone = var.availability_zones[count.index]

  # aws_vpc.main オブジェクトを参照することにより、Terraform はリソースの依存関係を把握する
  # VPC が作成された後に、サブネットを作成する必要があることを認識する
  vpc_id = aws_vpc.main.id

  # 組み込み関数と演算子は、サブネットアドレスの計算など、値の単純な変換に使用できる
  # ここでは、10.1.16.0/20 など、各アベリラビリティゾーンの連続したアドレスを使用して、各サブネットに /20 プレフィックスを作成する
  cidr_block = cidrsubnet(aws_vpc.main.cidr_block, 4, count.index+1)
}

AWS チュートリアル

大枠がつかめたところで、実際にどのような開発の流れとなるのか見てみましょう。
内容は AWS を利用した Terraform のチュートリアルとなっています。

Install

インストール方法はこちら
コマンド補完の方法はこちら

Build

前提条件

Terraform CLI (1.2.0+) がインストールされていること
AWS CLI がインストールされていること
AWS アカウントとそれに関連する認証がリソースの作成を許可していること

IAM の認証

Terraform AWS プロバイダの認証に IAM 認証情報を使用するには、環境変数 AWS_ACCESS_KEY_ID を設定する。

$ export AWS_ACCESS_KEY_ID=
$ export AWS_SECRET_ACCESS_KEY=

設定ファイルの記述

Terraform でインフラを記述するためのファイル群を、Terraform 設定と呼びます。
各 Terraform 設定は、独自の作業ディレクトリに配置される必要があります。

$ mkdir learn-terraform-aws-instance
$ cd learn-terraform-aws-instance
$ touch main.tf

main.tf ファイルを編集しましょう。

main.tf

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.16"
    }
  }

  required_version = ">= 1.2.0"
}

provider "aws" {
  region  = "us-west-2"
}

resource "aws_instance" "app_server" {
  ami           = "ami-830c94e3"
  instance_type = "t2.micro"

  tags = {
    Name = "ExampleAppServerInstance"
  }
}

3つのブロックが定義されていますね。順番に見てきましょう。

main.tf

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.16"
    }
  }

  required_version = ">= 1.2.0"
}

Terrafrom ブロック
- Terraform が使用するプロバイダが含まれる
  - source 属性はオプションである
  - ホスト名、名前空間、プロバイダタイプを定義する
    - [筆者メモ] 上記の設定例では、省略されている...？
- Terraform は、デフォルトで Terraform Registry からプロバイダをインストールする
  - 上記の設定例では、aws プロバイダのソースを hashicorp/aws と定義している
    - これは registry.terraform.io/hashicorp/aws の省略形である
- required_providers ブロックで各プロバイダにバージョン制約を設定できる
  - version 属性は省略可能であるが、使用をおすすめする
    - version を指定しない場合、Terraform は初期化時に自動的に最新バージョンをダウンロードする

main.tf

provider "aws" {
  region  = "us-west-2"
}

Provider ブロック
- プロバイダ (この場合は aws) を設定する
  - プロバイダとは、Terraform がリソースを作成・管理するためのプラグインである
- 複数のプロバイダを管理することができる
  - 複数のプロバイダブロックを複数定義し、異なるプロバイダのリソースを管理することができる
  - 異なるプロバイダを一緒に使うこともできる
    - 例えば、AWS EC2 インスタンスの IP アドレスを DataDog の監視リソースに渡すことができる

main.tf

resource "aws_instance" "app_server" {
  ami           = "ami-830c94e3"
  instance_type = "t2.micro"

  tags = {
    Name = "ExampleAppServerInstance"
  }
}

Resource ブロック
- インフラのコンポーネントを定義する
  - リソースは、EC2 インスタンスのような物理的または仮想的なコンポーネントかもしれない
  - Heroku アプリケーションのような論理的なリソースかもしれない
- ブロックの前にリソース・タイプとリソース名の2つの文字列を書く
  - この例では、リソースタイプは aws_instance で、リソース名は app_server である
  - リソース・タイプのプレフィックスはプロバイダ名に対応する
    - この例では、Terraform は aws_instance リソースを aws プロバイダで管理する
  - リソースタイプとリソース名を合わせると、リソースの固有 ID になる
    - 例えば、EC2インスタンスの ID は aws_instance.app_server となる

ディレクトリの初期化

次に、ディレクトリを初期化しましょう。

terraform init コマンド
- 新しい Terraform 設定を作成するとき、ディレクトリを初期化する必要がある
- ディレクトリを初期化すると、Terraform 設定で定義されているプロバイダ (この場合は aws) をダウンロードして、インストールする

$ terraform init

Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/aws versions matching "~> 4.16"...
- Installing hashicorp/aws v4.17.0...
- Installed hashicorp/aws v4.17.0 (signed by HashiCorp)

(割愛)

Terraform has been successfully initialized!

(割愛)

.terraform ディレクトリの作成
- 使用するプロバイダ (この場合は aws) をインストールし、配置する
.terraform.lock.hcl ファイルの作成
- 使用するプロバイダの正確なバージョンを指定する
- プロジェクトで使用するプロバイダの更新するタイミングを、制御できるようにする

Terrafrom 設定のフォーマットと検証

コードのフォーマットと検証する方法を見ていきます。

terraform fmt コマンド
- カレントディレクトリの Terraform 設定をフォーマットする
- 変更したファイル名があれば、それを出力する

$ terraform fmt

terraform validate コマンド
- Terraform 設定が構文的に有効であり、内部的に一貫性があることを確認する

$ terraform validate
Success! The configuration is valid.

インフラの作成

コードに誤りがなければ、インフラのリソースを作成していきます。

terraform apply
- Terraform 設定を適用する

$ terraform apply

Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_instance.app_server will be created
  + resource "aws_instance" "app_server" {
      + ami                          = "ami-830c94e3"
      + arn                          = (known after apply)
(割愛)

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value:

実行計画の表示
- Diff 形式で実行計画を出力する
  - 設定される属性が表示される
  - + 接頭辞は、terraform がこのリソースを作成することを意味する
  - (known after apply) は、リソースが作成されるまで値が不明なことを意味する
    - 例えば、AWSはインスタンス作成時に Amazon Resource Names (ARN) を割り当てるため、事前に知ることはできない

実行計画を表示した後、Terraform は Enter a value: を表示して、ユーザーの承認を待ちます。

実行計画の承認
- Terraform は処理を進める前に、ユーザーの承認を待つ
  - 計画の中に危険なものがあれば、中止することができる
  - 計画が有効であれば、yes と入力して次に進むことができる

  Enter a value: yes

aws_instance.app_server: Creating...
aws_instance.app_server: Still creating... [10s elapsed]
aws_instance.app_server: Still creating... [20s elapsed]
aws_instance.app_server: Still creating... [30s elapsed]
aws_instance.app_server: Creation complete after 36s [id=i-01e03375ba238b384]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

状態の検査

terrafrom apply が完了すると、Terrafrom はリソースを管理するファイルを作成します。

terraform.tfstate ファイルの作成
- Terraform 設定の適用が完了すると、Terraform はこのファイルにデータを書き込む
  - 管理するリソースの ID とプロパティを保存し、管理する
- このファイルは、信頼できるチームメンバーのみにアクセスを制限する必要がある
  - terraform.tfstate ファイルは、機密情報を含むことが多いため
  - terraform.tfstate ファイルは、Terraform がリソースを追跡する唯一の方法であるため
- 本番環境では、以下のようなリモートバックエンドを使用して State を保管することをおすすめする
  - HCP Terraform や Terraform Enterprise
  - 他にサポートするリモートバックエンドはこちら

現在、Terrafrom が管理しているリソースの一覧を見てみましょう。

terraform show コマンド
- 現在の Terraform の State を表示する

$ terraform show
# aws_instance.app_server:
resource "aws_instance" "app_server" {
    ami                          = "ami-830c94e3"
    arn                          = "arn:aws:ec2:us-west-2:561656980159:instance/i-01e03375ba238b384"
    associate_public_ip_address  = true
    availability_zone            = "us-west-2c"
    cpu_core_count               = 1
    cpu_threads_per_core         = 1
    disable_api_termination      = false
    ebs_optimized                = false
    get_password_data            = false
    hibernation                  = false
    id                           = "i-01e03375ba238b384"
    instance_state               = "running"
    instance_type                = "t2.micro"
    (割愛)
}

状態の手動管理

terraform state コマンド
- Terraform には、高度な状態管理を実現するためのコマンドが用意されている
terraform state list コマンド
- Tettafrom プロジェクトの State にあるリソースの一覧を表示する

$ terraform state list
aws_instance.app_server

トラブルシューティング

terraform apply が失敗する場合、一般的なエラーに遭遇している可能性がある
- 詳細はこちら

Change

前回までの操作

コードは以下の通り。

main.tf

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.16"
    }
  }

  required_version = ">= 1.2.0"
}

provider "aws" {
  region  = "us-west-2"
}

resource "aws_instance" "app_server" {
  ami           = "ami-830c94e3"
  instance_type = "t2.micro"

  tags = {
    Name = "ExampleAppServerInstance"
  }
}

以下のコマンドを実行している。

$ terraform init

$ terraform apply

構成

前回までのステップで、Terrafrom を利用してインフラのリソースを作成することができました。
次に、Terrafrom を利用してインフラのリソースを変更する方法を見てみましょう。

まずは、コードを書き換えます。

Teffarom 設定ファイルの書き換え
- チュートリアルでは、インスタンスの AMI を更新する
  - main.tf の provider ブロックにある aws_instance.app_server リソースを変更する
  - 現在の AMI ID を新しいものに置き換える

main.tf
 resource "aws_instance" "app_server" {
-  ami           = "ami-830c94e3"
+  ami           = "ami-08d70e59c07c61a3a"
   instance_type = "t2.micro"
 }

この変更により、AMI が Ubuntu 16.04 AMI に変更される
- AWS プロバイダはインスタンス作成後に AMI を変更できないことを知っている
- そのため、Terraform は古いインスタンスを破棄して新しいインスタンスを作成する

変更の適用

コードの変更を適用しましょう。

terraform apply コマンド
- Terraform が、この変更を既存のリソースにどのように適用するかを確認する

$ terraform apply
aws_instance.app_server: Refreshing state... [id=i-01e03375ba238b384]

Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

  # aws_instance.app_server must be replaced
-/+ resource "aws_instance" "app_server" {
      ~ ami                          = "ami-830c94e3" -> "ami-08d70e59c07c61a3a" # forces replacement
      ~ arn                          = "arn:aws:ec2:us-west-2:561656980159:instance/i-01e03375ba238b384" -> (known after apply)
##...

Plan: 1 to add, 0 to change, 1 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value:

Diff 表示に見慣れない接頭辞が見えますね。

実行計画の表示
- -/+ 接頭辞は、Terraform がリソースを破棄して再作成することを意味する
- ~ 接頭辞は、Terraform がリソースをインプレースでアップデートすることを意味する

計画に誤りがなければ、承認しましょう。

実行計画の承認
- yes と打つことにより、実行計画を承認し、実行する

  Enter a value: yes

aws_instance.app_server: Destroying... [id=i-01e03375ba238b384]
aws_instance.app_server: Still destroying... [id=i-01e03375ba238b384, 10s elapsed]
aws_instance.app_server: Still destroying... [id=i-01e03375ba238b384, 20s elapsed]
aws_instance.app_server: Still destroying... [id=i-01e03375ba238b384, 30s elapsed]
aws_instance.app_server: Still destroying... [id=i-01e03375ba238b384, 40s elapsed]
aws_instance.app_server: Destruction complete after 42s
aws_instance.app_server: Creating...
aws_instance.app_server: Still creating... [10s elapsed]
aws_instance.app_server: Still creating... [20s elapsed]
aws_instance.app_server: Still creating... [30s elapsed]
aws_instance.app_server: Still creating... [40s elapsed]
aws_instance.app_server: Creation complete after 50s [id=i-0fd4a35969bd21710]

Apply complete! Resources: 1 added, 0 changed, 1 destroyed.

Destroy

インフラの削除

インフラを削除する方法を見ていきます。

terraform destroy コマンド
- Terraform が管理するリソースをすべて破棄する
- terraform apply コマンドと逆のことを行う
  - 現在の Terraform プロジェクトが作成したリソースを破棄する
  - 現在の Terraform プロジェクトが管理していない、別の場所で稼働するリソースは破棄しない

$ terraform destroy
Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated with the following symbols:
  - destroy

Terraform will perform the following actions:

  # aws_instance.app_server will be destroyed
  - resource "aws_instance" "app_server" {
      - ami                          = "ami-08d70e59c07c61a3a" -> null
      - arn                          = "arn:aws:ec2:us-west-2:561656980159:instance/i-0fd4a35969bd21710" -> null
##...

Plan: 0 to add, 0 to change, 1 to destroy.

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value:

実行計画の表示
- - 接頭辞は、インスタンスが破棄されることを示す
実行計画の承認
- yes と答えると、このプランが実行され、インフラストラクチャが破棄される

  Enter a value: yes

aws_instance.app_server: Destroying... [id=i-0fd4a35969bd21710]
aws_instance.app_server: Still destroying... [id=i-0fd4a35969bd21710, 10s elapsed]
aws_instance.app_server: Still destroying... [id=i-0fd4a35969bd21710, 20s elapsed]
aws_instance.app_server: Still destroying... [id=i-0fd4a35969bd21710, 30s elapsed]
aws_instance.app_server: Destruction complete after 31s

Destroy complete! Resources: 1 destroyed.

Variables

前回までの操作

コードは以下の通り。

main.tf

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.16"
    }
  }

  required_version = ">= 1.2.0"
}

provider "aws" {
  region  = "us-west-2"
}

resource "aws_instance" "app_server" {
  ami           = "ami-08d70e59c07c61a3a"
  instance_type = "t2.micro"

  tags = {
    Name = "ExampleAppServerInstance"
  }
}

以下のコマンドを実行している。

$ terraform init

$ terraform apply

インスタンス名を変数で設定

変数を利用し、より実際の開発に近い書き方を見ていきましょう。

変数の使用
- 変数を使うことにより、柔軟で再利用しやすい Terrafrom 設定を書くことができる
- 変数はどの *.tf ファイルに記述しても良い
チュートリアルの内容
- インスタンス名を定義する変数を追加する
  - variables.tf という新しいファイルを作成する
  - 新しい変数 instance_name を定義するブロックを記述する

variables.tf

variable "instance_name" {
  description = "Value of the Name tag for the EC2 instance"
  type        = string
  default     = "ExampleAppServerInstance"
}

変数の参照
- var.* で変数を参照することができる
- 変数の default 属性の値が適用される
  - 外部から変数の値を上書きすることもできる (次の 変更の適用 セクションを参照)

main.tf
 resource "aws_instance" "app_server" {
   ami           = "ami-08d70e59c07c61a3a"
   instance_type = "t2.micro"

   tags = {
-    Name = "ExampleAppServerInstance"
+    Name = var.instance_name
   }
 }

var.instance_name で変数を参照するように変更しました。

変更の適用

コードを変更した結果を適用しましょう。

terraform apply コマンドの実行
- yes を打つ

$ terraform apply

Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_instance.app_server will be created
  + resource "aws_instance" "app_server" {
      + ami                          = "ami-08d70e59c07c61a3a"
      + arn                          = (known after apply)
##...

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_instance.app_server: Creating...
aws_instance.app_server: Still creating... [10s elapsed]
aws_instance.app_server: Still creating... [20s elapsed]
aws_instance.app_server: Still creating... [30s elapsed]
aws_instance.app_server: Still creating... [40s elapsed]
aws_instance.app_server: Creation complete after 50s [id=i-0bf954919ed765de1]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

次に、変数を利用する別の方法を見ていきましょう。

-var フラグ
- コマンドラインから変数を設定する
  - 変数のデフォルト値を上書きできる
  - コード上の値は変更されない

$ terraform apply -var "instance_name=YetAnotherName"
aws_instance.app_server: Refreshing state... [id=i-0bf954919ed765de1]

Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # aws_instance.app_server will be updated in-place
  ~ resource "aws_instance" "app_server" {
        id                           = "i-0bf954919ed765de1"
      ~ tags                         = {
          ~ "Name" = "ExampleAppServerInstance" -> "YetAnotherName"
        }
        # (26 unchanged attributes hidden)




        # (4 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_instance.app_server: Modifying... [id=i-0bf954919ed765de1]
aws_instance.app_server: Modifications complete after 7s [id=i-0bf954919ed765de1]

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

Terrafrom には様々な変数の活用方法があります。詳しくはこちらを見てください。

Outputs

前回までの操作

コードは以下の通り。

main.tf

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.16"
    }
  }

  required_version = ">= 1.2.0"
}

provider "aws" {
  region  = "us-west-2"
}

resource "aws_instance" "app_server" {
  ami           = "ami-08d70e59c07c61a3a"
  instance_type = "t2.micro"

  tags = {
    Name = var.instance_name
  }
}

variables.tf

variable "instance_name" {
  description = "Value of the Name tag for the EC2 instance"
  type        = string
  default     = "ExampleAppServerInstance"
}

以下のコマンドを実行している。

$ terraform init

$ terraform apply

リソースの値のアウトプット

アウトプットを利用することにより、リソースの情報を表示することができます。

アウトプットの設定

アウトプットするためのコードを見ていきましょう。

Output ブロック
- アウトプット名を定義する
- アウトプットする値を定義する

outputs.tf

output "instance_id" {
  description = "ID of the EC2 instance"
  value       = aws_instance.app_server.id
}

output "instance_public_ip" {
  description = "Public IP address of the EC2 instance"
  value       = aws_instance.app_server.public_ip
}

出力値の検査

次に、terrafrom apply コマンドを実行しましょう。

terraform apply　コマンド
- 出力値を検査する前に、terraform apply コマンドを実行する必要がある

$ terraform apply
aws_instance.app_server: Refreshing state... [id=i-0bf954919ed765de1]

Changes to Outputs:
  + instance_id        = "i-0bf954919ed765de1"
  + instance_public_ip = "54.186.202.254"

You can apply this plan to save these new output values to the Terraform state,
without changing any real infrastructure.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes


Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

instance_id = "i-0bf954919ed765de1"
instance_public_ip = "54.186.202.254"

出力値を表示しましょう。

terraform output コマンド
- 出力値を画面に表示する

$ terraform output
instance_id = "i-0bf954919ed765de1"
instance_public_ip = "54.186.202.254"

Output 活用の一例を見てみましょう。

Terrafrom プロジェクトの接続
- Output を使用して、他の Terrafrom プロジェクトと接続することができる
- 詳細はこちら

Remote state

Remote state の内容については割愛します。

おわりに

まだまだまとめたりない部分があります！

Terraform Language の詳細
Remote state とは何か
実開発のベストプラクティス

今回はチュートリアル形式で terrafrom について知りました。次回は、Terrafrom Language についてまとめようと思います。

Discussion

ログインするとコメントできます