젠킨스를 이용한 CI/CD 구현
Docker 공부와 프로젝트 배포 작업을 진행하면서 한 가지 욕심이 생겼다. 프로젝트의 배포과정에서 CI/CD 환경을 한 번 구성 해보고 경험하고 싶다는 생각이 든 것이다. 사실 OTT 프로젝트의 실질적인 개발단계는 이미 끝났긴 했지만 아직 기능적으로 몇 가지 수정했으면 하는 것들 그리고 추가로 구현하고 싶었던 부분들이 몇 군데 존재했기 때문에 해당 작업들을 CI/CD 환경에서 진행하면 좋을 것 같다는 생각이 들었다. 간단한 CI/CD 환경을 구성하는 것이 그렇게 어려울 것도 없어 보였기 때문에 일단은 진행해 보기로 하였다.
젠킨스 서버의 도커환경 구성
젠킨스 서버를 EC2 호스트 서버에서 컨테이너로 띄우고 이후 운영을 준비하는 과정에서 한 가지 고민이 들었다. 젠킨스 서버에 Docker 환경 구성을 추가할 것인지에 대한 고민이었다. 사실 내 프로젝트의 전반적인 CI/CD 시나리오 과정을 생각해 보면 젠킨스 서버에 굳이 Docker 환경을 추가해 줄 필요는 없었다.
[CI/CD 시나리오]
프로젝트 소스 업데이트(깃허브 Push) -> 젠킨스 빌드 이벤트 발생(WebHook) -> 업데이트된 프로젝트 파일 빌드(WAR파일로 패키징) -> 톰캣서버로 전송 및 변경된 WAR로 톰캣서버 Reload
위와 같은 CI/CD 시나리오를 진행하는 것은 일반적인 젠킨스 환경으로도 충분했기 때문이다. 다만 젠킨스 서버(컨테이너)에 도커 환경을 구축한다면 CI/CD 과정에서 일련의 Docker 관련 작업들을 추가해서 진행할 수 있게 된다. 만약 프로젝트의 특정 어플리케이션(컨테이너) DockerFile 혹은 Docker-Compose 설정이 수정되었을 때에도 배포서버에 들어가 일일이 컨테이너를 수정해 줄 필요없이 젠킨스에서 자동화 처리가 되도록 설정하는게 가능해지는 것이다. 즉 도커라이즈화시킨 프로젝트를 자동화 빌드 및 배포 처리하는 것이 가능해진다.
사실 내 프로젝트에서는 이미 구성되어 있는 컨테이너들(톰캣,Redis,Oracle DB)의 설정이 바뀔 일은 거의 없어 보였고, 단순하게 프로젝트의 배포서버를 마련하는 데 도커를 이용한 것일 뿐이지 프로젝트 자체를 도커라이즈화하여 패키징 관리한 것은 아니였다. 한정된 AWS의 프리티어 EC2 자원으로 도커관련 작업까지 자동화 시키는 것도 많이 무거워 보이기도 하고 이런저런 고민들이 들긴 했지만 어쨌든 Docker 공부의 목적을 생각하면 CI/CD 과정에서 도커 관련 작업을 진행해 보는 것이 당연히 좋은 경험이 될 것 같았기에 우선은 해당 방식으로 진행해 보고자 하였다.
톰캣 서버(웹서버 어플리케이션) 도커라이즈화
우선 내가 구상한 OTT 프로젝트의 배포서버 환경을 요약하면 다음과 같다. 전체 배포서버는 AWS EC2의 프리티어 1대로 운영된다. 물리적으로는 DB서버와 웹서버 그리고 젠킨스서버 모두가 EC2 인스턴스 한 곳에서 전부 가동되지만 다만 DB서버는 마치 별도의 독립된 서버(RDS)로서 생각하고 운영할 것이다. 그리고 젠킨스를 메인 호스트 서버로 생각하고 젠킨스 내부에서 별도로 톰캣서버를 운용할 것이다. 즉 톰캣서버는 물리적으로 젠킨스 서버 안에 설치된 도커의 컨테이너로 동작하게 된다. EC2 호스트 서버에서 올린 젠킨스 컨테이너 -> 젠킨스 컨테이너 안에서 도커 인 도커 혹은 도커 아웃 오브 도커 방식으로 톰캣 컨테이너를 띄우는 형식이다.
톰캣 서버(애플리케이션)는 간단하게라도 도커라이즈화하여 DockerFile로 지속관리할 것이고 젠킨스에서 새로운 빌드가 유발될 때마다 도커라이즈화 시킨 톰캣 어플리케이션 이미지를 새롭게 빌드해서 컨테이너를 내리고 띄우는 형식으로 CI와 CD를 구현할 것이다.
