Docker Stop vs. Kill 비교: 각 명령어를 언제 사용해야 하는가?
Docker 컨테이너를 관리할 때, 컨테이너를 종료하는 방식의 미묘한 차이를 이해하는 것은 애플리케이션 안정성과 데이터 무결성에 매우 중요합니다. 컨테이너를 중지하는 두 가지 주요 명령어는 docker stop과 docker kill입니다. 둘 다 실행 중인 컨테이너를 중지하는 목표를 달성하지만, 작동 방식이 매우 다르고 고유한 사용 사례를 가집니다. 올바른 명령어를 선택하는 것은 데이터 손실을 방지하고, 애플리케이션의 정상적인 종료를 보장하며, 문제 해결에 도움이 될 수 있습니다.
이 글에서는 docker stop과 docker kill의 핵심적인 차이점을 자세히 알아보고, 그들의 기본적인 메커니즘을 탐구하며, 최적의 컨테이너 관리를 위해 각 명령어를 언제 사용해야 하는지에 대한 명확한 지침을 제공할 것입니다. 이러한 차이점을 이해함으로써 Docker 워크플로우를 개선하고, 종료 시퀀스 중에도 애플리케이션이 예측 가능하게 동작하도록 보장할 수 있습니다.
docker stop 이해하기
docker stop 명령어는 컨테이너의 정상적인 종료를 위해 설계되었습니다. docker stop <container_id>를 실행하면 Docker는 컨테이너 내부에서 실행 중인 주 프로세스에 SIGTERM 신호를 보냅니다. SIGTERM 신호는 프로세스에게 스스로를 깨끗하게 종료하도록 요청하는 것입니다. 이는 컨테이너 내부의 애플리케이션이 다음을 수행할 기회를 가짐을 의미합니다:
- 현재 상태 저장.
- 열려 있는 네트워크 연결 닫기.
- 보유하고 있는 리소스 해제.
- 진행 중인 모든 작업 완료 (예: 데이터를 디스크에 쓰는 작업).
SIGTERM 신호를 보낸 후 Docker는 기본 유예 기간인 10초를 기다립니다. 이 기간 내에 컨테이너 내부의 프로세스가 종료되면 컨테이너는 성공적으로 중지된 것으로 간주됩니다. 그러나 프로세스가 유예 기간 내에 종료되지 않으면 Docker는 SIGKILL 신호를 보내 강제로 종료합니다.
docker stop 작동 방식:
SIGTERM전송: Docker는 컨테이너 내의 기본 프로세스(PID 1)에SIGTERM신호를 보냅니다.- 유예 기간 대기: Docker는 구성 가능한 기간(기본값 10초)을 기다립니다.
SIGKILL전송 (필요한 경우): 유예 기간이 끝날 때까지 프로세스가 종료되지 않으면 Docker는SIGKILL신호를 보냅니다.
docker stop 사용 시점:
- 정상적인 애플리케이션 종료: 데이터베이스, 웹 서버 또는 중요한 쓰기 작업을 수행하는 애플리케이션과 같이 깨끗하게 종료되어야 하는 애플리케이션을 중지하는 데 선호되는 방법입니다.
- 개발 환경: 개발 중 일상적인 중지를 위해
docker stop은 진행 중인 프로세스를 실수로 중단하지 않도록 보장합니다. - 예정된 유지보수를 위한 프로덕션 환경: 서비스를 다시 시작하거나 업데이트를 수행해야 할 때
docker stop은 애플리케이션이 작업을 마칠 수 있도록 합니다.
예시:
# 'my-web-server'라는 컨테이너 시작
docker run -d --name my-web-server -p 80:80 nginx
# 컨테이너를 정상적으로 중지
docker stop my-web-server
# 컨테이너가 중지되었는지 확인
docker ps -a | grep my-web-server
docker kill 이해하기
반면, docker kill 명령어는 컨테이너를 즉각적이고 강제적으로 종료하도록 설계되었습니다. docker kill <container_id>를 실행하면 Docker는 컨테이너 내부에서 실행 중인 주 프로세스에 SIGKILL 신호를 직접 보냅니다. SIGTERM과 달리 SIGKILL 신호는 프로세스에 의해 catch되거나, 무시되거나, 처리될 수 없습니다. 이는 운영 체제에게 아무런 정리 기회도 주지 않고 프로세스를 즉시 종료하도록 지시합니다.
이는 저장되지 않은 데이터, 열려 있는 연결 또는 진행 중인 모든 작업이 갑자기 중단될 것임을 의미합니다. 이는 이러한 갑작스러운 종료를 처리하도록 설계되지 않은 애플리케이션의 경우 데이터 손상 또는 일관되지 않은 상태로 이어질 수 있습니다.
docker kill 작동 방식:
SIGKILL전송: Docker는 컨테이너 내의 기본 프로세스(PID 1)에SIGKILL신호를 직접 보냅니다.- 즉시 종료: 프로세스는 운영 체제에 의해 즉시 종료됩니다.
docker kill 사용 시점:
- 응답 없는 컨테이너: 컨테이너가 멈춰서
docker stop이 유예 기간이 지난 후에도 종료하지 못했을 때. - 비상 중단: 보안 사고나 치명적인 오류와 같이 결과에 관계없이 컨테이너를 즉시 중지해야 하는 상황에서.
- 복원력 테스트: 애플리케이션이 갑작스러운 종료 조건에서 어떻게 작동하는지 이해하기 위함 (일반적인 사용보다는 테스트 목적).
예시:
# 'my-test-app'이라는 컨테이너 시작
docker run -d --name my-test-app ubuntu sleep infinity
# 컨테이너를 강제로 종료
docker kill my-test-app
# 컨테이너가 중지되었는지 확인
docker ps -a | grep my-test-app
주요 차이점 요약
| 기능 | docker stop |
docker kill |
|---|---|---|
| 전송 신호 | SIGTERM (유예 기간 만료 시 SIGKILL) |
SIGKILL |
| 종료 | 정상적, 정리 허용 | 즉각적, 강제적, 정리 없음 |
| 데이터 무결성 | 일반적으로 데이터 무결성 유지 | 데이터 손상 또는 일관성 없는 상태 위험 |
| 사용 사례 | 정상 종료, 예정된 유지보수 | 응답 없는 컨테이너, 비상 중단 |
| 유예 기간 | 예 (기본 10초) | 아니요 |
모범 사례 및 고려 사항
- 항상
docker stop을 먼저 시도하세요: 일상적인 작업에는docker stop이 기본 선택이어야 합니다. 이는 애플리케이션과 데이터를 보호합니다. - 애플리케이션의 신호 이해: 애플리케이션은
SIGTERM신호를 처리하도록 프로그래밍될 수 있습니다. 애플리케이션의 진입점 스크립트 또는 프로세스 관리자가SIGTERM을 수신하고 정상적으로 응답하도록 설정되어 있는지 확인하십시오. docker stop의 유예 기간 조정:-t또는--time플래그를 사용하여docker stop에 대한 사용자 지정 유예 기간을 지정할 수 있습니다. 예를 들어,docker stop -t 30 my-container는 컨테이너에게 종료하는 데 30초를 줍니다.docker kill은 최후의 수단으로 사용:docker stop이 효과가 없거나 중요하고 긴급한 상황에서만docker kill을 사용하십시오.- 컨테이너 상태 모니터링: Docker 설정에 상태 확인을 구현하면 응답하지 않는 컨테이너를 식별하는 데 도움이 되어
docker kill이 필요하기 전에 잠재적으로 문제를 해결할 수 있습니다.
결론
docker stop과 docker kill은 모두 Docker 컨테이너를 관리하기 위한 필수 도구이지만, 서로 다른 목적을 가지고 있습니다. docker stop은 정상적인 종료를 허용하고, 데이터 무결성을 보존하며, 정리 기회를 제공함으로써 애플리케이션 상태를 우선시합니다. docker kill은 즉각적이고 강제적인 종료를 제공하며, 데이터 손실의 위험을 감수하더라도 속도가 가장 중요한 응답 없는 컨테이너 또는 비상 상황을 위해 가장 적합합니다.
특정 시나리오에 따라 적절한 명령어를 이해하고 적용함으로써 더 강력하고 신뢰할 수 있는 컨테이너화된 애플리케이션을 유지할 수 있습니다. 항상 더 부드러운 접근 방식인 docker stop을 선호하고, 모든 다른 옵션이 실패했거나 즉각적인 종료가 절대적으로 필요한 경우에만 docker kill을 사용하십시오.