このブログのシステム構成についてのメモ
全体
ひとまず全体図
運用としては以下のような感じ
- ローカルマシン上の Hugo プロジェクト用リポジトリで記事書いて commit
- GitHub 上のリモートリポジトリに push
- ( push をトリガーに GitHub Actions が起動して、その中で Hugo での公開用として生成されたものが公開用リポジトリに push される)
- 公開用リポジトリは GitHub Pages で公開していて、
blog.shida-ws.net
というドメインでアクセスして見る
各コンポーネント
記事作成
記事に関しては Hugo で書いていて、 GitHub でリポジトリ管理している。
最初は適当なレンタルサーバ借りるなり、AWS で EC2 立てて入れるなりで WordPress を動かすことを考えていたが、 色々調べてる中で SSG (静的サイトジェネレータ)なるものがあることを認識し、良さそうと思ったため方針変更した。
- サーバのスペック(コスト)のことをあまり考えなくて良い
- 静的ファイルの配信になる(アプリケーションが動かない)ので大したスペックいらないし、そういった用途向けの安いサービスも色々あるはず
- 記事の作成部分も基本テキストエディタが動けば良いし、調べた感じサイトファイルの生成部分もネックになることはなさそう
- セキュリティのこともあんまり考えなくて良い
- 管理部分と公開部分を分けられるので、配信環境に公開するファイルを置いてしまえばそれ以上やることがあまり無い
- バックアップのこともあんまり考えなくて良い
- 生成サイトの元になるSSG用のファイルを Git 管理してしまえばそれで良さそう
- ローカルリポジトリとリモートリポジトリで一応冗長できている
- 変更履歴的な意味ではコミットログがそのまま使える
- 生成サイトの元になるSSG用のファイルを Git 管理してしまえばそれで良さそう
SSG として Hugo を選んだことについて大した理由は無い。
- 軽く調べた感じサイト生成の処理が速いらしいとというのを見ていた
- いくつか試そうと思っている中で、最初に触った感じすんなりいって不満もなかった
- 触ったのは QuickStart くらいの内容と
config.toml
を少し弄ったくらい
- 触ったのは QuickStart くらいの内容と
気が向いたら他のものも試して比較してみようと思う。
Hugo の設定について
- テーマは 公式 にあった中から見やすいと思ったものを選んで設定だけ弄って使っている
- 使っているテーマは Mainroad (サイトのフッターにも出てるが)
- そのうちテーマのカスタマイズや、オリジナルのテーマも作ってみたい
- 記事は日付と記事タイトルのみで階層化して、全部
posts
の下に置いていく形にしている- セクションやカテゴリはあまり理解できてない気がするので、もう少し記事が増えてから改めて調べて考えたい
- 記事の Markdown までのパスは
contet/posts/2022/09/08/archtecture-of-this-blog/index.md
のような感じにしている- Markdown と画像ファイルを同じディレクトリで扱うため Page Bundle の仕組みを使っている
サイトホスティング
サイトのホスティングについては GitHub Pages を使っている。
- しばらく無料で使えそう
- キャパシティ的な制限はいくつかあるが後述
- カスタムドメインを使えるのと、 Let’s Encrypt での証明書の取得もやってくれる
- GitHub 内で完結する
- 最初からあんまり色んなサービス連携させて考えること増やしたくない
- なんとなく構成としてキレイな気がする
辺りが主な理由。
また、 GitHub Pages で公開するリポジトリは記事を書いている Hugo プロジェクトのリポジトリとは分けている。 記事を書いているリポジトリの中に静的ファイルを生成してしまって、生成したディレクトリをトップページとして公開する運用もできそうだったが、 後述する制限に引っかかって GitHub Pages から別の何かに移すとなったときに分けておいた方がやりやすそうと思ったため。 制限自体に引っかかりにくくなりそう、というのもある。
GitHub Pages の制限
- GitHub Pages で公開するリポジトリのサイズは 1GB 以下を推奨
- 帯域制限として100GB/月
- サイトのビルドは10回/時間、ただし GitHub Actions を使ってビルドする場合は適用されない
- GitHub Pages のサービス品質維持のために速度制限がかかる場合がある、その場合は HTTP ステータスコード 429 で説明用のページが表示される
制限オーバーした場合はサイトが公開できなくなったり、サポートから対応を促す丁寧なメールが届くらしい。
利用に金払っているわけでも無いので、メールが来たらすぐ対応できるように切り替え先は早めに試しておこうとは思っている。 切り替え先の候補としては Netlify 辺りを考えている。
記事作成リポジトリと配信リポジトリの連動について
GitHub の記事作成リポジトリへの push をトリガーに GitHub Actions が起動して、配信リポジトリに push される様にしている。
記事を Hugo で書くと決めたタイミングでは、手元で生成して手動で push する感じを想定していたが、調べたところ割と簡単にできたので採用した。
やったこととしては、
- リポジトリ間での push のための認証設定
- 記事作成リポジトリの Secret として秘密鍵配置
- 配信リポジトリの Deploy Keys として対応する公開鍵配置
- GitHub Actions の設定
- 記事作成リポジトリへの GitHub Actions 設定ファイル(
.github/workflows/gh-pages.yml
)の配置
- 記事作成リポジトリへの GitHub Actions 設定ファイル(
設定ファイルについては GitHub の公式ドキュメントの サンプル がほぼそのまま使えた。(一番下の数行を書き換えたくらい)
ドメイン
ドメインについては、取得、ホスティングともに AWS Route53 で行っている。 今のブログの構成で唯一金が掛かっている部分。
カスタムドメインにする必要はなかったが、自由に使えるドメイン1個くらい持ってれば今後何か試す時に使えるかなくらいの理由でドメインは取ることにした。
お名前.com とどっちかくらいで考えたが、以下辺りを考えた結果 AWS Route53 にした。
- 構築手順などを記録に残したかったので、 CLI が使えるAWSの方が都合が良かった
- お名前.com については仕事で使っていたが、あまり良いイメージがなかった
- お名前.com というよりは GMO ではあるが
- 金額的にはお名前.com の方が安かったが、許容できる金額ということで他を優先した
- お名前.com だと初年度のみ安い( .net ドメインの場合約1,600円/年のところが1円/年とかになる)
- Route53 だとドメインのホスティングやクエリベースの課金もあるが、正直今気にするものでも無いと判断した
GitHub Pages での公開ドメインについて
GitHub Pages でリポジトリを公開する際、デフォルトドメインの場合とカスタムドメインの場合でアクセスの仕方が少し変わる
- デフォルトドメイン
- カスタムドメインを設定しない場合は
<GitHubのアカウント名>.github.io
というドメインで公開される - 実際にブラウザ等でアクセスする際は
https://<GitHubのアカウント名>.github.io/<リポジトリ名>/
が公開するリポジトリのトップページになり、リポジトリ名をURLをに含む形になる - DNSの設定自体は GitHub 側でやってくれてるので利用者側でやることは無し
- カスタムドメインを設定しない場合は
- カスタムドメイン
- リポジトリ毎の公開設定としてカスタムドメインを指定することもできる
- カスタムドメインの場合、実際にアクセスする際は
https://<カスタムドメイン>/
がトップページになり、リポジトリ名は含まない - 利用者側でのDNSサーバの設定としては、リポジトリを公開するドメインのCNAMEを
<GitHubのアカウント名>.github.io.
に向ける設定をする
また、GitHub Pages でカスタムドメインを使っている場合もチェックボックス1つでHTTPS化ができる。 有効化すると Let’s Encrypt の証明書を取ってくれるが、証明書取得に関する利用者側での作業は特に無い。 HTTP-01 チャレンジ の対応を GitHub 側でよしなにやってくれているんだろうと想像している。
あとがき
今回初めて使ったものはいくつかあるが、公式ドキュメントや先人の記事が充実していたこともありどれもすんなりいったので良かった。
- Hugo
- GitHub Actions
- GitHub Pages
ただ、調べて弄ってを繰り返す最中に参考にしたサイトや得た理解等をあまりメモっておらず、 記事としてまとめながらリンク貼ったりしているのでこれは反省点。
また、構築・設定手順というよりは採用意図・経緯を中心にまとめたが、文章としてまとまりがない感じになった感がある。 構成は構成、意図は意図、経緯は経緯で別々にまとめた方が良かったのかもしれない。
個人的に見返す備忘録にはひとまず良しと思っているが、あまり参考になる感じの記事ではないかもという気もしている。 この辺の反省は今後に活かしたい。
2023/06/19 追記
以下の記事で書いたが、 2023年6月頃に構成変更を行ったので本稿で書いたような構成ではなくなっている。