Fastly Compute と DevOps, CI/CD (2) Terraform を使った構成管理
この記事は Fastly Compute 一人アドベントカレンダー 2024 19 日目の記事です。本稿では Compute と DevOps(CI/CD) という切り口のシリーズ第二回目として、Terraform を使った Compute サービスの構成管理の概要について紹介します。
本稿のねらい
Terraform を使って Fastly サービスを構成管理するノウハウや事例の記事は既に数多くインターネットで共有されていて、検索すると以下のような記事を確認することができます。
これらすべて参考になる知見が共有されていますが、これらは大体 VCL サービスの構成管理を目的とした記事が多く、Compute サービスの構成管理ついてはあまり触れられていない印象があります。そこで本稿では特に Fastly のサービスの中でも Compute に関係するリソースに焦点をあてて構成管理の方法について整理してみたいと思います。
Compute と Terraform
Compute は VCL に比べるとコードの中にロジックを多く含める分、サービスの設定値は少なくなる傾向にあるためその点では構成管理によって受けられる恩恵は VCL ほど多くないかもしれません。一方で、Compute 自体が VCL と組み合わせて（サービスチェインしながら）使われることも多いことや、 KV Store など各種永続ストレージと Compute サービスの Resource Link の管理が煩雑になりがちという側面を考えると、Compute を Terraformn で構成管理する一定の価値はやはりありそうです。
実際に下記 Fastly プロバイダのドキュメントを見てみるとわかるのですが、幸い、Compute サービスにおいて管理が必要になるリソースはそれほど多くなく、上記ドキュメントにサンプルも記載されているため難なく利用できます。
これらを利用した自分用のテンプレートを作成しておくと後々管理面で恩恵を受けれるようになるかと思いますので、ここでは以下の Compute に関係するリソースがすべて入った HCL を template.tf として作成しておきます。
terraform {
required_providers {
fastly = {
source = "fastly/fastly"
version = ">= 5.10.0"
}
}
}
provider "fastly" {
api_key = "<YOUR FASTLY API TOKEN>"
}
// variables
variable "service_domain" {
default = "mytest.edgecompute.app"
}
variable "backend_address" {
default = "httpbin.org"
}
variable "backend_name" {
default = "origin_0"
}
// stores
resource "fastly_kvstore" "example" {
name = "kvstore_${var.service_domain}"
}
resource "fastly_secretstore" "example" {
name = "secretstore_${var.service_domain}"
}
resource "fastly_configstore" "example" {
name = "configstore_${var.service_domain}"
}
resource "fastly_configstore_entries" "example" {
store_id = fastly_configstore.example.id
entries = {
key1 : "value1"
key2 : "value2"
}
}
// compute service
resource "fastly_service_compute" "default" {
name = var.service_domain
domain {
name = var.service_domain
}
backend {
address = var.backend_address
name = var.backend_name
use_ssl = true
port = 443
override_host = var.backend_address
ssl_cert_hostname = var.backend_address
ssl_sni_hostname = var.backend_address
}
package {
filename = "./pkg/my-first-project.tar.gz"
source_code_hash = filesha512("./pkg/my-first-project.tar.gz")
}
logging_https {
name = "stdout"
url = "https://my-test.glitch.me/endpoint"
}
logging_papertrail {
name = "stderr"
address = "logs.papertrailapp.com"
port = 99999 // put your real port number
}
resource_link {
name = "kvstore_${var.service_domain}"
resource_id = fastly_kvstore.example.id
}
resource_link {
name = "secretstore_${var.service_domain}"
resource_id = fastly_secretstore.example.id
}
resource_link {
name = "configstore_${var.service_domain}"
resource_id = fastly_configstore.example.id
}
force_destroy = true
}
このテンプレートの中で特筆しておきたいのは force_destroy=true フラグで、これによって Compute サービスの生成と破棄を高速にできるようになりますし、各種ストアに対する Resource Link の作成や紐付けも UI や CLI だと複数ステップ必要な部分が terraform であれば apply コマンド一発で済むので、Compute でもデプロイの体験がかなり良くなります。（コマンド発行後、実際にそのバージョンがデプロイされるまで 1 分前後かかる点には注意が必要ですが）
ついでに上記テンプレートに対応する実行コマンドもメモしておきます。
$ terraform apply -var "service_domain=my-first-terraform-deployment.edgecompute.app"
$ terraform destroy
まとめ
本稿では Compute と DevOps(CI/CD) という切り口のシリーズ第二回目として、Terraform を使った Compute サービスの構成管理の概要や Tips を紹介しました。先週の記事で Compute サービスから NGWAF を呼び出して扱う方法について紹介しましたが、NGWAF 自体も Terraform を用いて構成管理することに対応している（参考ブログ記事）ので、今回作成した Compute のテンプレートとあわせて管理することで WAF 含めた Compute サービス全体を構成管理することなどの応用も可能です。
次回は Compute と DevOps(CI/CD) という切り口のシリーズ第三回目として、GitHub Actions を使った CI/CD 環境の構築について概要を紹介します。
Discussion