프로젝트를 진행하는 중에 개발 초기 단계에 먼저 CICD line 을 뚫어 놓고 개발을 진행하자는 팀원의 의견을 반영해서 약 1주일을 결려 CI/CD line을 구성했다.
다음은 CICD pipe line 을 구성하기 위해서 필요한 것들이다.
구축에 사용한 플렛폼
- github actions runner
- ec2 server
- S3 bucket
- code deploy
- rds (Mysql)
필자의 환경
- spring boot 2.7.3 (개발 초기 단계에서 3.0.1 을 사용했지만 spring fire fox 적용을 위해서 다운드레이드 했다.)
- ubuntu 20.04 (아래에서 다시 설명하겠지만 반드시 이 버전을 사용해야하는 이유가 있다)
- gradle 7.6
- Mysql 8.0.1
위의 서버들의 역할을 간략하게 설명해 보자면
-
actions runner 는 self hosted runner 를 사용하는 방법과 action runner 를 사용해서 runner 를 github action 으로 구성하는 방법이 있다. 필자는 초기 CICD pipe line 을 구축하는 과정에서 self hosted server 를 ec2에 적용해서 시도 했었으나 amazone의 code deploy를 이용하기 위해서 S3 bucket 에 build 된 jar 파일을 올려는 방식으로 구성했다.
-
ec2 server 는 host server 로 이용하기 위해서 사용했고 필자는 개발 초기 단계에서 메모리 부족 그리고 cpu의 과동한 사용으로 ssh 마저 접속할 수 없는 경우를 많이 격었기 때문에 t2.medium 인스턴스를 사용했다. 현재 환율의 증가로 인해서 한달에 약 50000만원 정도의 비용이 발생할 것으로 보인다.
-
S3 bucket 은 서버 이외의 스토리지를 제공하는 역할로 이를 이용해서 버전별 application 을 관리할 수도 있고 또한 이미지나 다른 바이너리 파일을 저장하는 것도 가능하다.
-
code deploy는 server에서는 codedeploy-agent server 와 연결되어서 jar 파일의 배포 그리고 여러개의 애플리 케이션을 하나의 인스턴스에서 효휼 적으로 관리할 수 있게 해준다.
ec2 인스턴스 생성
aws 에서 제공하는 ec2 인스턴스는 강력하고 간편하게 서버를 운영할 수 있다는 장점을 제공하며 방화벽, 인터넷 데이트웨이 인바운드 규칙 , 리전을 간단하게 제공되는 console GUI를 통해서 한번에 제어할 수 있다는 장점이 있다.
필자가 구성한 환경을 간력하게 요약한 표는 다음과 같다.
| instance spec | ip | rds | os |
|---|---|---|---|
| t2.medium | 탄력적 ip(ipv4) | Mysql 8.0.1 | ubuntu-20.04 |
필자는 개발 초기 단계에 과금을 피하기 위해서 t2.micro를 사용했었는데 cpu 부족 Mps 부족 메모리 부족으로 잦은 서버 stop and start를 했었고 그로인해서 여러 번의 실패를 겪었다.
위에서 필자가 ubuntu-20.04 버전을 추천한 이유는 배포 과정에서 사용하는 것들은 S3 bucket 으로의 access 그리고 code deploy-agent 의 사용은 필수적이라고 생각하는데 아직까지 code deploy가 22.04를 정식적으로 지원하는것이 아니기 때문에 사용을 할 수는 있지만 이를 위해서는 의도적으로 ruby 버전을 낮추어서 진행하야하고
sudo service code - agent status 명령등 기본적인 명령을 수행하는데 많은 시간이 든다 따라서 20.04 버전으로 서버를 구성하는 것을 추천한다. 필자는 모르고 22.04 버전으러 진행하다가 ruby와의 호환성 문제로 ruby를 삭제하는 과정에서 환경변수를 건드려서 꼬였다... 그리고 진짜 완전 삭제하더라고 잘안돌아가서 피똥을 샀다
ec2 인스턴스를 생성하고 나서는 반드시 인바운드 규칙을 설정하는 것을 추천한다. 그래야 나중에 app을 배포했을 때 왜 안되는거야? 라는 물음표를 가지는 과정을 줄일 수 있다.
필자가 구성한 인바운드 규칙이다 진짜 application 을 배포하기는 분이라면 3306 port는 데이터 베이스와의 통신을 허용해버릴 것이므로 반드시 닫아주기 바란다 필자는 아직 테스트 환경이기 때문에 다음과 같이 구성했다.
vpc
vpc는 가상 클랑드 네트워크 환경을 제공하는 것으로 이를 통해서 외부와 격리된 서브넷 환경을 생성하기 위해서 사용한다. 기본적으로 생성되는 환경에서는 gate way가 제공되지만 aws에서는 명시적으로 public subnet이 제공되지는 않는다.
이번 CICD 환경을 구축하는데 있어서 제일 어려웠던 개념이 vpc 였다 개념은 간단한데 이를 public 하게 만들어주는 정에서 고려해야할 점이 있다.
필자는 환경을 구성하면서 동일한 vpc 안에 rds, ec2, s3가 모두 포함되도록 구현을 했다. 이 때 내부 서버 끼리는 통신에 문제가 없지만 외부외의 통신을 생각한다면 고려해야할 사항이 생긴다. 기본적으로 aws 에서는 vpc를 생성할 때 외부와의 통신을 위해서 gateway를 제공한다. 하지만 public subnet은 제공하지 않기 때문에 리전 가용영역을 고려한 gateway를 생성하고 이 gateway와 subnet을 연결해야만 public ip와의 통신을 보장할 수 있다 필자는 서비스를 대한민국에서 돌릴 것이기 때문에 ap-northeast-2a ~ 2d 까지 4가지 가용영역에 대해서 서브넷을 생성하고 gate way와 vpc에 대해서 연결했다.
- ec2 는 기본적으로 외부 네트워크와 분리된는 특징이다. (생성할 시점에 설정에 따라서 다를 수 있다.) 하지만 vpc의 gate와 서브넷을 설정한다면 외부와 통신가능하게 만들수 있다
👉 결과
