VPSを解約してFirebase Hostingにブログを移した

タイトルの通り。なんとなく自分のサイトを自分で運用したいと思っている。それはWebエンジニアとしてのポートフォリオ的な側面もあるし、それに加えて、自分の書いた文章を自分の管理下におきたい欲求があるのだと思う。

サブブログを、はてなブログに持っていますが(https://blog.song.mu)、これもまた、コンテンツはblogsync を使って管理しています。

このサイトはもともとVPS上のNginxから静的配信されており、

• VPS上のgit bareリポジトリに直接push
• post-receive Hook で riji を呼び出してサイト再構築

という結構カッコいいフローを組んでいて 、これがなかなか気に入っていた。以下のような点が良かった。

• 国内のVPSへのgitリポジトリへのpushはかなり早い
  • GitHubへのpushに少し引っかかりを感じるレベル
  • とはいえコンマ数秒程度の違いでしかないんだけど
• VPS上でそのまま再構築と反映が行われるのですぐサイトが更新される

Markdownをコミットしてpushすればものの数十秒でサイトが更新されるのが嬉しかった。Nginxでの静的配信なので、リソースやパフォーマンス的にも問題なかった。

とはいえ、VPSを維持する労力やセキュリティ上の懸念もあった。アップデートパッチは自動で当ててしまっていたものの、たまのOS入れ替えがなんだかんだでダルかったし、サボりがちだった。

それに、この仕組みを構築したのはもう7年半前だが、今はホスティングサービスも選択肢が増えてきているし、サイト構築の自動化もGitHub Actionsなんかを使ってしまえばいいとは思っていた。しかし、構築済みのVPS一台で30秒以内で完結する今のリリースフローに比べると、複雑なCI/CDを組むと反映時間がかかってしまいそうなのがネックに感じていた。

とはいえ、VPSも古くなっており、アップデートが必要な状況で放置していたので、年末年始で重い腰を上げて移行作業をした。

サイト移行

紆余曲折あったが結果的にこうなった。

• リポジトリをGitHubに移す
• RijiをDocker化する
• GitHub Actionsでサイト構築
• Firebase Hostingへのサイト反映

GitHub Actionsのstep部分を一部抜粋して公開用に調整すると以下のような感じ。

steps:
  - uses: actions/checkout@v2
    with:
      fetch-depth: 0
  - name: Build
    run: |
      docker run --rm -e TZ=Asia/Tokyo -v $(PWD):/riji -v $(PWD)/.git:/riji/.git ghcr.io/songmu/riji:latest publish
      mkdir public
      mv ./riji ./public/riji
  - uses: FirebaseExtended/action-hosting-deploy@v0
    with:
      repoToken: '${{ secrets.GITHUB_TOKEN }}'
      firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT_SITENAME }}'
    ...

docker runで./rijiディレクトリにサイトが出力されるので、それをpublicディレクトリに移してから、それをFirebase Hostingにdeployしている。

ちなみに、fetch-depth: 0にしたり、docker runで.gitをマウントしているのは、Rijiがgit logからRSSを出力するシステムであるため。

Docker化で環境構築の時間を短縮できたので、これで大体1分程度でgit pushからサイト反映されるようになった。流石に少し遅くなったが、許容範囲。

Firebase Hosting

ホスティングサービスは幾つか検討したが、結局使い慣れているFirebase Hostingに落ち着いた。

以前に比べてGitHubとの連携が楽になっていて感心した。firebase init hostingを叩くと、GitHubから情報をとってきて、サービスアカウントを自動で作ってそこからトークンを発行してリポジトリのSecretに登録して、GitHub ActionsのYAMLの雛形を生成するところまでやってくれた。

それに加えて感心したのは、サイトの引っ越しについてもケアされていて、サイトをいきなり切り替えたときに、SSL証明書のエラーが出ないように、事前にSSL証明書を出しておいて、それからDNSのAレコードを切り替えると言うフローも用意されていたことだ。この時ACMEプロトコルのフローを、手動でDNSのTXTレコードを設定する必要があったのはちょっと面白かった。

無料プランだと月に10GBの転送量制限があり、場合によっては厳しくなることがありそう。ただ、幾ばくかの料金を払うことはやぶさかではないし寧ろ払いたい。

Cloudflare Pages

実は最初はCloudflare Pagesが本命だった。使ったことなかったので興味があったし、料金も安い。試用した感じかなり使い勝手も良く、気に入ったが、フィットしない点が幾つかがあって残念ながら断念した。

一番困ったのは「拡張子 .html を勝手に削ってしまう」ということ。

If an HTML file is found with a matching path to the current route requested, Pages will serve it. Pages will also redirect HTML pages to their extension-less counterparts: for instance, /contact.html will be redirected to /contact, and /about/index.html will be redirected to /about/. --https://developers.cloudflare.com/pages/platform/serving-pages#route-matching

上に書いてあるように、 /contact.html が /contact になってしまうのは、このサイトの過去のURLも変わるので困るし、サイトのポータビリティを考える上でも微妙なので諦めた。

あと細かいネックとして以下のような点があった。

• ビルド環境にdockerコマンドが入っていない
• previewブランチの制御が細かくできない

Cloudflare PagesはCloudflare上のビルド環境でサイトをビルドしてくれて、ここにはいろいろなツールが入っているのだが、ここにdockerコマンドが残念ながら入っていなかった。ちなみにmakeは入っていた。

なので、独自のCMSを動かすという用途では使いにくい。これに関しては、GitHub Actions等で事前にビルドしたものをどこかに置いておくといった方法で解決できるが、ピタゴラ装置にはなる。

あとは、GitHubとの連携機能でpushを契機に自動的にサイトをビルドしてくれる。mainのブランチ以外でもプレビューサイトをビルドしてくれて事前確認ができる。これ自体は素晴らしいのだけど、このプレビュービルドを制御する方法が提供されていない。

つまり、一応ブランチを作ってからマージするフローを取ったときに、ブランチのビルドをする必要がない場合も、勝手にビルドしてしまって、ビルドキューを詰まらせてしまう。これは少し困る。これは以下でも議論されている。

https://community.cloudflare.com/t/disable-preview-publishing-on-pages/252329

これは、自動ビルドを切って、APIを使ってビルドを自分で制御すれば解決できるのかも知れない。それに関連して、ビルド環境のspin upも少し遅いのも気になった。

色々難点を書いてしまったが、Cloudflare Pagesは体験も良かったし、今後に期待できる。また新規でサイトを構築する場合には今でも最有力の選択肢になると思う。

とにかくGitHub連携が簡単で、GitHub ActionsのYAMLなども置く必要がなく、権限を委譲すれば後はよしなにやってくれる。

カスタムドメインのためにネームサーバー渡す必要があるけど、そのときに既存の設定を吸い出してくれて、あとはいい感じに設定してくれるのもよかった。CNAME Flatteningに対応しているのもカッコいい。

あとは、Cloudflareならではの各種CDN機能との連携が提供されているのも嬉しいポイント。

サイトのURL体系にしても新規サイトであれば気にならないし、機能不足にも感じる部分も、新しいサービスであるので逆に「最適なデフォルト」をいい感じに提供しているとも言える。全体的に必須の設定が少ないので混乱が少なく、いい感じにやってくれるので好印象でした。

その他

• Google Analyticsの古いタグを埋め込んでいたがGoogle Tag Managerを導入して、旧Google AnalyticsとGoogle Analytics 4を併用するようにした
• GitHub Pagesも検討したが、https://junkyard.song.mu で既に使っているのとsongmu.jpのAPEXドメインを使いたかったこともあり選択肢から外した。(やりようはあるとは思う)
• GitHubにリポジトリを移すと、今後書きたい記事とかもissue管理できるので良い
• VPSは10年以上契約していた。本当にお世話になりました。個人で手軽に手頃にVMを飼えるというのは当時は革命的だった
• 移行後にSSL証明書更新失敗のアラートが飛んできた。これはVPSで動かしていたcertbotのプロセスがコケたことによるもの。ちゃんとアラートが飛んできて偉い。どんどんマネージドに寄せてしまっているけど、こういうのを色々自前で組んでいたのは楽しかった
• Mackerelのアンバサダープランを使わせてもらっているのだけど、サイト移行時に外形監視のアラートが適切に飛んできてよかった。VPSを使わなくなるので監視項目は減ってしまうけど、引き続き便利に利用させてもらえると嬉しいです
• VPS上に動的なコンテンツも一部あったのだが、それらは諦めることにした。とくにデイリーポータルビューワーは長らく省力で維持してきたが、公式でライター別ページも提供しているのでもう良いだろうということで閉鎖した。
• 大学時代に書いていた黒歴史気味の日記もしれっと消した。gitの履歴上には残っている