目的

Terraformの基本的な部分を学び整理する。
（AWSリソースの作成方法については、別記事でまとめようと思います）

Terraform

システム基盤をコード管理するためのツール。
開発主体は、HashiCorp。
設定ファイルを準備し、リソースをHCL形式(HashiCorp構成言語)で記述する。

基本操作

1.terraform init

実行するときに必要となるバイナリファイルをダウンロードする。
一番初めに実行するコマンド

2.terraform validate

validate=検証
作成した「設定ファイルの記述が正しいか」構文チェックする。
terraform planでも構文チェックできるが、切り分けする時に原因が「構文」か「システム側」どちら側か確認するためにvalidateコマンドを使うほうが良い。

3.terraform plan

「これから何が実行されるのか」実行計画が出力される。

4.terraform apply

「terraform plan」のように、改めてplan結果が表示される。
確認後リソースの作成を実行する。

5.terraform destroy

作成したリソースを削除する。

ファイル

1.tfファイル

作成するリソースを定義するファイル

2.tfvarsファイル

tfファイルに読み込ませる変数を定義する。

3.tfstateファイル

現在の状態を記録する（自動的に作成される）。
tfstateのファイルの状態と、HCLのコードに差分があるとき、その差分だけを変更する。

基本構文

リソース定義以外の、基本的な構文をまとめる。

変数

variableを使う。
（例）test_instance_type変数を定義

variable "test_instance_type"{
    default = "t3.micro"
}

変数は実行するときに上書きできる。
コマンドを実行するときに-varオプションを使う。

terraform plan -var 'test_instance_type=t3.nano terraform plan'

環境変数でも上書きできる。
TF_VAR_<name>で、自動的に上書きされる。

TF_VAR_test_instance_type=t3.nano terraform plan

ローカル変数

localsを使う。
変数variableと異なり、コマンド実行時に上書きができない。

locals {
    test_instance_type = "t3.micro"
}

出力値

outputを使う。出力値を定義する。
terraform applyを実行したときに、ターミナルで値を確認できる。

output "test_instance_id" {
    value = aws_instance_test_id

(例)applyで確認したときの出力

terraform apply
Outputs:

test_instance_id = i-xxxx

データソース

外部データを参照するときに使う。

(例)最新のAmazon Linux2のAMIを参照したいとき

data "aws_ami" "recent_amazon_linux_2" {
    most_recent = true
    owners      = ["amazon"]

　　#検索条件を指定する
    filter {
    name   = "name"
    values = ["amzn-ami-hvm-2.0.xxxx-x86_64-gp2"]
    }
}

resource "aws_instance" "test" {
    ami           = data.aws_ami.recent_amazon_linux_2.image_id
    instance_type = "t3.micro"
}

プロバイダ

※TerraformはAWS、GCP、Azureなどにも対応している。
プロバイダを明示的に定義する。
設定変更が可能。下記の例では、リージョンを指定している。

provider "aws" {
    region = "ap-northeast-1"
}

プロバイダはTerraform本体とは分離している。
terraform initでバイナリファイルをダウンロードする必要あり。

セキュリティグループ

（例）EC2インスタンスを作成した後、セキュリティグループを作成する場合

EC2向けにセキュリティグループ作成

resource "aws_security_group" "test_ec2" {
    name = "testz_ec2"

    ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    }

    engress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
    }
}

EC2に関連付け

resource "aws_instance" "test" {
    ami                    = "ami-xxxx"
    instance-type          = "t3.micro"
    #[TYPE.NAME.ATTRIBUTE]形式で記述
    vpc_security_group_ids = [aws_security_group.test_ec2.id]

組み込み関数

用意されている組み込み関数は、公式ドキュメントで確認します。

例

> file("${path.module}/hello.txt") 
Hello World

user_data.shを同階層に作り、file関数を用いてApacheのインストールスクリプトを実行する例

user_data.sh

#!/bin/bash
yum -y install httpd
systemctl start httpd.service

resource "aws_instance" "test" {
    ami               = "ami-xxxx"
    instance_type     = "t3.micro"
    user_data         = file("./user_data.sh")

モジュール

モジュールについてまとめると

親となるソースコードから呼び出して使う
異なる親から同じモジュールを呼び出すことができる
パラメータを使うことで、ふるまい制御ができる

moduleを呼び出すコード

module "resource name" {
    source = "モジュール定義したフォルダパス"
    パラメーター名 = "パラメータ値"
}

モジュールの構造は以下の3つで成り立っている。

パラメータ　variable
本体　resource
戻り値　output

※それぞれのモジュール定義の例は以下の通り

1.パラメータの定義

variable "parameter_name" {
}

2. 本文

#resource "定義名" "リソース名"
 resource "aws_instance" "test"
    instance_type = var.instance_type

3.戻り値

output "instance_id" {
    value = aws_instance.test.instance_id
}

モジュール利用側の`main.tf`ファイル

下記のように利用するモジュールをsourceとし、実装したディレクトリを指定します。

module "server" {
    source = "./server"

まとめ

Terraformを使うためには、

.tfファイルの作成（変数を定義するときは.tfvarsファイルも作成）
terraform varidateで記述チェック
terraform plan で「どのリソースを追加・変更・削除するか」を画面表示
問題なければterraform applyを実行、リソースを作成する
環境が不要になったときはterraform destroyで削除する

Terraformを使うことで

誰が構築しても同じ環境を構築できる
作成する環境の一貫性を保つことができる
工数を削減できる
一度作った環境をもとに、同じ環境を構築する時の工数削減が期待できる
Gitによるバージョン管理
管理システム(GitOpsなど)を使い、テスト環境・本番環境を管理できる

【ふりかえり】Terraformの基礎

目的