01 S3 버킷, 역할 분리의 이유 source 버킷은 파이프라인 입력 artifact의 위치이고 production 버킷은 사용자가 접속하는 배포 결과 위치라는 역할 분리를 이해한다. KT AIVLE School
CI/CD Practice
S3, CodePipeline, GitHub source, CodeBuild, CodeDeploy로 이어지는 배포 파이프라인 실습 산문
- 원고
- 10
- 8월 25일-9월 24일
- 0편
01 S3 버킷, 역할 분리의 이유 source 버킷은 파이프라인 입력 artifact의 위치이고 production 버킷은 사용자가 접속하는 배포 결과 위치라는 역할 분리를 이해한다. 
02 CodePipeline 파일 흐름 해부: Source S3에서 Production S3까지 CodePipeline은 source 변경을 artifact로 잡아 deploy 단계에 넘기고, deploy는 production S3에 압축을 풀어 웹 사이트 결과를 만든다는 흐름을 이해한다. 
03 CodePipeline, GitHub 저장소 소스로 연결하기: 흐릿한 관계를 명확하게 GitHub 연결은 pipeline이 저장소 변경을 감지할 수 있는 인증 통로이고, git push는 source artifact를 새 버전으로 만드는 시작점임을 이해한다. 
04 하나의 변경으로 보는 CI/CD 흐름 하나의 commit이 원격 저장소, pipeline source event, production 결과, 로컬 작업 폴더에 순서대로 반영되는 흐름을 이해한다. 
05 buildspec.yml: CodeBuild 빌드 계약 해부하기 buildspec.yml은 빌드 환경에서 실행할 명령과 최종 artifact 위치를 정하는 계약서이며, CodeBuild는 source artifact를 실행 가능한 배포 artifact로 바꾸는 단계임을 이해한다. 
06 Build 단계가 아티팩트 흐름을 바꾸는 이유 Build 단계가 들어오면 source artifact와 build artifact가 분리되고, deploy 단계는 빌드 결과물을 기준으로 실행된다는 흐름을 이해한다. 
07 CodeDeploy 배포, 그 '보이지 않는 착륙장'의 비밀 CodeDeploy가 EC2에 배포하려면 서비스 권한, 대상 인스턴스 권한, 인스턴스 안의 agent, 웹 서버 실행 환경이 모두 맞아야 함을 이해한다. 
08 CodeDeploy: 배포 대상을 고르는 진짜 주체는 누구? Application은 배포 단위의 이름이고 Deployment Group은 서비스 역할과 태그 조건으로 실제 EC2 대상 집합을 고르는 규칙임을 이해한다. 
09 appspec.yml: EC2 배포 동작의 청사진 appspec.yml은 build artifact 안의 파일을 EC2의 목적지로 옮기고 lifecycle hook에서 실행할 스크립트를 지정하는 배포 계약임을 이해한다. 
10 최종 CI/CD 흐름에서 Source, Build, Deploy, 검증을 한 줄로 읽는 법 최종 pipeline은 source revision, build artifact, appspec 기반 EC2 배포, browser verification을 이어 보는 운영 흐름임을 이해한다.