Fuwariを土台に、Astroで記事を作った#

土台に選んだのは、Astroのブログテーマ「Fuwari」です。記事はMarkdownファイルに書きます。冒頭にタイトル、公開日、カテゴリーを書き、その下に本文を続けます。

たとえば、コーヒー器具のお手入れの記事は src/content/posts/coffee-care/index.md にあります。書き直すときは、このファイルを編集します。ブラウザー上の管理画面は使っていません。

Astroで記事や一覧ページをHTMLに変換してから、Workers Static Assetsで配信します。読者がページを開くたびに、データベースから本文を取り出す仕組みは使っていません。

静的なブログをWorkersへ公開する方法は、CloudflareのAstroガイドにも載っています。

ただ、Fuwariを入れるだけで、このブログの今の状態になるわけではありません。日本語の記事、プロフィール、カテゴリー、画像の置き方をこのサイトに合わせて直しました。検索や公開前の検査も、テーマとは別に加えています。

記事を書いたら、PCでページを開きました。Markdownファイルを読んだだけでは、見出しや画像がどう並ぶか分かりません。

このブログでは、記事一覧のアイキャッチと、H2見出しの直下に置く画像を別々に作っています。入れ忘れがないかも、表示されたページで見ました。

サイト内検索にはPagefindを使っています。検索用データができるのはビルド時です。開発用の画面で記事が読めても検索は試せないため、ビルド後のプレビューを開きました。

ソースをGitHubに保存し、公開の起点にした#

記事や設定ファイルは、GitHubの非公開リポジトリに保存しました。非公開なのはソースです。完成したブログのページは、URLを知っていれば誰でも見られます。

作業を始めたころは、GitHubのアカウントもありませんでした。手元でブログを作り、アカウントとリポジトリを用意してから、Cloudflareへつなぎました。

公開に使うのは main ブランチです。PCで記事を直しても、それだけでは公開ページは変わりません。変更をGitに記録してGitHubへ送ると、Cloudflareの公開処理が始まります。

Gitに残した記録を見れば、後でどこを変えたかもたどれます。

PCのファイルを保存すること、Gitに変更を記録すること、GitHubへ送ることは別々です。サイトを直したのに公開が変わらないときは、どこまで進んだかを見ます。

PCには複数のサイトを置けるようにしています。その中で、Coffee BreakのGitリポジトリは独立させました。別サイトのファイルや公開先と混ざるのを防ぐためです。

公開先の取り違えを防ぐため、サイトごとに設定を分けた#

後からPC上のフォルダーを複数サイト用に整理しました。Coffee Breakは sites/coffee-break/ にあります。一方、GitHubのリポジトリには、このブログのファイルだけを置いたままです。

Cloudflareは、GitHubに置いたリポジトリの一番上の階層からファイルを読み込みます。PC上では sites/coffee-break/ に置いていますが、GitHubにはこのブログのファイルだけを送っているため、Cloudflareのビルドルートは / です。

サイトごとに設定ファイルを作り、GitHubのリポジトリと公開に使うブランチを書いています。Cloudflareのアカウント、Worker名、公開URLもここにまとめました。

このサイトでは site.config.json に接続先を書き、wrangler.jsonc にWorkerの設定を置いています。公開前に送信先を調べるスクリプトも用意しました。画面を開いて記憶を頼りに選ぶ回数を減らすためです。

別サイトはGitHubやCloudflareのアカウントが異なるかもしれません。Coffee Breakの接続先を、そのまま共通設定にはできません。

公開前には、設定ファイルとGitの送信先が合っているかを調べます。別のリポジトリやWorkerへ送ってしまえば、Coffee Breakは更新されません。サイトが増えた今は、送信先の名前まで見てから公開します。

Workers Buildsで、更新を公開へつなげた#

公開先には新しいWorkerを一つ作りました。既存のWorkerには触れていません。このWorkerにGitHubのリポジトリをつなぎ、main に変更を送るとビルドが始まるようにしました。

Workers Buildsでは、GitHubに変更が届くとビルドが始まります。必要なソフトを入れ、AstroをチェックしてHTMLを作る工程です。

続くデプロイで、Wranglerが生成済みのファイルをWorkerへ反映します。公式の設定資料にも、この流れが載っています。

ビルド時には、Astroのチェック、HTMLの生成、サイト独自の検査を順に行います。pnpm build ではPagefindの検索データも作ります。

Cloudflareの設定画面では、ビルドコマンドとデプロイコマンドを別々に入力しました。前者は公開するファイルを作り、後者はそのファイルをWorkerへ送ります。どちらか一方だけ終わっても、記事の更新は読者に届きません。

pnpm verify では記事や内部リンク、画像の代替テキストを調べます。pnpm secrets:check は、公開するファイルに秘密情報の既知のパターンが混じっていないかを調べるコマンドです。

**ビルド成功だけでは、新しいページはまだ見られません。**HTMLを作る工程と、Workerへ公開する工程は別です。Cloudflareの履歴では、対象のコミットがデプロイまで進んだかを見ました。

公開前にビルドと表示を確認した#

記事を追加するときは、まずPCで文章と画像を見ます。それから型チェックとビルドを行い、生成されたファイルを検査します。エラーがなくても、最後にプレビューで記事と一覧を開きます。

最初の4記事を揃えたとき、Astroの型チェックは通りました。ビルド後には記事と一覧のHTMLに加え、Pagefindの検索データもできていました。

生成物の検査では、記事数とページ数、サイト内のリンクや画像を照合しました。ページ自体ができても、リンク先が欠けていることはあり得るからです。

手元で実行するコマンドは次の四つです。Cloudflare側のビルドにも同じ検査を入れました。PCで通ってもCloudflare上で失敗することはあるので、GitHubへ送った後の履歴も見ます。

1
pnpm check
2
pnpm build
3
pnpm verify
4
pnpm secrets:check

アイキャッチは記事一覧のカードだけに表示します。記事ページの冒頭には出しません。代わりに各H2の直下へ、その話題に合う画像を置きます。

画像が読み込まれるか、スマートフォンの幅でもアイキャッチが横長に見えるかは、公開前に確認する項目です。

カテゴリー名は日本語、URLは英語にしています。たとえば「コーヒー」のURLは coffee。この記事には「ブログ運営」を新設し、URLは blogging にしました。

表示名だけを追加すると、カテゴリーのリンク先が意図しないURLになることがあります。新しいカテゴリーでは、名前とURLを一緒に設定します。

記事一覧に表示されたカテゴリー名を押して、対応する一覧が開くかも見ます。ファイルの中で「ブログ運営」と書けていても、リンクが違えば読者は記事をたどれません。

構築当初は、検索エンジンに載せないための noindex を付けていました。その後、この設定を外し、サイトマップを用意しました。検索結果に載るかどうかはGoogleの判断ですが、少なくともサイト側で掲載を止める設定は取り除いています。

GitHubアカウントの登録から始めた#

GitHubのアカウントを持っていなかったので、登録から始めました。ブログのファイルを保存し、Cloudflareとつなぐためです。

メールアドレスを入力したところ、Email domain could not be verified というエラーが出ました。使っていたのは hotmail.com です。

その後、アカウントは作れました。何がエラーの原因だったかは分かっていません。hotmail.com では登録できない、という意味ではありません。

ブログ用の非公開リポジトリを作り、サイトのファイルを送りました。Cloudflareが読み込むのは、このリポジトリの中身です。PCで記事を直しても、GitHubへ送るまでは公開に使われません。

登録時のエラーを越えても、Cloudflareとの連携でまた止まりました。GitHubへの登録と、二つのサービスの接続は別の作業です。どちらで止まっているのか、画面を見て切り分けました。

Cloudflareとの接続エラーを解消した#

Cloudflareの作成画面でGitHubとの接続を選ぶと、GitHubに認可画面が開きました。画面に出た名前は「Cloudflare Workers and Pages」。今回の公開先はWorkersです。

認可画面では、Cloudflareがアクセスできるリポジトリを選びます。Coffee Breakのリポジトリだけを対象にしました。

認可画面は別ウィンドウで開きました。許可する前にアカウント名と対象リポジトリを見ます。「すべてのリポジトリ」と「選んだリポジトリだけ」では、許す範囲が違うからです。

認可を進めた後、Cloudflareに「Gitアカウントへの接続エラー」が出ました。GitHubに入った連携アプリを確認し、今回のインストールを解除しました。Cloudflareの画面から接続をやり直すと、先へ進めました。

エラーの原因までは分かっていません。今回分かったのは、連携アプリを入れ直した後に接続できたことだけです。同じ表示が出ても、誰にでもこの方法が必要とは限りません。

同じエラーが出たら、まずGitHub側でアプリの状態と対象リポジトリを見てください。確認する場所はCloudflareのGit連携資料にも載っています。

すでに別サイトでも連携アプリを使っているなら、解除する前に影響を確かめる必要があります。

最初のビルドを止めて、権限を整理した#

GitHubとの接続後は、ビルドと公開に使うAPIトークンを設定しました。先に自分で作ったWorkers向けのトークンは、候補に出てきません。そこで、Cloudflareの作成画面からビルド用トークンを作りました。

表示された権限には、Workersのほかにデータベース、ストレージ、AIなども含まれていました。このブログでは使っていない機能です。そのまま公開を始める前に、権限を整理することにしました。

初回だけ、ビルドが途中で止まるようにコマンドを設定しました。Workerとトークンを作ってから、権限を直すためです。最初の履歴は「失敗」と出ましたが、このときは予定どおりでした。

通常のビルドコマンドの代わりに、終了コード1を返す短いコマンドを入れました。Cloudflare上では失敗の履歴になりますが、デプロイには進みません。権限を直す時間を作るための、一時的な設定です。

CloudflareのAPIトークン画面で、不要な権限を外しました。残したのは、アカウントに対する「Workersスクリプトの編集」と「アカウント設定の読み取り」です。

ただ、管理画面ではWorker一つにだけ権限を絞れませんでした。対象アカウント内のWorkersに及ぶ設定です。トークン名にブログの名前を付けても、操作できる範囲までブログ専用になるわけではありません。

公開先のWorker名は wrangler.jsonc に指定してあります。それでも、設定ファイルの公開先とトークンが操作できる範囲は別です。両方を見ておくと、権限を絞ったつもりで広く残してしまうのを防げます。

初回ビルドを止めたのは、今回の画面でトークンを作るために選んだ方法です。毎回必要な手順ではありません。公開を許す前に、そのトークンで何を操作できるかを見ることが肝心でした。

設定を戻し、デプロイ完了まで確認した#

権限を直したら、ビルドコマンドを通常の設定へ戻します。途中で設定画面を再読み込みした際、保存前の入力が消えたこともありました。控えていたコマンドと環境変数を入れ直し、保存内容を見ました。

トークンを編集した直後、Workerの設定画面では「利用できません」と出たこともあります。トークン一覧で有効なことを確かめ、設定画面を再読み込みすると、名前が正しく表示されました。表示だけで新しいトークンを作り直さずに済みました。

ビルドは、依存関係のインストールから始まります。Astroのチェック、HTMLと検索データの生成、生成物の検査が終わると、npx wrangler@latest deploy で公開します。

Cloudflareの画面では、ビルドが終わったところで閉じず、デプロイの完了まで見ました。

設定を戻した後は「ビルドを再試行」を使いました。ログで通常のコマンドに変わっているかを先に見て、最後にデプロイの成功表示を確認します。途中に Uploaded と出ても、それだけでは公開完了とは判断しません。

意図して止めた初回と、その後に成功した回は、同じ「ビルド履歴」に並びます。「失敗」の行が残っていても、それだけで現在の公開状態は分かりません。新しい履歴の日時とコミットを見て、どこまで進んだかを確かめました。

接続が済めば、記事を更新するたびに認可画面を開く必要はありません。変更を main へ送ると、Workers Buildsが動きます。

最初に決めた公開先とビルドコマンドは、その後の更新にも使われます。設定内容を残しておけば、次に更新が止まったときも見直せます。

所有していた nishikobe.com をWorkerに接続した#

nishikobe.com は、ブログを作る前から持っていたドメインです。Workerでサイトを公開できた後、このドメインをつなぎました。

迷ったのは、ドメインをどこまで使うかでした。coffee.nishikobe.com なら、元のトップページを残したままブログを追加できます。選んだのは nishikobe.com そのもの。以前のWebサイトをCoffee Breakに置き換える形です。

このドメインでメールは使っていません。そのため、今回はWebサイトの切り替えを中心に進めました。メールを使っているドメインなら、メール用のDNSレコードも確認が必要です。

Cloudflareにドメインを追加し、WorkerのCustom Domainとして nishikobe.com を接続しました。サイトの設定ファイルに書くURLも、同じ名前に変えます。記事の正規URLや案内先が、実際の公開先とずれないようにするためです。

Worker名を変えることと、訪問者が使うドメインを変えることも別の設定です。ドメインだけ切り替えて、サイト内に古いURLが残らないよう、公開URLを持つ設定ファイルも見直しました。

CloudflareのCustom Domains資料によると、Workerにドメインを割り当てる際は、必要なDNSレコードと証明書が用意されます。画面で接続状態を確かめ、Workerの初期URLはオフにしました。訪問者には独自ドメインを使ってもらう設定です。

Workers Buildsの最新の履歴は「準備完了」。それでも、nishikobe.com で正しいページが開くとは限りません。次はDNSを調べました。

DNSに旧サーバーの情報が見えた#

PCで nslookup を実行すると、以前のサーバーのIPv4アドレスが表示されました。同じ画面にはCloudflareのIPv6アドレスもあります。古い情報と新しい情報が混ざって見えました。

DNSは、ドメイン名から接続先を調べる仕組みです。ただ、nslookup の結果が一つあるだけでは、どこに古い情報が残っているか分かりません。Cloudflareの設定か、問い合わせ先のDNSサーバーか。すぐにレコードを削除せず、順に調べました。

まず見たのはネームサーバーです。これは、そのドメインの接続先を正式に答えるサーバーを指します。ドメイン登録先で指定した名前がCloudflareの案内と違えば、Workerの設定が正しくても届きません。

CloudflareのDNS設定資料にも、ドメイン追加後にネームサーバーを切り替える手順が載っています。

ネームサーバーを切り替えた直後は、問い合わせ先によって答えが違うことがあります。旧サーバーのIPが一度出たからといって、公開失敗とは決められません。次は問い合わせ先を指定して比べました。

問い合わせ先を変えて、DNSの切り替えを確認した#

Cloudflareの公開DNSと、このドメインに割り当てられたネームサーバーへ直接問い合わせます。PCで実行したのは次のコマンドです。

1
nslookup -type=A nishikobe.com 1.1.1.1
2
nslookup -type=A nishikobe.com margaret.ns.cloudflare.com

-type=A はIPv4の接続先を調べる指定です。二つ目の問い合わせ先は、このドメインに割り当てられたネームサーバーです。自分のドメインで試す場合は、Cloudflareの画面に出た名前に置き換えてください。

このとき、どちらの問い合わせにもCloudflareのIPv4アドレス 104.21.88.22 と 172.67.171.250 が返りました。先ほどPCで見た以前のサーバーの接続先は含まれていません。少なくとも、この二つの問い合わせではCloudflareの接続先が返った、という結果です。 ただ、ここでDNSの確認は終わりませんでした。Aレコードを問い合わせた時点では新しいIPアドレスが返っていましたが、ネームサーバーの応答は別の動きを見せたからです。

そこで、Cloudflareの公開DNSに対してNSレコードも調べました。

1
nslookup -type=NS nishikobe.com 1.1.1.1

NSレコードは、そのドメインのDNS情報を管理するネームサーバーを示します。最初の数回は uns01.lolipop.jp と uns02.lolipop.jp が返り、その後はCloudflareの margaret.ns.cloudflare.com と mike.ns.cloudflare.com が返りました。ところが、Cloudflareの名前が続いた後に、Lolipopの名前へ戻ることもありました。

数分の間に同じコマンドを何度か実行したところ、旧ネームサーバーとCloudflareのネームサーバーが交互に見える時間帯がありました。返答に含まれる二つの名前の順番も入れ替わりました。毎回同じ結果になるわけではなく、画面を見ているだけでは、どちらが最終状態なのか判断しにくい状況でした。

このとき、1.1.1.1のキャッシュ更新ページを開き、nishikobe.com のNSレコードとAレコードを更新しました。その後も同じNS問い合わせを続けると、Cloudflareのネームサーバーが何度も返る一方で、Lolipopのネームサーバーが返る回もありました。キャッシュ更新の操作だけで、すべての応答がただちに揃ったわけではありません。

ここで分かったのは、1.1.1.1に問い合わせたときの応答が、確認するたびに変わって見えたことです。なぜその切り替わりが起きたか、どのキャッシュや経路が関係したかまでは特定できませんでした。したがって、「キャッシュを更新すれば必ず直る」とは言えません。私は、キャッシュ更新後も数回に分けて照会し、返答の推移を記録しました。

確認するときは、AレコードとNSレコードを混同しないことも大切です。AレコードはIPv4の接続先、NSレコードはDNS情報を管理するサーバーを示します。Aに新しいIPが返っていても、NSの応答が落ち着いたとは限りません。両方を確認したうえで、実際のページ表示も別に見ました。

この結果だけで、すべてのDNSサーバーが切り替わったとは言えません。実際、1.1.1.1にネームサーバーを問い合わせると、旧サーバーの名前が返ることもありました。DNSの応答とブラウザーの表示は分けて確かめる必要があります。普段のブラウザーには、まだ古いサイトが出ていました。

シークレットウィンドウでは新サイトが表示された#

同じ https://nishikobe.com/ を、シークレットウィンドウで開いてみました。こちらには新しいCoffee Breakが表示されます。一方、普段のウィンドウでは旧サイトのままです。

シークレットウィンドウで開けたなら、独自ドメインから新サイトに届いています。通常のウィンドウだけ表示が違う理由は、ブラウザー側にもありそうです。

シークレットウィンドウは、普段のウィンドウに残った情報の影響を受けにくい状態で試せます。ただし、表示の違いだけで原因まで特定はできません。

シークレットウィンドウでも旧サイトが出るなら、DNSやCustom Domainの設定を見直すところでした。今回は新サイトが見えたので、まず通常のブラウザーを再起動しました。

ブラウザーを再起動すると、通常画面も新サイトになった#

ブラウザーを終了して立ち上げ直すと、通常のウィンドウにもCoffee Breakが表示されました。再起動で直ったことは確かです。ただ、旧サイトの表示にブラウザー内の何が影響していたかまでは調べていません。

振り返ると、「公開できたか」には少なくとも三つの確認がありました。ビルドが終わったか、DNSが向いたか、ブラウザーで開けるか。どれか一つを見ただけでは足りません。

次に同じ構成で作るなら、GitHubへ送った後のビルドとデプロイ、DNS、ブラウザー表示の順に見ます。記事ページまで開いて、ようやく公開の確認が終わります。

現在、Coffee Breakは独自ドメインから開けます。作ってみて難しかったのは、設定した後に「どこまで動いたか」を見極めることでした。同じところで止まった人は、ビルド、DNS、ブラウザーのどこで表示が変わるかを順に見てみてください。