Zenn
🐈

Terraformと仲良くなるためにやったこと

2024/12/25に公開
Terraform
tech

はじめに

この記事はBrainpad Advent Calendar 2024 の6日目になります。
こんにちは。株式会社ブレインパッドの新卒の斉藤です。

今回は「初心者がTerraformと仲良くなるまでにやったこと」という記事を書くことで、自分が最近学んだことをアウトプットしつつ、新卒同期がアドベントカレンダーに積極的に参加する流れを作っていこうと思います。

概要

入社してから初めてTerraformというものを触りました。Terraformをだいたい扱えるようになるまでにやったことなどを、基本的な構文から設計、CI/CD設定まで順番に簡潔にまとめていこうと思います。

公式ドキュメントを軽く読む

まずは公式ドキュメントを軽く読み、HashiCorp社製品であること、インストール手順、HCLという言語で書くなどを理解する。

https://developer.hashicorp.com/terraform?product_intent=terraform

基本的な構文を知る

HCL（HashiCorp Configuration Language）で書く。

  • provider: 管理するクラウドプロバイダやサービス（例: AWS, GCP, Azure）
  • variable: 動的な値を管理するための変数
  • resource: 作成するリソース
  • output: 実行結果を出力するための機能

例：Google Cloudの場合

// main.tf
provider "google" {
  project = var.project_id
  region  = var.region
}

// variables.tf
variable "project_id" {
  description = "Google Cloud project ID"
  type        = string
}

variable "region" {
  description = "Google Cloud region"
  type        = string
}

// storage.tf
resource "google_storage_bucket" "my_bucket" {
  name          = "my-example-bucket"
  location      = "ASIA"
  storage_class = "STANDARD"
  
  versioning {
    enabled = true
  }

  lifecycle_rule {
    action {
      type = "Delete"
    }
    condition {
      age = 30
    }
  }

  labels = {
    environment = "dev"
    team        = "example-team"
  }
}

// output.tf
output "bucket_name" {
  value = google_storage_bucket.my_bucket.name
  description = "The name of the created GCS bucket"
}

基本的なコマンドを知る

  • terraform init：プロバイダのプラグインをダウンロードし、プロジェクトを初期化
  • terraform plan：実行計画を作成する。どのリソースが作成、削除されるかを確認
  • terraform apply：実行計画を適用して、リソースを作成または変更

ステートについて知る

Terraformは実行状態をステートファイル（terraform.tfstate）に保存する。このファイルはリソースの現在の状態を記録し、次回の実行時に変更点を検出するために使用される。

ステートの種類

ローカル

デフォルトでは、ステートファイルはローカルに保存される。

リモート

リモートバックエンドというものを使用して、外部のストレージサービスをステートファイルの配置場所に指定できる。（例：S3、GCS、Terraform Cloud）

terraform {
  backend "gcs" {
    bucket = "terraform-state-bucket"
    prefix = ""
  }
}

ステート設計の観点を知る

ステート設計は運用の効率性や安全性に大きく影響する。

観点1: 運用する環境

ステートを環境ごとに分割することで、環境間の干渉を防ぐ。

  • 開発環境用のステート
  • ステージング環境用のステート
  • 本番環境用のステート

観点2: リソースのライフサイクル

リソースのライフサイクルに応じてステートを分割することで、影響範囲を最小限に抑えることができる。

  • 長期間変更のないリソース（例: Cloud Storage）
  • 頻繁に変更されるリソース（例: Compute Engine）

観点3: モジュール化

再利用できそうな構成はモジュール化する。

module "example" {
  source = "./modules/my_module"

  # モジュールに渡す変数
  variable_name_1 = "value1"
  variable_name_2 = "value2"
}

ステートを飼い慣らす

  • terraform state list：ステートに登録されているリソースを一覧表示
  • terraform state rm：ステートからリソースを削除
  • terraform import：既存のリソースをTerraform管理下にインポート
  • terraform init -migrate-state：ステートを別のバックエンドに移行

デプロイを自動化する

CI/CDの設定して効率的に運用する。

例：Google Cloudで利用する場合

name: Terraform CI/CD

on:
  push:
    branches:
      - main

jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

     - name: Auth
       uses: google-github-actions/auth@v2
       with:
          project_id: ${{ secrets.PROJECT_ID }}
          workload_identity_provider: ${{ secrets.WORKLOAD_IDENTITY_PROVIDER }}
          service_account: ${{ secrets.SERVICE_ACCOUNT }}

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_wrapper: false

      - name: Initialize Terraform
        run: terraform init

      - name: Terraform Plan
        run: terraform plan

      - name: Apply Terraform (manual approval required)
        if: github.ref == 'refs/heads/main' && github.event_name == 'push'
        run: terraform apply -auto-approve

おわりに

いかがだったでしょうか。

Brainpad Advent Calendar 2024では他にもたくさんの記事が投稿されていますので、そちらもぜひ読んでみてくださいね。

Discussion