- Docker의 기본 재부팅 정책을 사용하여 시스템 오류를 처리합니다.
- 비정상적인 상태의 컨테이너를 위한 사용자 지정 스크립트 및 cron 구현.
- 시스템d와의 고급 통합을 통해 시작 및 종료 순서를 제어합니다.
- Podman Quadlet과 같은 외부 모니터링 대안 및 도구.
분명 여러분도 이런 경험이 있으실 겁니다: 서비스가 실행 중인 상황인데... 도커 알 수 없는 이유로 며칠에 한 번씩 작동이 멈춥니다. Docker 컨테이너가 응답하지 않을 때 자동으로 다시 시작하는 방법은 무엇인가요? 코드나 설정을 최적화하려고 애썼는데 아무것도 작동하지 않다가, 간단히 수동으로 재부팅하니 문제가 해결되고 모든 것이 일주일 동안 문제없이 작동하는 것을 발견할 때면 정말 답답합니다. 끊임없이 시간을 확인하는 대신, 이런 번거로운 작업을 자동으로 처리해주는 시스템을 구축하는 것이 가장 이상적인 해결책입니다.
컨테이너 가용성을 관리하는 것은 서버 전원이 켜질 때 자동으로 시작되도록 하는 것 이상의 의미를 지닙니다. 그들이 올바르게 응답하도록 하십시오. 요청에 대한 응답입니다. 때때로 컨테이너는 Docker 측에서는 "활성" 상태로 보이지만 내부 애플리케이션은 응답하지 않는 경우가 있습니다. 이 경우 기본적인 데몬 매개변수 설정부터 운영 체제에 복잡한 서비스를 생성하는 것까지 다양한 해결책을 찾아야 합니다.
Docker 네이티브 재부팅 정책
Docker 컨테이너를 자동으로 재시작하는 가장 간단한 방법은 플래그를 사용하는 것입니다. --restart 컨테이너를 실행하거나 명령어를 사용할 때 docker update 컨테이너가 이미 생성된 경우 Docker는 필요에 따라 여러 옵션을 제공합니다. 예를 들어 정책이 있습니다. 언제나 이렇게 하면 프로세스가 오류로 종료되었는지 또는 Docker 데몬 자체가 재시작되었는지 여부와 관계없이 컨테이너가 항상 다시 시작됩니다.
보다 정밀한 방법을 선호하신다면, 정지하지 않는 한 이는 많은 사람들이 선택하는 최고의 방법입니다. 이 구성은 이전 구성과 동일하지만, 유지 보수를 위해 컨테이너를 수동으로 중지하는 경우를 제외하면 동일합니다. Docker는 해당 기능을 켜려고 시도하지 않습니다. 서버 재시작 후 자동으로 실행되며, 사용자의 수동 설정에 따라 처리됩니다.
중대한 실패에 대응해서만 행동하려는 사람들을 위해, 실패 시이 정책은 컨테이너가 0이 아닌 종료 코드로 종료될 경우에만 재시작을 트리거합니다. 최대 재시도 횟수를 추가하여 오류가 지속적이고 심각한 경우 시스템이 무한 재시작 루프에 빠지는 것을 방지할 수도 있습니다.
"상태 불량" 컨테이너에 대한 자동화
여기서부터 흥미로운 점이 생깁니다. 때때로 컨테이너는 여전히 "활성" (켜짐) 상태로 표시되지만 실제 상태는 그렇지 않은 경우가 있습니다. 위험한 내부 검사를 통과하지 못했기 때문입니다. 해당 프로세스가 기술적으로 중단된 것이 아니므로 기존 정책은 효과가 없습니다. 이를 해결하기 위해 지침을 시행할 수 있습니다. 건강 검진 Dockerfile 또는 Docker Compose 파일에서 명령(예: curl 특정 포트로 접속하여 앱이 응답하는지 확인합니다.
건강 진단 설정이 완료되면 다음을 생성할 수 있습니다. Bash 스크립트 몇 분마다 실행되는 것은 다음을 사용합니다. crontab Linux 환경에서 실행되는 스크립트입니다. 이 스크립트는 특정 상태에 있는 컨테이너를 필터링해야 합니다. unhealthy 또는 오류 코드 128로 종료한 후 다시 실행하는 사용자 docker restart 그들에 대해서.
이 기능이 원활하게 작동하고 Docker 컨테이너를 자동으로 재시작하려면 cron 작업을 실행하는 사용자에게 필요한 권한이 있어야 합니다. 도커 그룹에 필요한 권한이러한 방식으로 시스템은 5분 또는 10분마다 환경을 모니터링하고 "좀비"가 된 서비스를 다시 가동시켜 사람의 개입 없이 거의 완벽한 가용성을 보장합니다.
systemd와의 고급 통합
보다 전문적인 환경에서 작업할 때는 컨테이너가 다음과 같이 동작하기를 원할 수 있습니다. 네이티브 리눅스 서비스통합하다 도커 Systemd를 사용하면 웹 애플리케이션보다 데이터베이스가 먼저 시작되도록 하는 것과 같은 복잡한 종속성을 관리할 수 있습니다. 이는 파일을 생성함으로써 구현됩니다. .service 경로에서 /etc/systemd/system/.
우리는 디자인할 수 있습니다 전원 끄기 및 전원 켜기 순서 제어 가능. systemd에 연결된 사용자 지정 스크립트를 사용하면 데이터 손상을 방지하기 위해 컨테이너의 종속성 역순으로 컨테이너를 중지할 수 있습니다. oneshot 그리고 구성하기 targets 적합한 (예를 들면) multi-user.target o shutdown.target), 서버는 컨테이너의 전체 수명 주기를 관리합니다.
Docker 컨테이너가 응답하지 않을 때 자동으로 다시 시작하는 또 다른 강력한 방법은 플래그를 사용하는 것입니다. --rm systemd와 함께 사용하면 컨테이너가 중지될 때 제거되고 시작 시 기본 이미지에서 새 컨테이너가 생성되어 안정적인 운영을 보장합니다. 용기의 상태는 항상 깨끗하고 변함없어야 합니다.데이터 영구 저장을 전적으로 외부 저장 장치에 위임합니다.
외부 도구 및 현대적인 대안
Bash 스크립트를 직접 작성하고 싶지 않다면 타사 도구를 사용할 수 있습니다. 특정 조건에 따라 컨테이너를 재시작하도록 설계된 오픈 소스 애플리케이션도 있습니다. 정해진 일정이는 SSL 인증서 갱신과 같은 반복적인 작업에 매우 유용합니다. 마찬가지로, 다음과 같은 도구들도 유용합니다. 업타임 쿠마 이러한 도구를 사용하면 시각적 대시보드에서 서비스 상태를 모니터링하고 문제가 발생하면 텔레그램이나 고티파이로 알림을 보낼 수 있습니다. 또한 도커 컨테이너가 응답하지 않을 때 자동으로 재시작하는 데 매우 유용합니다.
좀 더 가볍거나 현지적인 대안을 찾는 분들을 위해, 포드맨 정말 훌륭한 선택입니다. 데몬이 필요 없는 아키텍처와 뛰어난 기능 덕분입니다. 쿼드릿이를 통해 systemd가 자동으로 최적화된 서비스로 변환하는 간단한 선언적 파일을 생성할 수 있으므로 기존 Docker보다 훨씬 더 자연스러운 통합을 제공합니다.
서비스 수명주기를 완벽하게 제어하려면 다음 기술들을 결합하여 사용해야 합니다. 재시작 정책지속적인 감시를 통해 건강 검진 그리고 더 복잡한 경우에는 지원이 필요합니다. systemd 또는 모니터링 도구 이렇게 하면 인프라가 견고해지고 누군가가 매주 수동으로 서버를 재시작해야 하는 번거로움에 의존하지 않게 됩니다.
다양한 디지털 미디어 분야에서 10년 이상의 경험을 보유한 기술 및 인터넷 문제 전문 편집자입니다. 저는 전자상거래, 커뮤니케이션, 온라인 마케팅 및 광고 회사에서 편집자이자 콘텐츠 제작자로 일했습니다. 나는 또한 경제, 금융 및 기타 분야 웹사이트에 글을 썼습니다. 내 일은 또한 나의 열정이다. 이제 내 기사를 통해 Tecnobits, 저는 기술 세계가 우리 삶을 개선하기 위해 매일 제공하는 모든 뉴스와 새로운 기회를 탐색하려고 노력합니다.