db-init(prepare)を廃止し、マイグレーションのサービス名を init に変える

db/data の作成と所有者調整は postgres のエントリポイントが自分でやるので、
専用のワンショットは要らなかった。「ホスト側にディレクトリが無くても起動できる」
が狙いだったが、それが必要な standalone 環境ほど bind マウント先の自動作成に
頼れず、結局あらかじめ作っておく運用になっていた。standalone の雛形には
「データ置き場は先に作っておく」を明記した。

起動順は db → init → app に簡素化。GHCR のイメージ名(travel-log-db-init)は
据え置き(変えると workflow と GHCR 側の整理が要るため。名残であることは
db/Dockerfile のコメントに書いた)。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: claude

.github/dependabot.yml

@@ -23,7 +23,7 @@ updates:
       - dependency-name: "@types/node"
         update-types: ["version-update:semver-major"]
 
-  # Dockerfileのベースイメージ(アプリ本体=node、db-init=postgres)
+  # Dockerfileのベースイメージ(アプリ本体=node、DB用イメージ=postgres)
   - package-ecosystem: "docker"
     directories:
       - "/"

.github/workflows/docker-publish.yml

@@ -1,8 +1,8 @@
 # mainへのpushで本番用Dockerイメージをビルドし、GHCRへ公開する。
 # 本番環境の更新はこれらをpullするだけでよい(README「本番運用」参照)。
 #   ghcr.io/rtcode337/travel-log          … アプリ本体(Dockerfileのprodステージ、appサービス)
-#   ghcr.io/rtcode337/travel-log-db-init  … DBの準備とマイグレーション適用
-#                                           (db/Dockerfile、db-init/db-migrateサービス)
+#   ghcr.io/rtcode337/travel-log-db-init  … スキーマ・マイグレーション適用
+#                                           (db/Dockerfile、initサービス。イメージ名は旧構成の名残)
 #
 # アプリ本体は amd64/arm64 を「それぞれのアーキのネイティブランナー」で並列ビルドし、
 # ダイジェストで push したものを最後の merge ジョブでマニフェストにまとめる。

CLAUDE.md

@@ -5,8 +5,8 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
 ## コマンド
 
 ```bash
-docker compose -f docker-compose.dev.yml up --build   # 開発用: アプリ(localhost:7040, next dev+ホットリロード)+Postgres。スキーマ作成・未適用マイグレーションはdb-migrateサービスが自動で行う
-docker compose pull && docker compose up -d            # 本番用: GHCRのビルド済みイメージ(mainへのpushでGitHub Actionsが自動ビルド)で起動。未適用のマイグレーションはdb-migrateサービスが自動で当てる。SESSION_SECRET環境変数が必須(.env可)
+docker compose -f docker-compose.dev.yml up --build   # 開発用: アプリ(localhost:7040, next dev+ホットリロード)+Postgres。スキーマ作成・未適用マイグレーションはinitサービスが自動で行う
+docker compose pull && docker compose up -d            # 本番用: GHCRのビルド済みイメージ(mainへのpushでGitHub Actionsが自動ビルド)で起動。未適用のマイグレーションはinitサービスが自動で当てる。SESSION_SECRET環境変数が必須(.env可)
 npm run dev                                             # Next.js開発サーバー(ローカルPostgresを直接使う場合のみ)
 npm run build                                            # 本番ビルド(型チェック込み)
 ```
@@ -35,20 +35,21 @@ DB定義は`db/init/01_schema.sql`の1ファイルにすべてまとまってい
 
 ### DBの初期化・マイグレーションの流れ
 
-composeは`db-init` → `db` → `db-migrate` → `app`の順に起動する。`db-init`と`db-migrate`は同じイメージ(`db/Dockerfile`、`db/entrypoint.sh`のサブコマンド違い)で、どちらも1回走って終了するワンショット。
+composeは`db` → `init` → `app`の順に起動する。
 
 | サービス | 役割 | タイミング |
 |---|---|---|
-| `db-init` (`prepare`) | `db/data`の作成と所有者/パーミッション調整 | dbの起動**前** |
-| `db` | Postgres本体(空のDBができるだけ。スキーマは作らない) | — |
-| `db-migrate` (`migrate`) | スキーマ本体(`/init/01_schema.sql`)と`/migrations`の未適用SQLを適用し`schema_migrations`に記録 | dbのhealthcheck通過**後** |
-| `app` | Next.js。`db-migrate`が正常終了するまで起動しない | 最後 |
+| `db` | Postgres本体(空のDBができるだけ。スキーマは作らない)。`db/data`が無ければDockerが作り、所有者はpostgresのエントリポイントが自分で揃える | — |
+| `init` | スキーマ本体(`/init/01_schema.sql`)と`/migrations`の未適用SQLを適用し`schema_migrations`に記録するワンショット(`db/Dockerfile`、`db/entrypoint.sh`) | dbのhealthcheck通過**後** |
+| `app` | Next.js。`init`が正常終了するまで起動しない | 最後 |
 
-スキーマ本体もマイグレーションSQLも`db-init`イメージに焼き込まれるため、本番ホストのリポジトリの新旧に関わらず、pullしたイメージの中身がそのまま適用される。マイグレーションが失敗すると`db-migrate`が非ゼロ終了し、`app`も起動しないため、古いスキーマのままアプリが動くことはない。
+かつては`db/data`の作成とchownを行う`db-init`サービス(prepareサブコマンド)がdbの起動前にあったが、postgresのエントリポイントが同じことを自分でやるため廃止した。「ホスト側にディレクトリが無くても起動できる」が狙いだったものの、それが必要なstandalone環境ほどbindマウント先の自動作成に頼れず、結局あらかじめ作っておく運用になっていた。GHCRのイメージ名(`travel-log-db-init`)はこの名残で、`init`サービスが使い続けている。
+
+スキーマ本体もマイグレーションSQLも`travel-log-db-init`イメージに焼き込まれるため、本番ホストのリポジトリの新旧に関わらず、pullしたイメージの中身がそのまま適用される。マイグレーションが失敗すると`init`が非ゼロ終了し、`app`も起動しないため、古いスキーマのままアプリが動くことはない。
 
 `01_schema.sql`は`schema_migrations`上では`000_init_schema`という名前の「一番先頭のマイグレーション」として扱う。空のDBには実行し、既にテーブルがあるDB(旧方式でinitdbが作ったもの)には実行せず適用済みとして記録するだけにするので、既存の本番DBをそのまま引き継げる。
 
-**`db/init`をdbコンテナにマウントしないのは意図的**。かつては`docker-entrypoint-initdb.d`に`:ro`マウントし、`db-init`が`chmod -R a+rX`をかけていたが、git管理下のファイルのパーミッションをrootで書き換えるため、`01_schema.sql`を更新するとホスト側の`git pull`が失敗するようになっていた。スキーマ本体もイメージ側から流す方式にして解消した(`prepare`が触るのはgit管理外の`db/data`だけ)。
+**`db/init`をdbコンテナにマウントしないのは意図的**。かつては`docker-entrypoint-initdb.d`に`:ro`マウントし、起動前処理が`chmod -R a+rX`をかけていたが、git管理下のファイルのパーミッションをrootで書き換えるため、`01_schema.sql`を更新するとホスト側の`git pull`が失敗するようになっていた。スキーマ本体もイメージ側から流す方式にして解消した(コンテナがホスト側で触るのはgit管理外の`db/data`だけ)。
 
 開発環境では、スキーマを変えたら`db/data/`を捨てて作り直すのが手軽(移行スクリプトの検証は下記の使い捨てDBで行う)。
 

README.md

@@ -47,7 +47,7 @@ docker compose -f docker-compose.dev.yml up --build
 ```
 
 Node や Postgres をローカルにインストールする必要はない。初回起動時、
-`db-migrate` コンテナが `01_schema.sql` を自動実行してテーブルと既定のスポット種別
+`init` コンテナが `01_schema.sql` を自動実行してテーブルと既定のスポット種別
 (`tourist`=観光地、データは空)を作成する。以降スキーマに変更が入った場合も、
 起動するたびに未適用のマイグレーションが自動で当たる。
 
@@ -136,15 +136,15 @@ docker compose pull && docker compose up -d
   docker compose pull && docker compose up -d
   ```
 - 公開されるイメージは2つ。`ghcr.io/rtcode337/travel-log`(アプリ本体)と
-  `ghcr.io/rtcode337/travel-log-db-init`(DBの準備とマイグレーション適用)
+  `ghcr.io/rtcode337/travel-log-db-init`(スキーマ・マイグレーション適用。`init`サービスが使う)
 - **PostgreSQL 16 時代の`db/data`を持つ既存環境は、更新前に1回だけデータ移行が必要**
   ([docs/postgres-18-upgrade.md](docs/postgres-18-upgrade.md))。移行せずに起動すると
   dbコンテナが起動に失敗する(データは壊れない)
-- **DBスキーマの更新は自動**。`docker compose up`すると`db-migrate`サービスが未適用の
+- **DBスキーマの更新は自動**。`docker compose up`すると`init`サービスが未適用の
   マイグレーションを順に当ててから`app`を起動する(失敗した場合は`app`も起動しないので
   古いスキーマのまま動くことはない)。適用状況は
   `docker compose exec db psql -U travel_log -d travel_log -c "select * from schema_migrations"`、
-  ログは`docker compose logs db-migrate`で確認できる
+  ログは`docker compose logs init`で確認できる
 - GitHub Actions(`GITHUB_TOKEN`)から公開したパッケージはリポジトリに自動リンクされ、
   可視性もリポジトリと同じ(=public)になるため、追加設定なしで匿名pullできる。
   リポジトリをprivateにした場合は本番ホストで`docker login ghcr.io`

db/Dockerfile

@@ -1,24 +1,19 @@
-# DBの準備・マイグレーション適用用のイメージ。
+# スキーマ・マイグレーション適用用のイメージ(composeの init サービス)。
 # postgres公式イメージをそのまま使う(psql/pg_isreadyが入っており、
 # サーバ本体と同じバージョンのクライアントで確実に接続できるため)。
 #
-# 2つの用途を1つのイメージのサブコマンドで賄う(docker-compose.yml参照):
-#   prepare … db/data の作成と所有者調整(dbサービスの起動前)
-#   migrate … スキーマ本体と未適用のマイグレーションSQLの自動適用(dbサービスの起動後)
-#
 # mainへのpushでGitHub Actions(.github/workflows/docker-publish.yml)が
 # ghcr.io/<repo>-db-init として公開する。本番はこのイメージをpullして使う
+# (かつては db/data の準備(prepare)も担っていた名残でこのイメージ名。
+#  サービス名を変えてもイメージ名を変えると GHCR 側の整理が要るため据え置き)
 FROM postgres:18-alpine
 
 # スキーマ本体とマイグレーションSQLはイメージに焼き込む(本番ホストのリポジトリの
-# 新旧に関わらず、pullしたイメージの中身がそのまま適用される)。
-# /db 配下ではなく /init・/migrations に置く — prepareでは ./db をbindマウントするため、
-# /db 配下だとマウントで隠れてしまう
+# 新旧に関わらず、pullしたイメージの中身がそのまま適用される)
 COPY init /init
 COPY migrations /migrations
 COPY entrypoint.sh /usr/local/bin/db-init
 
 RUN chmod +x /usr/local/bin/db-init
 
 ENTRYPOINT ["/usr/local/bin/db-init"]
-CMD ["migrate"]

db/entrypoint.sh

@@ -1,11 +1,7 @@
 #!/bin/sh
-# DBの準備・マイグレーション適用(db/Dockerfile のENTRYPOINT)。
-#
-#   db-init prepare … db/data の作成と所有者調整。dbサービスの起動前に走る
-#   db-init migrate … スキーマ本体(/init/01_schema.sql)と /migrations の未適用SQLを
-#                     適用する。dbサービスの起動後に走る
-#
-# どちらも1回実行して終了するワンショット(compose側は restart: "no")。
+# スキーマ本体(/init/01_schema.sql)と /migrations の未適用SQLの適用
+# (db/Dockerfile のENTRYPOINT。composeの init サービス)。
+# dbサービスの起動後に1回実行して終了するワンショット(compose側は restart: "no")。
 set -eu
 
 MIGRATIONS_DIR="${MIGRATIONS_DIR:-/migrations}"
@@ -15,20 +11,6 @@ SCHEMA_VERSION=000_init_schema
 # マイグレーションの同時実行を防ぐためのadvisory lockのキー(任意の定数)
 LOCK_KEY=8241973
 
-prepare() {
-  # db/dataは.gitignore対象でgit管理下になく、cloneした直後は存在しない。dbサービスが
-  # 直接./db/dataをbindマウントすると、環境によってはホスト側にディレクトリがない状態で
-  # コンテナ起動そのものが失敗しうるため、ここで先に作ってpostgres(uid/gid 70)に
-  # 所有者を揃えておく。
-  # ここで触るのはgit管理外のdb/dataだけにすること — かつてはdb/initにもchmodを
-  # かけていたが、git管理下のファイルのパーミッションをrootで書き換えるため、
-  # db/init/01_schema.sqlに変更が入るとホスト側のgit pullが失敗するようになっていた
-  # (スキーマ本体はdbサービスにマウントせず、migrate側が流す方式に変えて解消した)
-  mkdir -p /db/data
-  chown -R 70:70 /db/data
-  echo "db-init: prepared /db/data"
-}
-
 wait_for_db() {
   # compose側でdbのhealthcheck完了を待ってから起動する想定だが、
   # 単体で起動された場合にも耐えるよう自前でも待つ
@@ -101,11 +83,4 @@ migrate() {
   echo "db-init: migrations done (applied=$applied, skipped=$skipped)"
 }
 
-case "${1:-migrate}" in
-  prepare) prepare ;;
-  migrate) migrate ;;
-  *)
-    echo "usage: db-init [prepare|migrate]" >&2
-    exit 64
-    ;;
-esac
+migrate

db/migrations/README.md

@@ -10,11 +10,11 @@
 
 ## 適用は自動
 
-`docker compose up`すると`db-migrate`サービス(`db/Dockerfile`のイメージ、`migrate`サブコマンド)が
+`docker compose up`すると`init`サービス(`db/Dockerfile`のイメージ)が
 dbの起動を待って、スキーマ本体と未適用のスクリプトを連番順に当てる。手で流す必要はない。
 
 - 適用済みのリビジョンは`schema_migrations`テーブルに記録され、2回目以降はスキップされる
-- `app`サービスは`db-migrate`が**正常終了するまで起動しない**(古いスキーマのままアプリが
+- `app`サービスは`init`が**正常終了するまで起動しない**(古いスキーマのままアプリが
   動くのを防ぐ)。マイグレーションが失敗したらアプリも上がらないので、失敗に気づける
 - 1本のスクリプトとその適用記録は1トランザクションにまとまっている。途中で失敗すれば
   記録も残らないため、スクリプトを直して`docker compose up`し直せばよい
@@ -24,7 +24,7 @@ dbの起動を待って、スキーマ本体と未適用のスクリプトを連
 docker compose exec -T db psql -U travel_log -d travel_log -c "select version, applied_at from schema_migrations order by version"
 
 # ログを見る
-docker compose logs db-migrate
+docker compose logs init
 ```
 
 ## 書き方のルール
@@ -48,7 +48,7 @@ docker compose logs db-migrate
 # 1. 旧スキーマのダンプを復元したDBにマイグレーションを当てる
 docker compose -f docker-compose.dev.yml exec -T db psql -U travel_log -d postgres -c "create database t_old"
 docker compose -f docker-compose.dev.yml exec -T db psql -U travel_log -d t_old < <旧スキーマのダンプ>.sql
-docker compose -f docker-compose.dev.yml run --rm -e PGDATABASE=t_old db-migrate
+docker compose -f docker-compose.dev.yml run --rm -e PGDATABASE=t_old init
 
 # 2. 最新スキーマで新規作成したDBを用意する
 docker compose -f docker-compose.dev.yml exec -T db psql -U travel_log -d postgres -c "create database t_fresh"

docker-compose.dev.yml

@@ -11,7 +11,7 @@ services:
       # 16の頃に必要だったPGDATAの上書き(マウント直下だとドットファイルの存在で
       # initdbが初期化を拒否する対策)は、既定がサブディレクトリになったので不要
     volumes:
-      # db/initはマウントしない。スキーマ本体(01_schema.sql)はdb-migrateが流す
+      # db/initはマウントしない。スキーマ本体(01_schema.sql)はinitサービスが流す
       # (git管理下のdb/initをコンテナに触らせるとホスト側のパーミッションが変わり、
       #  スキーマを更新したときにgit pullが失敗するようになるため)
       # マウント先が /var/lib/postgresql/data ではなく1段上なのは本番用と同じ理由
@@ -25,7 +25,7 @@ services:
 
   # スキーマ本体と未適用のマイグレーションを順に自動適用するワンショット(本番と同じ仕組み)。
   # 開発では公開イメージをpullせず、db/Dockerfileをその場でビルドして使う
-  db-migrate:
+  init:
     build:
       context: ./db
     depends_on:
@@ -49,7 +49,7 @@ services:
       context: .
       target: dev
     depends_on:
-      db-migrate:
+      init:
         condition: service_completed_successfully
     environment:
       DATABASE_URL: postgres://travel_log:travel_log@db:5432/travel_log