Docker Stop vs. Kill 비교: 각 명령어를 사용해야 하는 경우

컨테이너를 종료해야 할 때 docker stop과 docker kill은 서로 대체할 수 없습니다. 이 차이는 앱이 데이터를 쓰거나, 네트워크 연결을 유지하거나, 종료 전에 정리 시간이 필요할 때 가장 중요합니다.

정상적인 종료에는 docker stop을 사용하세요. 일반적으로 컨테이너가 정상 종료를 무시했거나 장애 동작을 테스트하는 경우와 같이 즉각적인 신호가 필요할 때 docker kill을 사용하세요.

docker stop 이해하기

docker stop 명령어는 컨테이너의 메인 프로세스에게 정상적으로 종료하도록 요청합니다. 기본적으로 Docker는 컨테이너 내부의 PID 1에게 SIGTERM을 보내고, 유예 기간 동안 기다린 후 프로세스가 계속 실행 중이면 SIGKILL을 보냅니다.

첫 번째 신호는 이미지의 STOPSIGNAL 명령어나 컨테이너 생성 시 사용된 --stop-signal 옵션으로 변경할 수 있습니다. 하지만 대부분의 일상적인 경우 docker stop은 "앱에 종료 요청을 보내고, 종료하지 않을 경우에만 강제 종료한다"고 생각하면 됩니다.

• 현재 상태를 저장합니다.
• 열려 있는 네트워크 연결을 닫습니다.
• 보유한 리소스를 해제합니다.
• 진행 중인 작업(예: 디스크에 데이터 쓰기)을 완료합니다.

Linux 컨테이너에서 기본 대기 시간은 일반적으로 10초입니다(컨테이너에 대해 다른 중지 시간 제한이 설정되지 않은 경우). Windows 컨테이너는 더 긴 기본값을 사용합니다. 명령어마다 -t 또는 --time으로 대기 시간을 재정의할 수 있습니다.

docker stop 작동 방식

1. SIGTERM 전송: Docker는 컨테이너 내의 기본 프로세스(PID 1)에 SIGTERM 신호를 보냅니다.
2. 유예 기간 동안 대기: Docker는 프로세스가 종료될 때까지 기다립니다.
3. 필요시 SIGKILL 전송: 유예 기간이 끝날 때까지 프로세스가 종료되지 않으면 Docker는 SIGKILL 신호를 보냅니다.

docker stop을 사용해야 하는 경우

• 정상적인 애플리케이션 종료: 데이터베이스, 웹 서버 또는 중요한 쓰기 작업을 수행하는 애플리케이션과 같이 정상적으로 종료해야 하는 애플리케이션을 중지하는 기본 방법입니다.
• 개발 환경: 개발 중 일상적인 중지의 경우 docker stop은 진행 중인 프로세스를 실수로 중단하지 않도록 합니다.
• 계획된 유지보수를 위한 프로덕션 환경: 서비스를 재시작하거나 업데이트를 수행해야 할 때 docker stop은 애플리케이션이 작업을 완료할 수 있도록 합니다.

예시

# 'my-web-server'라는 이름의 컨테이너 시작
sudo docker run -d --name my-web-server -p 80:80 nginx

# 컨테이너를 정상적으로 중지
sudo docker stop my-web-server

# 컨테이너가 중지되었는지 확인
sudo docker ps -a | grep my-web-server

앱이 큐를 비우거나 데이터베이스 연결을 닫는 데 더 많은 시간이 필요하다면 더 긴 시간 제한을 설정하세요:

sudo docker stop --time 30 my-web-server

docker kill 이해하기

docker kill 명령어는 컨테이너의 메인 프로세스에 즉시 신호를 보냅니다. 기본적으로 이 신호는 SIGKILL입니다. SIGTERM과 달리 SIGKILL은 프로세스가 포착, 무시 또는 처리할 수 없습니다. 운영 체제는 프로세스에게 정리할 기회를 주지 않고 프로세스를 종료합니다.

즉, 저장되지 않은 데이터, 열린 연결 또는 진행 중인 쓰기 작업이 중단될 수 있습니다. 상태 비저장 테스트 컨테이너는 문제가 되지 않을 수 있습니다. 하지만 데이터베이스, 큐 워커 또는 파일 처리 작업은 영향을 받을 가능성이 높습니다.

docker kill --signal을 사용하여 SIGHUP과 같은 다른 신호를 보낼 수도 있지만, 정상 종료가 목적이라면 docker stop이 일반적으로 더 명확합니다.

docker kill 작동 방식

1. SIGKILL 전송: Docker는 컨테이너 내의 기본 프로세스(PID 1)에 직접 SIGKILL 신호를 보냅니다.
2. 즉시 종료: 운영 체제에 의해 프로세스가 종료됩니다.

docker kill을 사용해야 하는 경우

• 응답하지 않는 컨테이너: 컨테이너가 멈춰서 유예 기간 후에도 docker stop이 종료에 실패한 경우.
• 긴급 중지: 보안 사고나 심각한 장애와 같이 결과에 관계없이 컨테이너를 즉시 중지해야 하는 상황.
• 복원력 테스트: 정리 과정 없이 프로세스가 사라질 때 애플리케이션이 어떻게 동작하는지 확인하기 위해.

예시

# 'my-test-app'이라는 이름의 컨테이너 시작
sudo docker run -d --name my-test-app ubuntu sleep infinity

# 컨테이너를 강제로 종료
sudo docker kill my-test-app

# 컨테이너가 중지되었는지 확인
sudo docker ps -a | grep my-test-app

주요 차이점 요약

특징	docker stop	docker kill
전송 신호	일반적으로 SIGTERM, 시간 초과 시 SIGKILL	기본적으로 SIGKILL
종료 방식	정상 종료, 정리 작업 허용	즉시 강제 종료, 정리 작업 없음
데이터 무결성	일반적으로 데이터 무결성 유지	데이터 손상 또는 불일치 상태 위험
사용 사례	정상 종료, 계획된 유지보수	응답하지 않는 컨테이너, 긴급 중지
유예 기간	있음	없음

모범 사례 및 고려 사항

• 항상 docker stop을 먼저 시도하세요: 일상적인 작업에서는 docker stop을 기본 선택으로 해야 합니다. 애플리케이션과 데이터를 보호합니다.
• 애플리케이션의 신호를 이해하세요: 애플리케이션은 SIGTERM 신호를 처리하도록 프로그래밍될 수 있습니다. 애플리케이션의 진입점 스크립트 또는 프로세스 관리자가 SIGTERM을 수신 대기하고 정상적으로 응답하도록 설정되어 있는지 확인하세요.
• docker stop의 유예 기간 조정: -t 또는 --time 플래그를 사용하여 docker stop의 사용자 지정 유예 기간을 지정할 수 있습니다. 예를 들어, sudo docker stop -t 30 my-container는 컨테이너가 종료되는 데 30초를 줍니다.
• 최후의 수단으로 docker kill 사용: docker stop이 효과가 없거나 중요하고 긴급한 상황에서만 docker kill에 의존하세요.
• 컨테이너 상태 모니터링: Docker 설정에 상태 확인(health check)을 구현하면 응답하지 않게 되는 컨테이너를 식별하여 docker kill이 필요해지기 전에 문제를 해결할 수 있습니다.
• PID 1 동작 확인: 셸 래퍼 스크립트는 실제 앱 프로세스로 신호를 전달하지 않으면 신호를 삼킬 수 있습니다. 진입점 스크립트에서 exec를 사용하여 앱이 종료 신호를 직접 수신하도록 하는 것이 좋습니다.

실용적인 핵심 내용

특히 상태 저장(stateful) 작업의 경우 docker stop을 일반적인 습관으로 만드세요. 컨테이너가 응답하지 않거나, 속도가 정리 작업보다 중요하거나, 의도적으로 충돌 동작을 테스트하는 경우에만 docker kill을 사용하세요.