CI/CD 파이프라인은 개발부터 배포까지의 전체 프로세스를 자동화하여, 코드 변경 사항이 신속하고 안정적으로 운영 환경에 반영하는 것을 도와 주며, DevOps 환경을 구축할 때 가장 핵심적인 요소 입니다. Spring Boot 애플리케이션, GitHub, 그리고 AWS EC2/Auto Scaling 환경에서 가장 기본적인 CI/CD 파이프라인을 구축하는 방법에 대해 알아보겠습니다.
1. 전체 파이프라인 개요
- Source 단계:
GitHub에 코드가 커밋/푸시될 때 자동으로 파이프라인이 시작됩니다. - Build & Test 단계:
AWS CodeBuild(또는 GitHub Actions)를 사용하여 애플리케이션을 컴파일하고, JUnit 테스트를 실행합니다.- Maven 또는 Gradle 스크립트를 통해 jar 파일이 생성됩니다.
- Deployment 단계:
AWS CodeDeploy를 이용해 빌드된 jar 파일을 EC2 인스턴스에 배포합니다.- 배포 스크립트를 통해 기존 애플리케이션을 중단하고 새로운 jar 파일로 교체합니다.
- AMI 생성 및 Auto Scaling 업데이트:
배포 성공 후, 배포된 EC2 인스턴스를 기반으로 새로운 AMI를 생성하고, 해당 AMI를 사용하도록 Auto Scaling 그룹의 Launch Configuration(또는 Launch Template)을 업데이트합니다.- 이 과정은 CodeDeploy의 후처리 스크립트나 AWS Lambda를 활용해 자동화할 수 있습니다.
2. 구성 단계별 상세 가이드
(1) GitHub와 AWS CodePipeline 연동
- 연동 설정:
AWS CodePipeline을 생성하고, 소스 제공자로 GitHub를 선택합니다.- 커밋 시마다 웹훅을 통해 CodePipeline이 자동으로 시작되도록 설정합니다.
(2) AWS CodeBuild 프로젝트 구성
- 빌드 환경 구성:
CodeBuild 프로젝트를 생성하여, 빌드 명령어(예: mvn clean package 또는 ./gradlew build)를 설정합니다.- 빌드 스크립트 내에 JUnit 테스트가 자동 실행되도록 구성되어 있어야 합니다.
- 결과:
테스트가 모두 성공하면 jar 파일이 생성되고, 이후 단계로 아티팩트가 전달됩니다.
(3) AWS CodeDeploy를 통한 배포
- 배포 설정:
CodeDeploy 애플리케이션과 배포 그룹을 생성하고, 대상 EC2 인스턴스를 지정합니다.- 애플리케이션 배포 시, 기존 애플리케이션을 중지하고 새 jar 파일을 배포하는 스크립트를 작성합니다.
- Hook 활용:
배포 후 Hook를 이용해 자동으로 AMI를 생성하는 스크립트(또는 AWS Lambda)를 호출하여 새 AMI를 만들고, Auto Scaling 그룹 업데이트 작업을 진행합니다.
(4) Auto Scaling 그룹 업데이트
- AMI 반영:
생성된 새 AMI ID를 기반으로 Launch Configuration(또는 Launch Template)을 업데이트합니다.- 업데이트된 구성으로 Auto Scaling 그룹이 자동으로 새 인스턴스를 기동하게 하여 무중단 배포 또는 롤백이 가능하도록 합니다.
3. 추가 고려 사항
- 롤백 전략:
배포 실패 시 이전 버전으로 롤백할 수 있는 전략을 마련합니다. CodeDeploy에서는 롤백 옵션을 지원하므로 이를 활용할 수 있습니다. - 모니터링 및 알림:
CloudWatch와 SNS를 연동하여 빌드 및 배포 상태를 모니터링하고, 이상 발생 시 자동 알림을 받을 수 있도록 설정합니다. - 확장성:
처음엔 기본적인 파이프라인으로 시작하되, 이후 필요에 따라 Blue/Green 배포, Canary 배포 등의 고급 배포 전략을 도입할 수 있습니다.
이와 같은 기본 CI/CD 구성은 GitHub에 커밋된 코드가 자동으로 빌드, 테스트되고, 성공 시 AWS CodeDeploy를 통해 EC2 인스턴스에 배포되며, 새 AMI를 생성해 Auto Scaling 환경에 반영되는 형태로 진행됩니다. 이를 통해 개발에서 운영까지의 전체 흐름이 자동화되어 신뢰성과 효율성을 높일 수 있습니다.
지금 소개해드린 방법은 AWS에서 EC2 기반 애플리케이션을 대상으로 가장 일반적으로 사용되는 CI/CD 구성 중 하나입니다. 그러나 상황과 요구사항에 따라 다양한 대안도 고려할 수 있습니다. 몇 가지 다른 방법은 아래와 같습니다.
- AWS 네이티브 서비스 활용
- AWS CodePipeline + CodeBuild + CodeDeploy:
위에서 설명한 방식처럼 GitHub 등에서 커밋이 발생하면 CodePipeline이 트리거되고, CodeBuild로 빌드와 테스트를 진행한 후, CodeDeploy로 배포하는 구성입니다. - AWS CodeStar:
CodeCommit, CodeBuild, CodeDeploy, CodePipeline 등을 하나의 통합 인터페이스에서 관리할 수 있도록 도와주는 서비스로, 초기 설정과 관리를 보다 쉽게 할 수 있습니다.
- AWS CodePipeline + CodeBuild + CodeDeploy:
- 서드파티 CI/CD 도구와의 연계
- Jenkins, GitHub Actions, GitLab CI/CD 등:
AWS에 배포하기 위한 플러그인이나 AWS CLI를 이용하여, 외부 CI/CD 도구를 통해 빌드, 테스트, 배포 프로세스를 구축할 수 있습니다. 이 경우, AWS 서비스와 직접 통합하기보다 기존에 익숙한 도구를 활용하는 장점이 있습니다. - CircleCI, Travis CI 등:
클라우드 기반 CI/CD 플랫폼을 사용하여, 빌드와 테스트 후 AWS로 배포하는 스크립트를 실행할 수 있습니다.
- Jenkins, GitHub Actions, GitLab CI/CD 등:
- 배포 대상과 아키텍처에 따른 대안
- 컨테이너 기반 배포:
만약 애플리케이션을 컨테이너화하여 AWS Elastic Container Service(ECS)나 EKS에 배포한다면, CodePipeline과 CodeBuild를 통해 컨테이너 이미지를 빌드하고, Amazon ECR에 저장 후 ECS/EKS로 배포하는 방식이 효과적입니다. - AWS Elastic Beanstalk:
PaaS 환경에서 애플리케이션을 운영하고자 한다면, Elastic Beanstalk의 배포 파이프라인을 활용해 CI/CD를 구성할 수 있습니다. - 서버리스 배포:
Lambda 기반의 서버리스 애플리케이션이라면, AWS SAM이나 Serverless Framework을 활용한 CI/CD 파이프라인도 고려해볼 수 있습니다./
- 컨테이너 기반 배포:
결국 가장 적합한 CI/CD 구성은 애플리케이션의 특성, 팀의 선호도, 운영 환경(예: EC2, 컨테이너, 서버리스) 등에 따라 달라지게 됩니다. 각 방식의 장단점을 고려해 환경에 맞는 최적의 솔루션을 선택하는 것이 중요합니다.