Docker 재시작 정책을 데이터베이스, 워커 및 웹 앱에 맞추는 방법

Compose 파일의 모든 컨테이너에 unless-stopped를 지정하기보다 서비스 수명 주기와 종료 의미에 맞춰 Docker 재시작 정책을 선택하세요.

재시작 정책은 컨테이너의 주 프로세스가 종료될 때 반응합니다. 반면 상태 점검은 실행 중인 프로세스를 비정상으로 표시할 수 있지만 자동으로 재시작하지는 않습니다. 따라서 데이터베이스, 워커, 웹 앱, 마이그레이션, 예약 작업은 계속 실행되어야 하는지, 정상 종료가 무엇을 의미하는지, 반복되는 오류를 어떻게 표시해야 하는지에 따라 서로 다른 설정이 필요합니다.

재시작 동작과 상태 및 준비 상태를 분리하세요

재시작 정책은 프로세스가 중지된 후 Docker가 컨테이너를 다시 시작할지 결정합니다. 상태 점검은 실행 중인 서비스가 정의된 작업을 수행할 수 있는지 확인합니다. 의존성 준비 상태는 다른 서비스가 아직 시작해도 되는지 판단합니다. 서로 관련되어 있지만 해결하는 문제는 다릅니다.

2026년 글인 상태 점검과 재시작은 별개입니다에서는 이러한 구분을 설명하고, 서비스가 실제로 준비될 때까지 Compose 상태 조건으로 종속 서비스의 시작을 지연하는 방법을 보여줍니다.

종료하지 않는 비정상 웹 프로세스를 restart: always가 복구해 줄 것이라고 기대하지 마세요. 상태 점검만으로 해당 프로세스가 재시작될 것이라고 기대해서도 안 됩니다. 계속 실행하는 것이 안전하지 않을 때 애플리케이션이 종료되도록 하거나, 외부 복구 메커니즘을 추가하거나, 서비스 설계에 따라 비정상 상태를 알리세요.

장기 실행 데이터베이스에는 지속적인 재시작 정책을 사용하세요

홈 서버의 데이터베이스는 일반적으로 호스트나 Docker 데몬이 재시작된 후 다시 실행되어야 합니다. 관리자가 의도적으로 중지한 상태를 존중해야 한다면 unless-stopped가 실용적인 기본값인 경우가 많습니다. 재부팅 시 수동 중지 상태를 무시하도록 설계했다면 always가 적합합니다.

2026년 7월 글인 재시작 정책은 프로세스 종료를 따릅니다에서는 no, on-failure, always, unless-stopped의 차이와 정책이 상태가 아니라 프로세스 종료에 반응한다는 점을 자세히 설명합니다.

데이터베이스에는 실제 상태 점검과 영구 저장소도 필요합니다. PostgreSQL을 반복해서 재시작해도 디스크 가득 참, 잘못된 구성, 손상된 상태 또는 호환되지 않는 마이그레이션은 해결할 수 없습니다. 반복되는 재시작을 성공적인 복원력으로 간주하지 말고 이에 대해 알림을 설정하세요.

큐와 종료 의미에 따라 워커 정책을 선택하세요

장시간 실행되는 큐 워커가 항상 작업을 소비해야 한다면 unless-stopped를 사용할 수 있습니다. 유한한 워커나 배치 프로세스는 on-failure:N을 사용해 일시적인 오류에는 제한된 재시도를 적용하고, 지속적인 오류가 발생하면 명확하게 중지되도록 할 수 있습니다.

최신 글인 제한된 on-failure 재시도에서는 프로세스가 영구적으로 실행되어야 하는지 또는 정상적으로 완료되어도 되는지에 맞춰 재시도 동작을 정해야 한다고 강조합니다.

워커 이미지에서 종료 코드 0이 무엇을 의미하는지 파악하세요. “작업 완료”를 의미한다면 always는 성공적으로 끝난 일회성 작업을 무한 반복으로 바꿀 수 있습니다. 워커가 데몬으로 실행되도록 설계되었다면, 예상치 못한 정상 종료에도 unless-stopped를 통한 자동 재시작이 필요할 수 있습니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

웹 앱은 장기 실행하되 실제 의존성에 따라 시작을 제어하세요

대부분의 셀프 호스팅 웹 애플리케이션은 계속 사용할 수 있어야 하므로, 일반적으로 제한된 오류 전용 정책보다 unless-stopped가 이해하고 관리하기 쉽습니다. 재시작 설정이 데이터베이스, 캐시, DNS, 시크릿 및 마운트된 경로가 준비되어야 한다는 필요성을 없애 주지는 않습니다.

관련 ZimaSpace 진단 글인 컨테이너 의존성으로 인한 재시작 루프에서는 눈에 보이는 앱을 반복해서 재시작하면 먼저 발생한 데이터베이스, 캐시, 마운트, 마이그레이션 또는 메모리 오류가 가려질 수 있는 이유를 설명합니다.

적절한 경우 시작 순서를 제어하기 위해 의존성 상태 점검을 사용하고, 애플리케이션의 재시도 동작에는 제한을 두세요. PostgreSQL이 시작될 때까지 웹 서비스가 5초마다 충돌하는 것보다, 준비 상태를 기다린 후 한 번의 명확한 시작 과정을 수행하는 편이 관찰하기 쉽습니다.

마이그레이션과 일회성 작업에는 유한한 수명 주기를 부여하세요

마이그레이션 컨테이너, 가져오기 도구, 유지 관리 작업 및 일회성 초기화 작업은 일반적인 데몬이 아닙니다. 이들의 성공 상태는 대개 “코드 0으로 종료하고 중지된 상태로 유지”하는 것입니다. always 또는 unless-stopped를 사용하면 완료된 작업이 의도치 않게 다시 실행될 수 있습니다.

일회성 운영 도구는 명시적으로 유지하여 숨겨진 상시 실행 서비스가 되지 않도록 하세요. 마이그레이션이나 가져오기 도구는 명령이 종료된 후에도 유한한 성공 상태가 드러나야 합니다.

실패 시 검사를 위해 중지해야 한다면 restart: "no"를 사용하세요. 명령을 다시 실행해도 안전한 경우에만 제한된 on-failure를 사용하세요. 스키마 마이그레이션은 재시도를 자동화하기 전에 부분적으로 적용된 마이그레이션의 반복 실행을 지원하는지 확인해야 합니다.

실제 장애 상황으로 정책을 테스트하세요

각 서비스에 대해 정상 프로세스 종료, 0이 아닌 오류로 인한 충돌, 호스트 재부팅, Docker 데몬 재시작, 수동 중지, 실행 중이지만 비정상인 상태, 사용할 수 없는 의존성을 테스트하세요. 구성을 복원력 있다고 판단하기 전에 각 상황 이후에 예상되는 상태를 기록하세요.

재시작 횟수를 추적하고 일정 시간 내 횟수가 낮은 임계값을 넘으면 알림을 설정하세요. 자동 재시작은 일시적인 오류로부터의 복구 시간을 줄여야 하지만, 새로운 컨테이너를 끝없이 생성해 지속적인 충돌을 보이지 않게 만들어서는 안 됩니다.

좋은 정책 매트릭스는 명확합니다. 장기 실행 데이터베이스와 웹 앱은 인프라 재시작 후 다시 실행되고, 데몬 워커는 큐의 의미에 따라 복구되며, 유한한 작업은 완료되면 중지되고, 상태 및 준비 상태 점검은 재시작 정책으로는 확인할 수 없는 오류를 드러냅니다.