ブログを Cloudflare Pages から Workers へ乗り換えました

どうも白澤です。

バタバタとギリギリで決算書類と申告書類を作って提出して納税まで終わらせられたので、一旦心に落ち着きを取り戻しました。本当に学生時代の宿題と同じように放置グセがあると良くないですね。なんなら自分は学生時代は長期休暇の課題は間に合わなさそうなら諦めるタイプだったので、同じような感覚でいると痛い目を見ます。

せっかく会社作って 5 年経過したので、会社やっててどうなの？みたいなことも発信していければと思っています。ブログでも YouTube でも。

さて。なんだかブログ環境の話ばかりしている気がしますが、今回は Cloudflare Pages から Workers へ移行した話です。

なぜ移行したか？

単純な話、Cloudflare 公式で Workers に乗り換えないかい？というお知らせをいろんなところで出していたからです。

管理画面で Pages プロジェクトを開くと、上部にこんな感じのメッセージが出ていたり。

Cloudflare Pages to Workers

また、Cloudflare の社員さんも X で基本 Workers でいきましょう、みたいな感じの話をしていたり。

一回コーポレートサイトを Workers に移行しようとしてみたことがあったのですが、現時点ではコーポレートサイトは Next.js で実装されていて、OpenNext ↗ を使ってビルド・デプロイする感じになるのですが、コンパイルサイズがデカすぎて（これは多分自分のせいだが）Workers の制限に引っかかってしまい、移行を断念していました。

それに対してブログは Astro で実装されていて、ビルドサイズも小さめなので、多分大丈夫やろ、ということで移行してみることにしました。

移行の手順

簡単です。Cloudflare ↗ や Astro ↗ の公式ドキュメントを参照すれば良いだけ。

引っかかった（と言うほどでもないが）点としては、Pages 前提での wrangler.jsonc 設定項目があったので、それを修正しないとデプロイできなかったです。

{
  "$schema": "node_modules/wrangler/config-schema.json",
  // ...
  "pages_build_output_dir": "dist" // これが邪魔
  // ...
}

あまりハマるポイントはなかったですね、Astro はこういう面倒ごとが少ないところも大好きです。

管理画面まわり

ファーストインプレッション

Workers に移行したことで、管理画面が Pages のものから Workers のものに変わります。同じ Cloudflare の管理画面上なので、そこまで大きくは変わりませんが、Pages だと思って操作すると最初は違和感があるかもしれません、まあ別物だからね。

一覧表示で既にちょっと違う。上が Pages のプロジェクト、下が Workers のプロジェクトです。

Workers 一覧画面

Pages の管理画面はこんな感じでした。

Pages 管理画面

Workers の管理画面はこんな感じ。

Workers 管理画面

まず初期画面のタブが違う。Pages では Deployments が初期タブでしたが、Workers では Metrics が初期タブになっています。Deployments が初期タブではなくなったことで、デプロイの履歴を確認するのが少し面倒になりました。1 つ前の Workers 一覧ページを見ればわかることではありますがどうなんでしょう。慣れれば大丈夫かな。

ドメインまわり

Pages の時はデフォルトドメインである *.pages.dev ドメインが自動で設定されていて、かつ使用停止にすることができませんでした。Workers では同じように *.workers.dev ドメインが自動で設定されますが、こちらは使用停止にすることができます。

ここでちょっとだけトラップ。デフォルトの *.workers.dev ドメインを管理画面から disabled にできるのですが wrangler.jsonc の設定で workers_dev を false にしないと、次のデプロイ時に設定がリセットされてしまいます。実はこれはドキュメント ↗に書いてるんですねー。

If you disable your workers.dev route in the Cloudflare dashboard but do not update your Worker’s Wrangler file with workers_dev = false, the workers.dev route will be re-enabled the next time you deploy your Worker with Wrangler.

リセットされて、「あれ？戻ってる。でもこの挙動絶対おかしいから wrangler.jsonc でいじれそうだな」と思ったら案の定でした。設定で false にしておくと管理画面上でも disabled のままになります。逆に管理画面上で enabled にできるようになるので、多分これは検証用とかで *.workers.dev を使いたい時でも管理画面からいじって使うことができるようになっているのかなと思います。ここはカスタムドメイン設定したらデフォルトを disabled に自動でしておいてほしい気持ちがちょっとしますね。

まとめ

Next.js で引っかかったことからあまり乗り気がしなかった Workers への移行ですが、Astro であれば特に問題なく移行できそうですね。多分 Pages よりも Workers の方がこれからサポートが手厚くなると思うので、今後に期待って感じです。

様子見て Next.js も Workers にちょっとずつ移行してみたいと思います。実は結構 Next.js + Cloudflare Workers の組み合わせのプロジェクト結構あるので、軽めのものからチャレンジしてみようかなと思います。

おまけ: 画像アップロード用シェルスクリプト書いた

ブログ記事内で使っている画像は Cloudflare R2 にアップロードしているのですが、毎回手動で圧縮してアップロードするのが面倒だったので、シェルスクリプトを書きました。

#!/bin/bash

set -e

BUCKET_NAME="バケット名"
BUCKET_TARGET="バケット内のパス"
REMOVE_FILE="true" # 処理後にオリジナルファイルを削除するかどうか

INPUT_FILE_NAME="$1"
TARGET_DIR="$2"
UPLOAD_NAME="$3"

# png なら lossless にして、それ以外は普通にやる
if [[ "$INPUT_FILE_NAME" == *.png ]]; then
  cwebp -lossless "$INPUT_FILE_NAME" -o "tmp_$UPLOAD_NAME"
else
  cwebp -q 80 "$INPUT_FILE_NAME" -o "tmp_$UPLOAD_NAME"
fi

bunx wrangler r2 object put "$BUCKET_NAME/$BUCKET_TARGET/$TARGET_DIR/$UPLOAD_NAME" --file="tmp_$UPLOAD_NAME" --remote

rm "tmp_$UPLOAD_NAME"

if [[ "$REMOVE_FILE" == "true" ]]; then
  rm "$INPUT_FILE_NAME"
fi

使い方はこんな感じ:

bin/conv "画像ファイル名" "アップロード先ディレクトリ" "アップロードするファイル名"

こうするだけでもだいぶ楽になりました。まだ管理方法は確定していないので暫定的なものですが、しばらくこれになりそうかな、、、