Terraform for さくらのクラウド で実現するインフラ自動化 (2) ～ いろいろなシステムを構築しよう

Terraform（テラフォーム）は、インフラ構成をコードで管理し、構築や変更を効率化するIaC（Infrastructure as Code）ツールです。

さくらのナレッジでは全2回にわたり、さくらのクラウド向けTerraformプロバイダ「Terraform for さくらのクラウド」を中心に、Terraformの基本的な考え方から実際の操作、利用イメージまでを開発者視点で解説します。さくらのクラウドをコード管理したい方や、Terraformの導入・移行を検討しているエンジニア、インフラの自動化・運用改善に関心のある方におすすめです。

この第2回では、Terraformを使った具体的なシステム構築例と利用上のテクニックを解説します。

※ 現在「Terraform for さくらのクラウド v3」を提供しており、新規の利用については「v3」の利用を推奨しています。
※本記事のコード例はTerraform for さくらのクラウド v3系を前提としています。

「さくらのクラウド」でいろいろなシステムを構築する

前回は、Terraformの基本的な使い方を解説しながら、さくらのクラウド上に「ディスク＋サーバ」を構築しました。Terraformと「さくらのクラウド」での基本的な利用方法は、そちらを参照してください。

今回は、まず「Terraform for さくらのクラウド」の具体的な設定例を紹介していきます。

• 設定例1：VPNルータを作成する
• 設定例2：KMSを利用する
• 設定例3：AppRun
• 設定例4：エンハンスドロードバランサ

設定例1：VPNルータを作成する

VPNルータは、クラウド上にVPN（Virtual Private Network）環境を簡単に構築できる仮想ルーターアプライアンスです。ファイアウォールやVPN接続など、セキュリティを高めるさまざまな機能を持っているほか、オンデマンドで機器の追加やネットワーク帯域を変更できます。プライベートネットワーク上のサーバーやデータベースへ安全に接続する用途にも利用できます。

そのため、VPNルータを作成する前に、依存リソースとして「スイッチ＋ルータ」と「コントロールパネル上のスイッチ」を定義します。

VPNルータのセットアップ内容は次のようになります。

# 依存リソースの作成
# スイッチ+ルータ
resource "sakura_internet" "foobar" {
  name = "foobar"
}

# コントロールパネル上のスイッチ
resource "sakura_vswitch" "foobar" {
  name = "foobar"
}

次の設定ファイルでVPNルータを作成すると、VPNルータが利用するIPアドレスや接続先ネットワークを、Terraformがリソース間の参照関係から自動的に紐付けます。

具体的には、「sakura_internet」や「sakura_vswitch」リソースで作成したネットワークのIDやIPアドレスをVPNルータ定義内で参照することで、Terraformが依存関係を解析し、正しい順序でリソースを作成・関連付けします。

そのため、IPアドレスの割り当てやインターフェースの接続先を手動で指定する必要がなく、設定ミスを防ぎながら一貫した構成をコードで管理できます。

# VPNルータの作成 (関係するパラメータのみ)

resource "sakura_vpn_router" "premium" {
  # …
  plan = "premium"
  public_network_interface = {
    vswitch_id = sakura_internet.foobar.vswitch_id
    vip = sakura_internet.foobar.ip_addresses[0]
    ip_addresses = [sakura_internet.foobar.ip_addresses[1], sakura_internet.foobar.ip_addresses[2]]
    # …
  }
  private_network_interface = [{
    index = 1
    vswitch_id = sakura_vswitch.foobar.id
    # …
  }]
}

設定例2：KMSを利用する

次は、KMS（Key Management Service）の利用方法です。

KMSはデータ暗号化に用いられる暗号鍵の作成、保管、削除などを含むライフサイクル管理を行うためのサービスです。現在、さくらのクラウドのディスクやデータベースなど、さまざまな機能がKMSに対応しています。データ暗号化に使用する鍵を安全に管理できます。

まずは、KMSの取得・作成です。次のように2つの書き方が可能です。

既存のKMSを使う場合は、次のように「data "sakura_kms"」を使います。

# KMSの取得/作成　その1

data "sakura_kms" "foobar" {
  name = "foobar"
}

# KMSをリソースの作成で利用（その1）

resource "sakura_disk" "foobar" {
  name = "foobar"
  kms_key_id = data.sakura_kms.foobar.id
  encryption_algorithm = "aes256_xts"
}

resource "sakura_nosql" "foobar" {
  name = "foobar”
  # …
  disk = {
    encryption_algorithm = "aes256_xts"
    encryption_key = {
            kms_key_id = data.sakura_kms.foobar.id
    }
  }
}

KMSを新規作成・管理したい場合は、次のように「resource "sakura_kms"」を使うといいでしょう。

# KMSの取得/作成　その2
resource "sakura_kms" "foobar" {
  name = "foobar"
  description = "via Terraform"
  key_origin = "generated"
  tags = [”terraform"]
}

# KMSをリソースの作成で利用（その2）

resource "sakura_disk" "foobar" {
  name = "foobar"
  kms_key_id = sakura_kms.foobar.id
  encryption_algorithm = "aes256_xts"
}

resource "sakura_nosql" "foobar" {
  name = "foobar"
  # …
  disk = {
    encryption_algorithm = "aes256_xts"
    encryption_key = {
            kms_key_id = sakura_kms.foobar.id
    }
  }
}

このようにKMSをTerraformで新規作成した場合は、sakura_kms.*.id を参照することで、同じ設定ファイル内の他リソースから暗号化キーとして利用できます。

Terraformはリソース間の参照関係を自動的に解析するため、KMSの作成後にディスクやデータベースが作成されるよう、実行順序も自動的に制御されます。
システムを安全に保つためにも、ぜひKMSを利用してください。

設定例3：AppRun

次はAppRunです。AppRunは、コンテナ化されたアプリケーションを簡単にデプロイでき、自動スケーリングにも対応しています。

AppRunを利用するには、次のように設定ファイルを記述します。この例では、コンテナレジストリが事前に用意されている前提になっています。

# AppRun

resource "sakura_apprun_shared" "foobar" {
  name = "foobar"
  timeout_seconds = 60
  port = 8080
  min_scale = 0
  max_scale = 1
  components =[{
    name = "foobar"
    max_cpu = "0.1"
    max_memory = "256Mi"
    deploy_source = {
    container_registry = {
            # …
      }
    }
    # …
  }]
}

設定例4：エンハンスドロードバランサ

次は「エンハンスドロードバランサ」です。エンハンスドロードバランサは、L4/L7に対応した高機能なロードバランサーです。多くのサーバーを起動する場合、その前段にエンハンスドロードバランサを配置します。また、AppRun共用型で不足する機能を補うために、その前段にエンハンスドロードバランサを設置する場合もあります。

エンハンスドロードバランサを利用するには、次のように設定ファイルを記述します。こちらも、バックエンドサーバー（sakura_server）が事前に用意されている前提になっています。

# エンハンスドロードバランサ
resource "sakura_enhanced_lb" "foobar" {
  name = "foobar"
  vip_failover = true
  health_check = {…}
  bind_port = [{…}]
  server = [{
    ip_address = sakura_server.foobar.ip_address
    port = 80
    group = "group1"
  }]
  rule = [{
    action = "forward"
    host = "www.example.com"
    source_ips = "192.2.0.1,192.12.0.2"
    path = "/"
    group = "group1"
  }]
  # …
}

※ これらの設定ファイルのサンプルの詳細は、次のリンクを参照してください。

• sacloud/sakura - Documentation | Terraform Registry

Terraformの利用テクニック

ここでは、Terraformを利用するときの基本的なテクニックを紹介します。

設定は組み合わせて利用できる

ここまで「さくらのクラウド」用にTerraformによる設定例を紹介してきました。これらのリソースは、組み合わせて自動構築できます。たとえば、次のようにKMSやディスク・サーバなどを組み合わせできます。

1. KMSリソースで暗号化を準備
2. ディスクやデータベースなどをKMSを利用して作成
3. スイッチやパケットフィルタなどを作成
4. スイッチ・パケットフィルタを使ってサーバ/AppRunを作成
5. サーバ/AppRunの前段にエンハンスドロードバランサーを作成

Terraformでは、カレントディレクトリにある *.tf ファイルがすべてまとめて読み込まれ、1つの巨大な設定として解釈されます。実行順序は、記述した順番ではなく、参照関係で決まります。そのため設定ファイルを分割して、可読性を高めて管理を容易にしましょう。

設定ファイルが用意できれば、これらのリソースを一括して作成できます。リージョンとゾーンの指定を変更すれば、同じシステム構成を別の場所にすぐに再現できます。また、destroyコマンドでクリーンアップできます。

for_eachで、複数リソースを作成する

Terraformの設定ファイルでは、for_eachでコードをループ実行できます。同じコードを複数個所にコピーしなくても、複数のリソースを1つのコードでコンパクトに記述できます。

次のコードは、変数と for_each を使って複数のディスクとサーバをまとめて作成する例です。

variable "names" でサーバ名のリストを定義し、変更点を変数化しています。data "sakura_archive" では Ubuntu の最新アーカイブを取得します。sakura_disk リソースでは for_each により、名前リスト分のディスクを自動生成します。続く sakura_server では、作成済みディスクを参照して同数のサーバを作成し、ディスクとサーバの依存関係を自動的に構築しています。

これにより、名前を追加するだけで台数を調整できるので、可読性と再利用性が高まります。

# 変更箇所を変数で定義
variable "names" {
  # マップ・オブジェクトも可能
  type = list(string)

  default = [
    "foobar1",
    "foobar2",
  …
  ]
}

data "sakura_archive" "ubuntu" {
  os_type = "ubuntu"
}

# 複数のリソースを一括管理
resource "sakura_disk" "foobar" {
  for_each = toset(var.names)

  name = each.value
  source_archive_id = data.sakura_archive.ubuntu.id
}

resource "sakura_server" "foobar" {
  for_each = sakura_disk.foobar

  name = each.value.name
  disks = [each.value.id]
  description = format("%s-desc", each.value.name)
  # …
}

CIでTerraformを利用する

さくらインターネットの現場でも、簡単なアクションだけで済む場合は、CIの中に組み込んだTerraformを利用することが広く行われています。

GitHubのリポジトリで設定ファイルを管理していて、たとえばDNSを更新するときにAレコードを追加したいと思ったら、担当エンジニアがパッチを投稿して、管理者がレビューして問題なければマージします。そうすると裏側でGitHub Actionsが走り、その中でTerraformが動いて、クラウドのDNSが更新されます。

自社の環境でも、Terraformだけで済むような変更があれば、CIに組み込んでTerraformで管理すれば、運用が楽になりコスト削減につながります。

Terraform policyでセキュリティチェック

「Terraform policy for さくらのクラウド」は、Terraform for さくらのクラウドを用いて記述されたTerraformコードを、セキュリティおよびガバナンスの観点から静的にチェックするためのポリシーです。たとえば「ゾーンは tk1b のみ」「特定プラン以外は作成禁止」などを事前にチェックできます。これにより属人化や誤操作を防ぎ、安全で一貫したインフラ運用を実現できます。

「Terraform policy for さくらのクラウド」を利用するには、OPA（Open Policy Agent）とConftestを利用します。チェック用ルールは、OPAのポリシー言語で記述します。詳しい使い方は、GitHubリポジトリのREADMEファイルを参照してください。

• Terraform policy for さくらのクラウド
• V2用 https://github.com/sacloud/terraform-provider-sakuracloud-policy
• V3用 https://github.com/sacloud/terraform-provider-sakura-policy

まとめ

ここまで、Terraformを使った具体的なシステム構築例と利用上のテクニックを解説してきました。

Terraformを利用することで、さくらのクラウドでも、サーバーやネットワーク、データベース、ロードバランサーなど、これまで手作業で作ったり管理画面（GUI）で設定したりしていた作業を、設定ファイル（コード）として記述して自動構築できます。

さくらのクラウドでは、サービスの拡充に合わせて、今後もTerraform対応を進めていく予定です。Terraformは、構成の再現性と変更履歴の管理を両立できるため、継続的なシステム運用に適しています。ぜひ、Terraformを活用していきましょう。

関連リンク

2025年11月開催の「クラウド活用最前線セミナー」では「Terraform for さくらのクラウド」開発者の中川真宏が使い方などを解説しました。次の動画を参照してください。

そのほか以下のリンク先も参考にしてください。

Terraform

• Terraform | HashiCorp Developer

Terraform for さくらのクラウド

• Terraform for さくらのクラウド | さくらのクラウド マニュアル

v3

• sacloud/sakura | Terraform Registry
• GitHub: sacloud / terraform-provider-sakura

関連ツール

Usacloud

• Usacloud導入ガイド - Usacloudドキュメント
• Usacloudドキュメント

Terraform policy for さくらのクラウド

• Terraform policy for さくらのクラウド
• V2用 https://github.com/sacloud/terraform-provider-sakuracloud-policy
• V3用 https://github.com/sacloud/terraform-provider-sakura-policy

さくナレでの解説記事

前述したように2022年に「v2」ベースで記述された記事を公開しています。

• さくらのクラウドでTerraformを使ってみる | さくらのナレッジ

やってみた

外部の解説記事でも取り上げていただいています。

• さくらのクラウドでTerraformでサーバーを立ててみた #Terraform - Qiita
• さくらのクラウドの検証環境を都度作るのが面倒なのでTerraform化してみる - gokigenmaruのブログ
• AWS経験者もハマる！Terraformで学ぶさくらのクラウドとcloud-initの罠｜BEMA Lab｜エンジニアの成長を支援する技術メディア