지난 글에 application.yml 파일을 s3에 저장하고 spring cloud config를 통해서 가져오는 방법을 테스트하였다.
그러나 해당 방식을 사용하지 않고 다른 방법을 사용하기로 했는데,
현재 사용하는 CodeBuild buildspec에 aws cli로 s3 설정파일을 가져왔기 때문이다
? CodeBuild는 뭐고 buildspec이란 무엇인가?
AWS에서 제공하는 CI/CD 기능 중 하나로 우리 회사는 운영서버 배포까지 CodePipeline을 사용한다
그렇다 오늘은 이게 뭔지 알아보도록 하자
AWS CodePipeline
-> 뭔가 많은 서비스
CodeCommit
우리가 일반적으로 사용하는 Github와 비슷하다
CodeCommit에서 관리하면 보안/호스팅 서비스 등등 장접들을 이야기 하고 있고 검색해보면 Github에서 CodeCommit으로 마이그레이션 하는 방법들이 많이 나오는데, 그럼에도 불구하고 이걸 꼭 써야하는지 잘 모르겠어서 Github를 사용한다.
CodeBuild
애플리케이션 코드를 빌드하기 위한 서비스
소스코드 컴파일, 테스트 실행하여 배포 준비가 완료된 산출물 생성
해당 산출물(아티팩트)은 S3에 저장할 수도 있다.
우리 회사의 경우 buildSpec.yml 파일을 통해 바로 ECR에 올려버린다.
buildspec.yml
CodeBuild 가 소스 빌드 시 작업 환경 설정 파일
현재 우리 설정에서 사용되는 것은 phases와 artifacts로 볼 수 있는데
phases의 경우 (install), pre_build, build, post_build로 나뉘어 각 단계에 맞는 명령을 호출한다.
나의 경우 pre_build에 맨 위에서 말했던 application.yml 파일을 가져왔다.
artifacts는 산출물을 나타내는 단계
이외에도 cache, batch 등등이 있다
- AWS에서 제공하는 Sample
version: 0.2
#env:
#variables:
# key: "value"
# key: "value"
#parameter-store:
# key: "value"
# key: "value"
#secrets-manager:
# key: secret-id:json-key:version-stage:version-id
# key: secret-id:json-key:version-stage:version-id
#exported-variables:
# - variable
# - variable
#git-credential-helper: yes
#batch:
#fast-fail: true
#build-list:
#build-matrix:
#build-graph:
phases:
#install:
#runtime-versions:
# name: version
# name: version
#commands:
# - command
# - command
#pre_build:
#commands:
# - command
# - command
build:
commands:
# - command
# - command
#post_build:
#commands:
# - command
# - command
#reports:
#report-name-or-arn:
#files:
# - location
# - location
#base-directory: location
#discard-paths: yes
#file-format: JunitXml | CucumberJson
#artifacts:
#files:
# - location
# - location
#name: $(date +%Y-%m-%d)
#discard-paths: yes
#base-directory: location
#cache:
#paths:
# - pathsCodeDeploy
CodeBuild를 수행하였으면 해당 산출물을 배포하는 서비스
위에서 말했듯이 ECR에 이미지를 저장하였기 때문에 우리의 경우 ECS에 배포한다.
ECS 말고도 Amazon EC2 인스턴스, 온프레미스 인스턴스, 서버리스 Lambda 함수 이런 서비스들에서도 배포 가능하다.
appspec.yml
CodeDeploy의 작업 환경 설정 파일
- AWS 공식 문서의 ECS 배포용 예제 (https://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/reference-appspec-file-example.html)
version: 0.0
Resources:
- TargetService:
Type: AWS::ECS::Service
Properties:
TaskDefinition: "arn:aws:ecs:us-east-1:111222333444:task-definition/my-task-definition-family-name:1"
LoadBalancerInfo:
ContainerName: "SampleApplicationName"
ContainerPort: 80
# Optional properties
PlatformVersion: "LATEST"
NetworkConfiguration:
AwsvpcConfiguration:
Subnets: ["subnet-1234abcd","subnet-5678abcd"]
SecurityGroups: ["sg-12345678"]
AssignPublicIp: "ENABLED"
CapacityProviderStrategy:
- Base: 1
CapacityProvider: "FARGATE_SPOT"
Weight: 2
- Base: 0
CapacityProvider: "FARGATE"
Weight: 1
Hooks:
- BeforeInstall: "LambdaFunctionToValidateBeforeInstall"
- AfterInstall: "LambdaFunctionToValidateAfterInstall"
- AfterAllowTestTraffic: "LambdaFunctionToValidateAfterTestTrafficStarts"
- BeforeAllowTraffic: "LambdaFunctionToValidateBeforeAllowingProductionTraffic"
- AfterAllowTraffic: "LambdaFunctionToValidateAfterAllowingProductionTraffic"CodePipeline
문서를 보니
AWS CodePipeline은 소프트웨어를 릴리스하는 데 필요한 단계를 모델링, 시각화 및 자동화할 수 있게 해주는 지속적 전달 서비스입니다.
라고 하는데 나의 언어로 바꾸어 보자
결국 위의 CodeCommit(Github), CodeBuild, CodeDeploy를 한 번에 하나의 프로세스로 동작할 수 있도록 만들어주는 서비스이다
실제로 구성을 보면 'Source' - 'Build' - 'Deploy'로 나누어져 있으며 파이프라인 들어가 [변경 사항 릴리즈] 버튼을 누르면 앞의 단계들이 한 번에 실행되는 것을 볼 수 있다.
그림 요약
vs Jenkins
장점
- 따로 서버구성해서 세팅하지 않아도 된다 (예전에 사양 낮은 서버 사용했다가 꺼먹은 적 많다)
- 현재 AWS에 서비스들이 구성되어 있어서 AWS 관련 세팅할 때 좀 수월한 듯
단점
- 비용이 든다
- 젠킨스가 여러 플러그인들이 많은 듯
