같은 커밋으로 컨테이너만 다시 띄울 때는 배포 스크립트가 쓰는 이미지 이름표를 전부 맞춘다

환경 변수 하나만 바꿔 같은 커밋으로 컨테이너를 다시 띄우고 싶을 때가 있습니다. 새로 빌드하기는 번거로우니, 이미 있는 앱 이미지에 배포 스크립트가 기대하는 커밋 이름표만 붙이고 스크립트를 돌립니다. 그런데 앱이 뜨기도 전에 마이그레이션 단계에서 idna 「label empty or too long」 같은 DB 호스트 이름 오류로 멈춥니다. 바꾼 것은 환경 변수뿐인데 DB 주소가 깨진 것처럼 보입니다.

원인은 배포 스크립트가 쓰는 이미지가 하나가 아니라는 데 있습니다. 이런 스크립트는 흔히 docker compose run --rm <다른 서비스> printenv DATABASE_URL처럼 보조 서비스 컨테이너를 잠깐 띄워 설정값을 읽고, 그 값으로 다음 단계를 진행합니다. 그 보조 서비스의 이미지에는 새 이름표가 없으니 compose가 이미지를 받으려 하고, 그 진행 출력이 명령 출력에 섞여 변수에 들어갑니다. 결과적으로 DB 주소 자리에 「Pulling…」 같은 글자가 들어가고, 호스트 이름 해석이 그 지점에서 실패합니다. 오류 메시지가 실제 원인(이미지 이름표 누락)과 전혀 다른 곳을 가리키는 것이 함정입니다.

해법은 두 가지입니다. 가장 안전한 것은 수동 교체를 하지 않고, 바뀐 설정을 다음 정식 배포에 실어 보내는 것입니다. 꼭 손으로 해야 한다면 compose가 참조하는 이미지 이름표를 전부 확인하고 모두 맞춥니다.

# compose가 쓰는 이미지 목록을 뽑아, 로컬에 없는 이름표를 찾는다
docker compose config --images | while read -r img; do
  docker image inspect "$img" >/dev/null 2>&1 || echo "없음: $img"
done

스크립트 쪽에서도 막을 수 있습니다. 값을 읽는 run에는 --pull never를 주어 이미지가 없으면 바로 실패하게 하고, 읽은 값이 기대하는 모양(예: postgres://로 시작)인지 검사한 뒤에 다음 단계로 넘어가게 합니다. 그러면 엉뚱한 단계에서 엉뚱한 오류를 보는 대신, 「이미지가 없다」는 진짜 원인에서 멈춥니다.