feat: k8s デプロイ用マニフェストとイメージビルドスクリプトを追加

[mhaya]

概要

JAIRO Cloud Groups Manager を k8s 上で動かすためのイメージビルド手順とマニフェストを追加します。構成・命名・スクリプトの流儀は weko-k8s の web デプロイ (deploy/weko/manifest_template/deploy-web.yaml + scripts/make_weko_manifests.sh + scripts/deploy_weko.sh) に揃えました。

ミドルウェア (PostgreSQL / Redis / RabbitMQ) は JAIRO Cloud 共通クラスタを使う前提 を既定にしています。

構成

443 ─▶ Ingress ─▶ Service ─▶ Deployment <domain>-web (1 Pod 3 コンテナ)
                              ├─ nginx  : nginx + shibd + shibauthorizer/responder + 静的SPA
                              ├─ web    : uwsgi (Flask API) :5050
                              └─ worker : celery
                                   │
        ┌──────────────────────────┼───────────────────────────┐
   pgpool.weko3pg      weko-sentinel-service.weko3re   weko-rabbitmq.weko3ra
   (DB: jcgroups)      (db 割当 + db4 = WEKO 共有)      (vhost: jcgroups)

nginx / web / worker を 1 Pod に同居させています。

• nginx / shibd / shibauthorizer / shibresponder は Unix ドメインソケットで通信するため、そもそも同居が必須
• nginx イメージに upstream api_server { server web:5050; } が焼き込まれているので、hostAliases で web を 127.0.0.1 に向ける。これにより nginx が起動時に解決した ClusterIP をキャッシュし続ける問題 (Pod 入れ替え後の 502) を回避できる

追加したもの

パス	内容
k8s/deploy/jcgroups/manifest_template/	__PLACEHOLDER__ 入りのマニフェスト (deploy-web / service / ingress / configmap / secret / volume-pv / volume-pvc / job-db-init / namespace)
k8s/deploy/jcgroups/params.env.example	環境ごとのパラメータ
k8s/deploy/middleware/	検証用の単一インスタンス PostgreSQL / Redis / RabbitMQ
k8s/scripts/build_images.sh	アプリ / nginx イメージのビルド (+ push)
k8s/scripts/make_jcgroups_manifests.sh	params.env からマニフェストと設定ファイル・証明書を生成
k8s/scripts/deploy_jcgroups.sh / delete_jcgroups.sh	適用と削除
k8s/README.md	手順・設計上の注意・検証結果

nginx/Dockerfile に ARG SERVER_NAME を追加しました。Nuxt の serverName (configs/app.config.ts) はビルド時に静的 SPA へインライン展開されるため実行時に差し替えられず、FQDN ごとにイメージをビルドし直す必要があります。build_images.sh は --build-arg SERVER_NAME で注入し、生成物を grep して実際に入ったかを確認します。

.gitignore に params.env を追加しました (secret_key / DB パスワードが入るため)。

設定ファイルの生成方針

server.config.toml と shibboleth2.xml はテンプレートを複製せず、リポジトリの configs/server.config.toml / nginx/shibboleth2.xml を唯一の正として環境依存の値だけを上書きします (設定項目が増えても追従漏れが起きないようにするため)。生成時に [develop] セクションを丸ごと落とし、置換結果を assert します。

共通ミドルウェアを使う上での注意

• Redis の DB 番号は共有資源。共通 Redis は 1 インスタンスを全機関で共有し (databases 40000)、DB 番号は機関ごとに払い出し済みです。RedisSentinelCache のときは REDIS_DB_APP_CACHE / _ACCOUNT_STORE / _RESULT_BACKEND の明示を必須にし、リポジトリ既定値 (0/1/2) の暗黙利用を禁止しています (未指定・重複はスクリプトが停止)
• REDIS_DB_GROUP_CACHE は 4 固定。WEKO の GROUP_INFO_REDIS_DB = 4 と揃える必要があり、ここが WEKO との唯一の実行時結合点です
• PostgreSQL は CREATEDB 権限付きロールを事前に用意すれば、DB 自体は db-init Job の flask db init が作ります
• RabbitMQ は make_rabbitmq_vhost.sh と同じ流儀で専用 vhost を作ります

手順は k8s/README.md に記載しています。

検証

kind (k8s v1.34) で実デプロイして確認しました。

共通構成

• イメージ2種のビルド (serverName の焼き込み確認まで)
• 本番相当パラメータ (NFS / pull secret / nodeSelector / LoadBalancer / replicas=2 / 機関別証明書2件) のスキーマ検証: kubectl apply --dry-run=server --validate=strict 通過
• db-init Job Completed → Pod 3/3 Running
• GET / 200 / GET /_nuxt/*.js 200 / GET /api/auth/check 401 (nginx → hostAliases → uwsgi) / GET /api/dev/accounts 404 / GET /Shibboleth.sso/Metadata 200
• web → worker のファイル共有、非 root 実行 (runAsUser: 1000)
• delete_jcgroups.sh → deploy_jcgroups.sh --skip-db-init で既存 DB を保持して再デプロイ

共通ミドルウェア構成 (Service 名 / Namespace / Sentinel / headless Service / databases 40000 を kind 上に模擬)

• ロール作成 → flask db init で jcgroups DB (owner=jcgroups) と 4 テーブル生成
• クロス Namespace 接続 3 種すべて疎通、worker は amqp://invenio:**@weko-rabbitmq.weko3ra:5672/jcgroups へ接続
• Sentinel 経由の Redis 接続で read/write 成功、app_cache=db100 / account_store=db101 / group_cache=db4 が実際に使われることを Redis 側の keyspace で確認

未検証: mAP Core への到達を要する機能、Shibboleth 実 IdP との SAML 認証、Ingress コントローラ経由の疎通 (kind では Service への port-forward で確認)、NFS RWX PVC での複数レプリカ運用、実際の共通クラスタ (pgpool の md5 認証・Sentinel 複数台でのフェイルオーバ) への接続

補足

CI (.github/workflows/ci.yml) は src/** tests/** pyproject.toml uv.lock の変更でのみ起動するため、この PR ではチェックが走りません。

🤖 Generated with Claude Code