monolithic kernel

Blog のホスティングを Firebase Hosting に乗り換えて GitHub Actions で自動デプロイするようにした

October 19, 2019

    表題の通りのことをした。

    以前は Netlify を利用していて、機能面では何ら不満はなかったのだが、CDN を使っているという触れ込みの割にページのロードが遅いのが若干気になっていた。無料なのでそれくらいは仕方ないかと思っていたのだが、調べてみると、Firebase Hosting の無料枠で自分のブログくらいなら足りそうで、速度的にも評判がよいことが分かり、かつ今更ながら気になっていた GitHub Actions を使えば CI/CD も割と簡単に実現できそうだったので、サクッとやってみた。

    結果としては、特に躓くこともなくアッサリ移行できた。さすがに Netlify ほどの簡単さではなくなるが、すでに GitHub Actions で Firebase を使うための Action が公開されていて、これを使うだけだった。

    Workflow の設定例まで書いてあって、これが分かりやすいので、ほんとにコピペして調節するだけ。設定ファイルのフォーマットが分かりやすいのもよいと思った。

    あと Netlify から Firebase Hosting への移行だと、リダイレクトやカスタムヘッダの設定を移したくらい。

    最後に Certificate を発行して DNS の A レコードを切り替えればおしまい。いきなり A レコードを切り替えてしまうと、Certificate が発行されるまでの数時間の間、証明書がなくておこられることになるので、その点は注意が必要。最初に練習でやってみた別サイトでやらかした。

    移行してみて、速度については割とどうでもよくなって、GitHub Actions よさげだなということのほうが印象に残っている。個人で使う観点だと、Private リポジトリにも無料枠があって、それを超えた場合の課金体系も従量課金で手を出しやすいのもありがたい。まだ足りない部分はあるものの、GitHub からこれだけ手軽に使えると、他の CI ツールベンダーはどうなってしまうのだろう……。

    2019-12-21 追記

    GitHub Actions が Private リポジトリでは一定以上の利用は有料になることに関しては分かっていたのでよいのだけど、ワークフロー間でのデータの受け渡しのためにアーティファクトとして書き出す必要があるのと、アーティファクトを自由に消せないのとの合わせ技によって、あっという間にストレージを食いつぶしてしまい、どうにもできなくなったので使うのをやめた。

    今は GCP の Cloud Build にしている。同じ Google のプロダクトというだけあって、サービスアカウントに権限を付ければ token 不要で簡単にデプロイできてよい。