12/4に、TerraformでGCPのリソースを扱うGoogle Provierが 3.0.0
にメジャーバージョンアップしました。(ちなみにその翌日、 v3.1.0
もリリースされております。)
1.xx 系から2.0にバージョンアップしたときは、 Beta Provierが新たに新設され、GAになっていない機能はBeta Providerでリソース定義するようになりましたが、2.xx系から3.0.0にアップグレードするには、どういった点に注意するのかを書いていこうと思います。
目次
- 対象読者
- アップグレードの概要
- Terraform 0.11 以前は動作対象外となった
- Terraformのリソース管理IDが SelfLink ベースに統一された
- google_cloudfunctions_function の runtime 属性
- google_compute_instance_group_manager と google_compute_region_instance_group_manager の template 属性
- google_compute_instance_group_manager と google_compute_region_instance_group_manager の update_strategy 属性
- google_compute_subnetwork の enable_flow_logs 属性
- google_container_cluster の ip_allocation_policy ブロック属性
- google_project_service のBigQuery API設定
- google_project_services リソースの廃止
- google_storage_bucket の condition.is_live 属性
- バージョンアップでトラブルにならないために
- まとめ
対象読者
- TerraformでGCPリソースを管理している人、または、管理した経験がある人
- Terraformが大好きな人
アップグレードの概要
公式ドキュメントとして Terraform Google Provider 3.0.0 Upgrade Guide がありますので、まずはこちらをご一読頂くとよいと思います。
大きな変更点について書いていきますと、
- Terraform 0.11 以前は動作対象外となった (Terraform 0.12以降を使用する必要がある)
- Terraformのリソース管理IDが SelfLink ベースに統一された
- 2.xxで、廃止予定(Depricated)になっていたリソースやリソース属性が廃止され使用不能になった
- 一部のリソースにおいて、省略可能(Optional)な属性が必須(Required)になった
細かい変更点が非常に多く全てを説明していくことは難しいため、個人的に気になった点について書いていこうと思います。
Terraform 0.11 以前は動作対象外となった
これはそのままですね。まずは Terraformを 0.12 以降に移行しましょう。
たとえTerraform CLI 0.11.14 を使って terraform init
すると、Google Provider は 2.20.0
がダウンロードされます。
このとき、provider の version 指定に "= 3.0.0"
を指定して terraform init
すると、以下のようなエラーになります。
No available provider "google" plugins are compatible with this Terraform version.
From time to time, new Terraform major releases can change the requirements for
plugins such that older plugins become incompatible.
Terraform checked all of the plugin versions matching the given constraint:
= 3.0.0
Unfortunately, none of the suitable versions are compatible with this version
of Terraform. If you have recently upgraded Terraform, it may be necessary to
move to a newer major release of this provider. Alternatively, if you are
attempting to upgrade the provider to a new major version you may need to
also upgrade Terraform to support the new version.
Consult the documentation for this provider for more information on
compatibility between provider versions and Terraform versions.
Terraform 0.11系(またはそれ以前のバージョン)を使用している方は、まずはTerraformのバージョンを 0.12 以降に上げましょう。Terraform 0.12 に上げるときは以前のエントリをご参考にして頂ければと思います。
Terraformのリソース管理IDが SelfLink ベースに統一された
Terraformのリソース参照において id
という、Stateファイルの管理ID属性を参照することができます。この id
属性の形式が SelfLink の形式に統一されるため、既存コードで id
属性を参照しているコードが非互換となる可能性があります。
例えば、VPC Networkを管理する google_compute_network
リソースのIDは、 2.20.0
ではネットワークの name が使われていましたが、 3.0.0
では "projects/{PROJECT_ID}/global/networks/{NETWORK_NAME}"
と、self_link と同じ形式になっていました。リソースの id
属性をリソース参照に使っている人は形式の変更に注意しましょう。
※個人的には、 id
はあくまでState管理上の内部IDなので、リソース間の参照は self_link
等のドキュメント記載の属性を使用する方が好ましいと思います。
google_cloudfunctions_function の runtime 属性
Cloud Functionsは2019/4/18に、 gcloud functions deploy
コマンドの --runtime
パラメータが必須になり、 Node.js 6 ランタイムはDepricatedになりました。 (参考)
同様に、Terraformの google_cloudfunctions_function
の runtime
属性はRequiredになり、 nodejs6
はデフォルト値ではなくなりました。(runtime
属性を省略してデフォルト値を期待するコードを記述している場合は、明示する必要があります。)
google_compute_instance_group_manager と google_compute_region_instance_group_manager の template 属性
マネージドインスタンスグループを設定するときに使用するインスタンステンプレートを指定する template
属性が廃止されました。代わりに version.instance_template
を使用します。
version
ブロックは v2.19.0 から追加されており、template
属性の廃止予告はありましたが、正式に廃止されたものになります。
google_compute_instance_group_manager と google_compute_region_instance_group_manager の update_strategy 属性
マネージドインスタンスグループのインスタンス更新を制御する update_strategy
属性が廃止されました。代わりに update_policy
ブロックを使用します。
update_policy
ブロックは v2.19.0 から追加されており、update_strategy
属性の廃止予告はありましたが、正式に廃止されたものになります。
google_compute_subnetwork の enable_flow_logs 属性
サブネットワークのフローログ(トラフィックのログ)を取得する設定である、 enable_flow_logs
属性が削除されました。代わりに、 log_config
ブロックを使用します。
log_config
ブロックは v2.19.0 から追加されており、enable_flow_logs
属性の廃止予告はありましたが、正式に廃止されたものになります。
google_container_cluster の ip_allocation_policy ブロック属性
ip_allocation_policy
ブロック属性は、主にVPC Native Clusterの設定で使います。このブロック属性の仕様に幾つかの非互換があります。
use_ip_aliases 属性が削除されました
今まではVPC Native Cluster設定の有効/無効を use_ip_aliases
のブール値で制御することができましたが、 3.0.0
からは ip_allocation_policy
の有無自体がVPC Native Clusterの有効/無効を制御するようになります。
もし、 use_ip_aliases
属性を記述している場合は、記述を削除しましょう。
また、 VPC Native Cluster を使わない場合(無効にしたい場合)は、 ip_allocation_policy
ブロック自体を削除することで無効にできます。
GKEサブネットワークを暗黙で作成できなくなりました
今までは、 create_subnetwork
を有効にしたり、 node_ipv4_cidr_block
でCIDRを設定することで、GKEクラスタリソース作成とサブネットワーク作成を同時に行うことができましたが、この2つの属性は削除され、クラスタとサブネットワークを1つのリソースで作成することはできなくなりました。
代わりに、 google_compute_subnetwork
リソースを使って明示的にサブネットワークを作成し、その name
か self_link
を google_container_cluster
の subnetwork
属性で関連付けて設定します。
※余談ですが、個人的は Cluster CIDRやService CIDR用のセカンダリIP範囲についても、 ip_allocation_policy.cluster_ipv4_cidr_block
や ip_allocation_policy.services_ipv4_cidr_block
ではなく google_compute_subnetwork
で定義し、 ip_allocation_policy.cluster_secondary_range_name
と ip_allocation_policy.services_secondary_range_name
で関連付けた方がよいと思います。
LoggingとMonitoringのデフォルト設定
GKEでは v1.14 から Stackdriver Kubernetes Monitoring が標準になります。
これに合わせて、 logging_service
属性と monitoring_service
属性のデフォルト値が、Stackdriver Kubernetes Monitoringになります。 logging_service
属性と monitoring_service
属性の設定を省略している場合は、Providerバージョンアップで変更される可能性があります。 logging_service
属性と monitoring_service
属性は明示した方がよいでしょう。
zone, region, additional_zones 属性の廃止
Provider 2.3.0
から、 GKEクラスタ/ノードプールの zone
,region
の代わりにlocation
を使うようになり、また、additional_zones
はnode_locations
を使うようになりました。(v2.xxまでは、どちらも使うことが可能でした。)
3.0.0
で、zone
, region
, additional_zones
は完全に廃止されました。バージョンアップする場合は、記述の修正が必要になります。
※このセクションは google_container_cluster
の説明ですが、 location
と node_locations
の変更は google_container_node_pool
も同様です。
google_project_service のBigQuery API設定
BigQueryのAPIエンドポイントが bigquery-json.googleapis.com
から bigquery.googleapis.com
に変更となります。
参考: リリースノート
これに伴い、 3.0.0 から google_project_service
で bigquery-json.googleapis.com
を設定しようとすると以下のようなエラーが発生します。
Error: expected service to not match any of [dataproc-control.googleapis.com source.googleapis.com stackdriverprovisioning.googleapis.com bigquery-json.googleapis.com], got bigquery-json.googleapis.com
google_project_service
でBigQuery API有効化に bigquery-json.googleapis.com
に使っている場合は,
bigquery.googleapis.com
に修正する必要があります。
google_project_services リソースの廃止
悪名高き google_project_services
が廃止となります。
google_project_services
は、 明示的に設定していないサービスはApply時に削除するという動作(Authoritative)があり、Cloud Consoleでとりあえず有効化したような場合、Terraformで再度無効化されたりして、非常に危険でした。
サービスAPI有効化は google_project_service
のみを使うことができます。
google_project_services
のようにまとめてサービスAPIを有効化したい場合は、 for_each 構文を使って記述するか、 project_services モジュールを使って記述する、ということになりそうです。
余談ですが、アップグレードガイドの設定例ですと、 project_services モジュールを利用する場合モジュールの version に v3.3.0
を指定していますが、 このバージョンは内部的に count
属性で実装しているため、サービス設定を変更する際に、余計なサービス無効化処理が入る可能性があり、ちょっと危険です。
project_services モジュールの v4.0.0
以降から、 for_each
で実装しているようなので、 project_services モジュールの version は v4.0.0
以降を指定するのがよいと思います。
google_storage_bucket の condition.is_live 属性
Cloud Storageバケットのライフサイクルルールで、オブジェクトのライブ状態の設定である condition.is_live
属性は廃止されました。代わりに、 condition.with_state
属性を使用します。
condition.with_state
属性は v2.4.0 から追加されており、condition.is_live
属性の廃止予告はありましたが、正式に廃止されたものになります。
バージョンアップでトラブルにならないために
アップグレードガイドのProvider Version Configuration にも記載されておりますが、もし 3.0.0 へのアップグレードにすぐ対応できない場合は、 Google Providerのバージョンを固定し、時期をみて 3.0.0 以降へ移行するのも手だと思います。
以下の例は、2.17.0 に固定する場合の設定です。バージョン固定は provider
の中で version
を設定します。(アップグレードガイドの記述そのままです。)
provider "google" {
# ... other configuration ...
version = "~> 2.17.0"
}
バージョン固定は、今回のようなアップグレードの非互換を防ぐためだけではなく、CIツールでTerraformを使う場合に、CIツールで使うバージョンと、手元でPlanするバージョンを一致させる目的でも使用しますので、今回の対応に限らず、provider の version 設定は入れておく方がよいと思います。
まとめ
Google Provider 3.0.0 の変更点は、上記で説明した内容だけでなく非常に多くのリソースにおいて廃止された機能や必須属性の追加等があります。アップグレードを行う前に、アップグレードガイドを読みながら設定を更新していくのがよいと思います。
商用環境等、トラブル影響が大きいシステムですと、こうした非互換に対応するためのバージョンアップは大変ではあります。
しかし、GCPの機能は日々進化しているため、古いProviderを使い続けることはGCPのAPI仕様からの乖離が発生しリスクとなります。計画的にバージョンアップしていけるよう、準備していきましょう。