app deploy: first deploy ignores 'app env set' values for accessory containers

[crowdy]

Summary

When deploying a multi-service compose stack with accessories, the first conoha app deploy brings up accessories using compose default values (\${VAR:-default}) instead of the values set via conoha app env set. A second conoha app deploy recreates the app slot and applies the env vars, but accessories are not re-created — so any state seeded with the wrong values (e.g., a Postgres DB initialized with the default password) sticks around.

Version

conoha-cli v0.7.1-3-g7127ce0

Reproduction

Repo: crowdy/conoha-cli-app-samples — feat/dns-server-sample branch

compose.yml excerpt:

services:
  app:
    environment:
      - DATABASE_URL=postgres://pdns:${POSTGRES_PASSWORD:-pdns}@db:5432/pdns
  db:
    image: postgres:17-alpine
    environment:
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD:-pdns}

conoha.yml:

name: dns-server
hosts: [api.example.com]
accessories: [pdns, db, pdns-init]

Steps:

conoha proxy boot --acme-email me@example.com dns-server-test
conoha app init dns-server-test --app-name dns-server
conoha app env set dns-server-test --app-name dns-server POSTGRES_PASSWORD=mysecret
conoha app deploy dns-server-test --app-name dns-server

# accessory db started with POSTGRES_PASSWORD=pdns (the compose default), not mysecret
ssh root@<vps> 'docker inspect dns-server-accessories-db-1 --format "{{range .Config.Env}}{{println .}}{{end}}" | grep PASSWORD'
# POSTGRES_PASSWORD=pdns                  <-- WRONG

conoha app deploy dns-server-test --app-name dns-server
# new slot's app gets POSTGRES_PASSWORD=mysecret in DATABASE_URL, but accessories
# (db, pdns) still hold the old defaults — DB volume already initialised with `pdns` user pwd

Workaround

Run conoha app deploy twice, then SSH in and docker compose -f compose.yml -p <app>-accessories down -v to drop the volume, then conoha app deploy once more — only then does the DB re-initialize with the correct password.

Expected

conoha app deploy should ensure accessory containers see app env set values on first deploy, not require a second deploy + manual volume teardown.

[crowdy]

재현 검증 요청

코드 베이스 확인 결과, 이 이슈가 #166 의 fix (1b2d16b, fix(deploy): pass --env-file to compose so .env.server feeds interpolation) 에 의해 이미 해결되었을 가능성이 있습니다. 보고된 버전 v0.7.1-3-g7127ce0 에는 해당 fix 가 포함되어 있습니다.

현재 코드 상태

cmd/app/remotecmds.go:119-128 buildAccessoryUp 가 first-run 액세서리 기동 시 --env-file '/opt/conoha/<app>/.env.server' 를 명시적으로 전달합니다:

return fmt.Sprintf(
    "cd '%s' && touch '%s' && docker compose --env-file '%s' -p %s -f %s %sup -d %s",
    workDir, envFile, envFile, project, composeFile, overrideArg, args)

이 경로가 동작한다면 compose.yml 의 ${POSTGRES_PASSWORD:-pdns} 는 .env.server 의 값으로 치환되어 액세서리 컨테이너에 주입되어야 합니다.

재현 시 추가 정보 부탁드립니다

다음 정보가 있으면 root cause 식별이 빠릅니다:

1. deploy 직전 서버 상태 확인:

   ssh root@<vps> 'cat /opt/conoha/dns-server/.env.server'

   POSTGRES_PASSWORD=mysecret 이 실제로 들어 있는지.

2. deploy 가 실제로 발행한 명령어:
   conoha app deploy --debug (또는 -v) 출력에서 docker compose --env-file ... 이 포함된 라인.

3. 액세서리 컨테이너의 실제 env:

   ssh root@<vps> 'docker inspect dns-server-accessories-db-1 --format "{{range .Config.Env}}{{println .}}{{end}}"'

   첫 deploy 직후의 전체 env 덤프.

4. app env set 실행 시점의 stderr:
   Set POSTGRES_PASSWORD / Next: run 'conoha app deploy ...' 메시지가 정상 출력되었는지.

5. conoha.yml / compose.yml 전문:
   가능하면 재현 가능한 minimal repro 를 첨부.

가능한 별개 원인 후보

만약 위 #1 에서 .env.server 에 값이 정상 기록되었는데도 액세서리에 반영되지 않는다면:

• compose.yml 의 environment: 가 - POSTGRES_PASSWORD=${POSTGRES_PASSWORD:-pdns} 형식이 아니라 다른 구조 (e.g., env_file: 지시어, Kamal-style nested map) 일 가능성
• accessories: 리스트와 compose.yml 의 service 키 매핑이 어긋났을 가능성
• app init 이 cleanup 없이 재실행되어 이전 deploy 의 accessory 컨테이너가 남아 있을 가능성 (docker compose -p <app>-accessories ps -a 로 확인 가능)

재현 정보 회신 부탁드립니다.

[crowdy]

検証結果: 再現せず (v0.7.1-10-gdecebee)

報告いただいた手順を fresh VPS 上で再実行しましたが、accessory に mysecret が正しく注入されました。#166 の修正 (commit 1b2d16b, 報告バージョン v0.7.1-3-g7127ce0 にも含まれる) が想定通り機能しているようです。

再現環境

項目	値
バイナリ	v0.7.1-10-gdecebee (main HEAD)
イメージ	vmi-docker-29.2-ubuntu-24.04-amd64 (Docker 29.2.1)
flavor	g2l-t-c3m2
サンプル	crowdy/conoha-cli-app-samples main, dns-server/

再現手順 (issue 記載のまま)

conoha server create --name issue-195-* --flavor g2l-t-c3m2 \
  --image vmi-docker-29.2-ubuntu-24.04-amd64 \
  --key-name <key> --security-group default --security-group IPv4v6-SSH --security-group IPv4v6-Web --no-input --wait

conoha proxy boot <id> --acme-email me@example.com --no-input --yes
conoha app init <id> --no-input --yes               # cwd: dns-server/
conoha app env set <id> --app-name dns-server POSTGRES_PASSWORD=mysecret --no-input --yes
conoha app deploy <id> --no-input --yes             # ← 1 回目の deploy

1 回目 deploy 直後の証跡

$ ssh root@<vps> 'cat /opt/conoha/dns-server/.env.server'
POSTGRES_PASSWORD=mysecret

$ ssh root@<vps> 'docker inspect dns-server-accessories-db-1 \
    --format "{{range .Config.Env}}{{println .}}{{end}}"' | grep PASS
POSTGRES_PASSWORD=mysecret                    ← ✅ 期待通り

$ ssh root@<vps> 'docker inspect dns-server-accessories-pdns-1 \
    --format "{{json .Config.Cmd}}"'
["--gpgsql-password=mysecret"]                ← ✅ 期待通り (compose の ${POSTGRES_PASSWORD} 補間が効いている)

$ ssh root@<vps> 'docker inspect dns-server-accessories-pdns-init-1 \
    --format "{{range .Config.Env}}{{println .}}{{end}}" | grep DATABASE'
DATABASE_URL=postgres://pdns:mysecret@db:5432/pdns   ← ✅ 期待通り

$ ssh root@<vps> 'docker inspect dns-server-551f59a-app \
    --format "{{range .Config.Env}}{{println .}}{{end}}" | grep -E "PASS|DATABASE"'
DATABASE_URL=postgres://pdns:mysecret@db:5432/pdns
POSTGRES_PASSWORD=mysecret                    ← ✅ 期待通り (slot 側も)

compose -p dns-server-accessories ps -a:

NAME                                 IMAGE                              SERVICE     STATUS
dns-server-accessories-db-1          postgres:17-alpine                 db          Up (healthy)
dns-server-accessories-pdns-1        powerdns/pdns-auth-49:4.9.14       pdns        Restarting (1)*
dns-server-accessories-pdns-init-1   dns-server-accessories-pdns-init   pdns-init   Exited (0)

* pdns の Restarting は :53 バインドが届かない別件 (UFW / sysctl net.ipv4.ip_unprivileged_port_start) で、env 補間とは無関係。

推察される報告者環境の差分

報告のワークアラウンド「2 回 deploy → down -v → 3 回目 deploy」が効くという挙動から、db_data ボリュームに古い pdns パスワードで初期化された Postgres データが残っていたケースに見えます。Postgres の POSTGRES_PASSWORD は データディレクトリが空のときだけ 反映される設計なので、過去に app env set 前の deploy で一度初期化されてしまうと、その後 env を設定して再 deploy しても DB のパスワードは更新されません。

具体的なシナリオ候補:

1. app env set を忘れて先に app deploy を 1 度実行 → 既定値 pdns で db ボリュームが initdb 済み
2. その後 app env set POSTGRES_PASSWORD=mysecret を実行 → .env.server 更新
3. app deploy 再実行 → slot 側の DATABASE_URL は mysecret になるが、db コンテナの POSTGRES_PASSWORD env は確かに mysecret で渡されるものの、ボリューム内の HBA / role table は古いまま → app から認証エラー

このシナリオは「accessory の env がコンテナに反映されていない」ように見えますが、実際は env は届いているのに データが先に初期化されているせいで上書きされない という Postgres 仕様によるものです。

提案

• このまま閉じて差し支えないと思います。env 補間自体は動作しています。
• 別途、「accessory 関連で破壊的更新が必要なときに app deploy がそれを検知 / 警告 / 自動でやってくれる」UX 改善 は別 issue で扱うのが良さそうです (例: app accessories down -v のようなサブコマンド、もしくは --reset-accessories フラグ)。これは spec レベルで議論したいので、希望されれば別 issue を立てます。

検証用の VPS は issue-195-34138 (160.251.201.104) として残してあるので、もし「ここを叩いてほしい」というポイントがあればすぐ確認できます。

[crowdy]

検証結果に基づき closing します。env 補間自体は v0.7.1+ で正常動作しています (検証コメント)。

Postgres ボリューム初期化との相互作用 / accessory の volume 自動破棄 UX 改善が必要であれば、別 issue として切ってください。