AWS CodePipeline

본문의 내용은 AWS CodePipeline의 공식 문서를 발췌한 내용입니다.
의역과 오타가 있을수 있으며, 해당 내용이 발견된다면 댓글 주시면 감사하겠습니다.

CodePipeline에 대한 내용과 사용 방법에 대해서 기술한 문서 입니다.

AWS Pipeline

CodePipeline으로 할 수 있는 작업

릴리스 프로세스 자동화

• CodePipeline은 빌드, 테스트, 배포를 통해 소스 리포지토리에서 시작해서 말단까지 릴리스 프로세스를 완전히 자동화합니다.
• Source 단계를 제외하고 모든 단계에서 수동 승인 작업을 포함시키면 파이프라인을 통해 변경 내용이 이동하지 않도록 방지할 수 있습니다.
• 인스턴스 한 개나 여러 개에 원하는 시기에 원하는 방식으로 선택한 시스템에서 릴리스할 수 있습니다

일관된 릴리스 프로세스 수립

• 모든 코드 변경에 대해 일관된 단계를 정의하십시오. CodePipeline기준에 따라 릴리스의 각 단계를 실행합니다.

품질을 개선하면서 제공 속도 증가

• 개발자들이 증분 방식으로 코드를 테스트하고 릴리스할 수 있도록 릴리스 프로세스를 자동화하며 새 기능을 고객에게 빨리 선보일 수 있습니다.

즐겨 찾는 도구 이용:

• 기존의 소스와 빌드, 배포 도구를 파이프라인에 통합할 수 있습니다.진행 상황 한 눈에 보기

1. 파이프라인의 실시간 상태를 검토
2. 알림의 세부 정보를 확인
3. 실패한 작업을 재시도
4. 각 단계의 최신 파이프라인 실행에 사용된 소스 수정에 대한 세부 정보를 확인
5. 파이프라인을 수동으로 다시 실행할 수 있습니다.

파이프라인 기록 세부 정보 보기

시작 및 종료 시간, 실행 기간 및 실행 ID 등의 파이프라인 실행에 대한 세부 정보를 볼 수 있습니다.

간단히 보는 Pipeline

• 이 예에서 개발자가 소스 리포지토리에 변경을 가하면 CodePipeline이 자동으로 변경 내용을 감지합니다.
• 그러한 변경 내용을 빌드하고 테스트를 구성하는 경우에는 그 테스트를 실행합니다.
• 테스트를 마친 후 테스트를 위해 빌드된 코드를 스테이징 서버로 배포합니다.
• 스테이징 서버에서 CodePipeline은 통합이나 로드 테스트 같은 추가 테스트를 실행합니다.
• 테스트가 성공적으로 끝나고 파이프라인에 추가한 수동 승인 작업에 승인을 받고 나면 CodePipeline이 테스트가 완료된 승인받은 코드를 프로덕션 인스턴스에 배포합니다.
• CodePipelineCodeDeployAWS Elastic Beanstalk, 또는 AWS OpsWorks Stacks 를 사용하여 애플리케이션을 EC2 인스턴스에 배포할 수 있습니다.
• CodePipelineAmazon ECS를 사용하여 컨테이너 기반 애플리케이션을 서비스에 배포할 수도 있습니다.
• 개발자는 CodePipeline과 함께 제공되는 통합 포인트를 이용해 빌드 서비스, 테스트 제공자, 다른 배포 대상이나 시스템 같은 다른 도구나 서비스를 플러그인할 수 있습니다.
• 파이프라인은 릴리스 프로세스가 요구하는 대로 단순하거나 복잡해집니다.

CodePipeline 시작하기

CodePipeline 개념

파이프라인

• 파이프라인이란 소프트웨어 변경 사항이 릴리스 프로세스에 적용되는 방법을 설명하는 워크플로우 구성입니다.
• 각 파이프라인은 일련의 단계로 구성됩니다.

Stages

• 단계는 환경을 격리하고 해당 환경에서 동시 변경 작업의 수를 제한하는 데 사용할 수 있는 논리 단위입니다.
• 각 단계에는 애플리케이션 아티팩트에 대해 수행되는 작업이 포함됩니다.
• 소스 코드는 아티팩트의 한 예입니다.
  • 소스 코드가 빌드되고 테스트가 실행되는 빌드 단계가 될 수 있습니다.
  • 또한 코드가 런타임 환경에 배포되는 배포 단계가 될 수도 있습니다. 각 단계는 일련의 직렬 또는 병렬 작업으로 구성됩니다.

작업

• 작업은 애플리케이션 코드에서 수행되고 지정된 지점에 파이프라인에서 작업이 실행되도록 구성된 일련의 작업입니다.
• 여기에는 코드 변경의 소스 작업, 애플리케이션을 인스턴스에 배포하는 작업 등이 포함될 수 있습니다.
  • 예를 들어 배포 단계에는 Amazon EC2 또는 같은 컴퓨팅 서비스에 코드를 배포하는 배포 작업이 포함될 수AWS Lambda 있습니다.

파이프라인 실행

• 실행은 파이프라인에서 릴리스된 변경 집합입니다.
• 각 파이프라인 실행은 고유한 자체 ID를 가집니다.
• 실행은 병합된 커밋 또는 최신 커밋의 수동 릴리스와 같은 변경 집합에 해당합니다.
• 두 실행은 서로 다른 시간에 동일한 변경 집합을 릴리스할 수 있습니다.
• 파이프라인은 동시에 여러 실행을 처리할 수 있지만 파이프라인 단계는 한 번에 하나의 실행만 처리합니다.
  • 두 파이프라인 실행이 동시에 같은 단계를 차지할 수는 없습니다.
• 점유 단계에 진입하기 위해 대기 중인 실행을 인바운드 실행이라고 합니다.
• 인바운드 실행은 여전히 실패하거나 대체되거나 수동으로 중지될 수 있습니다.

중지된 실행

• 진행 중인 파이프라인 실행이 파이프라인을 통해 계속되지 않도록 파이프라인 실행을 수동으로 중지할 수 있습니다.
• 수동으로 중지한 경우 파이프라인 실행은 완전히 중지될 때까지 Stopping 상태로 표시됩니다.
• 그런 다음 Stopped 상태로 표시됩니다. Stopped 파이프라인 실행을 다시 시도할 수 있습니다.
• 파이프라인 실행을 중지하는 방법은 두 가지입니다.
  • 중지 및 대기
  • 중지 및 중단

실패한 실행

• 실행이 실패하면 작업이 중지되고 파이프라인을 완전히 순회하지 못합니다.
• 상태는 FAILED 상태가 됩니다.
• 실패한 실행이 대체되었거나 다시 시도할 수 없는 경우가 아니면 실패한 실행을 재시도할 수 있습니다.

대체된 실행

• 파이프라인을 통해 최신 변경 집합을 전달하기 위해 보다 최근의 실행이 파이프라인을 통해 이미 실행 중인 실행을 전달 및 대체합니다.
• 이 경우 이전 실행은 새로운 실행으로 대체됩니다.
  • 실행은 단계 사이의 특정 지점에서 보다 최근의 실행으로 대체될 수 있습니다.
• 실행이 잠금 상태의 단계로 진입하기 위해 대기 중인 경우, 보다 최근의 실행이 이를 파악해 대체할 수 있습니다.
• 이제 보다 최신의 실행이 단계가 잠금 해제될 때까지 대기하고, 대체된 실행은 SUPERSEDED 상태로 중지됩니다.
• 파이프라인 실행이 대체되면 실행이 중지되고 파이프라인을 완전히 순회하지 않게 됩니다.
• 이 단계에서 대체된 실행은 이후에 더 이상 재시도할 수 없습니다.

단계 실행

• 스테이지 실행은 스테이지 내의 모든 작업을 완료하는 프로세스입니다.

작업 실행

• 작업 실행은 지정된 아티팩트에서 작동하는 구성된 작업을 완료하는 프로세스입니다.
• 입력 아티팩트, 출력 아티팩트 또는 둘 다가 여기에 해당될 수 있습니다.
  • 예를 들어 빌드 작업은 애플리케이션 소스 코드 컴파일과 같은 입력 아티팩트에서 빌드 명령을 실행할 수 있습니다.
• 작업 실행 세부 정보에는 작업 실행 ID, 관련된 파이프라인 실행 소스 트리거, 작업의 입력 및 출력 아티팩트가 포함됩니다.
• 작업의 유효한 상태는 InProgress, AbandonedSucceeded, 또는Failed 입니다.

작업 유형

• 사전 구성된 CodePipeline 작업입니다.
• 소유자, 공급자, 버전 및 범주 별로 정의됩니다.
• 파이프라인에서 작업을 완료하는 데 사용되는 사용자 지정 매개 변수를 제공합니다

Transitions

• 전환은 파이프라인 실행이 파이프라인의 다음 단계로 이동하는 지점입니다.
• 단계의 인바운드 전환을 비활성화하여 실행이 해당 단계로 들어가지 못하도록 한 다음, 전환을 활성화하여 실행을 계속할 수 있습니다.
• 둘 이상의 실행이 비활성화된 전환에 도달하면 가장 최신의 실행만 다음 단계로 계속되어 전환이 활성화됩니다.
• 즉, 전환이 비활성화된 동안 보다 최신의 실행이 대기 중인 실행을 계속 대체하고 전환이 활성화된 후에는 계속 진행되는 실행이 대체 실행이 됩니다.

Artifacts

• 아티팩트는 애플리케이션 소스 코드, 빌드된 애플리케이션, 종속성, 정의 파일, 템플릿 등과 같이 파이프라인 작업을 통해 만들어진 데이터 컬렉션을 의미합니다.
• 아티팩트는 일부 작업에서 생성되고 다른 작업에서 사용됩니다.
• 파이프라인에서 아티팩트는 작업에서 만들어진 파일 집합(입력 아티팩트)이거나 완료된 작업의 업데이트 출력(출력 아티팩트)이 될 수 있습니다.
• 작업은 파이프라인 아티팩트 버킷을 사용하여 추가 처리를 위해 출력을 다른 작업에 전달합니다.
• CodePipeline 아티팩트를 아티팩트 저장소에 복사합니다. 아티팩트 저장소에서 해당 아티팩트를 픽업합니다.

소스 개정

• 소스 코드를 변경하면 새 버전이 생성됩니다.
• 소스 개정은 파이프라인 실행을 트리거하는 소스 변경의 버전입니다.
• 실행은 해당되는 소스 개정만 처리합니다.
• GitHub 및 CodeCommit 리포지토리의 경우 커밋입니다.
• S3 버킷 또는 작업의 경우 객체 버전이 여기에 해당됩니다

DevOps 파이프라인 예제

• 파이프라인의 예로, 2단계 DevOps 파이프라인에는 Source라는 소스 단계와 Prod라는 두 번째 단계가 있을 수 있습니다.
• 이 예제에서는 파이프라인이 애플리케이션을 최신 변경 사항으로 업데이트하고 최신 결과를 지속적으로 배포합니다.
• 최신 애플리케이션을 배포하기 전에 파이프라인은 웹 애플리케이션을 빌드 및 테스트합니다.
• 이 예제에서는 개발자 그룹이 라는 GitHub 리포지토리에 웹 애플리케이션의 인프라 템플릿과 소스 코드를 MyRepository 설정했습니다.

예를 들어 개발자가 웹 애플리케이션의 인덱스 페이지를 수정 사항을 푸시하며 다음과 같은 상황이 발생합니다.

애플리케이션 소스

• 애플리케이션 소스 코드는 파이프 라인에서 GitHub 소스 작업으로 구성된 리포지토리에서 유지 관리됩니다.
• 개발자가 커밋을 리포지토리로 푸시하면 CodePipeline은 푸시된 변경 사항을 감지하고 Source Stage(소스 단계)에서 파이프라인 실행이 시작됩니다.

애플리케이션 소스 변경 완료

• GitHub소스 작업이 성공적으로 완료되었습니다.
• 즉, 최신 변경 사항이 다운로드 되어 해당 실행에 고유한 아티팩트 버킷에 저장되었습니다.
• GitHub 소스 작업에서 생성된 출력 아티팩트 (리포지토리의 응용 프로그램 파일) 는 다음 단계에서 작업에서 작업할 입력 아티팩트로 사용됩니다.

프로덕션 단계로 변환

• 파이프라인 실행은 Source Stage(소스 단계)에서 Prod Stage(프로덕션 단계)로 전환됩니다.
• Prod Stage(프로덕션 단계)의 첫 번째 작업은 CodeBuild에서 생성되고 파이프 라인에서 빌드 작업으로 구성된 빌드 프로젝트를 실행합니다.
• 빌드 작업은 빌드 환경 이미지를 가져오며 가상 컨테이너에서 웹 애플리케이션을 빌드합니다.

CodeBuild 작업

• Prod Stage(프로덕션 단계)의 다음 작업은 CodeBuild에서 생성되고 파이프라인에서 테스트 작업으로 구성된 단위 테스트 프로젝트입니다.

Prod Stage

• 다음 단계로 단위 테스트 코드는 프로덕션 환경에 애플리케이션을 배포하는 Prod Stage(프로덕션 단계)의 배포 작업에서 처리됩니다.
• 배포 작업이 성공적으로 완료되고 난 후 해당 단계의 최종 작업은 CodeBuild에서 생성되고 파이프라인에서 테스트 작업으로 구성된 통합 테스트 프로젝트입니다.
• 테스트 작업은 웹 애플리케이션에서 링크 검사기와 같은 테스트 도구를 설치하고 실행하는 셸 스크립트를 호출합니다.
• 성공적으로 완료가 된 후에는 빌드된 웹 애플리케이션 및 테스트 결과 집합이 출력됩니다.

권장 파이프라인 구조

• 작업이 모두 동일한 실행을 처리하도록 단계 내에서 관련 작업을 그룹화하는 것이 가장 좋습니다.
• 각 애플리케이션 환경 또는 가용 영역 AWS 리전 등에 대한 단계를 만들 수 있습니다.
• 단계가 너무 많은(즉, 너무 세분화된) 파이프라인은 동시 변경을 너무 많이 허용할 수 있으며, 큰 단계(잘 세분화되지 않은)에서 작업의 수가 많은 파이프라인의 경우 변경 사항을 릴리스하는 데 너무 오랜 시간이 걸릴 수 있습니다.
  • 예를 들어, 동일한 단계의 배포 작업 이후의 테스트 작업은 배포된 것과 동일한 변경 사항을 테스트하도록 보장됩니다.
• 이 예제에서는 변경 사항을 테스트 환경에 배포하고 테스트한 다음, 테스트 환경의 최신 변경 사항을 프로덕션 환경에 배포합니다.
• 권장되는 예제에서 테스트 환경과 프로덕션 환경은 별도의 단계입니다.
  
  

  Pipeline 생성(CodeCommit 리포지토리)

CodeCommit 셋팅

• Pipeline 생성의 예시이기에, 예시 코드를 생성합니다.

• 위의 파일 구조를 가지고, 아래의 Pipeline을 생성합니다.

Amazon EC2 Linux 인스턴스 생성 후, 에이전트 설치

• 이 단계에서는 샘플 애플리케이션을 배포하는 Amazon EC2 인스턴스를 만듭니다.
• 이 프로세스의 일부로 인스턴스에 CodeDeploy 에이전트를 설치하고 관리할 수 있는 인스턴스 역할을 생성합니다.
  • CodeDeploy 에이전트는 인스턴스를 CodeDeploy 배포에서 사용할 수 있게 해주는 소프트웨어 패키지입니다.
• 또한 CodeDeploy 에이전트가 애플리케이션을 배포하는 데 사용하는 파일을 인스턴스에서 가져오고 SSM에서 인스턴스를 관리하도록 허용하는 정책을 첨부합니다.

인스턴스 시작하기

• 대시 보드에서 역할을 누릅니다.

• 상단 오른쪽에 역할 만들기 버튼을 클릭합니다.

• 위 옵션을 선택하고, 다음을 누릅니다.

• 위에 AmazonEC2RoleforAWSCodeDeploy 를 검색하고 추가합니다.

• 위 처럼 AmazonSSManagedInstanceCore 를 검색하고 정책을 추가합니다.

• 위 처럼 이름을 지정하고 난 후에 Role를 생성합니다.
• 후에 EC2를 생성하기 위해 인스턴스 시작 버튼을 누릅니다.

1. 이름(Name)
   1. MyCodePipelineDemo를 입력합니다.
   2. 이렇게 하면 인스턴스에 태그 NameKey와 태그Value가 할당됩니다.
   3. MyCodePipelineDemo 나중에 샘플 CodeDeploy 애플리케이션을 이 인스턴스에 배포하는 애플리케이션을 생성합니다.
2. CodeDeploy태그를 기반으로 배포할 인스턴스를 선택합니다.

3. 애플리케이션 및 OS 이미지 (Amazon 머신 이미지) 에서 AWS 로고가 있는 Amazon Linux AMI 옵션을 찾아 선택되어 있는지 확인합니다. (이 AMI는 아마존 리눅스 2 AMI (HVM) 로 설명되며 “프리 티어 적격”이라는 라벨이 붙어 있습니다.)
4. 인스턴스 유형 에서 프리 티어 대상 t2.micro 유형을 인스턴스의 하드웨어 구성으로 선택합니다.
   
   
5. key pair (로그인) 에서 키 페어를 선택하거나 키 페어를 만듭니다.

키 페어가 없이도 진행할 수 있습니다.

 

네트워크 설정에서 다음을 수행합니다.
퍼블릭 IP 자동 할당에서 상태가 활성화인지 확인합니다.

CodeDeploy에서 애플리케이션 생성

• CodeDeploy에서 애플리케이션은 배포하고자 하는 소프트웨어 애플리케이션이 포함된 리소스입니다.
• 나중에 이 애플리케이션을 사용하여 샘플 애플리케이션을 Amazon EC2 CodePipeline 인스턴스에 배포하는 작업을 자동화합니다.
• 먼저 CodeDeploy가 배포를 수행하도록 허용하는 역할을 생성합니다. 그런 다음 CodeDeploy 애플리케이션을 생성합니다.

IAM Role 등록

• IAM Roles를 클릭합니다.

• 새로운 Role을 만들어 줍니다.
  • 예를 들면 : CodeDeployRole

• AWSCodeDeployRole을 클릭하여 해당 Role에 추가합니다.

Deploy 생성

• Compute platform에서는 현재 해당되는 platform을 선택해서 넣어주면 됩니다.

CodeDeploy 배포 그룹

• 배포 그룹은 배포할 인스턴스, 배포 속도와 같은 배포 관련 설정을 정의하는 리소스입니다.

• 그룹 이름을 지정하고, 전에 만들었던 Role을 아래에 Service role을 클릭합니다.

• Deployment type은 원하는 것을 선택하고, Amazon EC2 instacne를 선택합니다.

• 위와 같이 Key 값과 Value 값을 채워줍니다.

• AWSSystems Manager Manager를 사용한 에이전트 구성에서 '지금'을 선택하고 업데이트를 예약합니다.
  • 이렇게 하면 인스턴스에 에이전트가 설치됩니다.
• Linux 인스턴스는 이미 SSM 에이전트로 구성되어 있으며 이제 CodeDeploy 에이전트와 함께 업데이트됩니다.

• 아래도 환경에 맞게 셋팅하면 됩니다.

• 아래와 같이 CodeDeploy를 생성하면 됩니다.

CodePipeline 생성

• Create pipeline 을 누릅니다.

• pipeline name을 클릭하여, 이름을 지정합니다.

2 step

• 소스 공급자를 선택합니다.
  • 저희 환경은 CodeCommit이기에, CodeCommit을 선택합니다.

• 선택하게 된다면 위의 그림처럼 세부 정보를 볼 수 있습니다.
  • 이 부분도 환경에 맞게 셋팅 하면 됩니다.

• 배포할 리소스를 선택하면 Pipeline 셋팅이 끝나게 됩니다.