Docker Compose에서 env_file을 바꿨는데 값이 그대로였던 실수

겉으로는 재시작했는데 값은 그대로였다

환경변수 하나를 바꾸고 docker compose restart를 실행했다. 그런데 앱 안에서는 예전 값이 계속 찍혔다. 파일을 잘못 저장했나 싶어서 몇 번을 열어봤지만 .env.production에는 새 값이 들어 있었다.

내가 놓친 부분은 restart가 컨테이너를 새로 만들지 않는다는 점이었다. 이미 만들어진 컨테이너의 환경변수는 파일을 고쳐도 자동으로 다시 읽히지 않았다.

설정이 실제로 어떻게 들어가는지 보기

먼저 Compose가 읽은 최종 설정을 확인했다.

docker compose --env-file .env.production config

여기서 값이 맞으면 파일 파싱 문제는 아니라고 볼 수 있다. 그 다음 실행 중인 컨테이너 안의 환경변수를 확인했다.

docker compose exec web printenv | sort | grep APP_

두 결과가 다르면 컨테이너 재생성이 필요한 상태다.

적용할 때 쓴 명령어

나는 운영에서는 아래처럼 서비스만 지정해서 다시 만들었다.

docker compose --env-file .env.production up -d --force-recreate web

이미지도 같이 바뀐 배포라면 pull 또는 build 단계가 앞에 있어야 한다.

docker compose --env-file .env.production pull web
docker compose --env-file .env.production up -d --force-recreate web

restart와 up을 구분하기

내 기준은 이렇게 잡았다.

• 프로세스만 다시 띄우면 되는 경우: restart
• 환경변수, 볼륨, 포트, 이미지 태그가 바뀐 경우: up -d
• 정말 같은 설정으로 다시 만들고 싶은 경우: --force-recreate

다음 배포부터 넣은 확인

배포 스크립트 마지막에 버전과 환경 이름만 짧게 찍도록 했다. 비밀값은 절대 출력하지 않고, 현재 컨테이너가 어느 설정 묶음으로 떴는지만 확인한다.

docker compose exec web node -e "console.log(process.env.APP_ENV)"

결론 대신 적어둔 문장

.env 파일을 고쳤다는 사실과 컨테이너가 그 값을 들고 있다는 사실은 다르다. Compose를 쓸 때는 최종 config와 컨테이너 내부 값을 따로 확인해야 덜 헤맨다.