배포 전략 - init container 이용하여 소스 파일 받아오기

개발 환경이나 테스트 환경은 매일 배포가 돌아가고 있는 상황에

개발 환경을 쿠버네티스로 전환하였더니 문제가 발생했다.

 

톰캣 기동 중에 참조하는 소스파일에 변화가 생겨 파드가 멈추는 현상이었다.

톰캣의 app base로 지정한 폴더와 nas가 nfs로 마운트 되어있다보니

실시간으로 배포가 반영되어 생기는 현상이다.

 

 

이를 해결하기 위해 중요하게 생각했던 점은

 

1. 배포가 완료되면 파드가 업데이트

2. 서비스에는 영향이 없어야함

 

이렇게 2가지 였다.

 

모든 파드가 연결이 죽는 경우를 제외하고 다른 문제가 있는지 확인해보았다.

 

톰캣 기동시간이 400초에서 500초 정도로 상당히 긴것을 확인했다(최대는 600초이상)

Probe의 설정값에 맞지 않아 재시작하는 경우도 발생했다.

톰캣 기동시에 소스 파일을 스캔하고 파싱하는 과정이 상당히 오래걸리는 것을 확인했다.

소스 파일이 있는 디렉토리가 nas와 마운트 되어 있다 보니

 

단순히 cat 명령어로 파일목록을 읽기만 하는 작업도

컨테이너 이전의 환경과 비교하면 6배나 느렸다.

 

 

고민하던 중에

airflow가 DAG파일을 git에서 pull하는 방식이 생각났다.

airflow에서는 init container를 이용하여 기동시에 git에 있는 DAG파일을 가져오고

sidecar를 이용해 특정 주기마다 체크하여 추가되거나 변경사항이 생긴 DAG파일을 가져온다.

 

init container가 git에서 소스를 받아오면 emptyDir과 마운트된 폴더에 소스를 이동시키고

main container가 emptyDir의 그 폴더에 마운트하여 옮겨진 소스파일을 사용하는 방식이다.

init container, sidecar container, tomcat container는 다 같은 파드에 있다.

위와 같이 init container로 pull을 받아 emptyDir storage로 넘기고

was container에서는 emptyDir과 AppBase 폴더를 마운트하는 방식이다.

같은 파드 내부에 있다보니 톰캣이 소스파일을 스캔하거나 파싱하는 속도가 비약적으로 상승했다.

646초에서 189초로 약 70%정도 감소

 

배포 후 파드가 새로 생성될 때도

기존의 파드는 각자의 소스파일을 갖고 있어 영향을 미치지 않았다.