CodePipeline에서 만드는 변경 관리 파이프라인

이 기사는 "Opt Technologies Advent Calendar 2017"2일째입니다.

소개

안녕하세요, mshibuya입니다.
이번에는 이전보다 따뜻했던 「변경 관리 파이프라인」의 도입을 향해, AWS CodePipeline/CodeBuild를 접할 기회가 있었으므로 내용을 소개하고 싶습니다.

변경 관리 파이프라인이란?

오라일리 사에서 나오는 「 Infrastructure as Code 」 12장에 나오는 개념으로, 혼란스럽게 말하면 인프라 코드의 배포 파이프라인입니다.

소스 코드 리포지토리에 커밋 된 인프라 코드 변경에 대해 흐르도록

자동화된 테스트

자동화된 배포

변경 사항 확인 및 승인

등을 조합해, 동작 환경에의 반영까지를 실시하는 플로우를 만드는 것으로, 프로덕션 환경에의 변경의 반영을 원활하게 실시할 수 있는 구조가 됩니다.

이것을 활용함으로써,

변경 배달 절약

수작업으로 인프라 변경 방지

배포 작업 균질화 (수작업으로 인한 실수 방지)

추적 성 향상

등 다양한 장점을 즐길 수 있습니다. 좋습니다.

시도한 내용

여기에서는 실현 가능성의 검증이라고 하는 것으로, 다음과 같은 파이프라인을 작성했습니다.

GitHub 저장소의 변경 사항 감지

CodeBuild로 CloudFormation Template JSON 생성

얻은 Template JSON으로 CloudFormation Stack 업데이트

농담

CodePipeline에서 CloudFormation 스택 업데이트를 시도하는 동안 다음과 같은 오류가 발생했습니다.

Template exceeds maximum length of 51200 bytes

CloudFormation에서는 통상 템플릿의 상한 사이즈가 51,200bytes로 되어 있어, S3에 템플릿을 한 번 업로드해 건네주는 것으로 그 제약을 회피해 460,800bytes까지의 사이즈를 취급할 수 있습니다만, CodePipeline에서는 S3에 업로드 해 의 전달 방법을 할 수 없다는 것.
htps : // ふふる ms. 아 ws. 아마존. 이 m/th레아 d. js 파? 엄청난 D = 785905 & ts rt = 0

이것 보통으로 곤란하네요… 어떻게든 해 주었으면 합니다. 위 스레드에서 제안 된 해결 방법은 "CodeBuild에서 S3에 업로드하여 CloudFormation 적용"같은 느낌으로 ... 음, 확실히 그것으로 움직일 것입니다. . .

미래

상당히 이미지하고 있던 대로 일을 할 수 있는 전망은 서 있었으므로, 다음은 실제로 스테이징 환경에서의 운용을 시작하고 싶다-라고 생각하고 있습니다.
진전이 있으면 다시 보고 싶습니다!