CI/CD와 GitLab CI + AWS ECS 자동배포

💡  오늘 학습 키워드

• CI/CD
• GitLab CI + AWS ECS

 

 

🎯  학습 내용 정리

1. CI/CD

소프트웨어를 개발하다 보면 새로운 기능을 추가하거나 버그를 수정할 때마다 다음과 같은 과정을 반복하게 된다.

• 코드 작성
• 빌드
• 테스트
• 배포

이 과정을 모두 사람이 직접 수행한다면 시간이 오래 걸리고, 실수할 가능성도 높아진다.

CI/CD는 이러한 과정을 자동화하여 개발 생산성과 서비스 안정성을 높이는 방법이다.

 

 

CI는 Continuous Integration의 약자로 지속적인 통합을 의미한다.

여러 개발자가 작업한 코드를 자주 메인 브랜치에 병합하고, 코드가 변경될 때마다 자동으로 빌드와 테스트를 수행하는 과정이다.

 

예를 들어 GitHub이나 GitLab에 코드를 Push하면 다음과 같은 작업이 자동으로 실행된다.

코드 Push
  ↓
소스 코드 다운로드
  ↓
프로젝트 빌드
  ↓
테스트 실행
  ↓
성공 여부 확인

이를 통해 코드 충돌이나 버그를 빠르게 발견할 수 있으며, 문제가 있는 코드는 운영 환경에 반영되기 전에 수정할 수 있다.

 

 

CI가 끝난 이후에는 생성된 결과물을 서버에 배포해야 한다. 이 과정을 자동화한 것이 CD이다.

CD는 두 가지 의미로 사용된다.

 

Continuous Delivery

빌드와 테스트가 완료된 결과물을 자동으로 배포 가능한 상태까지 준비하는 과정이다.

운영 환경에 실제 배포하는 단계는 사람의 승인을 거친다.

Build
 ↓
Test
 ↓
Deploy Ready
 ↓
승인
 ↓
Production

 

 

Continuous Deployment

테스트를 통과하면 사람의 승인 없이 운영 서버까지 자동으로 배포하는 방식이다.

Build
 ↓
Test
 ↓
Production

서비스 규모가 크거나 안정성이 매우 중요한 환경에서는 Continuous Delivery를 많이 사용하며, 스타트업이나 빠른 배포가 필요한 서비스에서는 Continuous Deployment를 적용하는 경우도 많다.

 

 

CI/CD를 적용하면 다음과 같은 장점이 있다.

• 코드 변경 사항을 빠르게 검증할 수 있다.
• 빌드와 테스트가 자동으로 수행된다.
• 배포 과정에서 발생하는 실수를 줄일 수 있다.
• 모든 환경에서 동일한 방식으로 배포된다.
• 개발 속도가 빨라지고 배포 주기가 짧아진다.
• 코드 품질을 지속적으로 유지할 수 있다.

 

 

CI/CD를 구축하기 위한 도구는 다양하지만 가장 많이 사용하는 것은 다음 세 가지이다.

 

1) GitHub Actions

GitHub에서 제공하는 CI/CD 서비스이다.

GitHub 저장소와 완전히 통합되어 있으며, .github/workflows 디렉터리의 YAML 파일만 작성하면 자동으로 파이프라인을 구성할 수 있다.

 

특징은 다음과 같다.

• GitHub와 완벽한 통합
• Marketplace를 통한 다양한 Action 제공
• 이벤트 기반 자동 실행
• GitHub 프로젝트에서 가장 많이 사용

 

2) Jenkins

Jenkins는 가장 오래된 오픈소스 CI/CD 도구 중 하나이다.

직접 서버를 구축하여 사용하는 방식이며, 수천 개 이상의 플러그인을 지원한다.

 

특징은 다음과 같다.

• 높은 확장성
• 자유로운 커스터마이징
• 온프레미스 환경에 적합
• 자체 서버 운영 필요

 

3) GitLab CI

GitLab에서 제공하는 CI/CD 도구이다.

.gitlab-ci.yml 파일을 이용하여 파이프라인을 구성하며 GitLab과 자연스럽게 통합된다.

 

특징은 다음과 같다.

• GitLab 저장소와 통합
• 파이프라인 관리 기능 제공
• DevOps 전 과정을 하나의 플랫폼에서 관리 가능
• Self-hosted 환경도 지원

 

 

GitHub과 GitLab은 모두 Git 기반의 저장소를 제공하지만 CI/CD를 사용하는 방식에는 차이가 있다.

항목	GitHub	GitLab
CI/CD 도구	GitHub Actions	GitLab CI
설정 파일	.github/workflows/*.yml	.gitlab-ci.yml
실행 환경	GitHub Runner	GitLab Runner
특징	Marketplace 기반의 다양한 Action 활용	저장소와 CI/CD가 긴밀하게 통합
주요 활용	오픈소스 및 협업 프로젝트	기업 및 자체 DevOps 환경

GitHub에서는 GitHub Actions를 이용하여 Workflow를 정의하고, GitLab에서는 GitLab CI를 이용하여 Pipeline을 구성한다.

두 플랫폼 모두 YAML 파일을 작성한다는 점은 동일하지만, 실행 환경과 문법, 제공 기능에는 차이가 있다.

 

 

2. GitLab CI + AWS ECS

Amazon ECS는 Elastic Container Service의 약자로 AWS에서 제공하는 완전관리형 컨테이너 오케스트레이션 서비스이다.

Docker 컨테이너를 손쉽게 실행하고 관리할 수 있으며, Kubernetes보다 비교적 단순하게 사용할 수 있어 소규모부터 중규모 프로젝트까지 많이 활용된다.

또한 EC2 기반뿐 아니라 AWS Fargate(Serverless) 환경도 지원하여 인프라를 직접 관리하지 않고도 컨테이너를 실행할 수 있다.

 

 

ECS는 여러 구성 요소가 함께 동작하여 컨테이너를 운영한다.

 

Amazon ECR

Amazon ECR(Elastic Container Registry)은 Docker 이미지를 저장하는 저장소이다.

애플리케이션을 Docker 이미지로 빌드한 뒤 ECR에 업로드하면 ECS는 해당 이미지를 내려받아 실행한다.

 

ECS Cluster

Cluster는 컨테이너가 실행되는 논리적인 그룹이다.

여러 개의 서비스와 Task를 관리하며, Fargate를 사용할 경우 별도의 EC2 인스턴스를 관리하지 않아도 된다.

 

ECS Service

Service는 하나 이상의 Task를 지속적으로 실행하는 역할을 한다.

Task가 종료되면 자동으로 다시 생성하며 원하는 개수만큼 유지한다.

 

ECS Task

Task는 실제 실행되는 Docker 컨테이너이다.

ECS에서 컨테이너를 실행하는 최소 단위이다.

 

 

Task Definition

Task Definition은 Task를 실행하기 위한 설정 파일이다.

다음과 같은 정보가 포함된다.

• 사용할 Docker 이미지
• CPU
• Memory
• Port
• Environment Variable
• Volume
• Logging 설정

즉, 컨테이너의 실행 정보를 정의하는 설계도라고 볼 수 있다.

 

 

이제, GitLab과 AWS ECS를 활용하여 CI/CD 파이프라인 구축을 진행해보자.

 

0) GitLab을 이용한 CI/CD 구축 과정

GitLab에서는 .gitlab-ci.yml 파일을 통해 파이프라인을 정의한다.

전체 흐름은 다음과 같다.

Git Push
  ↓
GitLab Pipeline
  ↓
Gradle Build
  ↓
Docker Image 생성
  ↓
Amazon ECR Push
  ↓
Amazon ECS 배포

 

 

 

1) 프로젝트 준비

CI/CD를 구축하기 위해 먼저 Spring Boot 프로젝트를 생성한다.

프로젝트에는 다음과 같은 요소를 준비한다.

• REST API 작성
• Dockerfile 생성
• GitLab Repository 연결

Dockerfile은 애플리케이션 이미지를 생성하기 위한 파일이다.

FROM eclipse-temurin:17-jdk-jammy

VOLUME /tmp

ARG JAR_FILE=build/libs/*.jar

COPY ${JAR_FILE} app.jar

ENTRYPOINT ["java","-jar","/app.jar"]

 

 

2) Amazon ECR 생성

Docker 이미지를 저장하기 위해 Amazon ECR Repository를 생성한다.

CI 파이프라인에서는 Docker 이미지를 빌드한 뒤 이 저장소로 Push한다.

Spring Boot
  ↓
docker build
  ↓
Docker Image
  ↓
docker push
  ↓
Amazon ECR

 

 

3) Amazon ECS 구성

ECR이 준비되면 ECS를 생성한다.

일반적으로 다음 순서로 구성한다.

1. Cluster 생성
2. Task Definition 생성
3. Service 생성
4. Load Balancer 연결

Service는 Task를 실행하고 관리하며, Load Balancer를 통해 외부 요청을 분산한다.

 

4) AWS IAM 설정

GitLab에서 AWS 리소스를 제어하려면 AWS 접근 권한이 필요하다.

이를 위해 IAM 사용자와 Access Key를 생성한 뒤 GitLab CI/CD Variables에 등록한다.

 

대표적으로 사용하는 변수는 다음과 같다.

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

실제 프로젝트에서는 Access Key를 코드에 직접 작성하지 않고 CI/CD 환경 변수(Variables 또는 Secrets)를 사용하여 안전하게 관리한다.

 

5) GitLab CI Pipeline 작성

GitLab에서는 .gitlab-ci.yml 파일 하나로 전체 파이프라인을 정의한다.

일반적인 파이프라인은 다음 세 단계로 구성된다.

Build
  ↓
Docker Build
  ↓
Deploy

각 단계에서는 다음 작업을 수행한다.

 

Build

• Gradle Build
• 테스트 수행
• JAR 생성

Docker Build

• Docker Image 생성
• Amazon ECR Push

Deploy

• ECS Service Update
• 새로운 Task 실행
• Rolling Update 수행

 

 

진행한 자동 배포 과정을 정리해보자.

개발자가 코드를 Push하면 다음 과정이 자동으로 수행된다.

Git Push
  ↓
GitLab CI 실행
  ↓
Gradle Build
  ↓
Docker Image 생성
  ↓
Amazon ECR Push
  ↓
ECS Service Update
  ↓
새로운 Container 실행
  ↓
서비스 배포 완료

이 과정을 통해 개발자는 서버에 직접 접속하지 않아도 새로운 버전을 배포할 수 있다.

 

 

CI/CD는 단순히 빌드와 배포를 자동화하는 기술이 아니라 개발부터 운영까지의 전체 과정을 표준화하고 자동화하는 DevOps의 핵심 요소이다.

GitHub Actions와 GitLab CI는 각각 GitHub와 GitLab 환경에서 손쉽게 CI/CD를 구축할 수 있도록 지원하며, AWS의 ECR과 ECS를 함께 활용하면 Docker 이미지를 자동으로 배포하는 안정적인 파이프라인을 구축할 수 있다.

자동화된 CI/CD 파이프라인을 적용하면 반복 작업을 줄이고, 코드 품질을 지속적으로 검증하며, 빠르고 일관된 배포를 수행할 수 있어 개발 생산성과 서비스 안정성을 동시에 향상시킬 수 있다.

 

 

📚  한줄 정리

CI/CD는 코드 변경부터 Docker 이미지 생성, 컨테이너 배포까지의 모든 과정을 자동화하여 빠르고 안정적인 서비스 운영을 가능하게 하는 핵심 DevOps 기술이다.