Docker 의 Healthcheck 체크

Docker 의 Healthcheck 체크

 

도커는 이미지가 올라가고 컨테이너가 실행되면 기본적인 헬스 체크를 합니다. 예를들어 자바 , 혹은 닷넷 프레임 워크 같은 특정한 프로세스가 실행되는데 도커가 확인하는 것은 이 프로세스의 실행 상태입니다.

 

그리고 이 실행상태가 비정상 적 으로 종료가 될 경우 컨테이너 또한 종료가 됩니다.

 

클러스터 환경에서 플랫폼이 종료되면 컨테이너를 재시작 하거나 새 컨테이너 로 교체하는 작업을 대신 해준다. 그러나 이정도 에서 보장되는 것은 프로레스가 실행 상태라는 점 뿐이지 애플리케이션이 정상적으로 동작하는 상태를 확인하는 건 아니다. 

 

웹 애플리케이션 의 경우 API 를 호출 할 경우 트래픽이 과하게 몰릴경우 503 에러를 뿜 을 것이다. 하지만 여전히 컨테이너는 해당 웹 애플리케이션 멈췄다고 하여도 도커는 정상적으로 동작 중이라 인식하고 판단한다.

 

그래서 도커는 애플리 케이션의 상태가 실제로 정상인지 체크하는 기능을 제공한다. Dockerfile 작성시 상태 확인을 위한 로직을 추가하는 것이다. 

 

Dockerfile 작성시 다음과 같은 HEALTHCHECK 구문을 추가해주면 된다. 

HEALTHCHECK CMD curl --fail http://localhost/check

 

HEALTHCHECK  구문의 경우 도커 컨테이너 안에서 실행하는 명령을 지정하게 된다 이 명령이 반환하는 상태코드를 보고 애플리케이션의 상태를 확인한다.

 

컨테이너의 상태는 총 3가지의 상태가 존재하며 'Starting' 의 초기 상태 , HEALTHCHECK 가 통과 했을때의 'healthy' 와 그리고 HEALTHCHECK  를 통과 못했을 때의 'unhealthy' 가 존재한다. 

 

--fail 옵션을 붙이면 curl 이 전달받은 상태코드를 도커에 전달하고 요청에 성공할경우 0 을 반환 하며 실패할경우 0 이외의 다른 값을 반환한다. 

 

HEALTHCHECK  는 몇초 간격으로 계속 실행되며 이때 우리가 지정한 명령어가 실행됩니다.  

 

더 자세한 사항은 공식 문서 참고:

https://docs.docker.com/engine/reference/builder/

Dockerfile reference

 

길벗 출판사의 도커 교과서 예시를 아래에 적습니다. 

도커 교과서 : 네이버 도서

(PS. 굉장히 만족하면서 공부중 도커에 관심있는 분들은 꼭 사는걸 추천드림)

 

컨테이너를 실행하면 다음과 같이 status 에 정상적으로 health:starting 인 것을 확인할수 있습니다.

 

이후 특정 URL 을 호출하여 의도적으로 애플리케이션을 먹통으로 만들었습니다.

 

다시 컨테이너 목록을 검색해보면 status 가 unhealthy 로 바뀐 것을 확인할수 있습니다. 

 

 

컨테이너 안에서 테스트 이후 그 결과를 도커가 전달 받았으나 재시작 하거나 컨테이너를 교체하지 않는 이유는 도커가 해당 작업을 안전하게 처리할수 없기 때문이다.  

 

도커 엔진은 단일서버에 동작하는데 해당 컨테이너를 재시작 하거나 컨테이너를 교체하는 동안 해당 애플리케이션을 죽어 있는 상태이다. 

 

컨테이너를 제거한 이후 다시 실행하게 될경우 컨테이너 안의 데이터가 유실되거 할 가능성도 존재하기 때문이며

도커 가 만약 컨테이너를 재시작한다고 하여도 해결이 될 거라는 보장이 없기 때문이다. 

 

그렇기 때문에 컨테이너를 그대로 두는 것 이다.

 

다음은 Chat.GPT 를 통해 얻은 답변입니다.

https://chat.openai.com/share/0db71e5e-302b-4b12-b168-09888a878c4e

ChatGPT

도커에서 헬스 체크 이후 컨테이너를 재시작하지 않거나 교체하지 않는 이유는 다양합니다. 헬스 체크는 컨테이너가 정상적으로 작동하는지 확인하는 기능으로, 주기적으로 컨테이너의 상태를 모니터링하고 문제가 발생했을 경우 적절한 조치를 취할 수 있습니다. 하지만 바로 컨테이너를 재시작하거나 교체하는 것이 항상 옳은 선택은 아닙니다.

재시작과 교체에 따른 서비스 중단: 컨테이너를 재시작하거나 교체하는 과정은 일시적인 중단이 발생할 수 있습니다. 특히, 헬스 체크에 문제가 없어도 재시작이나 교체로 인해 서비스가 잠시 중단될 수 있으며, 이는 사용자 경험에 영향을 줄 수 있습니다.

비용과 자원 관리: 컨테이너를 재시작하거나 교체하는 것은 일시적으로 자원을 추가로 소비하게 됩니다. 컨테이너를 재시작하면 컨테이너가 다시 시작될 때 초기화 과정이 발생하고, 컨테이너를 교체하면 새로운 컨테이너를 생성하고 실행해야 합니다. 이로 인해 서버 자원의 비효율적인 사용이 발생할 수 있습니다.

문제의 원인 해결: 헬스 체크는 컨테이너가 동작하는지 여부만을 확인하는 것으로, 문제가 발생한 원인을 해결하지는 않습니다. 문제가 재발하는 경우, 해당 문제를 진단하고 해결하는 과정이 필요합니다. 단순히 재시작하거나 교체하는 것만으로는 지속적인 안정성 확보가 어려울 수 있습니다.

로드 밸런싱과 확장성: 컨테이너를 재시작하거나 교체할 때마다, 로드 밸런싱된 환경에서 컨테이너를 재배치하고 확장하는 과정이 필요할 수 있습니다. 이로 인해 추가적인 설정과 관리가 필요할 수 있으며, 불필요한 리소스 소비를 유발할 수 있습니다.