2025. 10. 23. 14:12ㆍCI\CD/CI\CD 종합
이번에는 아래와 같은 구조의 CI/CD를 만들어보도록 할 것이다
GitHub ───────────▶ GitHub Actions
├─(app.zip 업로드)──────────────▶ S3
└─(배포 트리거)───────────────▶ CodeDeploy
│
└─(배포 지시)──▶ EC2(Agent)
먼저 GitHub Actions로 빌드한 파일을 S3에 업로드 하고 빌드가 완료되면 CodeDeploy에게 배포하라고 지시한다
그러면 CodeDeploy는 EC2에게 S3에 업로드된 빌드 파일을 내려받아서 배포를 진행하라고 지시한다
EC2(Agent) ───────────────────────(app.zip GET)──────▶ S3
(다운로드)
그러면 EC2는 S3에서 빌드 파일을 내려받아 배포하는 과정을 진행한다.
이를 더 쉽게 이해하기 위해서 먼저 내용에 들어가기전에 이번에 사용하게 될 AWS의 S3와 Code Deploy에 대해서 알아보자.
1. AWS S3
AWS의 S3는 Simple Storage Service를 의미하며 이는 AWS에서 제공하는 클라우드 기반 객체 스토리지 서비스이다.
이는 파일(데이터)을 인터넷 상의 버켓(Bucket)이라는 공간에 저장하고 관리할 수 있도록 하는 시스템이다.
기본적으로는 S3는 하드디스크나 NAS처럼 데이터를 저장하지만 실제론 AWS 데이터 센터(클라우드)에 존재하는 저장소이다.
데이터를 저장할 때 폴더 개념 대신에 객체(Object) 단위로 저장하며 객체는 Key(파일 이름, images/logo.png), Value(실제 파일 데이터), Metadata(파일의 속성정보로 MIME 타입, 권한 등)로 구성된다.
주요 특징은
- 확장성(Scalability) : 용량 제한이 없음, 필요한 만큼 무한정 저장 가능
- 내구성(Durability) : 데이터가 여러 지역에 중복 저장되어 99.999999999%
- 가용성(Availability) : 장애 발생 시 자동 복구 메커니즘으로 높은 서비스 지속성을 유지
- 보안(Security) : IAM(Identity and Access Management)으로 접근 제어 가능, 버킷 단위/ 객체 단위 권한 부여 가능
- 요금제(Pay-as-you go) : 사용한 용량과 트래픽(전송량)에 비례해서 과금
보통이 S3는 정적 웹사이트 호스팅(HTML, CSS, JS 파일을 업로드해 웹사이트처럼 동작가), 백업 및 로그 저장소(서버 백업, 로그 파일, 데이터베이스 스냅샷 저장용으로 활용 가능), CDN 연동(S3에 저장된 파일을 전 세계에 빠르게 배포 가능), CI/CD 과정에서 생성되는 아티팩트의 저장소(GitHub Actions, Jenkins 등에서 빌드 산출물을 S3에 저장함)로 사용된다.
우리는 여기서 빌드된 산출물인 아티팩트의 저장을 위해 사용할 것이다.
2. AWS CodeDeploy
AWS의 CodeDeploy는 코드를 자동으로 EC2, 온프레미스 서버, Lambda, ECS 등에 배포해주는 AWS의 배포 자동화 서비스로 코드가 수정되면 자동으로 서버에 배포하는 과정을 클릭 몇 번 또는 스크립트 한 줄로 수행하게 해주는 자동 배포 도구이다
온프레미스(On-premises) 서버
온프레미스 서버는 간단하게 AWS의 외부 서버를 지징하는 말로 쉽게 각 회사가 직접 보유하고 있는 물리적인 자체 서버를 의미한다.
CodeDeploy는 인터넷만 연결되어 있다면 외부의 서버에도 배포가 가능하다.
AWS Lambda
서버 없이 함수 단위로 코드를 실행하는 서비스로 서버리스 환경을 의미한다.
EC2처럼 서버를 직접 운영하지 않으며 코드를 올려두면 AWS가 자동으로 실행환경을 만들어 함수처럼 수행한다.
Python, Node.js, Java등 다양한 언어를 지원한다
(서버를 유지하는 유지비가 들지 않음)
ECS(Elastic Container Service)
AWS의 컨테이너 오케스트레이션 서비스로 Docker 컨테이너를 자동으로 관리해주는 플랫폼이다.
EC2위나 AWS의 Fargate(완전 관리형) 위에서 컨테이너 실행이 가능하며 여러개의 컨테이너를 클러스터로 묶어 배포, 스케일링, 업데이트 기능을 하고 docker-compose 같은 구조를 클라우드 에서 자동으로 운영해준다고 보면 된다.
(여러개의 docker 컨테이너를 AWS가 대신 돌려주는 자동 컨테이너 농장쯤으로 생각하자 )
CodeDeploy는 기존엔 코드가 빌드되고 SSH로 서버에 접속한 다음에 기존 서비스를 중단하고 새파일을 복사하고 그 서비스를 재시작하는 과정을 진행했는데 이 과정을 자동으로 가능하게 해준다.
CodeDeploy의 구성은 AppSpec.yml, CodeDeploy Agent, Deployment Group으로 구성되고 이는 각각
- AppSpec.yml : 배포 시 수행할 단계 정의 파일(어디에 복사, 어떤 스크립트 실행 등)
- CodeDeploy Agent : EC2 또는 온프레미스 서버에 설치되어 명령을 수행하는 에이전트
- Deployment Group : 어떤 서버에 어떤 버전을 배포할지 지정하는 그룹
의 기능을 한다
보통의 CodeDeploy의 동작의 흐름은 아래와 같다.
GitHub / S3에 빌드된 파일 업로드
↓
AWS CodeDeploy가 감지 (또는 수동 트리거)
↓
AppSpec.yml에 정의된 순서대로 실행:
- BeforeInstall: 기존 파일 백업
- Install: 새 파일 복사
- AfterInstall: 설정파일 수정
- ApplicationStart: 서비스 재시작
- ValidateService: 정상 작동 확인
↓
모든 대상 EC2 인스턴스에 자동 적용
이 CodeDeploy는 무중단 배포가 중요하거나 여러개의 서버에 배포가 진행되어야 하는 경우 사용된다.
3. CodeDeploy를 위한 역할 생성
CodeDeploy를 설정하기 전에 먼저 권한을 설정해줘야한다.
권한은 IAM이라는 부분으로 들어가면 설정이 가능한데 AWS의 콘솔에서 IAM을 검색해서 들어가주자.

여기서 왼쪽 메뉴에서 역할로 들어가보면

역할을 생성할 수 있다.

IAM이란
IAM은 Identity and Access Management로 AWS의 계정, 사용자, 권한, 역할을 통합 관리하는 보안 시스템으로 AWS안에서 누가 어떤 리소스(S3, EC2, CodeDeploy)에 접근할 수 있게 할지를 통제하는 중심 관리 센터이다.
역할이란
IAM의 역할(Role)은 특정 권한을 갖게하는 신분증이라고 보면 된다.
이는 사람이 직접 조작하는게 아니라 일시적으로 특정 권한을 위임 받아 수행할 때 사용하는 권한의 묶음으로 내부적으로는 정책(JSON)에 붙어서 "이 역할을 가진 서비스는 어떤것을 수행가능하다"로 정의 한다.
정리해보자면 IAM에 있는 역할을 CodeDeploy가 부여받아서 EC2를 조작할 수 있도록 해야지만 CodePlay가 잘 동작할 수 있다는 의미이다.
엔티티 유형은 AWS 서비스로 지정 하고 사용 사례는 CodeDeploy로 설정하고 다음을 눌러주자

다음에 보이는 CodeDeploy의 Role을 보면 저 내부에 이런 저런 권한들이 부여되어 있다.
그냥 저대로 다음을 눌러주자.

그리고 역할 이름을 지정해주고

아래로 내려서 역할 생성을 해주면

아래 처럼 역할이 생성된 것을 볼 수 있다.

4. CodeDeploy 생성
역할을 만들었으니 이제 CodeDeploy를 생성해보자
콘솔에서 CodeDeploy를 검색해주고 들어가보면

※ 사용할라고 했는데 레거시 프리티어만 접속 가능하고 사용하려면(7월 이후 생성 계정) 유료플랜으로 전환해야한다고 한다
그래서 그냥 유료 플랜 전환 하기로함...돈 나갈까봐 걱정이 심히 많이됨...
애플리케이션 항목으로 들어가주고

애플리케이션 생성을 눌러주고

애플리케이션 명을 작성하고 컴퓨팅 플랫폼은 EC2를 선택해주자.

그리고 생성해주면

이렇게 만들어진 것을 볼 수 있고 이제 아래 탭부분에서 배포 그룹을 생성해주자.

먼저 배포그룹 이름을 지정해주고

역할을 우리가 이전에 만들었던 역할을 선택해주자.

배포유형은 그대로 두고

환경유형은 EC2 인스턴스를 선택해주자.

여기서 키를 Name을 선택해주고

값에 우리가 만들었던 EC2 인스턴스를 선택해주자.

이제 로드벨런싱만 풀어주고(안쓰니까)

배포그룹 생성을 눌러서 배포그룹을 생성해주자.

이렇게 하면 CodeDeploy에 대한 세팅은 끝이다.
5. EC2가 S3에 접근할 수 있는 역할 생성 및 부여
이전에 CodeDeploy가 EC2에 접근해서 배포를 진행하도록 하게 하기 위해서 역할을 부여 했었다.
근데 결국에 실제로 배포를 하기 위해서는 파일이 저장되어 있는 S3로 EC2가 접근해서 파일을 내려받을 수 있어야한다
그런 권한은 모두 역할에서 관할하고 있기에 이제 EC2에게 사용될 역할을 하나 만들어주도록 하자.
그 전에 정책이란걸 하나 만들어 주도록 하자
IAM으로 가서

정책으로 들어가주자.


정책은 어떤 서비스에 접근할 수 있도록 할것인지에 대한 정보를 만들어주는 곳이다.
정책 생성을 눌러주고

JSON을 눌러주면

아래와 같이 코드를 넣어줌으로 해서 권한을 지정해 줄 수 있다.

이 안에는 아래와 같이
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:List*"
],
"Resource": "*"
}
]
}
작성해주자.
여기서 Action에 들어간 내용은 s3에 접근할 수 있는 권한과(Get*) 조회할 수 있는 권한(List*)을 Effect에 있는 Allow 하는 권한을 제공하는 정책이다.
이제 다음을 눌러주고

정책 이름만 지정해주고 정책을 생성해주자.

이제 역할로 들어가준 다음에

역할 생성을 눌러주자.

그리고 EC2에 해서 역할을 만들겠다고 설정해주고

다음 눌러준 다음에 우리가 만든 정책을 선택해주고 다음으로 넘어가

이름만 지정해주고

역할을 생성해주자.
이제 이렇게 만든 역할을 EC2에게 적용해주자.
EC2로 들어가서 인스턴스를 눌러준 다음에 역할을 부여하고자 하는 인스턴스를 체크 해주고 작업 > 보안 > IAM 역할 수정을 눌러주자.

그리고 우리가 만든 역할을 선택해준 다음에 IAM 역할 업데이트를 해주자.

이러면 역할이 EC2에 적용이 되었다.
6. EC2에 CodeDeploy Agent 설치
CodeDeploy는 AWS 콘솔에서 어떤 파일을 서버들에게 배포하라고 지시내리는 지시자이지만 보안 때문에 그 서버들에 직접 접근해서 지시를 내릴 수는 없다.
그렇기 때문에 CodeDeploy가 지시를 내리면 EC2 내부에 CodeDeploy Agent라는 것이 지시를 받아 EC2의 내부에서 파일을 내려받고 압축을 해제하고 스크립트를 수행하는 등의 작업을 진행해준다.
간단하게 설명하자면 CodeDeploy가 사용하는 EC2의 SSH 같은 느낌이라고 생각하면 된다.
이제 CodeDeploy Agent 를 설치해보자.
설치를 위한 명령어는 아래와 같다.
sudo apt update -y && \
sudo apt install ruby wget -y && \
cd /home/ubuntu && \
wget https://aws-codedeploy-ap-northeast-2.s3.amazonaws.com/latest/install && \
chmod +x ./install && \
sudo ./install auto
이렇게 설치하고 나면 자동으로 code deploy agent를 실행시켜준다.
아래 명령어를 통해서 code deploy agent가 실행되었는지 확인해보면
systemctl status codedeploy-agent.service

이렇게 실행중임을 확인할 수 있다.
7. GitHub Action을 위한 IAM
지금 까지는 AWS의 프로그램들이 다른 AWS의 프로그램에 접근하기 위해서 만들었던것이 IAM의 역할이다.
이번엔 GitHub Actions가 AWS의 프로그램, 여기선 CodeDeploy와 S3에 접근 할 수 있는 IAM을 만들려고 한다.
이렇게 외부의 프로그램이 AWS의 프로그램에 접근하기 위한 IAM은 사용자에서 만들 수 있다.

들어가서 사용자 생성을 클릭해주자.

그리고 사용자 세부 정보 에서는 사용자 이름을 지정해주고 다음을 눌러주자.

그리고 권한은 직접 정책 연결을 선택해주고 여기서 AWSCodeDeployFullAccess권한을 선택해주자.

그리고 S3에도 접근하기 위해서 AmazonS3FullAccess 권한도 추가해주자.

그리고 다음을 눌러주자.
그러면 권한 어떤걸 부여했는지를 보여주고 사용자 생성을 눌러 사용자를 생성해주자.

이제 생성된 사용자 이름 링크를 눌러 들어가주고

보안 자격 증명 탭으로 들어가주면

아래 쪽에 엑세스 키 라는 항목이 존재한다.

엑세스 키 만들기를 눌러주면

위와 같이 엑세스를 할 수 있는 서비스들이 존재한다.
여기서 우리는 GitHub Actions를 접근시킬 것이기 때문에 AWS 외부에서 실행되는 애플리케이션을 선택해서 다음을 눌러주자

설명 태그는 설정 하지 말고 그냥 엑세스 키 만들기를 눌러주자.

그러면 아래처럼 나오는 엑세스 키와 비밀 엑세스 키를 확인 가능한 곳에 저장해두고(외부에 노출되면 안됨, 같은 키는 다시 볼 수 없)

이제 완료를 눌러주자.
이제 GitHub로 들어가서 Secret 값에 이 값을 넣어주자.

이러고 이제 S3로 들어가서

버킷만 만들어주면 CI/CD 구성의 준비는 완료 되었다.
'CI\CD > CI\CD 종합' 카테고리의 다른 글
| Github Actions(CI/CD 구축) - 일반 프로젝트에서 많이 쓰는 CI/CD (0) | 2025.10.15 |
|---|---|
| Github Actions(CI/CD 구축) - .gitignore에 추가된 파일의 주입 (0) | 2025.10.11 |
| CI/CD (0) | 2025.10.03 |
| CI/CD - EC2에 서버 배포 (0) | 2025.10.03 |
| CI/CD - CI/CD를 위한 AWS (0) | 2025.10.03 |