AWS CodePipeline를 이용한 사내 CI/CD 환경 구현 사례

AWS CodePipeline은 코드 변경 → 빌드 → 테스트 → 배포 과정을 자동화하여 소프트웨어 배포 속도를 높이고, 품질을 유지하며, 운영 부담을 줄이는 AWS의 CI/CD 핵심 네이티브 서비스입니다.

CodePipeline의 역할은 코드 변경사항이 발생하면 이를 감지하고 자동으로 빌드와 배포를 수행하는 것으로 AWS에서는 여러 서비스들이 유기적으로 연결되어 있습니다.

 

일반적으로 CodePipeline의 역할은 코드 변경사항이 발생하면 이를 감지하고 자동으로 빌드와 배포를 수행하는 것으로 AWS에서는 여러 서비스들이 유기적으로 연결되어 있습니다.

주요 목적은 1) 수동 배포 과정 제거 → 자동화로 배포 시간 단축, 코드 변경 시 2) 즉각적인 테스트 및 품질 검증, 3) 인프라 변경(IaC)까지 포함한 DevOps 파이프라인 구축 등 을 목적으로 합니다.

 

주된 활용 사례는 웹 애플리케이션 CI/CD(소스 코드 수정 시 자동 빌드·배포), 인프라 IaC 배포(CloudFormation/Terraform 템플릿 변경 시 자동 반영) 그리고 멀티환경 배포(개발 → 스테이징 → 운영 환경 순차 배포) 입니다. 이를 통해  코드 변경 → 빌드 → 테스트 → 배포 과정을 자동화하여 소프트웨어 배포 속도를 높이고, 품질을 유지하며, 운영 부담을 줄이는 AWS의 CI/CD 핵심 서비스입니다.

 

위의 여러가지 툴 중에 이번 포스팅에서는 사내 프로젝트에서 사용했던 github, CodeCommit, CodeBuild, CodeDeploy를 기준으로 설명합니다.

 

 

Github

CodePipeline 내에서 제공하던 CodeCommit은 Deprecated된 관계로 github으로 대체해서 사용합니다.

개인 계정 사용 시 repository를 생성해 Spring project를 생성해 진행하시거나 github.com/lcw729/ccdemo 해당 repository를 clone해서 사용하시면 됩니다.

 

빠른 진행을 위해 이번 실습에서는 기본적인 Spring web 모듈만 포함된 repository url만 이용해서 실습하겠습니다.

 

github webhook을 이용해 main branch에 대한 알람을 받는 방법은 별첨으로 추가해뒀으니 관심있으신 분들은 참고하시면 됩니다.

(webhook, api gateway, lambda, sns를 이용한 메일 발송 프로세스)

 

https://github.com/ktds-lcw/ccdemo.git

GitHub - ktds-lcw/ccdemo

 

CodeBuild

지금부터는 CodeBuild를 생성합니다.  CodeBuild는 CI/CD 파이프라인에서 Build 단계를 담당합니다. 개발자가 소스 코드를 수정하고 코드가 커밋될 때마다 CodeBuild가 자동으로 빌드를 수행합니다.

 

CodeBuild의 역할은 다음과 같습니다.

1. 코드빌드
2. 유닛 테스트 수행
3. Docker 이미지, Jar파일 생성 등의 패키징
4. 배포 준비(S3, ECR 등의 배포 서버로 전송)
5. 로그 관리(빌드 로그)

 

우선 원하는 이름으로 CodeBuild 프로젝트를 생성해줍니다.

 

build badge: 최근 빌드의 상태를 볼 수 있게 public한 url로 공개되는 기능입니다.

 

Source는 public한 Github repository를 사용할 예정으로 아래와 같이 설정해주시면 됩니다.

참고로 아래와 같은 방법을 사용하면 Code가 Commit될 때마다 Build가 되지 않는다는 단점이 있지만,

Commit시마다 Build시키기 위해선 개인 Repository의 Auth 인증 등의 추가 절차가 필요하기 때문에 실습의 편의를 위해 public repo로 진행합니다.

 

[Public Repository 주소]

https://github.com/ktds-lcw/ccdemo.git

 

Environment에서는 Build할 환경을 설정하며, 사용할 Role을 설정합니다

 

실습의 편의를 위해 Timeout 시간을 각 5, 10분으로 설정해줍니다.

 

Buildspec - Use a buildspec file을 선택합니다.

 

Artifact를 저장할 레지스트리는 S3로 설정하며, S3 버킷을 생성합니다.

 

S3 버킷 생성시 중요한 점은 Versioning을 Enable로 체크해줘야 합니다.

 

바로 위에서 생성한 S3 버킷을 Artifact로 지정해줍니다.

 

Create 후 생성된 CodeBuild에서 Build 버튼을 클릭해 정상적으로 Build되는지 확인합니다.

 

CodeDeploy

CodeDeploy는 자동으로 애플리케이션을 다음의 서비스에 배포해주는 서비스입니다.

• EC2 instances
• On-premise instances
• AWS Lambda
• AWS ECS

AWS CodeDeploy 소개

 

실습 순서

CodeDeploy

1. IAM Role을 생성
2. EC2 인스턴스 생성 및 설정
3. appspec.yml & scripts 생성
4. CodeDeploy 항목 생성 (Application, Deployment Group)
5. 배포 실행

CodePipeline

1. Codepipeline 생성
2. 코드 수정 및 정상 동작 확인

 

Create CodeDeploy pre-requisite roles

CodeDeploy에 대한 Service Role 생성하기

CodeDeploy가 EC2에 배포하기 위해서는 EC2의 현재상태, Tag 정보 등을 조회할 수 있어야 합니다.
이를 위한 권한을 CodeDeploy에 부여하기 위해 Role을 생성해줍니다.

IAM > 역할 > 역할 생성

• AWS 서비스
• 사용 사례: CodeDeploy
• 역할 이름: restapps-codedeploy-service-role

 

 

IAM Instance Profile 생성하기

배포가 실행되면 EC2는 S3에서 Application 코드를 다운로드 받아서 설치해야 합니다.
이를 위한 권한을 EC2에 부여하기 위해, Role을 생성해줍니다.

IAM > Policies > Policy 생성

• Policy name: restapps-codedeploy-ec2-policy

 

IAM Instance Profile

{     "Version": "2012-10-17",     "Statement": [         {             "Sid": "Statement1",             "Effect": "Allow",             "Action": [                 "s3:Get*",                 "s3:List*"             ],             "Resource": "*"         }     ] }

 

IAM > Roles > Role 생성

• Role name: restapps-codedeploy-instance-profile

 

 

Create EC2 VM

EC2 VM 생성하기

• EC2 > Instances > Launch Instances

Instance 설정

 

Key Pair 생성

 

Network settings

• Public IP 자동 할당
• 8080 포트 Open

 

Advanced details

• 앞서 생성한 IAM instance profile 지정

 

• User data 스크립트 입력

실습을 진행하기 위해 Java, Tomcat, CodeDeploy Agent 등을 사전에 설치해줍니다.

#!/bin/bash # 패키지 업데이트 sudo yum update -y   # java 설치   # amazon corretto 17 RPM 다운로드 wget https://corretto.aws/downloads/latest/amazon-corretto-17-x64-linux-jdk.rpm   # RPM 패키지 설치 sudo yum install -y ./amazon-corretto-17-x64-linux-jdk.rpm   # Ruby 설치 sudo yum install -y ruby   # Tomcat 설치 sudo yum -y install tomcat9   # CodeDeploy Agent 설치 스크립트 다운로드 cd /home/ec2-user  # Amazon Linux에서 기본 사용자는 ec2-user입니다. aws s3 cp s3://aws-codedeploy-ap-northeast-2/latest/install . --region ap-northeast-2   # 실행권한 부여 및 설치 chmod +x ./install sudo ./install auto

CodeDeploy Agent와 Java가 정상 설치되었는지 확인하고 Tomcat을 실행시킵니다.

# 설치 확인 sudo service codedeploy-agent status    # 정상 설치가 됐다면 PID가 나타납니다.   # Java Version 확인 sudo java -version sudo service tomcat9 status sudo service tomcat9 start

Tomcat Index.html 생성하기

Tomcat이 정상 동작하는지 확인하기 위해 Index.html에 원하는 문구를 적고, 웹브라우저에 접속합니다.

cd /usr/share/tomcat9/webapps sudo mkdir ROOT cd ROOT sudo vi index.html

 

웹브라우저 접속 화면

 

Create CodeDeploy files and scripts

appspec.yml & scripts 생성하기

CodeDeploy Event LifeCycle

아래 같은 순서대로 Event들이 실행됩니다. 이 순서는 CodeDeploy에서 이미 정해 놓은 순서이고, 각각을 Event Hook 이라고 합니다.

일부 Event Hook은 사용자가 직접 스크립트파일을 생성하여 사용할 수 있습니다. (회색으로 되어있는 Event Hook 들은 스크립팅 할 수 없습니다.)

1. Start : lifecycle의 첫 번째 이벤트로, CodeDeploy 에이전트를 자동으로 실행하고 인스턴스 배포가 시작됩니다.
2. ApplicationStop : 이전 프로그램을 중지하는 스크립트를 실행하는 단계
3. DownloadBundle : 이벤트 동안 CodeDeploy에이전트는 새 버전을 인스턴스로 가져온다.(ex CodeBuild에서 패키징된 zip)
4. BeforeInstall : 이 이벤트를 통해 구버전의 설치 구성을 저장하고, 파일을 복호화하고, 현재 버전의 백업을 만들 수 있습니다.
5. Install : DownloadBundle을 통해 가져온 Bundle 압축을 해제하고 appspec.yml에 정의된대로 파일을 지정 경로로 복사합니다.
6. AfterInstall : 이 이벤트를 통해 프로그램이 시작되기 전에 프로그램의 구성을 변경할 수 있습니다.
7. ApplicationStart : 어플리케이션을 구 버전(v.0) 대신 새 버전(v.1)로 설정합니다.
8. ValidateService : 이 이벤트를 통해 배포가 성공했는지 확인할 수 있는 검증 로직을 실행할 수 있습니다.
9. End : lifecycle의 마지막 이벤트로, 인스턴스의 배포 성공유무를 중앙 서비스에 알립니다.

Create CodeDeploy Objects

Application 생성하기

• CodeDeploy > Deploy > Applications > Create application

 

Deployment Group 생성하기

• Service role - 위에서 생성한 Role 입력
• Environment configuration - EC2 선택 및 Key=Name, Value=인스턴스 이름 입력
• Enable Load Balancer - 해제
• Deployment configuration -  OntAtTime 으로 변경

  (1) OneAtaTime: 한 번에 한 한대의 서버에만 배포합니다.(속도가 오래걸리나, 안정적입니다.)

  (2) HalfAtaTime: 한 번에 절반의 서버에 배포합니다.

  (3) AllAtOnce: 한 번에 모든 서버에 배포합니다.(시간이 단축되나, 서비스에 이슈가 발생할 수 있습니다.)

 

 

Deployment 생성하기

 

Run CodeBuild and Create Deployment

• CodeBuild > Build Projects > ccdemo-cb1 > Start build
• 빌드 완료 후, S3 파일 다운로드 및 파일 확인합니다.

Deployment 성공

 

buildspec.yml 파일의 artifact에 기재해둔 파일 목록을

• artifacts : 빌드 파일 저장 및 캐싱 파일 관리

Tomcat 배포 확인

 

CodeDeploy agent log 확인

cd /opt/codedeploy-agent/deployment-root/deployment-logs/ tail -100f codedeploy-agent-deployments.log

CodeDeploy가 Event LifeCycle 순서로 실행되는 것을 확인할 수 있습니다.

 

웹브라우저 화면

CodePipeline

 

Pipeline 생성하기

    1. Artifacts: S3
    2. Source: Github
    3. Build: CodeBuild
    4. Deploy: CodeDeploy
    5. Server: EC2 Instance

 

 

Make Changes & Check-In Code

    1. Make changes to rest app and check-in
    2. Pipeline should trigger the build automatically

 

배포 완료 후, 반영된 웹 브라우저 화면

별첨: github webhook을 이용해 AWS SNS로 메일 전송하기

webhook을 이용한 AWS SNS 메일 발송 까지의 전체 흐름은 아래와 같습니다.

 

github repository 생성 후 Settings의 Webhooks에 접속시 Payload URL을 작성해 Webhook 발송이 가능합니다.

payload를 채우기 위해 Webhook을 수신할 URL이 필요한데, 이 때 SNS를 호출하기 위한 AWS Lambda를 외부에서 호출하려면 API Gateway가 필요합니다. 

 

우선 API Gateway부터 생성합니다.

Method 생성을 위해 Lambda를 생성합니다. 

코드는 잠시 후 작성 진행하며, 우선 API Gateway로 돌아와 방금 만든 Lambda를 연결해줍니다.

 

api gateway에 stage를 추가해줍니다. stage는 dev, stage, prod 등의 프로젝트 stage를 의미합니다.

API Gateway를 배포합니다.

 

람다로 돌아와 트리거로 API Gateway를 추가해줍니다.

아래 코드에는 SNS를 호출하는 코드를 작성합니다.

 

언어는 본인이 원하는 언어를 사용하셔도 상관 없으며 아래 스니펫과 같이 SNS 메시지를 전송하는 코드를 원하는 언어로 작성해주시면 됩니다.

 

SNS호출

import json import boto3   sns_client = boto3.client("sns") SNS_TOPIC_ARN = "arn:aws:sns:ap-northeast-2:566620743708:codepipeline_demo_sns"   def lambda_handler(event, context):     try:         body = json.loads(event.get('body', '{}')) # body가 없으면 빈 JSON 사용                   # GitHub Webhook 형식이 아닐 경우 대비         commit_msg = body.get('head_commit', {}).get('message', 'No commit message')         repo_name = body.get('repository', {}).get('name', 'Unknown repository')         sns_message = f"New push in {repo_name}: {commit_msg}"                               # SNS 메시지 전송         sns_client.publish(         TopicArn=SNS_TOPIC_ARN,         Message=sns_message,         Subject="GitHub Push Notification"         )               print(sns_message)         return {"statusCode": 200, "body": json.dumps("Notification sent")}           except Exception as e:         print(f"Error: {str(e)}")         return {"statusCode": 500, "body": json.dumps("Internal Server Error")}

 

SNS_TOPIC_ARN을 채울 SNS를 만들러 갑니다. Type을 Standard로 변경 후 Create해줍니다.

 

Topic 생성 후 subscription을 생성합니다.

 

subscription에서 protocol은 Email로, Endpoint는 이메일 주소로 설정해준 후 

방금 만든 topic의 ARN을 복사, Lambda의 코드 SNS_TOPIC_ARN에 붙여넣기 해줍니다.

 

자 이제 모든 기능 구현은 완료되었고 정상적으로 동작이 되고 문제가 없는지를 테스트까지 완료하였습니다.

 

아무래도 AWS CodePipeline은  가장 큰 장점은 “속도·품질·안정성을 모두 잡는 AWS 네이티브 CI/CD 서비스”로, 특히 이미 AWS 환경에 이미 구축된 워크로드를 사용함에 있어 향후 워크로드 확장성을 대비하여 준비한다면 자동화·표준화하는 데 강점을 가질 수 있다고 생각합니다.