~Terraformの基礎を90分で解説するチュートリアルをみて~

はじめに

インストール

tfファイルについて

  • このファイルに IaCで管理するリソースを書いていく
  • 実行時のポイント
    • 実行ディレクトリの直下にある tf ファイルを読みこんで実行する
      • 階層が違うと tf ファイルを認識してくれないので、各ファイルを同階層に置くのがベーシックな方法とのこと
      • さすがにそれだと管理が煩雑になりすぎるので、いろいろ工夫があるようだが今回触る範囲からは一旦外す
    • 各 .tf ファイルが結合されて実行される
      • リソース種類ごとの依存関係とかどうするんだと思ったけど、ある程度賢く terra form側で管理してくれるよう
      • 結合されるので各tfファイルの命名は動作には影響しない
  • 構文について
    • いっぱいあるけど、とりあえず一番基本的な3つの構文をピックアップ
      • resource: クラウドリソースを作るための構文
      • data: リソースの情報を取得するための構文
        • resource で作成したり管理してないけど、aws上にあるリソースの情報をとってくる時とかに使う(?)
        • 具体的な一例をあげると, 既存AWS環境を terraform に移行するときとか
      • variable: 変数を定義する
        • type で型の指定
        • default でデフォルト値の指定

構文のコード例

  • resource の例
    resource "リソースの種類" "リソース名" {
        設定項目1 = 設定値
        設定項目2 = 設定値
        設定項目3 = 設定値
    }
  • data の例
    data "リソースの種類" "リソース名"{
        filter = {
            Name = "リソース名"
        }
    }
  • variables の例
    # 変数定義側
    variables "変数名" {
        type = string,
        default = "hoge"
    } 

    # 呼び出し側
    resource "Xxxx" "Xxxx" {
        hoge = vars.変数名
    }

tfstateファイルについて

  • terraform で管理しているインフラリソースをすべて記載した json 形式のファイル
    • terraform.tfstate
  • 今回はローカルにこのファイルおく形とする。実務では複数人がさわる環境でローカルファイルで管理するわけにもいかないので、S3上でこのファイルを管理する方法がよく使われているらしい。

bicep との大きな違いの部分だと感じました。bicep ではインフラ全体の状態を管理するようなファイルはないので、IaCの設計方針が大分変わりそうですね。

実リソースとコードの差分がすぐに出せて比較できるのは素晴らしい反面、厳密に状態が管理される前提なので設計の難易度が高めと感じました。

コードを書く

  • 作業ディレクトリ用に適当なディレクトリを作成する

  • 作業ディレクトリ配下に以下ファイルを作成する。

    • provider.tf
    • vpc.tf
    • ec2.tf
      • ここでは webサーバー用途を想定しているので apache を入れてみている

  • provider.tf

provider "aws" {
    region = "ap-northeast-1"
}
resource "aws_vpc" "test-vpc" {
    cidr_block = "10.0.0.0/16"

    tags = {
        Name = "test-vpc"
    }
}

resource "aws_subnet" "test-subnet-public-ap-northeast-1a" {
    vpc_id = aws_vpc.test-vpc.id
    cidr_block = "10.0.1.0/24"

    availability_zone = "ap-northeast-1a"

    tags = {
        Name = "test-subnet-public-ap-northeast-1a"
    }
}
resource "aws_subnet" "test-subnet-public-ap-northeast-1c" {
    vpc_id = aws_vpc.test-vpc.id
    cidr_block = "10.0.2.0/24"

    availability_zone = "ap-northeast-1c"

    tags = {
        Name = "test-subnet-public-ap-northeast-1a"
    }
}
  • ec2.tf
resource "aws_instance" "sample_web_server" {
    ami                    = "ami-09d28faae2e9e7138" # Amazon Linux 2
    instance_type          = "t2.micro"

    user_data = <<EOF
    #! /bin/bash
    sudo yum install -y httpd
    sudo systemctl start httpd
    sudo systemctl enable httpd
    EOF
}

AWS のクレデンシャル設定について

AWS のクレデンシャル設定 の手順

  1. terraform で　terraform 用のアクセスキーを作成する
    1. IAMユーザー画面に遷移
    2. 対象のユーザーを選択 or 新規作成 (用途に合わせて)
    3. セキュリティ認証情報タブの下の方いくとアクセスキー周りの設定箇所あるのでそこで設定
  2. 作成したら、アクセスキーとシークレットキーをメモっておく
  3. 以下コマンドをターミナルから実行して、環境変数を設定
        export AWS_ACCESS_KEY_ID="Xxx"
        export AWS_SECRET_ACCESS_KEY="Xxx"
        export AWS_REGION="ap-northeast-1"
        terraform plan

コマンド紹介

  1. terraform plan
    • tfstateで管理されているリソースの状態と、現在のterraformのコードの状態を比較して差分をとってくれる
    • bicep とか使ってるとこれできるのめちゃ便利だなあと思う
  2. terraform validate
    • terraform の構文チェックができる
    • terraform plan でもエラーでるので基本あんま使わなさそう
  3. terraform fmt
    • terraform のフォーマット崩れてるところを修正してくれる
  4. terraform apply
    • このコマンドで実際にリソース作成が行われる
  5. terraform destroy
    • ちなみにすべてではなく特定のリソースのデストロイしたいとき -t オプションで指定できる

実行

  • 以下コマンドを実行する。コンソール画面とかを見ると、リソースが出来上がっているのがわかる。
terraform plan
terraform fmt #tfファイルをフォーマットしてくれる
terraform apply

いろいろリソース触ってみたりしてもらった後は、以下コマンドで消す。作ったものが一気に消せるの便利...！！

terraform destroy

リソース消したら AWS のアクセスキーを一応無効化しておきます

  1. IAMの画面に行く
  2. 使っていたIAMユーザーを選択
  3. セキュリティ認証情報 タブを下に行くとアクセスキーの項目があるので、アクションボタンから無効化をする

おまけ

module

  • オブジェクト指向でいうところのクラスみたいなイメージ
  • 例: VPC と　Subnet を組み合わせたテンプレートを作っておくなど
    • variables 構文を使って, cidr_block を渡してあげて、その部分だけは可変にするとかもできる

workspace

  • git のブランチみたいなイメージで、作業環境をterraform workspaceコマンドでスイッチできる
  • 例えば、環境ごとに workspace をスイッチするとかのユースケースが一例
    • develop,staging,production みたいな