Chillarin Blog 構成紹介 - 4.Dockerで本番サービス化（nginx + tunnel + remark42）-

本章の内容

これまで「公開経路（Cloudflare Tunnel）」と「Hugo 側の作り（テンプレ/テーマ）」を整理しました。 今回はそれを 本番として安定稼働させる"器" の話です。

このブログは、Docker Compose で以下3点セットを動かしています。

• nginx：静的ファイル（Hugoの生成物）を配信
• cloudflared：Cloudflare Tunnel（外部公開の入口）
• remark42：コメント基盤（self-host）

ゴール：ホスト再起動やコンテナ再起動があっても、勝手に復帰して"放置運用"できる状態にする。

全体像（通信と責務）

外から見ると「Cloudflare → Tunnel → nginx/remark42」に見えますが、肝はここです。

• 公開物は /opt/chirarin-blog-public に固定
• nginx はそのディレクトリを読むだけ
• cloudflared は"外向きの穴"を担当（ポート開放しない）
• コメントは remark42 を別サービスで独立

“2.公開の核：Cloudflare Tunnel設計” にて紹介した通信フローを再掲載しておきます。

ディレクトリ設計（“固定点"を作る）

本番運用の事故は「どこがソースで、どこが公開物か」が曖昧になると起きます。 Chillarin Blog では 役割ごとにディレクトリを分離して、固定点を作っています。

• /opt/chirarin-blog-site Hugo のソース（content/layouts/static/hugo.toml など）
• /opt/chirarin-blog-public 公開物（Hugo の生成物） ← nginx がここだけ読む
• /opt/chirarin-blog-infra 本番の器（docker-compose.yml / .env / 付随データ）

この分離のおかげで、デプロイは極端に言うとこうなります。

• Hugo のビルド結果を /opt/chirarin-blog-public に置く
• nginx は「置かれたもの」を配るだけ（設定を触らない）

docker-compose.yml の設計方針

Compose は “同じネットワーク内で3サービスを束ねる” のが役目です。

• cloudflared は 内部的に http://web:80 や http://remark42:8080 に到達できれば良い → ホスト側のポートをインターネットに開ける必要が無い
• nginx は /opt/chirarin-blog-public を read-only でマウントして配る
• remark42 は永続データ（DB）をホストに持たせて、コンテナ更新で消えないようにする

📦 この設定ファイルの全量は 有料コンテンツ: 自宅サーバ構築シリーズ に含まれています。

nginx が読むのは /opt/chirarin-blog-public

ここが運用の一番ラクなポイントです。

• nginx は /usr/share/nginx/html を配る
• そこに /opt/chirarin-blog-public を bind mount している
• つまり、公開物の置き場を固定すれば、nginx 側は触らずに済む

結果として、Hugo のデプロイはこういう思想になります。

• ビルド結果を /opt/chirarin-blog-public に反映
• nginx コンテナは “同じマウント先” を見続けるだけ

.env（秘密情報はここに閉じ込める）

cloudflared の token や remark42 の secret は compose に直書きしないで .env に隔離します。

📦 .env ファイルの設定例は 有料コンテンツ: 自宅サーバ構築シリーズ に含まれています。

• .env は Git に入れない
• バックアップは “安全な場所” に（漏れたら即ローテ）

起動・更新・ログ確認

運用で迷わないように、操作の"型"を固定します。

# 起動
cd /opt/chirarin-blog-infra
docker compose up -d

# 状態確認
docker compose ps

# ログ（cloudflared / nginx / remark42）
docker compose logs -f tunnel
docker compose logs -f web
docker compose logs -f remark42

# 更新（イメージ更新 → 再作成）
docker compose pull
docker compose up -d

再起動耐性：restart policy の考え方（どこまで守ってくれるか）

Compose の restart: unless-stopped は、雑に言うとこうです。

• コンテナが落ちたら 勝手に再起動する
• ホストが再起動して Docker が立ち上がった後、勝手に復帰する
• ただし、手動で docker stop したコンテナは勝手に上がらない（unless-stopped の挙動）

つまり「放置運用」したいなら、基本はこれで十分です。

systemd：さらに"確実に戻したい"場合の考え方

restart policy は強いですが、運用の安心感を上げたいなら systemd で"compose一式"をサービス化しておくのも手です。

• OS起動 → systemd → docker 起動 → compose 起動（を保証）
• “何が起動の責務か” が明確になる

📦 systemd サービスファイル（chirarin-blog-infra.service）の全量と有効化コマンド一式は 有料コンテンツ: 自宅サーバ構築シリーズ に含まれています。

どちらの方針でもOK。 「restart policy だけで十分」ならシンプルに保つ。 「OS再起動時の責務を明確化したい」なら systemd を追加する。

“壊れにくさ"のチェックリスト（最低限）

最後に、運用上の地雷だけチェックしておくと安心です。

• /opt/chirarin-blog-public が nginx に read-only マウントされている
• remark42 のデータが ホスト側に永続化されている（コンテナ更新で消えない）
• .env が Git 管理外になっている
• restart: unless-stopped が3サービスに入っている（落ちたら戻る）
• （必要なら）systemd で compose 一式の起動責務を固定している

ここまでのまとめ

• 本番は **docker-compose.yml（nginx + cloudflared + remark42）**で束ねる
• nginx が読む場所は /opt/chirarin-blog-public に固定すると運用がラク
• 再起動耐性は
  • まず restart: unless-stopped
  • さらに必要なら systemd で “compose一式” をサービス化

次回は、**デプロイと運用自動化（GitHub Actions / self-hosted runner）**について触れていきます。 「記事を書く → push → 勝手に公開物が更新される」までを、手順と事故防止込みでまとめます。

自宅サーバ運用の全体像は 自宅サーバ運用の完全ガイド — Proxmox + Cloudflare Tunnel + Docker で個人ブログを公開し続ける にまとめています。Proxmox クラスタ・公開経路・Docker 本番化・障害対応までを 1 ページで通読できる Pillar ガイドです。