Hugoプレビュー＆デプロイの自動化 on QNAP NAS

自宅サーバをQNAP NASにリプレースしたことにより、それまでFreeBSD（Jail）上に構築していたHugoのビルド/プレビュー環境がなくなってしまった。Hugo環境以外はQNAPのプリセット or AppCenterから導入できるアプリケーションで何とかなったものの、さすがにHugoは無理なので代替手段を検討することに。

「Container Station」なるDockerコンテナの動作環境があることは把握していたので、その上でHugo導入済みのコンテナを動かせば何とかなるんじゃない？と考えていたものの、やってみると幾つか躓いたポイントがあったので以下にまとめてみた。

Hugo導入済みのDockerコンテナ

当初はHugo公式が提供しているものを使おうと思っていたもののなさそうだったので、幾つか調べた上で良さげだったHugoModsが提供しているイメージを使用。

ドキュメントはちゃんとしており、導入やコンテナ設定自体は特に問題なく完了。

Hugoのプレビュー環境

実は一番苦労したのがここ。

元々はJail起動時にプレビューサイトを立ち上げるようにcronを設定していた。

最初は普通にContainer Stationの「コンテナ」メニューからDockerコンテナを作成したものの、どう頑張ってもコンテナ外部からプレビューサイトにアクセスできなかった。Container Station上のコンソールから見るとHugoのプレビュー環境は正しく起動していたため、ネットワーク構成の問題かと思い、NATでポートフォワーディングしたり、ブリッジで固定IP振ったりしてみたもののどれもNG。Webで調べてもほぼ古いバージョン（2.X系）の情報しかなく、その場合は先述の手順で問題なさそうだったのだが、現行のバージョンは3.X系ということであまり参考にならず。

さてどうしたものか・・と思っていたところ、よくよくContainer Stationの設定画面を見ると「アプリケーション」の項目にはWeb URLの記載があることを発見。つまり、外部から接続したい場合はアプリケーションとして作成しなければいけないのでは？という仮説よりそのように作成してみたところ、無事に外部から接続可能なコンテナ（アプリケーション）として作成することができた。

なお、Container StationにおけるアプリケーションはDocker Composeを使用して構成するようだったので、HugoModsのドキュメントにおけるDocker Composeでの構成例をベースに以下のように作成。ポイントは以下の2点。

• ブリッジで固定IPを振っているため、同IPアドレスを--baseURLオプションに指定
  • NATでポートフォワーディングするとこの設定自体は不要だが、プレビューサイト上の各種リンクにおけるホスト名がlocalhostのままになってしまい、まともに使用できないため。ただこのへんはテーマの種類によるかも。
  • HugoModsのバインド設定はデフォルト0.0.0.0のためその観点からは不要そう。
• FreeBSD（Jail）上のHugo関連ファイル一式をQNAP NAS上に配置の上、コンテナ上で/srcにマウント
  • これまで通り、記事ファイル等は自PCから直接編集したいため。特に指定しなければRWでマウントしてくれる模様。

version: '3'
services:
  hugo:
    image: hugomods/hugo:exts-non-root
    command: server -D --ignoreCache --disableFastRender --baseURL http://<アプリケーションのIPアドレス（ブリッジ構成）>/
    volumes:
      - <QNAP NAS上のHugo関連ファイル一式格納パス>:/src
    ports: [1313]

また「詳細設定」の「デフォルトのWeb URLポート」の設定をYAML設定と合わせる必要あり。上記設定の場合は

• サービス: hugo
• デフォルトのWeb URLポート: 1313

のような感じ。

Hugoのビルド＆デプロイ環境

元々はJail上でビルド＆デプロイ用のスクリプトをcronで定期実行していた。

最初は元々の仕組みに寄せる方針で、Docker Composeでビルド＆デプロイ用のスクリプト実行用のコンテナをもう1個立ててその中でcronを実行・・みたいなことを考えていたものの、Docker内部でcronを動かすとなるとしっかりDockerFileを書く必要がありそう＆それで上手くいかなかった時の解決策が今回の環境上限定されそうなことの2点より、もっとラクをする方針に。

具体的には、コンテナ起動時のエントリポイントをビルド＆デプロイ用のスクリプトに変更した上で、コンテナ自体をホストOS（QNAP NAS）から定期実行するようにした。コンテナからマウントするQNAP NAS上の領域に同スクリプトも含めてあげればOK。唯一の心配はコンテナ内部にgitが入っているかどうかだったが¹、問題なかった。コンテナの成り立ちを考えると当然かもしれないけども。

ただ、当初はいわゆるスケジューラのようなタスク定期実行のためのサービスなりプリセットアプリケーションがあるのかと思っていたものの、どうやらないらしく²、ホストOSのcrontabにベタ書きする必要があったのが画竜点睛を欠くというか、ちょっと綺麗に収まらなかったところではある。。ちなみに、公式FAQによるとユーザのcrontabに書くと再起動時に初期化されてしまうので、/etc/config/crontabに書く必要があるとのこと。

GitHub認証

元々はSSH鍵をGitHub上のユーザに紐付けて認証していたものの、サーバリプレースでその鍵がどっかに行ってしまい再作成必要＆コンテナ起動時に都度登録なり指定なりすることができるのか？の2点より、他の認証方式を調べていたところ現在の推奨は個人用アクセストークンらしく、それを使用することに。

公式ページ曰く、2種類あるトークンの内「fine-grained personal access token」が推奨とのことだったのでそちらを採用。設定画面にシレっとPreviewの記載があったのが気になったものの、特に問題なく認証できた。ただ、fine-grainedということで権限を細かく設定できるのだが、逆に今回の用途だとどの権限を指定すれば良いのかちょっと迷った。指定したのは以下の2つ。

• Actions: Read and Write
• Contents: Read and Write

各権限の詳細は公式ページを参照。Contentsがいわゆるリポジトリの使用権限（commitなりpush/pull）の権限を指すらしい。Actionsはgit push後にGitHub Pages側でビルドなりデプロイが走っていそうだったので念のために追加。不要かも？

うーん、なんか元記事より長くなってしまった。。。

自宅サーバのリプレースの顛末はまた次回以降で。本来は一番先にこれを書くのが綺麗だった気もしますが・・