Terraform Provider v3 正式リリースと移行のポイント

はじめに

さくらインターネット サービス統括本部 技術戦略室の山本です。

Terraform for さくらのクラウドでは、新しい世代となるTerraform Provider v3を正式にリリースしています。

v3では、これまでのサーバやネットワークといったインフラに加えて、APIゲートウェイやEventBusなどのプラットフォームサービスにも対応し、Terraformで管理できる範囲が大きく広がりました。あわせて、現在のサービス構造に沿ったリソース設計や、よりシンプルで見通しのよい記述方法への見直しも行っています。

この記事では、v3で何が変わるのかと、v2を利用している場合に確認しておきたいポイントについて解説します。具体的には、以下の内容を扱います。

• Terraform Provider v3で何が変わるのか
• v2からv3への移行で確認しておきたいポイント
• なぜ今後はv3を前提とした利用が推奨されるのか

なお、v2のメンテナンス終了については別途アナウンスしていますので、詳細は以下もあわせてご参照ください。
Terraform Provider v2 メンテナンス終了のお知らせ

Terraform Provider v3で何が変わるのか

v3では、現在のさくらのクラウドのサービスやTerraformの進化に合わせて利用体験を改善する見直しにより、より扱いやすい構成になっています。

主なポイントは以下の通りです。

• Terraformで管理できる範囲の拡大
• 現在のサービス構造に合わせたリソース設計・命名の整理
• よりシンプルで見通しのよい記述方法

これらの変更により、v3では現在のさくらのクラウドをより広くTerraformから管理できるようになっています。

一方で、v2とv3は完全な互換性を持っているわけではありません。リソース名や属性構造、設定ファイルの書き方が変わっている場合があるため、移行時には利用中のリソースやStateの扱いを確認する必要があります。

以降では、それぞれの変更点について説明します。

Terraformで管理できる範囲の拡大

最も大きな違いは、Terraformから管理できるサービスやリソースの範囲です。

近年、さくらのクラウドではAPIゲートウェイ、EventBus、Add-onなどの新しいサービスが追加され、従来のサーバやネットワークを中心としたクラウドから、より幅広いプラットフォームへと進化しています。

参考: 【さくらのクラウド】新たに13の機能を追加

こうした変化に合わせて、Terraform Providerから管理できる範囲も拡大してきました。

v2では、主にサーバやネットワークなどの基盤リソースをTerraformで管理することを中心としていました。一方でv3では、インフラリソースに加えて、現在のさくらのクラウドで提供されている各種プラットフォームサービスにも対応しています。例えば、以下のようなサービスはv3で利用できます。

• IAM
• オブジェクトストレージ
• モニタリングスイート
• AppRun（共用型、専有型）
• APIゲートウェイ
• EventBus
• シンプル通知
• シンプルMQ

今後追加されるサービスや機能も、v3を前提として利用できるように拡張されていく予定です。これにより、Terraformから利用できる機能やサービスの範囲もさらに広がっていきます。

現在のサービス構造に合わせたリソース設計・命名の整理

v3では、リソース名やリソース設計についても見直しを行っています。これは単純なProviderのプレフィックス変更ではありません。現在のサービス名称やサービス構造に合わせて、利用者から見たリソースの役割が理解しやすくなるように整理されたものです。

例えば、以下のような変更があります。

• sakuracloud_vpc_router → sakura_vpn_router
• sakuracloud_proxylb → sakura_enhanced_lb

これらは単なる名前の変更ではなく、現在のサービス名称や役割との整合性を高めることを目的としています。

v2を利用している場合、移行時にはリソース名や属性構造の対応関係を確認する必要があります。一方でv3では、現在のさくらのクラウドのサービス構造に沿った、リソース名から役割を理解しやすい構成を目指しています。

よりシンプルで見通しのよい記述方法

v3では、Terraformの設定ファイル（.tfファイル）の記述方法についても見直しを行っています。

主な変更点として、

• データソースのfilter構文の廃止
• block構文からattributeベースへの整理

があります。

例えばv2では、データソースで対象を絞り込む際にfilterブロックを利用していました。

data "sakuracloud_disk" "example" {
  filter {
    names = ["Example"]
  }
}

v3では、検索条件を属性として直接指定する形に整理されています。

data "sakura_disk" "example" {
  name = "Example"
}

このように、v3ではProvider固有の表現を減らし、Terraformの設定ファイルとして読みやすい形に整理しています。

一方で、v2からv3へ移行する場合は、設定ファイルの書き換えが必要になる箇所があります。移行の際は、リソース名や属性構造だけでなく、こうした記述方法の変更についても確認してください。

v2からv3への移行で確認しておきたいポイント

v2からv3への移行は、いくつかのポイントを押さえることで段階的に進めることができます。

まずは以下の2点を確認することをおすすめします。

• 利用中のリソースの対応状況を確認する
• Terraform Stateの移行方法を検討する

以降では、それぞれについて説明します。

利用中のリソースの対応状況を確認する

まず確認していただきたいのは、現在利用しているリソースがv3で利用可能かどうかです。

Terraform for さくらのクラウド v3では、サーバやスイッチ、ルータといった主要なリソースに加え、多くのサービスに対応していますが、現時点では一部未対応のリソースもあります。例えば、執筆時点では以下のリソースはv3に対応していません。

• アーカイブ共有: archive_share
• マネージドPKI: certificate_authority
• 2要素認証SMS: esme
• セキュアモバイルコネクト
  • モバイルゲートウェイ: mobile_gateway
  • SIM: sim

そのため、移行を検討する際は、まず現在のTerraform構成で利用しているリソースを棚卸しし、v3で利用可能かどうかを確認することを推奨します。

v3で利用可能なリソースや変更点については、以下も参考にしてください。

https://github.com/sacloud/terraform-provider-sakura/blob/main/CHANGES.md

v3に未対応のリソースを利用している場合、そのリソースを含むTerraform構成を一度にv3へ移行できない可能性があります。その場合は、以下のような対応を検討してください。

• v3対応済みのリソースから段階的に移行する
• 未対応リソースのみ、一時的にv2で管理を継続する
• 未対応リソースをTerraform管理対象から外し、コントロールパネルやAPIなど別の方法で管理する

v3未対応リソースについて、今後の対応に関するご要望がある場合は、利用中のリソース名や用途を添えてサポートまでお問い合わせください。

Terraform Stateの移行方法を検討する

v2とv3は、別のTerraform Providerとして提供されています。そのため、同じTerraform構成の中でv2とv3を併用することも可能です。

移行を進める際は、まず今後新しく作成するリソースからv3を利用することを推奨します。これにより、新規リソースについてはv3を前提に管理し、既存リソースの移行は影響範囲を確認しながら段階的に進められます。

一方で、すでにv2で管理しているリソースをv3へ移行する場合は、Terraform Stateの扱いを検討する必要があります。v2とv3は別Providerであるため、既存のStateが自動的にv3のリソースとして扱われるわけではありません。主な選択肢は次のとおりです。

• v3側のリソース定義とimportブロックを用意し、既存の実リソースをv3のリソースとして取り込む
• リソースを一度削除し、v3側のリソースとして再作成する
• 期日までに移行が難しい場合は、リスクを把握したうえで一時的にv2の利用を継続する

v3側のリソース定義を作成する際は、リソース名や設定内容の変更にも注意が必要です。v2とv3ではリソース名や属性構造が変更されている場合があります。既存のtfファイルをそのまま書き換えるのではなく、v3のドキュメントや変更履歴を確認しながら、対応するリソース定義を作成してください。

また、Terraformにはimportブロックから設定ファイルを生成するための -generate-config-out オプションもあります。ただし、執筆時点ではExperimentalな機能という位置付けのため、生成された設定をそのまま使うのではなく、内容を確認し必要に応じて修正してご利用ください。

参考: https://developer.hashicorp.com/terraform/language/import/generating-configuration

特に本番環境で利用しているリソースについては、事前に以下を確認することを推奨します。

• v3側で対応するリソース定義を作成できるか
• 既存リソースをv3のリソースとして取り込めるか
• 取り込み後のterraform planで意図しない差分が出ないか
• 再作成が必要な場合に、サービス影響を許容できるか
• v2の利用を継続する場合に、どのようなリスクを許容するのか

Stateの移行は、移行作業の中でも影響が大きいポイントです。検証環境や影響の小さいリソースで手順を確認したうえで、本番環境へ適用することを推奨します。

なぜ今後はv3を前提とした利用が推奨されるのか

今後もTerraformでさくらのクラウドを継続的に活用していくためには、v3を前提とした運用に移行していくことが現実的な選択になります。理由は大きく二つあります。

理由1: より正確で一貫した管理を実現するため

v3では、Terraform 本体の機能や型の扱いをより自然に表現できるようになり、未知値やnullの扱いなども含めて、より正確で一貫した挙動でリソースを管理しやすくなります。こうした改善は、現在主流となっているTerraform Plugin Frameworkを前提とした実装によって実現されています。

これは単なる実装方式の違いではなく、Terraformの進化に合わせて継続的に改善していくための前提となる基盤の違いです。今後も安定した運用や品質向上を続けていくためには、この新しい技術基盤を前提とした v3 を中心に開発・改善を進めていく必要があります。

理由2: 継続的な改善を安定して提供するため

近年、さくらのクラウドではIAM、モニタリングスイート、APIゲートウェイ、EventBus、シンプルMQ、シンプル監視、Add-onなど、多くの新しいサービスが追加されています。これらのサービスへの対応に加え、既存リソースの品質改善や設計の見直し、ドキュメントや移行支援も継続的に行っていく必要があります。

v2とv3の両方を前提とした対応を続ける場合、結果として新機能追加や品質改善の反映が遅くなる可能性があります。そのため、今後の開発・改善をv3に集約することで、より広いサービスを安定してTerraformから利用できる状態を継続的に提供していきます。

まとめ

• v3では、Terraformで管理できるサービスの範囲が拡大し、より一貫した形でさくらのクラウドを扱えるようになっています
• 今後の機能追加や品質改善は、v3を中心に行われます
• v2については、2026年12月末をもってメンテナンスを終了予定です

現在v2を利用している場合は、今後も継続的にTerraformで運用していくことを見据えて、まず利用中のリソースの対応状況を確認し、移行の進め方を検討することが重要です。特に本番環境で利用している場合は、検証環境での確認や段階的な移行を前提に、影響範囲を見極めながら進めていくことをおすすめします。