Docker 이미지가 최신 코드인지 확인하는 방법

Docker 배포가 성공했다고 표시되어도 실제 컨테이너가 최신 소스를 포함한다고 단정하면 안 된다. woosday 방문자 통계를 추가한 뒤 관리자 화면에 카드가 보이지 않는 문제가 있었다. 컨테이너 상태는 healthy였고 Tunnel도 실행 중이었지만, 실행 중인 이미지 안에는 이전 관리자 템플릿이 들어 있었다.

소스 변경부터 Docker 이미지 빌드와 컨테이너 실행, 실제 화면 검증까지의 절차

컨테이너 상태와 코드 버전은 다르다

docker compose up -d --force-recreate는 컨테이너를 새로 만들지만, 같은 이미지 태그를 계속 사용하면 애플리케이션 코드는 바뀌지 않는다. woosday-blog:local이라는 태그가 같다는 사실만으로 이미지 내용까지 같거나 다르다고 판단할 수 없다.

먼저 다음 정보를 확인한다.

docker compose ps
docker image inspect woosday-blog:local --format '{{.Id}} {{.Created}}'
docker inspect woosday-app-1 --format '{{.Image}} {{.Created}}'

컨테이너의 이미지 ID와 로컬 이미지 ID가 같아야 한다. 생성 시간이 배포 시점과 맞지 않거나, 소스 커밋 이후에도 이미지 ID가 바뀌지 않았다면 빌드가 실제로 새로 실행됐는지 다시 확인한다.

이미지 안의 산출물을 직접 확인한다

코드가 포함됐는지 가장 확실하게 확인하려면 실행 중인 JAR의 특정 파일을 읽는다. 운영 컨테이너에는 unzip이 포함되어 있으므로 다음처럼 템플릿 문자열을 검색할 수 있다.

docker exec woosday-app-1 sh -c "unzip -p /app/app.jar BOOT-INF/classes/templates/admin/dashboard.html | grep -n dailyVisitors"

새 기능의 식별자가 나오지 않으면 브라우저 캐시 문제가 아니다. 아직 이전 JAR가 실행 중인 것이다. 이 확인은 화면에 보이는 결과와 배포 산출물을 분리해서 판단하게 해 준다.

빌드 캐시를 의심할 때

일반적인 빌드는 변경된 레이어를 다시 만들지만, Dockerfile이나 빌드 컨텍스트가 예상과 다르면 캐시가 남을 수 있다. 원인을 확인해야 하는 상황에서는 한 번만 --no-cache로 빌드한다.

docker compose build --pull --no-cache app
docker compose --profile tunnel up -d --force-recreate

--no-cache는 매번 사용할 명령이 아니다. 의존성 다운로드와 전체 컴파일 시간이 늘어나므로, 문제를 해결한 뒤에는 일반 빌드로 돌아간다. 대신 배포 스크립트에 이미지 ID 확인이나 JAR 내부 식별자 검증을 추가하면 같은 실수를 빨리 발견할 수 있다.

Windows에서 생긴 추가 변수

Docker Desktop은 CLI 경로와 자격 증명 도우미 경로가 서로 다를 수 있다. 절대 경로로 docker.exe를 실행하더라도 이미지 레지스트리 인증 도우미가 PATH에서 발견되지 않으면 베이스 이미지 메타데이터를 읽지 못한다.

$env:Path = 'C:\Program Files\Docker\Docker\resources\bin;' + $env:Path
docker compose build --pull app

오류 메시지에 docker-credential-desktop을 찾을 수 없다고 나오면 빌드 자체가 시작되지 않은 것이다. 이후의 컨테이너 재생성 단계만 성공했더라도 최신 이미지가 만들어졌다고 보면 안 된다.

배포 후 최소 검증

배포 완료 문구보다 다음 네 가지를 확인한다.

  1. 로컬 health endpoint가 UP인지 확인한다.
  2. 공개 HTTPS health endpoint가 200을 반환하는지 확인한다.
  3. 새 기능을 식별하는 템플릿이나 API 응답이 이미지 안에 있는지 확인한다.
  4. 브라우저에서 강력 새로고침 후 실제 화면을 확인한다.

health check는 애플리케이션이 포트에서 응답한다는 뜻이지, 원하는 커밋이 실행된다는 뜻은 아니다. 배포를 자동화할수록 상태 확인과 버전 확인을 함께 넣어야 한다.

이번 문제를 겪고 deploy-woosday.ps1은 앱과 Tunnel을 강제 재생성하도록 정리했다. 그래도 이미지가 의심되면 위 명령으로 산출물을 직접 확인한다. 배포는 명령 한 줄의 성공보다 “어떤 코드가 실행됐는가”를 증명하는 과정에 가깝다.

함께 읽기: