Pipeline 구축 방법
CI/CD 파이프라인 생성을 자동화하는 가장 좋은 방법은 코드로서의 인프라를 통해 프로그래밍 방식으로 프로비저닝하는 것입니다. 이는 마이크로서비스당 파이프라인이 있는 마이크로서비스 환경에서 특히 유용합니다. 이는 잠재적으로 수십 개의 파이프라인을 의미할 수 있습니다. 이러한 파이프라인을 자동으로 생성하는 방법을 사용하면 개발자가 매번 콘솔에서 수동으로 빌드하지 않고도 필요한 만큼 생성할 수 있습니다.
파이프라인을 만드는 다양한 방법
프로그래밍 방식으로 파이프라인을 생성하기 위해 다양한 메커니즘을 사용하는 고객을 봅니다. 오늘날 개발자는 선택할 수 있는 선택지가 많지만 가장 일반적인 것은 다음과 같습니다.
AWS CloudFormation
AWS CDK
Terraform
AWS Serverless App Repository
AWS CDK 소개
이번에는 AWS Cloud Development Kit(CDK라고도 함)를 파이프라인 판매 메커니즘으로 사용할 것입니다. AWS CDK는 클라우드 인프라를 코드로 정의하고 AWS CloudFormation을 통해 프로비저닝하기 위한 소프트웨어 개발 프레임워크입니다.
TypeScript, C#, Python 또는 Java로 코드를 작성하여 인프라를 설명할 수 있습니다. 그런 다음 코드가 CloudFormation으로 합성되고 CDK CLI를 사용하여 AWS 계정에 배포할 수 있습니다.
SAM과 CDK는 어떻게 함께 사용할 수 있을까요?
서버리스 개발자는 SAM 프레임워크를 사용하여 애플리케이션을 정의하고, SAM CLI를 사용하여 애플리케이션을 구축 및 배포하고, AWS CDK를 사용하여 CI/CD 파이프라인과 같은 인프라 관련 리소스를 프로비저닝합니다. 이러한 도구의 좋은 점은 모두 CloudFormation이라는 공통 기반을 공유한다는 것입니다.
CDK project 설치
아래 명령어로 설치하면 됩니다.
npm install -g aws-cdk
project 시작
mkdir pipeline
cd pipeline
다음 명령을 실행하여 pipeline 폴더 내에서 새 CDK 프로젝트를 초기화합니다.
cdk init --language typescript
이제 파이프라인을 구축하는 데 사용할 CDK 모듈을 설치합니다.
npm install --save @aws-cdk/aws-codedeploy @aws-cdk/aws-codebuild
npm install --save @aws-cdk/aws-codecommit @aws-cdk/aws-codepipeline-actions
npm install --save @aws-cdk/aws-s3
이 시점에서 프로젝트는 다음과 같은 구조를 가져야 합니다(가장 관련성이 높은 파일 및 폴더만 표시됨). CDK 프로젝트 내에서 상호 작용할 기본 파일은 pipeline-stack.ts입니다. 지금은 나머지 파일에 대해 걱정하지 마십시오.
CDK 프로젝트의 entry-point인 bin/pipeline.ts 파일을 열고 스택 이름을 sam-app-cicd로 변경합니다.
lib/pipeline-stack.ts 파일을 엽니다. 현재 비어 있지만 여기에서 CI/CD 파이프라인을 빌드하기 위한 코드를 추가할 것입니다.(주석이 엄청 많습니다.ㅋ)
아직 코드를 작성하지 않았지만 여기에서 여러 번 수행할 것이며 프로세스에 익숙해질 것이므로 CDK 프로젝트를 빌드하고 배포하는 방법에 대해 알아보겠습니다. 다음 명령으로 프로젝트를 빌드하여 시작합니다.
cd ~/environment/sam-app/pipeline
npm run build
빌드가 완료되면 CDK CLI를 사용하여 파이프라인 프로젝트를 배포합니다.
cdk deploy
계정에 새 CloudFormation 스택이 생성되었지만 CDK 프로젝트가 비어 있기 때문에 생성된 리소스는 AWS::CDK::Metadata뿐입니다. CloudFormation 콘솔을 확인하면 새 스택과 메타데이터 리소스가 표시됩니다.
ARTIFACTS BUCKET
모든 코드 파이프라인에는 아티팩트 저장소라고도 하는 아티팩트 버킷이 필요합니다. CodePipeline은 이 버킷을 사용하여 다운스트림 작업에 아티팩트를 전달하고 SAM이 빌드 프로세스 중에 아티팩트를 업로드하는 위치이기도 합니다.
이제 이 버킷을 생성하는 코드를 작성해 보겠습니다.
확장자가 .ts인 파이프라인 스택 파일을 편집하고 있는지 확인하십시오.
// lib/pipeline-stack.ts
import * as cdk from '@aws-cdk/core';
import s3 = require('@aws-cdk/aws-s3');
import codecommit = require('@aws-cdk/aws-codecommit');
import codepipeline = require('@aws-cdk/aws-codepipeline');
import codepipeline_actions = require('@aws-cdk/aws-codepipeline-actions');
import codebuild = require('@aws-cdk/aws-codebuild');
export class PipelineStack extends cdk.Stack {
constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
// The code that defines your stack goes here
const artifactsBucket = new s3.Bucket(this, "ArtifactsBucket");
}
}
이제 이전에 했던 것처럼 프로젝트를 빌드하고 배포합니다.
npm run build
cdk deploy
결과 로그는 비슷합니다.
위와 같이 S3 가 생성 됩니다.
SOURCE STAGE
소스 단계는 모든 CI/CD 파이프라인의 첫 번째 단계이며 소스 코드를 나타냅니다. 이 단계는 새로운 코드 변경(예: git push 또는 pull 요청)을 기반으로 파이프라인을 트리거하는 역할을 합니다. 이 워크샵에서는 AWS CodeCommit을 소스 공급자로 사용하지만 CodePipeline은 S3, GitHub 및 Amazon ECR도 소스 공급자로 지원합니다.
pipeline-stack.ts 파일에서 버킷 정의 뒤에 다음 코드 조각을 추가합니다.
// Import existing CodeCommit sam-app repository
const codeRepo = codecommit.Repository.fromRepositoryName(
this,
'AppRepository', // Logical name within CloudFormation
'sam-app' // Repository name
);
// Pipeline creation starts
const pipeline = new codepipeline.Pipeline(this, 'Pipeline', {
artifactBucket: artifactsBucket
});
// Declare source code as an artifact
const sourceOutput = new codepipeline.Artifact();
// Add source stage to pipeline
pipeline.addStage({
stageName: 'Source',
actions: [
new codepipeline_actions.CodeCommitSourceAction({
actionName: 'CodeCommit_Source',
repository: codeRepo,
output: sourceOutput,
}),
],
});
주의 할점은 s3 설정 바로 다음에 입력해야합니다
이미 CodeCommit 리포지토리가 있으므로 새 리포지토리를 만들 필요가 없으며 리포지토리 이름을 사용하여 가져오기만 하면 됩니다.
또한 객체 sourceOutput을 파이프라인 아티팩트로 정의하는 방법에 주목하십시오. 이는 CodePipeline이 다운스트림 단계로 전달하려는 모든 파일에 필요합니다. 이 경우 소스 코드가 Build 단계로 전달되기를 원합니다.
파이프라인을 생성하려면 최소 2단계가 필요하기 때문에 아직 cdk 배포를 수행하지 마십시오.
다음 페이지로 계속 진행하여 먼저 빌드 단계를 추가합니다.
BUILD STAGE
빌드 단계는 서버리스 애플리케이션이 SAM에 의해 빌드되고 패키징되는 곳입니다. 파이프라인의 빌드 공급자로 AWS CodeBuild를 사용할 것입니다. CodePipeline은 Jenkins, TeamCity 또는 CloudBees와 같은 다른 공급자도 지원합니다.
AWS 코드 빌드가 필요한 이유
AWS CodeBuild는 빌드가 실행되는 시간에 대해서만 비용을 지불하기 때문에 훌륭한 옵션입니다. 따라서 실제로 근무 시간에만 빌드를 하는 전용 빌드 서버를 하루 24시간 실행하는 것에 비해 비용 효율성이 매우 높습니다. 또한 컨테이너 기반이므로 빌드가 실행되는 자체 Docker 컨테이너 이미지를 가져오거나 CodeBuild에서 제공하는 관리형 이미지를 사용할 수 있습니다.
빌드 단계 추가
계속해서 Pipeline-stack.ts에 빌드 단계를 추가해 보겠습니다.
// Declare build output as artifacts
const buildOutput = new codepipeline.Artifact();
// Declare a new CodeBuild project
const buildProject = new codebuild.PipelineProject(this, 'Build', {
environment: { buildImage: codebuild.LinuxBuildImage.AMAZON_LINUX_2_2 },
environmentVariables: {
'PACKAGE_BUCKET': {
value: artifactsBucket.bucketName
}
}
});
// Add the build stage to our pipeline
pipeline.addStage({
stageName: 'Build',
actions: [
new codepipeline_actions.CodeBuildAction({
actionName: 'Build',
project: buildProject,
input: sourceOutput,
outputs: [buildOutput],
}),
],
});
그리고 아래 명령어로 배포를 진행합니다.
npm run build
cdk deploy
이제 aws codepipeline에 가서 확인합니다.
생성은 되었으나 실행이 실패 되었다는 것을 볼 수 있습니다.
원인은 빌드중에 실행할 명령어를 지정하지 않았기 때문입니다.
이제 이것을 고쳐 볼 것입니다.
BUILDSPEC FILE
Buildspec 파일은 CodeBuild가 애플리케이션을 빌드하기 위해 실행하는 YAML 형식의 일련의 명령입니다. 이 파일은 SAM 애플리케이션의 루트 폴더에 있으며 CodeBuild는 자동으로 이 파일을 찾아 빌드 시간 동안 실행합니다.
Cloud9 편집기에서 sam-app 폴더를 마우스 오른쪽 버튼으로 클릭하고 새 파일을 선택하여 sam-app 디렉토리의 루트(최상위 수준)에 buildspec.yml이라는 새 파일을 만듭니다.
파일 확장자는 yml 또는 yaml일 수 있으며 CodeBuild는 어느 쪽이든 찾을 수 있습니다.
# ~/environment/sam-app/buildspec.yml
version: 0.2
phases:
install:
runtime-versions:
nodejs: 12
commands:
# Install packages or any pre-reqs in this phase.
# Upgrading SAM CLI to latest version
- pip3 install --upgrade aws-sam-cli
- sam --version
# Installing project dependencies
- cd hello-world
- npm install
pre_build:
commands:
# Run tests, lint scripts or any other pre-build checks.
- npm run test
build:
commands:
# Use Build phase to build your artifacts (compile, etc.)
- cd ..
- sam build
post_build:
commands:
# Use Post-Build for notifications, git tags, upload artifacts to S3
- sam package --s3-bucket $PACKAGE_BUCKET --output-template-file packaged.yaml
artifacts:
discard-paths: yes
files:
# List of local artifacts that will be passed down the pipeline
- packaged.yaml
해당 코드를 이제 push 합니다.
cd ~/environment/sam-app
git add .
git commit -m "Added buildspec.yml"
git push
그러면 build가 성공하는 것을 볼 수 있다.
DEPLOY STAGE
배포 단계는 SAM 애플리케이션과 모든 리소스가 AWS 계정에서 생성되는 곳입니다.
이를 수행하는 가장 일반적인 방법은 CloudFormation ChangeSets를 사용하여 배포하는 것입니다.
즉, 이 단계에는 CreateChangeSet 및 ExecuteChangeSet의 2가지 작업이 있습니다.
pipeline-stack.ts에 배포 단계를 추가합니다.
// Deploy stage
pipeline.addStage({
stageName: 'Dev',
actions: [
new codepipeline_actions.CloudFormationCreateReplaceChangeSetAction({
actionName: 'CreateChangeSet',
templatePath: buildOutput.atPath("packaged.yaml"),
stackName: 'sam-app',
adminPermissions: true,
changeSetName: 'sam-app-dev-changeset',
runOrder: 1
}),
new codepipeline_actions.CloudFormationExecuteChangeSetAction({
actionName: 'Deploy',
stackName: 'sam-app',
changeSetName: 'sam-app-dev-changeset',
runOrder: 2
}),
],
});
Deploy the pipeline
다음 명령어를 cmd에 입력하여 배포합니다.
cd ~/environment/sam-app/pipeline
npm run build
cdk deploy
CLI는 배포하기 전에 변경 사항을 확인하도록 요청할 수 있습니다. (저같은 경우는 항상 물어봄..)이는 애플리케이션을 배포하는 IAM 역할에 관리자 권한을 부여하기 때문입니다. 이 역할은 사람이 아니라 CloudFormation에서만 맡을 수 있기 때문에 일반적으로 나쁜 습관은 아닙니다. 그러나 조직에 더 엄격한 보안 태세가 있는 경우 세분화된 정책으로 사용자 지정 IAM 배포 역할을 생성하는 것을 고려할 수 있습니다.
Trigger a release
파이프라인으로 이동하면 배포 단계가 추가된 것을 볼 수 있지만 트리거되지 않았기 때문에 현재 회색으로 표시됩니다. 릴리스 변경 버튼을 클릭하여 파이프라인의 새 실행을 수동으로 트리거해 보겠습니다.
이제 확인을 해봅시다.
잘 돌아가는것을 확인 하실수 있습니다.
이제 변경사항을 푸시합니다.
sam-app 폴더내에서 수행합니다.
git add .
git commit -m "CI/CD Pipeline definition"
git push
이제 serverless application CI/CD를 만들었습니다.
'CLOUD > AWS' 카테고리의 다른 글
Canary 배포 개요(SAM) (0) | 2021.08.24 |
---|---|
AWS codecommit 리포지토리 연결 및 에러 (0) | 2021.08.24 |
Pipeline 만들기(SAM) 개요 및 리포지토리 생성 (0) | 2021.08.23 |
AWS에 수동 배포(SAM) (0) | 2021.08.23 |
로컬에서 프로젝트 실행(SAM) (0) | 2021.08.23 |
댓글