Zenn
🍁

2021年秋のgocon.jpのサイト構成

2021/11/20に公開
Web
tech

Go Conference 2021 Autumnの開催に先立ち、 https://gocon.jp/ のホスティング周りの構成を変更しました。特に大きな変更はFirebase HostingからGitHub Pagesへの切り替えです。

このテキストでは2021年秋時点の https://gocon.jp/ の構成とその背景を説明します。今後運用していくメンバーの参考になればと思います。

変更前の状況

2021年秋に向けての要件

  • イベントごとに https://gocon.jp/{year}{season}/ のような形式でページをサブディレクトリに配置したい
    • サブドメインよりもサブディレクトリで分けるほうがURLとして自然に感じるという意見が多数派だった
    • 他のイベントでもサブディレクトリを採用している例が多そう
  • イベントページはシーズンごとに独立して管理・更新したい
    • 「2022年春のサイトを更新するためには他シーズンのサイトもすべてビルドしないといけない」といった状況は避けたい
    • 「2022年春と2021年秋のデプロイ処理が競合して、一方の変更が反映されなかった」といった状況も避けたい
  • （これまでと同じく）静的なウェブサイトをホスティングしたい
  • （これまでと同じく）ウェブサイトの生成元データはGitHubで管理したい
    • mainブランチにpushしたらgocon.jpが自動で更新されてほしい

Firebase Hostingの問題とGitHub Pagesのカスタムドメイン機能

Firebase Hostingはドメイン単位でのホスティングを前提としたサービスなので、サブディレクトリ単位での更新はできません。すべてのサブディレクトリを手元に集めてからまとめてデプロイする必要があります。

ひとつの解決策としては、GoCon/gocon.jp のような集約用のリポジトリを作り、GoCon/2021springやGoCon/2021autumnのようなサブディレクトリに相当するリポジトリのmainブランチが更新されたら、GoCon/gocon.jpを自動で更新する、という方法が考えられます。

が、GitHub Pagesの「ユーザまたは Organization サイトのカスタムドメイン」機能を使うとサブディレクトリ単位のデプロイがシンプルに実現できるので、これを採用することにしました。

この機能をかいつまんで説明すると、

  1. Organizationサイトのリポジトリ（https://github.com/GoCon/gocon.github.io）にカスタムドメイン（gocon.jp）を紐付けると
  2. 他のリポジトリのGitHub Pagesが自動的にカスタムドメインのサブディレクトリにホストされる

という機能です。

一度カスタムドメインを設定しておけば、あとは通常通りにそれぞれのリポジトリでGitHub Pagesを運用するだけ（CI/CDパイプラインでサイトをビルドしてgh-pagesブランチにpushするだけ）なので、初期設定や運用はごくシンプルになります。

変更後の構成

GitHub Pagesのいいところ

  • 「ユーザまたは Organization サイトのカスタムドメイン」機能が要件にうまくマッチした
  • GitHubだけで完結するので設定が楽
  • 全機能が無料で使える（ありがとうございます！）

GitHub Pagesの気になるところ

いずれも今回のケースでは大きな問題にはなりませんでした。

  • ホスティング機能は必要最低限
    • URL rewrite機能がない
      • SPAとかで必要になりそう
      • ひとまず素朴なHTMLでやっていこうという流れっぽいので当面は問題なさそう
    • HTTPのキャッシュ期間が10分と短い
      • Lighthouseで警告が出る
    • FastlyやCloudflareなどのCDNをかぶせればカバーできる？
  • 「PRごとにステージング環境を用意する」的な機能はない

GitHub Actionsを選択した理由

  • 「HugoでビルドしてGitHub Pagesにデプロイする」という処理であれば、設定ファイルの記述量や実行速度はCircleCIと同等
  • どちらかといえばGitHubだけで完結するほうが楽
  • GitHub Actionsならリポジトリ新規作成時の初期設定が省ける

検討したホスティングサービスなど

Firebase Hosting

  • 安くて機能も充実している
  • が、前述のようにプロジェクトをドメイン単位（もしくはサブドメイン単位）でしか管理できないので選外とした

Netlify

  • 同じくドメイン単位でしか管理できない
  • メンバーの人数を基準にした料金体系が今回のチーム構成と合わなかった
  • Deploy Previewsは便利そう

サブドメインにホストしてサブディレクトリにURL rewriteする

他イベントの事例

JSConf.jp

https://jsconf.jp/の事例。

  • リポジトリはhttps://github.com/jsconfjp/jsconf.jp/
  • Go Conferenceの今回の構成に近い
    • URLはサブディレクトリ方式
    • ホスティングサービスはGitHub Pagesらしい
    • PRのプレビューページのホスティングはNetlify
  • 違うところ: jsconf.jpリポジトリに開催年度ごとのサブディレクトリを作り、それぞれを独立してビルドできるようにしている
    • 今年度のイベントだけはpush時にビルドしてデプロイする
    • 旧年度のイベントはある時点で更新を止めて、あらかじめコミットしておいたスナップショットをデプロイする

日本Rubyの会

RubyKaigiの開催や地域Ruby会議の支援を行っている日本Rubyの会の事例。

  • https://github.com/ruby-no-kai/rko-router
    • 前段にnginxを配置して、各所のGitHub PagesやHeroku appにproxy_passしている
    • 地域Ruby会議のページの実体は各地域のGitHub Organizationのページに持たせながら、regional.rubykaigi.orgのドメインからアクセスできるようにするようにしているらしい
      • サーバーやドメインの管理権限を各組織に移譲しなくていいので管理コストが抑えられてそう

おわりに

サイト構成の検討にあたって、ymotongpooさん、micchieさん、tenntennさん、mikiさんをはじめ、Go Conference運営スタッフの皆さんからご助言をいただきました。ありがとうございます。

Discussion