Category: AWS CodePipeline


Github에 대한 AWS DevOps 개발 도구 기능 확대

AWS 개발자 도구는 AWS CodeCommit, AWS CodePipeline, AWS CodeBuildAWS CodeDeploy를 포함하는 서비스 모음입니다. 이들 서비스는 애플리케이션 소스 코드의 버전 관리를 안전하게 저장 및 유지하고 애플리케이션을 AWS 또는 온프레미스 환경에 자동으로 구축하고 테스트하고 배포하는 데 도움이 됩니다. AWS 개발자 도구는 개발자 및 IT 전문가가 소프트웨어를 신속하고 안전하게 제공할 수 있도록 설계되어 있습니다.

AWS는 AWS 개발자 도구 에코시스템을 타사의 도구 및 서비스로 확장하려는 지속적인 노력의 일환으로 마침내 AWS CodeStarAWS CodeBuild와 GitHub의 통합을 실현했습니다. 이 덕분에 GitHub 사용자도 이제 AWS 개발자 도구를 사용하여 지속적 통합 및 배포 도구 체인을 릴리스 프로세스의 일부로 보다 용이하게 구축할 수 있게 되었습니다.

이 게시물에서는 다음에 대해 알아보겠습니다.

사전 조건:

AWS 계정, GitHub 계정, Amazon EC2 키 페어, 그리고 AWS Identity & Access Management(IAM), AWS CodeStar, AWS CodeBuild, AWS CodePipeline, Amazon EC2, Amazon S3의 관리자 수준 권한이 필요합니다.

GitHub와 AWS CodeStar의 통합

AWS CodeStar를 사용하면 AWS에서 애플리케이션을 빠르게 개발하고 빌드하고 배포할 수 있습니다. AWS CodeStar의 통합 사용자 인터페이스는 한 곳에서 소프트웨어 개발 활동을 손쉽게 관리할 수 있게 해 줍니다. AWS CodeStar를 사용하면 몇 분 이내에 지속적 배포 도구 체인 전체를 구축할 수 있으므로 코드 릴리스를 보다 빨리 시작할 수 있습니다.

AWS CodeStar가 올해 4월에 출시되었을 때 AWS CodeCommit을 호스팅 대상 소스 리포지토리로 사용했습니다. 이제는 AWS CodeCommit 또는 GitHub 중에 선택하여 CodeStar 프로젝트를 위한 소스 제어 서비스로 지정할 수 있습니다. 이에 더해, CodeStar 프로젝트 대시보드를 사용하면 커밋, 이슈 및 풀 요청과 같은 GitHub 활동을 추적할 수 있습니다. 이 기능은 CI/CD 도구 체인의 구성 요소 전체에 걸쳐 프로젝트 활동을 용이하게 관리할 수 있도록 해 줍니다. GitHub 대시보드 보기 기능이 추가되면 AWS 애플리케이션의 배포가 더욱 간단해질 것입니다.

여기에서는 CodeStar 프로젝트를 위한 소스 공급자로 GitHub를 활용하는 방법을 보여 드릴 것입니다. 아울러 CodeStar 대시보드에서 최근의 커밋, 이슈 및 풀 요청과 관련된 작업을 수행하는 방법을 알려 드릴 것입니다.

AWS Management Console에 로그인한 다음 [Services] 메뉴에서 [CodeStar]를 클릭합니다. CodeStar 콘솔에서 [Create a new project]를 선택합니다. 그러면 [Choose a project template] 페이지가 나타납니다.

CodeStar 프로젝트

프로그래밍 언어, 애플리케이션 범주 또는 AWS 서비스 별로 옵션을 선택합니다. 저는 Amazon EC2에서 실행되는 Rails 웹 애플리케이션에서 Ruby를 선택할 것입니다.

이제 [Project details] 페이지에서 GitHub 옵션을 확인할 수 있습니다. 프로젝트의 이름을 입력하고 [Connect to GitHub]를 선택합니다.

프로젝트 세부 정보

GitHub 리포지토리에 연결할 수 있는 권한을 요청하는 메시지가 표시됩니다. 메시지가 표시되면 [Authorize]를 선택한 다음 GitHub 계정 암호를 입력합니다.

승인

그러면 GitHub ID가 OAuth를 통해 AWS CodeStar에 연결됩니다. 언제나 [GitHub application settings]에서 탐색을 통해 설정을 살펴볼 수 있습니다.

설치된 GitHub 앱

아래와 같이 [AWS CodeStar is now connected to GitHub]라는 메시지가 표시됩니다.

프로젝트 만들기

퍼블릭 또는 프라이빗 리포지토리를 선택할 수 있습니다. GitHub는 퍼블릭 및 오픈 소스 프로젝트에 참여하는 사용자 및 조직에 대해 무료 계정을 제공하는 한편 무제한 프라이빗 리포지토리와 사용자 관리 기능 및 보안 기능(옵션)이 포함된 유료 계정 또한 제공하고 있습니다.

이 예제에서는 퍼블릭 리포지토리 옵션을 선택합니다. 원할 경우 리포지토리 설명을 편집한 다음 [Next]를 선택합니다.

CodeStar 프로젝트 세부 정보를 검토한 다음 [Create Project]를 선택합니다. [Choose an Amazon EC2 Key Pair]에서 [Create Project]를 선택합니다.

키 페어

[Review project details]에서 [Edit Amazon EC2 configuration]이 표시됩니다. 이 링크를 선택하여 인스턴스 유형, VPC 및 서브넷 옵션을 구성합니다. AWS CodeStar의 경우 AWS 리소스 및 IAM 권한을 생성하고 관리하려면 서비스 역할이 필요합니다. 이 서비스 역할은 [AWS CodeStar would like permission to administer AWS resources on your behalf ] 확인란을 선택하면 생성됩니다.

[Create Project]를 선택합니다. 프로젝트 및 리소스를 생성하는 데 몇 분 정도 걸릴 수 있습니다.

프로젝트 세부 정보 검토

CodeStar 프로젝트를 만들면 프로젝트 팀에 소유자로 추가됩니다. AWS CodeStar를 처음으로 사용하는 경우 다음과 같은 정보를 제공하라는 메시지가 표시되는데, 다른 사람에게 공개되는 정보입니다.

  • 표시 이름
  • 이메일 주소

이 정보는 AWS CodeStar 사용자 프로필에 사용됩니다. 사용자 프로필은 프로젝트가 아닌 단일 AWS 리전에 한정됩니다. 사용자가 여러 리전의 프로젝트 일원인 경우 각 리전마다 사용자 프로필을 생성해야 합니다.

사용자 설정

사용자 설정

[Next]를 선택합니다. AWS CodeStar는 여러분이 설정한 구성에 따라 GitHub 리포지토리를 생성합니다(예: https://github.com/biyer/ruby-on-rails-service).

IDE(통합 개발 환경)를 AWS CodeStar와 통합하면 원하는 환경에서 계속 코드를 작성하고 개발할 수 있습니다. 변경 사항은 코드를 커밋하고 푸시할 때마다 AWS CodeStar 프로젝트에 포함됩니다.

IDE

IDE를 선택한 후에, [Next]를 선택하여 CodeStar 대시보드로 이동합니다. 익숙해지도록 몇 분 정도 대시보드를 살펴보십시오. 작업 항목의 백로그에서 최근의 코드 배포까지 전체 소프트웨어 개발 프로세스에 걸쳐 진행 사항을 용이하게 추적할 수 있습니다.

대시보드

애플리케이션 배포가 완료되면 애플리케이션을 표시할 엔드포인트를 선택합니다.

Pipeline

해당 애플리케이션의 엔드포인트를 열면 다음과 같은 화면이 표시됩니다.

대시보드의 [Commit history] 섹션에 GitHub 리포지토리의 커밋 이력이 표시됩니다. 커밋 ID 또는 [Open in GitHub ]옵션을 선택하면, GitHub 리포지토리에 대한 핫링크를 사용할 수 있습니다.

커밋 이력

AWS CodeStar 프로젝트 대시보드에서 사용자와 사용자의 팀은 프로젝트에 대한 최신 커밋, 지속적 제공 파이프라인의 상태, 인스턴스 성능을 비롯한 프로젝트 리소스의 상태를 확인합니다. 이 정보는 특정 리소스 전용 타일에 표시됩니다. 이러한 리소스에 대한 자세한 내용을 보려면 해당 타일에서 세부 정보 링크를 선택합니다. 해당 AWS 서비스의 콘솔이 해당 리소스의 세부 정보 페이지에서 열립니다.

문제

또한 상태 및 할당된 사용자를 기준으로 이슈를 필터링할 수 있습니다.

필터

AWS CodeBuild, 이제 GitHub 풀 요청 구축 지원

CodeBuild는 소스 코드를 컴파일하고 테스트를 실행하며 배포 준비가 완료된 소프트웨어 패키지를 생성하는 완전 관리형 빌드 서비스입니다. CodeBuild를 사용하면 자체 빌드 서버를 프로비저닝, 관리 및 확장할 필요가 없습니다. CodeBuild는 지속적으로 확장되며 여러 빌드를 동시에 처리하기 때문에 빌드가 대기열에서 대기하지 않습니다. 사전 패키징된 빌드 환경을 사용하여 신속하게 시작할 수 있으며 혹은 자체 빌드 도구를 사용하는 사용자 지정 빌드 환경을 만들 수 있습니다.

최근 AWS는 AWS CodeBuild에서 이제 GitHub 풀 요청 구축을 지원한다는 사실을 발표했습니다. 이 기능을 사용하면 CodeBuild로 애플리케이션 코드를 편집하고 빌드하는 동시에 팀원들과 보다 용이하게 협업할 수 있습니다. AWS CodeBuild 콘솔 또는 AWS CodePipeline 콘솔에서 AWS CodeBuild를 실행할 수 있습니다. 또한 AWS Command Line Interface(AWS CLI), AWS SDK 또는 AWS CodeBuild Plugin for Jenkins를 사용하여 AWS CodeBuild의 실행을 자동화할 수 있습니다.

AWS CodeBuild

이 단원에서는 Webhook을 통한 GitHub로부터의 풀 요청을 사용하여 AWS CodeBuild에서 빌드를 트리거하는 방법을 알아보겠습니다.

https://console.aws.amazon.com/codebuild/에서 AWS CodeBuild 콘솔을 엽니다. [Create Project]를 선택합니다. CodeBuild 프로젝트가 이미 있는 경우, [Edit project]를 선택한 다음 지시를 따르면 됩니다. CodeBuild는 AWS CodeCommit, S3, BitBucket 및 GitHub와 연결하여 빌드의 소스 코드를 가져올 수 있습니다. [Source provider]에서, [GitHub]를 선택한 다음, [Connect to GitHub]를 선택합니다.

구성

GitHub와 CodeBuild 프로젝트를 성공적으로 연결한 후에는 GitHub 계정에서 리포지토리를 선택할 수 있습니다. CodeBuild 또한 임의의 퍼블릭 리포지토리에 대한 연결을 지원합니다. [GitHub application settings]에서 탐색을 통해 설정을 살펴볼 수 있습니다.

GitHub 앱

[Source: What to Build]의 [Webhook]에서 [Rebuild every time a code change is pushed to this repository ] 확인란을 선택합니다.

참고: 이 옵션은 [ Repository]에서 [Use a repository in my account]를 선택한 경우에만 선택할 수 있습니다.

소스

[Environment: How to build]의 [Environment image]에서 [Use an image managed by AWS CodeBuild]를 선택합니다. [Operating system]에서 [Ubuntu]를 선택합니다. [Runtime]에서 [Base]를 선택합니다. [Version]에서 가용한 최신 버전을 선택합니다. [Build specification]에서 빌드 명령 및 관련 설정 모음을 YAML 형식(buildspec.yml)으로 제공하거나 빌드 명령을 콘솔에 직접 삽입함으로써 빌드 사양을 재정의할 수 있습니다. AWS CodeBuild는 이들 명령을 사용하여 빌드를 실행합니다. 이 예제에서 출력은 문자열 “hello”입니다.

환경

[Artifacts: Where to put the artifacts from this build project]의 [Type]에서 [No artifacts]를 선택합니다. (이는 테스트를 실행하거나 도커 이미지를 Amazon ECR에 넣을 경우 선택하는 유형이기도 합니다.) AWS CodeBuild가 사용자를 대신하여 종속 AWS 서비스와 상호 작용할 수 있으려면 AWS CodeBuild 서비스 역할이 있어야 합니다. 기존에 역할이 없는 경우에는 [Create a role]을 선택하고 [Role name]에서 역할 이름을 입력합니다.

결과물

이 예제에서는 고급 설정을 기본값으로 둡니다.

[Show advanced settings]를 확장하면 다음을 포함하여 빌드를 지정할 수 있는 옵션이 표시됩니다.

  • 빌드 제한 시간
  • 이 프로젝트의 빌드에서 사용할 모든 결과물을 암호화하는 KMS 키
  • 도커 이미지 빌드 옵션
  • 빌드 작업 동안의 권한 상승(예: 빌드 컨테이너 내의 도커에 액세스하여 Dockerfile을 빌드)
  • 컴퓨팅 유형을 빌드하기 위한 리소스 옵션
  • 환경 변수(내장 또는 사용자 지정) 자세한 내용은 AWS CodeBuild 사용 설명서의 [Create a Build Project]를 참조하십시오.

고급 설정

AWS CodeBuild 콘솔을 사용하여 Amazon EC2 시스템 관리자에서 파라미터를 생성할 수 있습니다. [Create a parameter]를 선택한 다음, 대화 상자에 표시되는 지시에 따릅니다. (대화 상자의 [KMS key]에서 계정에 있는 AWS KMS 키의 ARN을 선택적으로 지정할 수 있습니다. Amazon EC2 시스템 관리자는 이 키를 사용하여 저장하는 동안 파라미터의 값을 암호화하고 검색 동안 암호를 해독합니다.)

파라미터 생성

[Continue]를 선택합니다. 나중에 [Review] 페이지에서 [Save and build] 또는 [Save]를 선택하여 빌드를 실행합니다.

[Start build]를 선택합니다. 빌드가 완료되면 [Build logs ]에 빌드에 관한 세부 정보가 표시됩니다.

로그

풀 요청을 시연하기 위해 리포지토리를 다른 GitHub 사용자로 포크하고, 포크된 리포지토리로 커밋하고, 변경 사항을 새로 생성된 브랜치로 체크인한 다음, 풀 요청을 엽니다.

풀 요청

풀 요청이 제출되는 즉시, CodeBuild가 빌드 실행을 시작합니다.

구축

GitHub가 HTTP POST 페이로드를 Webhook의 구성된 URL(강조 표시된 부분)로 전송합니다. 이 URL은 CodeBuild가 최신 소스 코드를 다운로드하고 빌드 단계를 실행하는 데 사용합니다.

빌드 프로젝트

GitHub 풀 요청에 대해 [Show all checks] 옵션을 확장하면 CodeBuild가 빌드를 완료하였고, 모든 확인이 통과되었고, CodeBuild 콘솔에서 빌드 이력을 여는 데 사용하는 딥 링크가 [Details]에 제공됨을 확인할 수 있습니다.

풀 요청

요약:

이 게시물에서 GitHub를 CodeStar 프로젝트의 소스 공급자로 활용하는 방법과 CodeStar 대시보드에서 최근의 커밋, 이슈 및 풀 요청과 관련된 작업을 수행하는 방법을 알아봤습니다. 또한 GitHub 풀 요청을 사용하여 AWS CodeBuild에서 빌드를 자동으로 트리거하는 방법과 특히 이 기능을 사용하면 CodeBuild를 통해 애플리케이션 코드를 편집하고 빌드하는 동시에 팀원들과 보다 용이하게 협업할 수 있다는 것을 알려 드렸습니다.


작성자 소개:

Balaji Iyer는 AWS 전문 서비스 팀에서 엔터프라이즈 컨설턴트로 활약하고 있습니다. Balaji Iyer는 이 역할을 맡으면서 다수의 고객이 AWS 제품을 알아보고 선택하는 데 일조했습니다. 그의 전문 분야는 고도 확장형 분산 시스템, 서버 없는 아키텍처, 대규모 마이그레이션, 운영 보안, 전략적 AWS 이니셔티브 등의 설계 및 구현입니다. Balaji Iyer는 Amazon에 합류하기 전에 10년 이상 운영 체계, 빅 데이터 분석 솔루션, 모바일 서비스 및 웹 애플리케이션을 구축해 왔습니다. 여가 시간에는 아웃도어 활동을 즐기거나 가족과 함께 시간을 보냅니다.

이 글은 AWS DevOps 블로그의 AWS Developer Tools Expands Integration to Include GitHub의 한국어 번역입니다.

AWS CodePipeline, 서울 리전 출시

오늘 AWS 코드 개발 서비스AWS CodePipeline이 서울 리전에 출시하였습니다. 하단 언어 메뉴를 한국어로 바꾸시면 한국어 콘솔 화면도 보실 수 있습니다.

사실 민첩하고 신속한 개발 및 운영(DevOps)과 클라우드 기반 인프라 자동화 관리는 개발자에게 매우 중요한 요소입니다. AWS의 개발 도구는 이러한 라이프사이클을 완벽하게 도와 주는 것으로 소스 코드 개발부터 테스트, 빌드 및 배포까지 자동화 합니다.

특히, AWS CodePipeline 은 출시 과정을 자동으로 운영하는 것으로, AWS CodeCommit이나 Github, AWS CodeBuild나 Jekins 그리고 AWS CodeDeployAWS Elastic Beanstalk 또는 AWS OpsWorks 를 통해 EC2 인스턴스 또는 자체 물리 서버에 배포 할 수 있습니다 .

지난 2015년 6월 AWS CodePipeline 정식 출시 이후에 추가된 기능 몇 가지를 추가로 소개해 드립니다.

  • AWS OpsWorks 통합
  • 람다 함수 트리거링
  • 수동 승인 조치
  • 커밋된 변경 사항에 대한 정보

AWS OpsWorks 통합 – AWS Codepipeline에서 모델링한 소프트웨어 출시 파이프 라인에서 AWS OpsWorks를 배포 공급자로 선택할 수 있습니다 .

또한,AWS OpsWorks for Chef에 포함 된 레시피를 사용하여 코드를 배포 할 수 있습니다.

AWS Lambda 함수 트리거 – 이제 소프트웨어 출시 파이프 라인 단계에서 람다 함수 트리거 할 수 있습니다. AWS Lambda는 거의 모든 작업을 수행하는 함수를 작성할 수 있으므로 파이프 라인이 작동하는 방식을 사용자 정의 할 수 있습니다.

수동 승인 조치 – 소프트웨어 출시 파이프 라인에 수동 승인 조치를 추가 할 수 있습니다 . 코드 변경이 필요한 IAM 권한을 가진 사람에 의해 승인되거나 거부 될 때까지 실행이 일시 중지됩니다.

커밋 코드 정보 보기 – 소프트웨어 출시 파이프라인에 소스 코드에 대한 최신 정보를 보실 수 있습니다.

CloudFormation 스택 워크플로 조합 기능 –  CodePipeline의 워크 플로는 여러 가지 방법으로 스택을 만들고 조작 할 수 있습니다.  이제 CloudFormation 스택에 대한 지속적인 배포 파이프 라인을 작성할 수 있습니다.

더 자세한 정보
AWS Codepipeline에 대한 상세한 정보는 아래 온라인 세미나 영상 및 자료를 참고하시기 바랍니다.

Channy(윤석찬);

AWS CodePipeline 정식 출시

지난해 가을 AWS re:Invent에서 AWS CodePipeline를 발표했습니다 (Code Management and Deployment라는 글에 자세한 내용이 있습니다). 이 도구는 여러분의 소프트웨어 출시 프로세스를 모델링하고 자동화하는 것을 도와드립니다. CodePipeline에서는 자동화 및 출시 프로세스를 보다 안정적이고 효율적으로 디자인 되어 있습니다.

정식 출시
AWS CodePipeline을 오늘부터 사용하실 수 있습니다.

자세한 이야기​​에 들어가기 전에 이 제품의 배경에 대해 공유하고 싶습니다.

아마존 내부 이야기: Pipelines
AWS CodeDeploy가 Apollo로 알려진 Amazon 내부 도구에서 영감을 받은 것처럼(The Story of Apollo – Amazon’s Deployment Engine) CodePipeline도 Amazon의 내부 도구를 기반하고 있습니다.

아마존 내부에서는 일단 코드가 체크인 된 후, 프로덕션 환경에 배포 될 때까지 시간을 측정 한 후 지속적인 배포 서비스를 개발했습니다. 그 시간은 엄청 길고 개발 팀이 만든 기능이 고객이 직접 사용할 때까지 가능한 빠르게 하기 위해 도전적인 문제였습니다.

좀 더 깊이 조사해 보니, 대부분 시간이 실제 빌드와 테스트 및 배포 시간에 사용되지 않는다는 것을 알 수 있었습니다. 대신 수동으로 티켓을 만들고, 팀 간의 연계를 할 때 시간이 많이 걸린다는 알 수 있었습니다. 즉, 대기열에 티켓이 들어가면 누군가가 그것을 주의 깊게 보지 못하고, 빌드 및 테스트 결과를 검토 할 때까지 방치되어 있어서 이러한 프로세스를 진행하려면 사람에게 매뉴얼로 통보 해야했습니다.

Amazon 내부에서는 물류 센터에서 조차 자동화에 집중하고 로봇을 이용하여 상품의 물류 속도를 높히고 있는데, 우리가 소프트웨어 배포 프로세스에서 무형의 컴퓨터 프로그램을 이동하기 위하여 수작업으로 사람이 움직이는 프로세스에 의존하고 있다는 점은 심각한 것이었습니다.

그래서, 속도를 높이기 위해 우리는 Pipelines라고 부르는 내부 시스템을 개발했습니다. 이 시스템을 통해 각 팀은 출시 프로세스의 모든 부분을 연결할 수 있게 되었습니다. 여기에는 소스 코드 관리, 빌드 및 배포 및 실 적용 직전의 환경에서 테스트하고 배치하는 모든 과정이 포함되었습니다. 물론 이 도구는 코드 변경으로 부터 프로덕션 환경에 도달 할 때까지 시간을 획기적으로 절감했습니다.

더 빠르게 배포하는 것이 이 프로젝트의 주된 목적 이었지만, 그 외에도 여러 가지 장점이 있다는 것을 목격했습니다. 모든 코드 변경이 같은 품질의 프로세스를 통과함으로써 각 팀은 보다 신속하게 문제를 파악할 수 있는 질 높은 자료를 만들 수 있어 결과적으로 나쁜 코드가 실전에 배치되었을 경우, 롤백 해야하는 횟수를 줄일 수 있었습니다.

지금은 Pipelines을 Amazon 곳곳에서 사용되고 있습니다. 각 팀은 대시 보드로 이용하고 그들의 소프트웨어 출시 모니터링 및 관리에 사용되고 있습니다.

오늘의 CodePipeline를 통해 여러분도 우리의 개발자와 같은 기능을 사용하실 수 있게 되었습니다.

CodePipeline의 모든 것
CodePipeline은 소프트웨어의 지속적인 배포(continuous delivery) 서비스입니다. 여러분의 소프트웨어를 출시하는 데 필요한 단계를 모델링하고 시각화 및 자동화 할 수 있습니다. 코드가 체크인에서 빌드 테스트 및 배포 될 때까지 모든 단계를 정의하고 맞춤형으로 사용자가 정의 할 수 있습니다.

여러분의 조직은 다른 조직과 마찬가지로 빌드 프로세스의 일부로 다양한(오픈 소스 및 기타) 도구를 이용하고 있으실 것입니다. 내부 연계를 통해 우리의 파트너에서 제공하는 것 이외에 이러한 고도로 자동화된 워크 플로우 중심의 프로세스에 기존 도구도 통합 할 수 있습니다. 자신의 소스 관리 및 빌드, 테스트 및 배포 도구와 CodePipeline는 사용자 정의 액션 API를 통해 연결하는 수도 있습니다.

출시 프로세스를 자동화하여 보다 빠르고 일관성 있는 업무를 할 수 있습니다. 그 결과 작은 기능 및 코드 변화를 자주 프로덕션 환경에 적응할 수 있을 것입니다. CodePipeline 대시 보드를 사용하여 출시 파이프 라인의 흐름을 확인 하고 변화를 시각화하여 관리할 수 ​​있게 될 것입니다.

빠르게 사용해 보기
이제 CodePipeline을 한번 살펴 보겠습니다. 버전이 있는 S3 버킷 및 샘플 애플리케이션을 출시하기 위해 AWS CodeDeploy를 사용한 간단한 두 단계의 파이프 라인을 만들겠습니다.

먼저 새 버킷 (jbarr-code)를 만들고 버전 관리를 사용합니다:

코드를 배포하는 장소가 필요하기 때문에 CodeDeploy 콘솔을 열고 샘플 배포를 이용합니다. 이에 따라 세 개의 EC2 인스턴스와 하나의 Deployment Group을 시작합니다:

그 다음 CodePipeline 콘솔을 열고 Deployment Walkthrough Wizard를 사용하여 배포 리소스를 만듭니다. 이 Pipeline을 DeployMyCode라고 부르겠습니다:

여기에서 CodePipeline 코드를 어디에서 찾을 것인지 알려줍니다. Source Provider에서 S3 버킷 및 객체 이름(이 객체는 배포하고자하는 코드를 포함)을 참조하십시오:

Source Provider로서 GitHub의 저장소를 대신 사용할 수 있습니다.

다음 단계에서는 Build Provider를 지정하여 코드를 어떻게 작성할지 알려줍니다. 이번 코드는 스크립트이기 때문에 그대로 실행 가능하며, 빌드를 할 필요가 없습니다.

Build Provider로서 Jenkins를 사용할 수 있습니다.

(파이프 라인을 실행 할때) 코드를 빌드하지 않기 때문에 다음 단계는 배포 전에 테스트를 하는 것입니다. 조금 전에 설치한 CodeDeploy 설정(대상 EC2 인스턴스를 포함)을 사용합니다:

CodePipeline에 자신의 계정의 AWS 리소스를 사용 권한을주고, IAM 역할을 생성합니다:

이 단계가 끝나면 선택 사항을 확인하고 파이프라인을 만들 수 있습니다 :

파이프라인이 곧 실행 됩니다:

특정 단계의 설정에 대해 자세히 볼 때, “i”에 커서를 올려 정보를 보실 수 있습니다 :

코드를 수정하고 새 버전을 S3에 업로드하면 CodePipeline는 그 변화를 감지하고 자동으로 파이프 라인을 실행합니다. Release change 버튼을 클릭해도 됩니다.

각 단계 사이에 파이프 라인을 중단할 필요가 있는 경우 클릭 하셔도 됩니다.

나중에 클릭하면 다시 활성화 할 수 있습니다!

파이프 라인의 편집도 가능합니다. 기존 단계를 변경하거나 새로운 단계를 마지막으로 추가하거나 파이프 라인 중간에 삽입 할 수 있습니다:

예를 들어, 테스트 단계를 추가 할 수 있으며 (만약 테스트가 성공하면) 프로덕션 환경에 배포합니다. 만약 테스트 단계를 더하려면 Test Provider를 선택 연결 해야합니다.

연결 단계에서는 Provider의 Web 사이트가 사용됩니다:

지금까지 설명한 모든 기능들은 AWS Command Line Interface (CLI)을 통해서도 가능합니다.

CodePipeline 통합
앞서 언급 한 바와 같이 CodePipeline은 기존 소스 관리 및 빌드, 테스트, 배포 도구를 사용할 수 있습니다. 아래는 제가 알고 있는 것인데, 추가되면 업데이트 해드리겠습니다.

소스 콘트롤

빌드 및 지속적 통합

  • Jenkins – 클라우드와 온-프레미스에서 호스팅되는 Jenkins 서버에서 빌드 실행
  • CloudBees – CloudBees의 Jenkins 플랫폼에서 빌드 및 테스트 CI를 실행

테스트

  • Apica – Apica 부하 테스트 서비스에서 높은 부하 테스팅
  • BlazeMeter – BlazeMeter 부하 테스트 서비스에서 높은 부하 테스팅
  • Ghost Inspector – Ghost Inspector의 서비스에서 UI 자동화 테스트 실행
  • Runscope -Runscope 서비스에서 API 테스트 실행

배포

지금 사용 가능합니다!
CodePipeline 지금부터 사용할 수 있으며 오늘부터 US East (Northern Virginia) 리전에서 사용가능합니다. 또한 다른 리전으로의 확장도 지속해 나갈 예정입니다.

요금 정책은 사용 중인 파이프 라인 당 매월 $1가 부과됩니다 (첫 하나는 AWS Free Tier에서 사용 가능합니다.) 사용 중인 파이프 라인이라는 것은 1개월 사이에 적어도 한 번의 코드 변경이 있었던 것을 의미합니다.

Jeff;

이 글은 Now Available – AWS CodePipeline의 한국어 번역입니다.