서론
이번 파이널 프로젝트에서 EC2와 Docker를 이용해서 배포를 해보면서, 이 둘이 배포에 어떻게 활용되는지 그리고 CI/CD가 실제로 어떻게 작동하는지 체감해보는 좋은 경험이 되었다.
도커를 도입하고 싶었던 이유는 CI/CD에 대한 경험을 쌓고 싶었고, 환경을 표준화하는 데 큰 장점이 있다고 생각했다. 개발 환경과 배포 환경을 동일하게 가져가면서 애플리케이션이 안정적으로 실행되게 해주는 도커의 역할을 실제로 느껴보고 싶었다. 도커 이미지만 잘 만들어 두면 컨테이너가 서버에 자동으로 설정되고 바로 띄워질 수 있는 구조가 완성되니까, 반복적인 배포 작업에 확실히 효율적이라는 생각이 들었다.
EC2는 가상 머신 기반인데, 인스턴스마다 독립적인 운영체제가 올라가는 거라서 처음엔 도커랑 어떤 차이가 있는지 헷갈렸다. EC2와 Docker 둘 다 서버를 띄운다는 개념에서 비슷해 보였기 때문이다. 하지만 도커는 호스트의 OS를 공유하고 EC2는 별개의 OS를 사용한다는 점에서 개념을 정립할 수 있었다.
기본 흐름
내가 진행한 배포 방식:
-
Docker 이미지 빌드 및 푸시
기존 프로젝트에서 도커 이미지를 빌드하고, 도커 허브에 업로드한다. 이렇게 올려두면 어디서든지 pull 받아서 컨테이너를 만들 수 있게 된다. -
EC2에서 Docker 실행
EC2 인스턴스에 도커를 설치하고, 업로드해 둔 이미지를 pull 받아 컨테이너로 만들어 실행한다. 이렇게 하면 EC2 위에 도커 컨테이너를 띄우는 방식으로 서비스가 돌아간다. -
SSL 인증서 설정
마지막으로, certbot을 사용해서 SSL 인증서를 받아 443 포트를 여는 작업이다. 이걸 설정해 두면 HTTPS로 보안이 강화된 연결을 지원할 수 있다.
그렇다고 해도 이번 프로젝트는 익숙하지 않은 CLI 환경과 Ubuntu를 처음 다루는 거라 꽤 헷갈리고 헤매는 부분이 많았다. 도커 파일을 작성하는 것도 처음이라 설정을 잡는 데 시간이 걸렸고, 각종 시행착오도 많이 겪었다.
특히 도커 컴포즈(Docker Compose)를 사용해서 여러 컨테이너를 띄우는 과정이 인상 깊었다. DB와 스프링 서버를 동시에 띄워야 하는데, 당연히 DB가 먼저 시작되어야 스프링 서버가 정상적으로 연결될 수 있었다. 그래서 health check 기능을 사용해서 DB의 상태를 확인하고, DB가 준비되었을 때 스프링 서버가 실행되게 설정했다. 덕분에 DB가 완전히 준비되기 전에 스프링 서버가 에러를 내는 걸 방지할 수 있었다.
그리고 또 하나, 도커 이미지 캐시도 한 번쯤은 다들 겪어봤을 거 같다. 캐시가 남아 있으면 이전 버전으로 실행되거나 불필요한 버그가 발생하기 쉬운데, 이번에도 비슷한 상황이 있었다. 그래서 로컬에서 꼭 이미지를 빌드하고, 도커 허브로 보내야만 제대로 된 패키지와 의존성이 올라가게 된다는 점도 다시 깨달았다.
결론
CLI 환경과 Linux 운영체제를 처음 접하면서 익숙하지 않은 부분도 많았지만, 그런 환경에서 EC2와 Docker 같은 도구들을 이용하면서 코드 작성과는 다른 재미를 느꼈다. 이런 도구들이 작업을 표준화하고 일관되게 만드는 데 있어서 얼마나 강력한지 알게 된 거 같다. 다음 목표는 쿠버네티스(Kubernetes)를 이용해서 조금 더 체계적인 CI/CD 파이프라인을 구축하는 것이다. EC2와 Docker로 기본적인 배포와 자동화에 익숙해진 지금, 그다음 스텝으로 쿠버네티스를 도전해 보고 싶다. 확실한 자동화와 관리 기능을 경험해보고 싶기 때문이다.
