Fastly Compute と DevOps, CI/CD (3) GitHub Actions を使った ビルドとデプロイ
この記事は Fastly Compute 一人アドベントカレンダー 2024 19 日目の記事です。本稿では Compute と DevOps(CI/CD) という切り口のシリーズ第三回目として、GitHub Actions を使った Fastly Compute サービスのビルドとデプロイについて概要を紹介します。
GitHub Actions for Compute の使い方
Fastly Compute では Compute サービスをビルド・デプロイするための GitHub Actions が用意されています。
使い方は以下の通りです。GitHub リポジトリの中で以下のファイルが .github/workflos フォルダに yaml 拡張子で保存されていれば動作します（以下は Go 言語の例ですが、Rust や JS も同様に動作します。別言語の例は README や開発者ドキュメントに記載されていますのでそちらを参照してください）
name: Deploy Application
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install Go toolchain
uses: actions/setup-go@v5
with:
go-version: "1.23" # WASI サポートのために 1.21 以降の指定が必須
- name: Deploy to the Compute platform
uses: fastly/compute-actions@v5
env:
FASTLY_API_TOKEN: ${{ secrets.FASTLY_API_TOKEN }}
本 GitHub Actions の中身を見ると分かるのですが、この Actions は内部的に fastly の cli をダウンロードし、$fastly compute build や $fastly compute deploy 等のコマンドを実行しているだけのシンプルな作りになっています。ということで、本 Actions の動作には cli の動作に必要な fastly.toml の中身が重要になってきます。
注意点: fastly.toml の一部内容を確定してから使うこと
ここでこれまであまり触れてこなかった fastly.toml の話をします。fastly.toml は fastly コマンドが動作するために必要な情報が入った設定ファイルで、コマンド実行時に読み込みだけでなく書き込みされることもあります。例えば以下のような fastly.toml が Rust のスターターキットで確認できます（source）。
authors = ["<oss@fastly.com>"]
description = "An empty starter kit project template."
language = "rust"
manifest_version = 3
name = "Empty starter for Rust"
[scripts]
build = "cargo build --bin fastly-compute-project --release --target wasm32-wasi --color always"
プロジェクトを初期化した時点では上記のような内容ですが、その後 $fastly compute publish を行うと以下のように内容が書き変わっていることが確認できるはずです。大分書き換わりますね😅 （個人的にはあまり大幅に書きかわらないのが好みですが・・）
# This file describes a Fastly Compute package. To learn more visit:
# https://www.fastly.com/documentation/reference/compute/fastly-toml
authors = [""]
cloned_from = "https://github.com/fastly/compute-starter-kit-rust-empty"
description = ""
language = "rust"
manifest_version = 3
name = "example-project-name"
service_id = "BqKJHuUd1FoDzUmi2KB7a4"
[scripts]
build = "cargo build --bin fastly-compute-project --release --target wasm32-wasi --color always"
この中で最も重要な変更点はデプロイ後に service_id の項目が追加されている点です。この service_id は、fastly.toml の公式リファレンスによると以下のように説明されています。
The Fastly service ID of the service to which the fastly CLI should deploy the package. If not specified, a new service will be created when the project is deployed.
要約すると、この service_id の値が指定されているかどうかで fastly compute deploy または fastly compute publish コマンドの動作が以下のように変化すると記載されています。
- service_id 未指定→新しい Compute サービスが新規作成される
- service_id が既に存在→指定された service_id に対してサービスがデプロイされる
通常 Compute サービスの開発を始める際に $fastly compute init コマンドを使ってプロジェクトを初期化（あるいは先日 Fastly ブログで告知があった npm init @fastly/compute コマンドで JavaScript/TypeScript プロジェクトを初期化）することが多いと思うのですが、先ほど見たようにその際に用意される fastly.toml にはどれも service_id は存在しない状態で開発がスタートします。この service_id はそのプロジェクトの初回デプロイを経て初めて確定しますので、ローカルで一度もデプロイせずに service_id を確定しない状態で今回紹介した Compute 用の GitHub Actions を使い続けると、GitHub に git push する毎に毎回サービスが生成されてしまいます。
当然ながら一つのサービスをインクリメンタルに使い続けていくのが基本的な Compute サービスの使い方になりますので、今回の Actions を利用する際には初めに service_id を確定することが必要になることを覚えておいてください。
まとめ
本稿では Compute と DevOps(CI/CD) という切り口のシリーズ第三回目として、GitHub Actions を使った Fastly Compute サービスのビルドとデプロイについて概要を紹介してきました。本シリーズで紹介した各種テストの書き方や Terraform を使った構成管理のテクニックを併せて使うことで手軽に高度なエッジコンピューティング用の CI/CD パイプラインを実現することが可能になりますので、プロジェクトの状況に合わせて適切な取り組みを検討することがあれば、本シリーズの内容を参照してもらえたら嬉しいです。
次回は昨年紹介したFastly Compute を便利に使う Tips のシリーズ第四回目として、 aws-sdk-go-v2 を使った AWS サービスの操作について概要を紹介します。
Discussion