◇ 공부 기록용으로 작성하였으니 틀린점, 피드백 주시면 감사하겠습니다 ◇
CI/CD (Continuous Integration/Continuous Delivery)
AWS의 CI/CD 툴
AWS에서 제공하는 대표적인 CI/CD 툴은 다음과 같다.
- AWS CodePipeline
- AWS CodeCommit
- AWS CodeBuild
- AWS CodeDeploy
- AWS CodeGuru
- AWS CodeArtifact
- AWS CodeStar ... 서비스 종료
CI/CD Pipeline
AWS CodePipeline
AWS의 CI/CD 프로세스를 자동화 하는 서비스이다. CI/CD의 Build, Test, Deploy의 프로세스를 설정한다.
쉽게 말하자면, AWS의 CI/CD 툴(CodeCommit, CodeBuild, CodeDeploy)의 설정을 관리하는 서비스이다.
(위의 AWS의 CI/CD 툴이 아닌 다른 Thrid party의 서비스를 사용할 수 도 있다)
✔ 참고 내용)
✅ CodePipeline + SNS
CodePipeline은 Amazon SNS와 통합하여 파이프라인의 특정 단계별 1)알림 보내기 및 2)승인 액션(approval action)를 추가할 수 있다. 특정 권한을 가지고 있는 IAM이 승인 액션을 포함한 워크플로우를 수정할 수 있다.
✅ CodePipeline + Step Functions
복잡한 워크플로우가 필요한 경우 3)AWS Step Functions를 사용할 수 있다.
[공식 문서]
- 알림 보내기: https://docs.aws.amazon.com/codepipeline/latest/userguide/notification-rule-create.html
- 승인 액션 (Approval Action): https://docs.aws.amazon.com/codepipeline/latest/userguide/approvals-action-add.html
- Step Functions: https://docs.aws.amazon.com/codepipeline/latest/userguide/action-reference-StepFunctions.html
Code Repository (Git)
AWS CodeCommit
AWS의 소스 코드 저장소 서비스로, Git과 호환되는 완전 관리형(fully-managed) 서비스이다.
(즉, Github와 Gitlab와 같다고 생각하면 된다)
✔ 참고 내용)
[Public Key 등록]
CodeCommit에 접근하려면 SSH를 통해 연결해야 하며, 이를 위해 사용자의 공개 키(public key)를 사전에 IAM에 업로드해야 한다. 이 과정을 통해 사용자는 SSH 키를 사용하여 CodeCommit 리포지토리에 안전하게 접근할 수 있게 된다.
[Pull Request]
CodeCommit에서는 Pull Request 기능을 사용하여 다른 사람이 작성한 코드 변경 사항을 리뷰하고, 검토 후에 승인할 수 있다. 주로 리더나 마스터 역할의 사용자가 이러한 변경을 승인하여 메인 브랜치에 반영하게 됩니다. (Github와 Gitlab와 같다)
✅ IAM 권한
CodeCommit의 접근 권한은 AWS IAM Policy을 통해 관리된다.
일반적으로 CodeCommitPowerUser
Policy을 적용하여 기본적인 모든 접근 권한을 부여할 수 있다.
이 Policy는 리포지토리의 생성, 수정, 삭제 등의 작업을 수행할 수 있는 권한을 제공한다.
✅ CodeCommit + EventBridge (CloudWatch Events)
CodeCommit은 EventBridge와 통합할 수 있다.
새로운 코드 변경을 트리거로 특정 작업을 자동으로 실행하도록 설정할 수 있다.
예를 들어, 리포지토리에 푸시(push) 이벤트가 발생하면 이를 감지하여 Lambda 함수를 호출하거나 다른 CI/CD 프로세스를 자동으로 실행할 수 있다. 이 기능을 통해 개발 워크플로우를 자동화하고 효율성을 높일 수 있다.
✅ Github에서 CodeCommit으로 이전하기
비교적 쉽게 Github에서 CodeCommit으로 마이그레이션할 수 있다.
Continuous Integration Service
AWS CodeBuild
AWS의 완전 관리형 Build 서비스로, 소스 코드를 컴파일하고 테스트하며, 실행 가능한 소프트웨어 패키지를 생성하는 데 사용된다. CodeBuild를 통해 새로운 코드 변경 시 자동으로 빌드를 실행하여 소프트웨어 개발의 효율성을 높인다.
[CodeBuild의 유사한 서비스]: Jenkins, GitHub Actions, GitLab CI/CD, CircleCI 등등
✔ 참고 내용)
buildspec.yml: CodeBuild에서 빌드 작업을 정의하는 설정 파일
✅ buildspec.yml
buildspec.yml
은 Build 실행 시에 수행할 명령어(Command)들을 정의한 YAML 형식의 파일이다.
CodeBuild는 기본적으로 이 위치에서 buildspec.yml
파일을 찾아 읽어들여 빌드 작업을 실행한다.
buildspec.yml
이 파일은 소스 코드의 루트 디렉터리(root of the source directory)에 위치해야 한다.
buildspec.yml
의 예시
version: 0.2
phases:
install:
commands:
- echo Installing dependencies...
- npm install # 의존성 설치
build:
commands:
- echo Starting build phase...
- npm run build # 빌드 명령어 실행
post_build:
commands:
- echo Build complete. Starting post-build phase...
- echo All done!
artifacts:
files:
- '**/*' # 모든 빌드 결과 파일 포함
discard-paths: yes # 빌드 결과의 경로를 유지하지 않음
CodeBuild의 Artifacts는 빌드 프로세스가 완료된 후 생성된 파일들을 정의하고 관리하는 섹션이다.
(이 섹션은 빌드 결과물을 어디로 저장할지, 어떤 파일들을 포함할지 등을 설정하는 데 사용된다)
✅ Build의 결과물(Artifacts) 암호화
AWS CodeBuild에서 Artifacts는 빌드 결과물을 의미한다.
CodeBuild는 빌드 작업이 완료된 후 생성되는 결과 파일(artifacts)을 안전하게 관리/보호하기 위해 암호화를 한다.
이 기능은 민감한 데이터를 포함한 빌드 결과물을 AWS의 저장소에 저장할 때, 해당 파일이 암호화된 상태로 저장되도록 설정하는 것이다.
암호화는 CMK(Customer Managed Key) 또는 AWS Managed 키로 암호화 할 수 있다.
✅ Build의 타임아웃 설정
CodeBuild는 실행 시간에 따라 요금이 부과되기 때문에, 빌드가 오래 걸리면 비용이 증가할 수 있다.
(에러로 인해 계속 끝나지 않고 계속 빌드할 수 있다.)
기본 타임아웃 시간은 60분으로 설정되어 있지만, 필요에 따라 타임아웃을 설정할 있다.
CLI에서 queuedTimeoutInMinutesOverride
옵션을 사용하여 타임아웃 시간을 설정할 수 있으며, 최소 5분에서 최대 480분까지 조정 가능하다.
✅ CLI 명령을 통한 CodeBuild 설정
privilegedModeOverride
: 이 옵션을 true로 설정하면 권한 모드가 활성화되어, Docker 내에서 Docker를 실행하거나 특권이 필요한 빌드를 수행할 수 있다.
reportBuildStatusOverride
: 이 옵션은 빌드 상태(시작 및 완료)를 GitHub, Bitbucket과 같은 소스 코드 제공자에게 보고할지 여부를 설정한다.
Automated Code Deployment
AWS CodeDeploy
CodeDeploy는 애플리케이션을 AWS 서비스(EC2, Lambda,..) 온프레미스 서버 등 다양한 컴퓨팅에 자동으로 배포(Deploy)할 수 있게 도와주는 서비스이다.
이를 통해 Lambda 함수의 버전 업데이트, 애플리케이션 배포 중의 다운타임 방지 등이 더 쉬워지며, git 명령어를 사용하여 소스 코드를 버전 관리할 수 있다.
[CodeDeploy의 유사한 서비스]: Jenkins, Octopus Deploy, GitLab CI/CD, Jenkins 등등
✔ 참고 내용)
appspec.yml: 배포 시 어떤 파일을 어디에 복사하고,어느 시점에 어떤 스크립트를 실행할지를 지정
✅ appspec.yml
파일
CodeDeploy에서 애플리케이션 배포 방식을 정의하는 YAML 파일이다.
배포 프로세스의 각 단계에서 무엇을 해야 하는지, 어떤 파일을 어디에 배치할 것인지, 그리고 배포 중에 실행할 스크립트나 명령어을 명시한다.appspec.yml
파일은 애플리케이션의 소스 코드 루트 디렉터리(root of the source directory)에 위치해야 한다.
appspec.yml
파일이 필요한 이유
(예시) 개발 팀이 EC2 인스턴스에서 실행되는 웹 애플리케이션을 정기적으로 업데이트하고 배포해야 한다고 할 경우, 배포 과정에서 다음과 같은 단계가 필요하다.
- 현재 서버 중지: 새 파일을 덮어쓰기 전에 서버를 먼저 중지
- 새 버전의 파일 복사: 최신 애플리케이션 파일을 서버의 올바른 위치에 덮어쓰기한다.
- 필수 라이브러리 설치: 의존성이 생겼다면 새 파일에 맞는 라이브러리를 설치
- 서버 재시작: 업데이트가 완료된 웹 애플리케이션 서버를 다시 시작
- 검사 및 완료: 모든 단계가 성공적으로 완료되었는지 확인
위와 같은 단계를 appspec.yml
를 통해 정의한다.
예시) appspec.yml
- version: AppSpec 파일의 버전을 정의한다
- os: 운영 체제를 지정한다. (주로 linux 또는 windows로 지정)
- files: 애플리케이션 소스 파일을 어디에 배치할지를 정의하는 부분
- hooks: 배포 과정 중 특정 시점에 실행할 스크립트나 명령어를 정의
- ApplicationStop
- BeforeInstall
- AfterInstall
- ApplicationStar
- ValidateService
version: 0.0
os: linux
files:
- source: /
destination: /home/username/myapp
hooks:
ApplicationStop:
- location: scripts/stop_server.sh
timeout: 300
runas: username
BeforeInstall:
- location: scripts/pre_install.sh
timeout: 300
runas: username
AfterInstall:
- location: scripts/post_install.sh
timeout: 300
runas: username
ApplicationStart:
- location: scripts/start_server.sh
timeout: 300
runas: username
ValidateService:
- location: scripts/validate_service.sh
timeout: 300
runas: username
✅ AppSpec 파일의 hooks 섹션 : (In-Place Deployment)
배포 과정 중 특정 시점에 실행할 스크립트나 명령어를 정의한다. 아래의 순서대로 실행된다.
- ApplicationStop: 배포 전에 실행 중인 애플리케이션을 중지.
- BeforeInstall: 새로운 애플리케이션이 설치되기 전에 실행.
- AfterInstall: 새 애플리케이션 버전이 설치된 후 실행.
- ApplicationStart: 새 버전을 설치한 후 애플리케이션을 다시 시작.
- ValidateService: 배포가 완료된 후 서비스가 정상적으로 작동하는지 확인.
✅ 배포 유형: (In-Place, Blue/Green)
AWS CodeDeploy에서는 2가지 배포 유형을 제공한다.
- In-Place Deployment (인플레이스 배포) ...기존 애플리케이션에 직접 새로운 버전을 설치하는 방식
- Blue/Green Deployment (블루/그린 배포) ...기존 버전(블루)과 새로운 버전(그린)을 동시에 운영하는 방식으로, 새로운 버전이 완전히 준비되면 트래픽을 전환하는 방식
AWS 서비스마다 선택가능한 배포 방식이 다르다
ECS : Blue/Green 배포만 지원
EC2/On-Premises : In-Place 배포 또는 Blue/Green 배포
Lambda : Canary, Linear, All-at-Once
✅ Deployment Group (배포 그룹)
CodeDeploy의 Deployment Group은 배포할 대상 서버 그룹을 정의하는 설정이다
- 배포 대상 지정: (예를 들어, PROD, DEV 환경을 나누고 각 환경별로 배포 대상을 다르게 지정할 수 있다)
- EC2 인스턴스
- Lambda 함수
- ECS
- 배포 환경 제어: 배포 시 로드 밸런서 사용 여부, 배포 방식 (In-place 또는 Blue/Green) 등을 설정할 수 있다.
- 자동 롤백(Rollback): 배포 실패 시 자동으로 롤백하는 설정을 할 수 있다 (혹은 특정 이벤트 발생 시 자동으로 작업을 트리거하는 기능을 제공한다)
✅ CodeDeploy Agent
EC2 환경에서 CodeDeploy를 사용하려면 CodeDeploy Agent를 EC2 인스턴스에 설치해야 한다.
CodeDeploy Agent는 appspec.yml 파일을 실행하는 데몬 역할을 하며, 인스턴스에 설치되면 그 인스턴스를 CodeDeploy에서 사용할 수 있게 만든다.
(공식 문서) 설치하는 방법:
https://docs.aws.amazon.com/codedeploy/latest/userguide/codedeploy-agent-operations-install-ssm.html#download-codedeploy-agent-on-EC2-Instance
👩🏫 확인 문제:
개발자는 코드변경을 Code Deploy를 사용해서 AWS ECS에 배포할려고 한다. 이때 사용할 수 있는 배포 유형은??
- In-Place
- Canary
- Blue/Green
- Linear
정답
정답. 3번
CodeDeploy를 사용한 ECS 배포는 Blue/Green 유형만 지원한다.
Inline 배포는 EC2 인스턴스나 온프레미스 서버에 직접 애플리케이션을 배포할 때 사용하는 유형이다.
Code Review Tool
AWS CodeGuru
CodeGuru는 개발자가 작성한 코드를 자동으로 리뷰하고, 코드의 품질 및 성능 문제를 찾아내며, 이를 해결하기 위한 추천 사항을 제공한다.
CodeGuru Reviewer
GitHub이나 CodeCommit에 등록된 애플리케이션의 소스 코드를 리뷰하고, 결과를 Pull Request로 알려준다
현재 Java와 Python 언어를 지원한다.
CodeGuru Profiler
에이전트를 설치하여 애플리케이션을 실행시킴으로써 CPU 사용률이나 지연 시간 등 여러 항목을 분석하고 시각화해주며, 성능 문제가 있을 경우 이를 자동으로 식별하고 수정 방법을 제안해준다.
CodeGuru Reviewer | CodeGuru Profiler |
Artifact Repository - securely store, publish, and share software packages.
AWS CodeArtifact
CodeArtifact는 개발팀이 애플리케이션 개발에 필요한 패키지(예:Maven
, npm
, Python
, NuGet
)를 저장, 관리, 공유할 수 있는 완전 관리형 패키징 매니지먼트 서비스이다.
'클라우드(AWS)' 카테고리의 다른 글
[AWS] SDK란? 쉽게 정리 (Software Development Kit) (2) | 2024.10.03 |
---|---|
[AWS] SAM (Serverless Application Model)이란? 쉽게 정리 (SAM CLI, Template) (0) | 2024.10.02 |
[AWS] CloudFormation이란? 쉽게 정리 (IaC, Template, Stack, StackSets, Service Role, Service Catalog) (0) | 2024.09.25 |
[AWS] Redshift란? 쉽게 정리 (데이터 웨어하우스) (1) | 2024.09.14 |
[AWS] Security Group ID 란?? 쉽게 정리 (0) | 2024.09.12 |