CodePipeline을 이용한 CI/CD - 파이프 라인 생성
지금까지 ECS 자동배포를 위한 ECR과 ALB를 생성하고 세팅했었다. 이제 AWS CodePipeline을 이용해 ECS 자동 배포를 시작해 보자. 일단 나는 GitHub main 브랜치에 Push가 되면 자동 배포를 trigger 하는 구성이다.
1. ECR, ECS 그리고 CodePipeline을 같이 사용하는 이유
AWS ECR (Elastic Container Registry), ECS (Elastic Container Service), 그리고 CodePipeline을 함께 사용하는 것은 매우 강력한 CI/CD (Continuous Integration/Continuous Deployment) 파이프라인을 구축할 수 있는 방법이다.
1-1. 자동화된 워크플로우
- CodePipeline을 사용하면 코드 변경이 발생할 때마다 자동으로 빌드와 배포 프로세스가 시작된다.
- ECR에서 빌드된 도커 이미지를 저장하고 이를 ECS로 자동 배포할 수 있다.
1-2. 일관성과 높은 가용성
- 이러한 자동화는 일관된 배포를 보장하고, 높은 가용성을 유지하는데 도움을 준다.
1-3. 간소화된 관리
- 세 서비스가 모두 AWS 에코시스템 내에 있기 때문에 관리가 간편하다.
- AWS의 다양한 관리 도구와 모니터링 서비스를 쉽게 통합할 수 있다.
1-4. 보안
- AWS IAM (Identity and Access Management)을 이용해서 누가 ECR에 이미지를 푸시하거나 ECS에서 컨테이너를 실행할 수 있는지 등의 접근 제어를 세밀하게 설정할 수 있다.
1-5. 확장성
- ECS는 확장성이 뛰어나므로 트래픽이 증가할 경우 자동으로 스케일을 조정할 수 있다.
1-6. 감소된 오류율
- 자동화된 테스트와 배포 과정을 통해 사람에 의한 오류를 최소화할 수 있다.
1-7. 비용 효율성
- AWS의 서비스들은 서로 잘 통합되어 있어 추가적인 인프라 구축 비용이나 유지 관리 비용이 줄어든다.
따라서 ECR, ECS, 그리고 CodePipeline을 함께 사용하면 각각의 서비스의 이점을 최대화하면서, 효율적이고 안정적인 CI/CD 파이프라인을 구축할 수 있다.
2. 파이프 라인 생성하기
2-1. AWS CodePipeline 서비스 화면으로 이동한다.
CI/CD Pipeline - AWS CodePipeline - Amazon Web Services
AWS CodePipeline은 빠르고 안정적인 애플리케이션 및 인프라 업데이트를 위해 릴리스 파이프라인을 자동화하는 데 도움이 되는 완전관리형의 지속적 전달 서비스입니다.
aws.amazon.com
2-2. 우측에 [파이프라인 생성] 을 클릭한다.
- 그럼 아래와 같이 5단계가 있다.
3. 파이프라인 설정 선택 - Step 1
- 이름을 작성하고 버전은 V2를 선택한다.
- 서비스 역할에서 '새 서비스 역할'을 선택하든, '기존 서비스 역할'을 선택하든 큰 차이는 없다.
- 역할 이름은 파이프라인 이름을 작성할때 자동으로 입력된다.
- 하단의 변수 설정은 default로 두고 [다음] 버튼을 눌러서 넘어간다.
4. 소스 스테이지 추가하기 - Step 2
4-1. 소스 스테이지를 추가한다.
4-2. 소스 공급자는 Github(버전 2)를 선택한다.
- 기존에 연결해 둔 GitHub가 있다면 돋보기 영역을 클릭해서 선택하면 된다.
- 기존에 연결해 둔 GitHub가 없다면 [GitHub에 연결] 버튼을 클릭한다.
4-2-1. 새로 열린 팝업창에서 '연결 이름'을 작성하고 [GitHub에 연결] 버튼을 클릭한다.
4-2-2. GitHub와 AWS 연동이 처음이라면 AWS 연결 페이지가 나올 것이고 여기서 [Authorize AWS Connector for GitHub] 버튼을 누른다.
4-2-3. 다음으로 Gihubu에 연결하는 설정이 나온다.
- 여기서 우측에 [새 앱 설치] 버튼을 클릭한다.
4-2-4. 이제 여기서 GitHub 계정에 연결해준다.
4-2-5. AWS Connector for GitHub를 'Install' 해준다.
- 여기서 나는 All repositories를 선택해 줬는데 Only select repositories를 선택해 줘도 된다.
4-2-6. 이제 다시 연결하는 창으로 이동될 것인데 아까 만든 앱이 자동으로 선택되어 있을 것이다.
4-3. 소스 공급자로 깃허브를 연결했다면 아래와 같이 나온다.
4-4. 하단에서 리포지토리 이름을 클릭해서 내가 CI/CD로 연결해 줄 리포지토리를 선택한다.
4-5. 다음으로는 파이프라인을 동작시킬 트리거를 설정한다.
- 나는 여기서 '브랜치 내 푸시'를 선택하고 브랜치 이름에서 'main'을 선택했다.
- 'release' 브랜치나 다른 브랜치를 원한다면 git repository에서 브랜치를 생성하고 오면 브랜치 이름에서 선택할 수 있다.
4-6. 마지막으로 출력 아티팩트 형식은 CodePipeline 기본값으로 선택하고 “다음” 버튼을 눌렀다.
5. 빌드 스테이지 추가하기 - Step 3
5-1. 소스 스테이지를 추가했다면 이제 “빌드 스테이지”를 추가할 차례다.
- 공급자에는 AWS CodeBuild를 선택한다.
5-2 프로젝트를 설정해 준다.
- 이미 존재한다면 그것을 선택하고 없다면 우측의 [프로젝트 생성] 버튼을 눌러서 만들어 주자
5-2-1. 기존에 만들어준 프로젝트가 없다면 프로젝트를 구성한다.
- 프로젝트 이름과 설명을 적는다.
5-2-2. '환경'을 설정한다.
- 환경 이미지는 “관리형 이미지”를 선택한다.
- 운영 체제는 'Ubuntu'
- 런타임은 'Standard'
- 이미지는 'standard:7.0'을 선택했고
- 이미지 버전도 '이 런타임 버전에 항상 최신 이미지 사용'을 선택한다.
- 환경 유형은 'Linux'를 선택한다.
5-2-3. 권한이 있음 체크 (나는 추후 도커 이미지 빌드를 위해 체크해 주도록 한다.)
5-2-4. 서비스 역할을 설정한다.
- 사실 여기서 가장 중요한 게 서비스 역할이다.
- 나는 로그를 S3에 작성하고, 도커 이미지를 ECR에서 가져와서 배포를 진행하는 구성이다.
- 그래서 '새 서비스 역할'을 선택했다면 [IAM > 역할]에 들어가서 생성된 역할에 S3 접근 권한과 ECR 접근 권한을 추가해줘야 한다.
- 아니면, 기존에 S3 접근 권한과 ECR 접근권한이 있는 역할이 있다면 '기존 서비스 역할'을 선택하고 그 역할을 선택해 주면 된다.
5-2-5. 이제 다음으로 Buildspec을 선택한다.
- '빌드 명령 삽입'을 선택하고 Buildspec을 넣는다.
- 아래는 Buildspec.yml 예시 코드다.
version: 0.2
phases:
pre_build:
commands:
- echo Logging in to Amazon ECR...
- aws ecr get-login-password --region <리전> | docker login --username AWS --password-stdin <이미지 URI>
build:
commands:
- echo Building the Docker image...
- docker build -t <이미지 URI>:<태그> .
post_build:
commands:
- echo Pushing the Docker image...
- docker push <이미지 URI>:<태그>
5-2-6. 아래의 나머지 하단의 설정들은 그냥 default로 두고 하단의 “CodePipeline으로 계속” 버튼을 누른다.
5-2-7. 'CopePipeline으로 계속' 버튼을 누르면 아래와 같이 나오는데 겁먹지 말고 “나가기”를 누르자
5-3. 이제 프로젝트가 생성되면서 자동으로 방금 만든 프로젝트가 선택되었을 것이다.
5-4. 맨 하단의 [다음] 버튼을 누른다.
5-5. 아래의 사진은 다 작성한 “빌드 스테이지 추가”의 최종본이다.
6. 배포 스테이지 추가 및 검토 - Step 4
6-1. 이제 배포 스테이지를 추가한다.
- 배포 공급자에 Amazon ECS를 선택하고 ECS 클러스터를 선택하고 서비스도 선택한다.
- 서비스 이름에서 선택할 수 있는 서비스는 현재 EC2가 실행 중인 서비스만 나온다.
- 나머지 설정은 기본으로 둔다.
6-2. 위에서 “다음” 버튼을 누르면 아래의 검토로 이동된다
- 여기서 지금까지 했던 설정들을 한번 살펴보고 생성한다.
6-3. CodePipeline 생성이 완료되면 아래와 같이 나온다.
7. 마무리
다음 포스팅에서 제대로 배포가 되었는지 확인하는 과정을 작성해 보도록 하겠다.
코드 파이프라인을 이용한 CI/CD가 사실 되게 빨리 끝날 것 같았는데 생각보다 오래 걸렸다. 블로그 정리된 글도 생각보다 별로 없었고 하나를 설정하면서 다른 하나를 또 생성해 주고 이 모든 게 엮여있었기 때문에 조금 어려웠다.
하지만 이렇게 AWS 서비스를 이용해서 클라우드 네이티브로 전환되는 구성을 보면서 뿌듯함을 느꼈다.
'AWS' 카테고리의 다른 글
| [AWS] CodePipeline을 이용한 CI/CD (3) - 빌드 오류 해결 (IAM 역할에 권한 정책 연결) (0) | 2023.11.01 |
|---|---|
| [AWS] CodePipeline을 이용한 CI/CD (2) - 빌드 오류 해결 (S3 접근 권한) (2) | 2023.10.31 |
| [AWS] ECS 생성5 - ECS 생성 및 설정 (w ALB) (0) | 2023.10.31 |
| [AWS] ECS 생성4 - ECS 생성 및 설정 (w/o ALB) (0) | 2023.10.30 |
| [AWS] ECS 생성3 - ALB 세팅하기 (0) | 2023.10.30 |
