2026년 11월 13일 금요일

GitOps 자동 배포가 "성공"인데 코드가 안 바뀔 때 — compose 의 pull_policy: build

push 만 하면 배포되도록 Portainer 의 GitOps 폴링을 켰는데, 배포 기록은 매번 성공인데도 사이트는 예전 코드 그대로였다. compose 파일에 한 줄이 빠져 있었다.

증상

  • 스택은 git 저장소 기반이고, 이미지는 레지스트리에서 받지 않고 build: . 로 서버에서 직접 빌드한다.
  • 폴링 주기마다 새 커밋을 잘 감지하고 "재배포 성공"으로 표시된다.
  • 그런데 컨테이너 안의 코드는 바뀌지 않는다. 컨테이너가 재생성조차 되지 않는 경우도 있다.

원인

docker compose up 은 서비스에 쓸 이미지가 이미 로컬에 있으면 다시 빌드하지 않는다. 처음 배포할 때 만든 이미지가 같은 이름으로 남아 있으니, 소스가 바뀌어도 compose 입장에서는 "이미지 있음, 할 일 없음"이다. 손으로 배포할 때는 --build 를 붙여서 몰랐던 문제가, 자동 재배포에서는 그 옵션이 붙지 않으면서 드러난 것이다.

해결

서비스에 pull_policy: build 를 넣는다. 이 값이면 compose 가 올릴 때마다 이미지를 빌드한다(바뀐 게 없으면 레이어 캐시 덕분에 금방 끝난다).

services:
  app:
    build: .
    pull_policy: build
    restart: unless-stopped

확인 방법

배포가 실제로 반영됐는지는 배포 기록이 아니라 결과물로 확인하는 편이 확실하다.

  • 이미지 생성 시각: docker image inspect <이미지> --format '{{.Created}}'
  • 앱이 빌드 시점의 커밋 해시나 버전을 응답에 내보내도록 해 두고 그것을 본다.

정리

레지스트리 없이 서버에서 빌드하는 구성으로 GitOps 를 쓸 때는 pull_policy: build 가 사실상 필수다. "성공"이라는 표시는 compose 명령이 오류 없이 끝났다는 뜻일 뿐, 새 코드가 올라갔다는 뜻이 아니다.

댓글 없음:

댓글 쓰기

반도체 주식을 보기 전에 그려 두는 지도 — 설계, 파운드리, 메모리, 장비, 소재, 후공정

"반도체주"라고 한 묶음으로 부르지만, 그 안의 회사들은 하는 일도 돈 버는 방식도 전혀 다르다. 같은 뉴스에 어떤 회사는 오르고 어떤 회사는 내리는 이유가 여기에 있다. 종목을 들여다보기 전에 머릿속에 그려 두면 좋은 지도를 정리한...