<366강 AWS의 CI CD>
> 지금까지 배운 기본적인 AWS 자원 활용, AWS CLI 활용, EBStalk 활용한 배포 등..
> 수동적으로 작업하다보면 실수할 가능성이 높음
> Target Repository 에 코드를 보관 및 AWS에 배포되게 해보자
>> 자동으로, 배포전 test 완료, 다른 환경 (dev/test/prod) 으로 넘어가는 것도 생각
> 지금까지 배운 모든 배포들을 자동화 하는 것 + 안전성을 증가시키는 과정
> 이번에 배울 내용
>> CodeCommit - 코드 보관
>> CodePipeline - 보관한 코드를 EBStalk 과 파이프라인으로 연결 (EBS 와의 CD)
>> CodeBuild - CI 단계, 코드를 Build 및 Test 를 수행
>> CodeDeploy - EBStalk 이 아닌 자원 (EC2 따위) 에 코드를 배포하는 것
>> CodeStar - 개발 관련 활동 관리
>> CodeArtifact - SW 패키지를 store / publish / share 하는 곳
>> CodeGuru - 머닌 러싱을 활용한 Automated Code Review
<CI>
> CI 란 지속 통합으로, 중앙 코드 Repo (ex: GitHub, CodeCommit, Bitbucket 등) 에 코드를 지속적으로 push 하는 것
> 푸시되는 즉시 testing / build 서버가 즉시 code 를 test / build 하며 문제가 없는지 확인한다 (ex : CodeBuild, Jenkins CI, Github Action 등)
> 테스트 결과를 받게 됨 (시간이 매우 절약, 코드를 테스트 해서 버그를 조기에 발견)
> 더 자주 테스트가 되며, 더 자주 Deploy 하게 된다
<CD>
> Code Repo 에 코드가 푸시될 때마다 적절한 테스트만 거친다면 지속 배포되게 함
> CI 부분에 해당하는 영역이 돈다 (이 부분은 따로 하는지 과정인지는 맞고 틀림이 없다고 배움)
> CI 혹은 빌드의 결과가 성공시 배포 서버로 넘어가게 되고, 앱 서버에 배포함 (V1 -> V2)
> 배포가 더 자주, 신속하게 진행되어 에러나 피드백에 대한 반영이 빠르게 이루어질 수 있음
> 자동화된 배포 도구 필요 (ex: CodeDeploy, Jenkins, Spinnaker 등)
<CI/CD 의 기술 Stack>
> Code repository 가 있고, 그 이후 Build / Test Phase 가 있다
> 그 이후 Deploy 단계로 넘어가고, EC2, 온프레미스, 람다 혹은 ECS로 배포가 진행된다
> 인프라를 프로비저닝 하는 경우 CodeDeploy 대신 EBStalk 를 사용해서 배포 & 인프라 프로비저닝할 수 있음
> 이 모든걸 CodePipeline 을 사용하여 CI CD 처리를 정의하고 관리할 수 있다 (뼈대가 됨)
----------------------------
<367 CodeCommit 개요>
> Version Control : 시간에 따른 Code 의 변화를 인지, 필요시 Rollback 을 위한 기능
> Git 이라는 Version Control System 으로 대부분이 사용된다
> Git 은 로컬에서 사용되기도 하지만 온라인에 central repo 로 많이 사용됨
>> 개발자들과 협업 가능, 코드가 클라우드에 백업, Viewable & Auditable - 누가 커밋했는지, 롤백 가능 등
<CodeCommit 소개>
> CodeCommit 을 사용해 개발자들이 push/pull code 가 가능하다
> CodeCommit 이 Git 대비 가지는 이점 (사실상.. 없는 듯? 그래서 올해부로 종료될 예정이라고 함)
>> Github, Gitlab, Bitbucket 등이 사용하는 Git Repo 는 비싸다(?)
>> AWS 클라우드 개인 VPC 내에 코드가 있음 - 개인 Git 이 생김 (보안 강화)
>> Repo 에 크기 제한이 없음
>> 다른 CI Tool 들과 연동성이 좋음
<CodeCommit 이 지원한는 Security>
> 표준 Git 으로 기본적으로 동작하지만 인증이 필요함
> Authentication (인증)
>> SSH 키 - AWS 유저로서 SSH 키를 콘솔에서 Configure 해서 사용한다
>> HTTPS - 표준 로그인 방식으로 PW 사용해서 액세스 가능
> Authorization
>> IAM Policy - 특정 Repo 에 대해 User / Role 의 접근을 제어
> Encryption
>> Repo 내에 코드들은 AWS KMS 를 통해 자동으로 암호화됨
>> Code Commit 등 transit level 에서는 HTTPS / SSH 로 Encrypt 된다
> Cross-Account Access
>> 당연히 SSH 키나 AWS Credential 는 공유하지 않는다
>> 너의 AWS 계정에 IAM Role 을 사용. AWS STS (AssumeRole API) 를 사용하여 타 계정에서 CodeCommit Repo 에 액세스 하도록 한다
> 둘다 PR 및 코드 리뷰 지원, CodeBuild 와의 통합 지원, 인증 지원
> 보안은 Github 내부 보안이며, CodeCommit 은 AWS와 잘 통합된 IAM User & Role 을 사용
----------------------------
<368 CodeCommit 실습 1>
> CodeCommit 로 이동, repo 생성 후 aws-cicd 폴더 내에 node.js-v2-blue 의 index.html 을 업로드 한다
> author, email, commit msg 기입하여 업로드가 됨
> main branch 와 같이 branch 와 commit id 까지 다 확인된다 (Git 을 활용하기 때문)
> Pull Request
>> 타 브랜치로 병합하기 위함. 타 브랜치의 변경을 현 브랜치에 반영하기 위함
> Commit
>> 커밋 목록들을 확인할 수 있고, visualizer 로 보기 쉽게 확인, Compare 로 커밋간 비교가 가능
> Setting
>> Repo 에 대한 ID, ARN 을 확인할 수 있다
>> Repo 에 대한 Notification 규칙 생성 가능
>>> Notification 내용안에 포함하고 싶은 내용이 Full / Basic 선택 가능
>>> 알람 Trigger 로 발생 상황을 선택할 수 있다 ( Commit, PR, Branch 변경 등등 )
>> Repo 에 대한 Trigger 생성 가능 (알람을 좀 더 제한적이게?)
>>> Trigger 는 more specific actual code events 이다 (ex: 모든 event, Push to branch, Create/Delete branch or tag 등)
>>> Notification 과 유사하게 SNS 연동도 가능하고, Lambda 연동도 가능하다
----------------------------
<369 CodeCommit 실습 2>
> UI 를 사용하지 않고 commit 을 사용하는 방법에 대해 배운다
> IAM 으로 돌아가서 User/Security Credential 이동하면 [SSH Key for CodeCommit] 과 [HTTP Git Credentials for AWS CodeCommit] 을 볼 수 있음
> 두 방법을 사용해서 CC 에게 인증을 받을 수 있다는 점을 명심 (이게 시험을 위해 젤 중요)
>> 1안은 Git 을 잘 쓰는 경우, SSH 키를 발급 받아 업로드 후 Repo 에서 확인할 수 있는 SSH 경로를 사용하라고 하는데 정확히 무슨 뜻인지 잘 모르겠음
>> 2안은 초보를 위한 것으로, 사용자 이름/비밀번호 사용해서 AWS CodeCommit 에 HTTPS 로 로그인을 하는 방식이다 (내가 아는 방식?)
>>> 2안을 실습하는데, Generate 만 하면 알아서 생성해줌
> Git 활용 (평소 쓰던 Git 을 쓰는 부분이였음)
>> Repo 에서 Clone HTTPS 선택, origin 주소를 받음
>> git clone ${URL} 을 통해 동기화를 하는데, 이 때 ID/PW 를 위에서 HTTPS Credential 에서 생성한 ID/PW 를 사용하면 됨
>> CodeCommit 도 git 을 사용하므로, git init 이 되어 있고 main 브랜치에 있는걸 알 수 있음
>> 또한, nodejs-v2-blue 에 있는 모든 파일들을 지금 연동된 경로로 붙여넣는다
>> git add . 를 통해 전체 파일 추가, commit 을 통해 커밋을 실행
>> git push 할 준비가 되어서, 진행하면 CodeCommit 에 푸시가 됨
----------------------------
<370 CodePipeline>
> AWS 내부에서 CI/CD 를 오케스트레이션 해줄 수 있는 툴, 다음과 같은 Phase 들을 가질 수 있다
> Source 를 명시할 수 있다 - Code 가 GitHub/CodeCommit/S3 에 있다, Image 가 ECR에 있다 등
> Build 를 명시할 수 있다 - CodeBuild/Jenkins/CloudBees/TeamCity 등과 연계할 수 있다
> Test 를 가질 수 있다 - IOS/AOS 앱은 DeviceFarm , 다른 테스트 툴 연계가능
> Deploy 를 지정할 수 있다 - CodeDeploy/EBStalk/CF/ECS/S3 등등에 배포를 연계할 수 있다
> Invoke 를 지정할 수 있다 - Lambda 혹은 Step Function 호출 가능
> Stage 랑 Phase 랑 같은 말로 인식하는게 편한다 (아래 좀 더 세부적으로 정리함)
> Stage 는 연속적/병렬적인 Action Group 들로 구성할 수 있다
> Stage 를 기준으로 수동 Approval 을 적용할 수 있다 (타인이 확인시 다음 단계 진행)
> Phase, Stage, Action Group 에 대해 구분해볼 필요가 있다
- Phase 는 크게 구분되는 틀 같은 것 (Source, Build, Test 단계 등) - 대표 ActionGroup 느낌
- Action Group 은 Stage 를 구성하는 단위들로, Stage 내에서 실행되는 단위
- Stage 는 Action Group 들이 실행되는 단계를 말함
<Artifacts>
> Artifact 란 Pipeline 과정 중 생성된 모든 것들을 말하며, 각 파이프라인 Stage 는 Artifact 를 생성할 수 있다
> Artifact 는 S3 버킷에 저장되어 다음 Stage 로 전달된다 (Pipeline 구성시 auto 생김, SourceArti/ 라는 경로 생성)
> Source / Build / Deploy Phase 가 있다고 함 (CodePipeline 으로 전체적인 오케스트레이션)
> CodeCommit 이 Push 를 받으면 코드를 추출하여 Artifact 를 만들고 S3에 넣는다
> CodeBuild 가 호출되면 (by Pipepline) 위에서 만들어진 Artifact 가 CodeBuild 로 주입된다
>> 따라서 CodeBuild 가 직접 CodeCommit 에 접근할 필요가 없음 (중요)
>> CodePipeline 이 S3에 접근해 그 Artifact 를 CodeBuild 에 주입하게 됨
> CodeBuild 는 일을 하고, 빌드 결과물 아티팩트를 역시 S3 버킷에 넣음 (by pipeline)
> 똑같이 이를 역시 CodeDeploy 에 주입한다 (by Pipeline)
>> 위와 같이 CodePipeline 은 아티팩트를 S3와 상호작용 시키면서 Stage 를 진행시킨다
<Troubleshooting>
> Pipeline / Action / Stage Execution State Changes 등을 확인해야 하므로, cw log, EventBridge, CloudTrail 를 활용할 수 있다
>> EventBridge 를 활용해 Failed Pipeline / Cancelled Stage 등에 대해 email 을 받을 수 있다
>> AWS CloudTrail 로 발생하는 API 호출에 대한 감시 가능
> Pipeline 에서 stage fail 이 발생하면, 콘솔에서 쉽게 확인 가능
> 만약 Pipeline 이 CodeBuild / CodeCommit 과 어떤 상호작용이 안되는 것 같다면, Code Pipeline 의 [IAM Service Role] 을 호가인해 적절한 IAM 권한을 가지고 있는지 확인 (ㅅㅂ 이름이 다 다른 것 같음, 람다에서 execution role 이였던거 아님?)
----------------------------
<371 CodePipeline 실습 준비>
> 이번 실습에서 사용할 EBStalk 를 만든다.
> EBStalk 환경을 만들어서 CodePipeline 을 활용해 업데이트들을 이 환경에 배포할 것임
> 환경을 일반 / Prod 이름으로 두개를 만든다. 완료시에는 꼭 삭제하기
----------------------------
<372 CodePipeline 실습>
> ServiceRole 생성 : 이 Pipeline 은 하는 일이 많을 것 - S3, CodeCommit, EBstalk 와의 통신을 함 (내가 구성한 것에 따라서 위와 같은 Role 과 Policy 를 생성하여 넣어준다)
>> CodePipeline 은 당연히 IAM Role 이 연결되어야 한다는 점을 인지!
> Source 제공자 선택 : 최초 코드의 제공자 (Commit 사용할 것임) 와 브랜치 선택
> Change Detection 은 CW Event 를 권장, 모든걸 자동으로 만들어줌
> CodeBuild 는 잠깐 Skip
> Deploy Stage 에서는 EBStalk 를 선택한다 (EBStalk 으로 배포를 진행)
>> 그럼 각 Stage 들을 구성한 Pipeline 이 완성되고, 이를 생성할 수 있다
>> 구성되자마자 작업을 시작할 것이다
>> Source 가 바로 Run 해서 CodeCommit 을 확인함
>> 기존 EBStalk 에 초기 배포된건 초록색인데, 이 Pipeline 이 끝나면 파란색으로 변경되는 것을 확인할 수 있다
>> EBStalk 로 들어가보면 실행중인 버전이 code-pipeline 으로 생성된 버전임을 알 수 있다
> 이번엔 Pipeline 확장을 해볼 것이다
> Add Stage 를 하고 Add Action Group 을 한다
>> Action Name : Manual Approval
>> Provider 는 Manual Approval 이다 이렇게 하고 완료를 하면 됨
> (중요한 사실) Stage 는 여러 ActionGroup 으로 구성될 수 있다 (1:N 관계)
>> UI 적으로 볼 수 있지만, Sequential Action 을 지정 할 수 있고, Parallel Action 으로 지정할 수도 있다
> 다음 ActionGroup 은 EBStalk 가 될 것이고, SourceArtifact 를 받아오며 prod 환경에 배포를 한다고 정의
>> Node.js 의 배포를 자동으로 해주는건 EBStalk 에서 Node.js 배포용 환경 및 init 시 실행 명령어를 만들어줬기 때문임. 그게 아니면 다 직접 구성해줘야 함
> 이 새로운 Pipeline 은 어떻게 실행하는가?
>> Pipeline 을 trigger 하는건 CodeCommit 으로 해놨었음 (Event Bridge). 따라서 Code 의 색을 red 로 바꿔서 올려보자. 그럼 Pipeline 이 트리거 된다
>> 제대로 trigger 가 되었고, 수동 승인에서 직접 승인하도록 대기하고 있는 것까지 확인할 수 있다. 승인시 배포된게 빨간색으로 변경된다 (승인은 콘솔에서 할 수 있다)
>> 가는 도중 dev 환경에서는 자동으로 배포되는 것까지 볼 수 있다
> Pipeline History 에 들어가면 Pipeline Execution 이 한 객체로 저장되어서 내역을 볼 수 있다
> Action 별 로깅 데이터들을 확인할 수 있다 (시작, 완료 시간, Aciton Provider 등)
> AWS 리소스만 쓴다면 진짜 ㅈㄴ 편하긴 한듯..
----------------------------
<373 CodeBuild>
> Source 지정 - CodeCommit, S3, Bitbucket, Github 등으로 부터 받아올 수 있다
> Source 안에 Build instruction 을 지정할 수 있는데, 그게 buildspec.yml 이다. (github action 시 source 안에 action 디렉토리에 파일 추가하는거랑 똑같)
> 앱 빌드 후 output log 들은 추후 분석을 위해 S3 에 저장 혹은 CW Log 를 사용할 수 있다
> CW Metric 으로 빌드 모니터링 가능, EventBridge 로 Build Fail 에 대한 알림 연계 가능
> CW Alarm 으로 지속적인 Fail 시 알람 가능
> Build 에 대한 정의는 CodeBuild 로 될 수도 있지만, CodePipeline 내에서 정의될 수도 있다
>> CodePipeline 에서 이미 정의된 CodeBuild 를 사용할 수도 있다
> CodeBuild 자체와, CodePipeline 과의 연계를 독립적으로 인지할 수 있어야 함 (S3 에 올리고 jenkins 에서 이를 가져가게 할 수도 있는거임 ㅇㅇ)
<지원되는 환경>
> Java, Ruby, Python, Go, Node.js, Android, .Net Core, PHP 를 사용한다면 Test 를 위한 Image 가 제공되며, Docker 로 원하는 환경을 customize 가능하다
<동작 원리>
> CodeBuild 를 사용하려면 app package 최상단에 buildspec.yml 이 있어야 함
> CB 는 이 코드 가져오고, 환경에 맞춰 Build Container 를 준비한다
>> 이 Build Container 는 Docker Image 를 사용하는데, 위에서 말했듯이 미리 지원되는 이미지거나, 스스로 올려둔 custom 이미지일 수도 있음
> 이후 소스 코드를 모두 컨테이너에서 로딩하고 buildspec.yml 에 명시된 지침대로 실행을 하게 된다
> 이 때, buildspec 과정이 제법 길 수도 있어서, 빌드 과정에 있어서 파일들을 재사용하기 위해 S3 Bucket 을 사용하여 캐시할 수도 있다 (선택)
> Log 는 아까 말했듯이 S3 / Log 에 저장시킬 수 있고, Artifact 는 S3 에 저장된다
<buildspec.yml>
> buildspec.yml 이 매우 중요하다 (root 디렉토리에 있어야 함)
> env : 사용할 변수 정의
>> variables - 단순 변수 하드코딩 정의
>> parameter-store - SSM Param Store 에 정의된 변수 가져옴
>> secrets-manager - AWS Secrets Manager 로 관리되는 보안이 중요한 변수 가져옴
> phase : CodeBuild 가 실제로 수행할 일들
>> install - build 를 수행하기에 앞서 필요한 것들을 준비
>> pre_build - build 직전에 필요한 명령어 기입 (필요시)
>> build - 실제 “build command" (매우 중요)
>> post_build - 빌드 수행 후 이행할 명령어 기입 (ex: zip 파일 형성)
> artifacts : 어떤 파일들을 S3 에 보낼지 명시
> cache : 패키지 내 어떤 경로들에 있는 파일들을 잠시 S3에 저장하여 속도를 높일지 지정 (ex - root/.m2/** : 해당 경로 안에 있는 모든 것들은 Pipeline 전체적으로 동일하니까 재사용을 위해 저장한다)
----------------------------
<374,375 CodeBuild 실습>
> 우선 Pipeline 내부에서 CB 를 사용해서 Test 를 돌리는 것 부터 해보자
> 아주 초간단 예제로, “Congratulation” 이라는 Text 가 있는지 테스트 한다고 하자
> CB 로 이동 해서 생성한다 (CC 로부터 가져올 것이고, 커밋 ID 없으면 최신 커밋으로 함)
> 사용할 이미지 지정 가능 (Managed > Ubuntu > aws/codebuild 용 이미지)
> 새 서비스 역할 (Service Role) 생성 - 아마 S3 같은거 접근해야 하니까
> 추가 구성에서 여러가지 설정 가능
>> ex : 빌드 제한시간, VPC, 환경 변수 등
> Artifact 지정 가능
>> S3 로 보낸다 등을 지정 가능. 현재 Test 만 볼 것이므로 No Artifact
> CW Log 활성화 가능
> Build 를 수행해본다
>> Fail 발생 : 전체 로그 확인 가능 (현재 yml 파일 없음 에러) - 내 CodeCommit 에 buildspec 을 넣어주지 않았기 때문
>> buildspec.yml 을 다음과 같이 추가해준다
version: 0.2
phases:
install:
runtime-versions:
nodejs: latest
commands:
- echo "installing something"
pre_build:
commands:
- echo "we are in the pre build phase"
build:
commands:
- echo "we are in the build block"
- echo "we will run some tests"
- grep -Fq "Congratulations" index.html
post_build:
commands:
- echo "we are in the post build phase"
> 소스코드는 위에 이론 설명한거대로 읽으면서 해석해보면 됨
>> 중간에 grep -Fq "Congratulations" 를 보면 [index.html] 안에서 “Congrats" 텍스트가 있는지 찾아본다는 뜻
>> 즉 없으면 Fail 을 발생시키는 명령어임 (없으면 exit 1 을 발생시킴)
>> 즉, 이런식으로 build 과정 안에 테스트가 build 안에 포함되어 있는 것임 (gradle 처럼)
>> 내가 원하는대로 build 내부를 구성할 수 있다
> 빌드를 다시 기동해보면, 실패 없이 진행된다 (위에 사진이 성공한 사진)
> 단계 세부 정보를 보면, 빌드가 진행된 단계와 걸린 시간에 대한 기록을 확인할 수 있다
> CW Log 에서 전체 로그를 확인할 수 있다
>> 아까 buildspec 에서 명시했던 echo 들도 phase 별로 다 확인할 수 있다
> 이번엔 source / deploy Stage 사이에 BuildAndStage Stage 를 넣어볼 것이다 (CI)
> Source 를 CodeBuild 로 하여 우리가 작업한걸 지정한 후 저장
> 다시 한번 CodeCommit 으로 가서 Congrats text 를 fucking 으로 바꾼다
>> 테스트 실패하는 것을 야기 (위에서 CodeBuild 내에서 "Congratulation" 단어를 못찾으면 Fail 하는 간단한 Test 가 돌기 때문)
> 다시 돌자마자 BuildAndTest Phase 에서 Fail 이 발생하는 것을 볼 수 있음
> 다시 Congrats 혹은 포함된 단어로 바꾸면 정상적으로 기동한다
> 내가 직접 Jenkins로 PL을 설계했어서 그런지, 이렇게 다 자동으로 해주는게 좀 어색하다. AWS 이미지 안에서 npm install, npm build 이런걸 해줬으면 빌드까지 한 결과물을 연결해줘야 했을 것이다. 내가 보기엔 현재 그걸 EBStalk 에서 해주니까 그걸 스킵한 것으로 보임
> 그래도 ㅈㄴ 편리한건 진짜 확실하게 알겠다
----------------------------
<376 CodeDeploy>
> 앱 배포를 자동화 해주는 리소스다
>> 사실 근데 Pipeline 으로 뭔가 다 될 것 같은데.. CB 나 CD 나 다 Pipeline 과 독립적으로 구분할 수 있는게 좋을듯
> 배포를 EC2 인스턴스, On-Premise, Lambda, ECS 등에 배포할 수 있다
>> Code Deploy 는 앱을 업데이트 뿐만 아니라 롤백도 지원한다 (배포물이 예상과 다르게 동작하면 자동 롤백을 실시할 수 있다)
> 배포되는 방식도 설정 가능( 롤링 업데이트 하냐, 한번에 하냐 ㅇㅈㄹ)
> appspec.yml 파일을 활용해 배포 방식을 정의한다
<CD on EC2/On-Premise>
> In-Place Deployment 혹은 Blue/Green Deployment 를 사용 가능 (새 환경을 구성하냐 아니냐의 차이로 느껴짐)
> 대상 노드에 CodeDeploy Agent 를 실행시켜야 한다 (마치 JNLP 처럼) - 인스턴스에서 업데이트를 수행함
> Deployment 속도 조절 가능 (속도와 다운타임이 반비례 관계)
>> AllAtOnce : 다운타임이 발생, 한번에 일괄 수정으로 가장 빠름
>> HalfAtATime : 50% 씩 수정 (중간)
>> OneAtATime : 가장 느리게 (Availability 에 가장 낮은 영향)
>> Custom 가능 (x%)
> In-Place 에서만 속도 조절이 되는건가?
<In-Place Deployment + HalfAtATime 설정>
> 반개의 인스턴스 중지 -> 그들은 바로 V2 로 업데이트 기동
> 이제 나머지 반개 중지 -> 그들을 V2 로 업데이트
<Blue/Green Deployemnt>
> V1 을 지칭하는 ALB 가 있다. 이 때 새로운 ASG 가 형성되고 V2 를 지칭하는 앱들이 기동된다
>> 이 떼, ASG 형성은 CodeDeploy 가 자동으로 해줘도 되고, 직접 수동으로 해서 연결해줘도 된다
> CodeDeploy 가 새 ASG에서 띄우도록 설정된 모든 V2 인스턴스를 띄운다
> ALB 는 이후 이 ASG 를 지칭하게 되고, 오래된 ASG 는 제거된다
> 얘는 띄우는 속도가 아닌, Traffic 을 분배하는 정도로 이전을 진행하는 것 같음
<Code Deploy Agent>
> 이 Agent 는 deploy 되는 노드 (EC2) 에 전제조건으로 설치되어야 한다 (간단하게 가능)
>> EC2 인스턴스가 System Manager 로 관리된다면, 이를 통해 설치도 자동화 가능
> Node 는 배포할 앱이 S3 에 있기 때문에 S3 에 대한 접근 권한 (IAM Permission) 이 필요하다
<CD on Lambda Platform>
> Code Deploy 는 Lambda 별칭들간 Traffic shift 를 해줄 수 있다 (특정 별칭 내 버전 이동)
>> ex: PROD 라는 별칭에 대해 V1 -> V2 로 이전
> SAM Framework 와 연계된다
> 위 그림처럼 PROD 별칭이 있다고 해보자 (이거 람다 할 때 나왔었던 것 같음 : https://mooncake1.tistory.com/277 마지막 쯤에 있음)
> v1 -> v2 로 shift 해주고 싶을 수 있음 (위 그림에서 x-> 100 이 될 때가지 움직여줌)
> x = 0 에서 점진적으로 100 까지 증가 (어떻게 증가하냐에 따라 또 나뉘어진다)
>> 람다에서 배웠었던 거에서 세부 사항 확인하셈, LambdaLinear10PercentEvery3Minute 같이 지정 가능, Canary 가능 (X percent 이후 5분 뒤에 100% 이런식), AllAtOnce 가능 (잘 동작하는지에 대한 확인 시간이 없음)
<CD on ECS Platform>
> 새로운 ECS Task Definition 으로 자동 배포 가능
> B/G Deploy 방식만 가능
> ECS Cluster 안에서 V1 이 기동되는 TG 가 있고, 여기에 ALB 가 이 TG 에 연결되어 있음
> CD 를 사용해서 새로운 TG (V2 기동) 가 만들어 진다.
>> 새로운 ECS Task Definition 으로 오게 됨, 이전과 같은 용량
> CD 가 ALB 를 조정해 V2 TG 로 트래픽을 이전시킨다
>> Shift 하는 방식도 또 유사함
>> Linear, Canary, AllAtOnce
EC2/On-Premise
> 직접 구성하는 노드들 같은 경우에는 In-Place Deployment / BG Deployment 를 지원하는 것
> 그리고 IBD 같은 경우 속도 조절이 가능, BG 같은 경우는 이전하는 % 를 조절할 수 있을텐데, 이건 안나오긴 함
Lambda
> x% 에 대한 트래픽을 분배해주며 점차 증가시켜주는 방식
> BG 라 하긴 애매함 (새로운 람다 V2 는 직접 구성해주기 때문)
ECS
> BG Deployment 방식으로 새로운 TG 을 만들어 ALB 를 조절함 (ALB 필수)
> 위와 같은 구분으로 CD 가 지원되는 방식을 이해하면 된다
----------------------------
<377 CodeDeploy 실습>
> IAM Role 을 미리 만든다. 주체는 AWS Service 이고, CodeDeploy 가 사용할 것이다.
>> CodeDeploy for EC2로 만들어서 적절한 정책을 추가해 준다 (알아서 적합한 권한을 넣어줌)
> 하나 더 만드는데, EC2 가 주체가 되는 Role 로, S3 Read 정책을 갖는 Role 이 필요하다 (S3ReadOnly 라는 간단한 정책)
>> 왜냐하면 CD Agent 가 EC2 에 있는데, 얘가 직접 pull 하기 때문이다
> 실습은 EC2 용을 CD를 대상으로 한다 (실제 EC2 하나 함 - 난 귀찮아서 안함)
> EC2 인스턴스를 생성, EC2 인스턴스 연결을 진행
>> EC2 로 들어가서 CD Agent 를 설치할 것이다
> 경로 내에서 다음과 같은 동작을 수행한다
> 또한 EC2 에 아까 만든 S3 접근 권한을 준다
$sudo yum update
$sudo yum install ruby // Agent 가 기반이 되기 때문에 Ruby 설치 필요
$wget https://aws-codedeploy~~ // 정확한건 검색후 사용, CDA 설치 파일 다운로드임
$chmod +x ./install // 설치 진행
$sudo ./install auto // Agent 가 설치
$ sudo service codedeploy-agent status // 실행된 것을 확인
> DeploymentGroup 을 생성해보자
> dev 용 group 을 먼저 만들고, 태깅을 통해서 이를 인식하도록 한다
> CD on EC2 는 In-Place, BG Deploy 를 지원한다고 했었지? BG 는 ASG 가 연계되어 있어서 할 필요 없지만, In-Place 방식은 사용하는 Ec2 들을 CD도 인식하고 있어야 함
>> EC2 인스턴스로 이동해서, tag 로 가서 environment : development 태그를 추가한다 (LB가 없어서 태깅을 쓰는 듯?)
> 아까 만든 ServiceRole 지정
> System Manager 가 Agent 설치하게 해주겠냐 하는거 Never 로 하면 됨 (직접 해줬기 때문)
>> 일단 이건 System Manager 는 무시하는 걸로...
> Deployment 방식은 일단 AllAtOnce
> LB 를 사용할 수도 있는데 일단 하지 않음. LB 쓰면 태깅 필요 없다 아님? 이건 잘 모르겠음. 그래도 태킹이 필요할 것 같음. BG 처럼 ASG 가 해주는게 아니므로
> 이제 ec2 에 CD 를 돌려볼 준비가 되었다
> DeploymentGroup 으로 노드와 연결하는거고, Deployment 로 실제 배포 작업을 실행하는 것이다
> 우선 앱을 S3 에 둬보자. lecture-377-cd-bucket 으로 만든다. (Deployment 에서 가져올 S3)
> codedeploy 폵더 안에 있는 SampleApp 을 사용할 것임
> 다음과 같이 appspec.yml 을 볼 수 있다
version: 0.0
os: linux
files:
- source: /index.html
destination: /var/www/html/
hooks:
BeforeInstall:
- location: scripts/install_dependencies
timeout: 300
runas: root
- location: scripts/start_server
timeout: 300
runas: root
ApplicationStop:
- location: scripts/stop_server
timeout: 300
runas: root
> files : 패키지 내 index.html 이 source 의 경로에 복사되어야 함을 명시함 (zip 해제 후 index.html 을 웹서버에 연동시켜주는 과정)
> hooks 도 설정
>> BeforeInstall, ApplicationStop 시에 각각 script 를 실행하도록 명시되어 있다
>> script 는 강사가 매우 간단하게 구성함
>> 이걸 zip 으로 업로드를 할 수 있음
> 다시 돌아와서 S3 URL 을 지정해준다 (Revise location), 그 후 바로 생성
> Deployment 는 생성시 자동으로 수행, 앞으로 lifecycle event 들이 바로 등록된다
> 성공적으로 EC2 가 S3 로 부터 zip 을 가져와서, script 대로 수행 후 앱을 성공적으로 배포한 것을 볼 수 있다
> 접근 IP 를 통해 접근하면 index.html 의 웹 내용을 확인할 수 있다
> 참고로 Deployment Configuration 에서 직접 배포되는 방식을 연계할 수 있다 (롤백, 배포 속도 구성 등등)
> CodePipeline 과 연계하진 않는듯? 너무 길어져서 그런 듯
> 생성한 모든 자원은 삭제!!
----------------------------
<378 EC2 및 ASG 용 CD>
> EC2 인스턴스에 접근 할 때는 appspec.yml + Deployemnt 전략 설정 을 통해서 진행했다
>> 또한 hook 함수를 지정해서 원하는 동작들을 수행시킬 수도 있었다
> 또한 ECS, Lambda 에서의 CD 연동을 이론만 학습했다
< ASG 용 CD >
> 대상을 ASG 로 지정할 수도 있는데, 이 때는 In-Place 와 BG 모두 지원된다
>> In-Place Deploy 는 똑같이 수행함. EC2, On-Premise 의 것들과 똑같다. 한 ASG 안에서 V2 를 띄우기 위해 반반 쇼쇼를 하는 것
> B/G 같은 경우 ELB 를 사용하고 있어야 한다 (ASG 간 Traffic Shift 를 해줘야 하기 때문)
> 새로운 ASG 가 만들어지고, 여기에 V2 를 기동하는 EC2 들을 띄움
> ALB 는 설정된 시간동안 둘다 수신하다가 (Testing) V1 을 제거
<Redeploy & Rollback>
> 롤백 : 이전에 배포된 버전을 redeploy 할 때 사용
>> Automatically : 배포에 지속 실패시 CW Alarm 이 트리거 되었을 때 자동으로 rollback 하도록 연동
>> Manually 도 가능 (직접 Rollback 수행)
> 롤백 비활성화 - 실행되지 않음
> 롤백을 하면 CD 는 마지막으로 “성공한 리비전”을 토대로 자동으로 배포를 한다. (예전 배포를 또 쓰는게 아니라, “성공한 리비전” 으로 새로운 배포를 진행해서 띄움)
>> (시험유의) 롤백을 하더라도 복원된 버전이 아닌, 새로운 배포 버전이다!!
---------------------------------------
<379 CodeStar 개요>
> 모든 서비스를 그룹화하는 통합 솔루션 (다 통합이래 ㅅㅂ)
>> Github, CodeCommit, CodeBuild, CF, CodePipeline, ...
> Python Project 를 가지고 클릭 몇 번이면 EC2, Lambda, EBStalk 등의 프로젝트에 대하여 백엔드를 SU 하여 매우 편리 (CICD 까지 세팅해줌)
> 지원 언어는 C#, Go, HTML, Java, PHP, Python, Ruby 등
> Cloud 9 과 연계되기도 한다
> 이 시험에선 크게 중요하진 않는 것으로 보임
--------------------------------
<380 Code Artifact >
> 참고로 CA 는 서울 Region 은 제공되지 않음 ㅋㅋ..
> 개발된 SW 패키지들은 라이브러리나 API 와 같은 형태로 서로를 의존한다 (코드 의존성)
> Artifact Management : 아티펙트 관리란 SW에 있어서 전체적인 종속성을 관리하는 것을 말함
> 원래는 보통 스스로 Artifact Management System 을 만들어 사용했는데 이게 꽤 어려웠다고 함
> CodeArtifact 는 secure / scalable / cost-effective 한 Artifact Management System 이다
>> 일반적인 Maven, Gradle, Npm, Yarn, Twine, Pip 와 같은 Dependency Management Tool 들과 통합적으로 연계됨 (아래 그림 참조)
> 장점 : CodeBuild 와 개발자 로컬작업시 모두 종속성들을 CodeArtifact 로부터 가져올 수 있다는 것 (약간 nexus, jfrog 같은 거인 듯, publish / share 하는 곳)
> 모든 Artifact 들이 VPC 내에 있음.
> CA 에서는 도메인을 정의하는데, 도메인이란 Repository 의 다른 이름이다
> 만약 개발자가 npm 으로 빌드하는 명령어를 수행한다면, 이를 CodeArtifact 로 부터 가져오게 설정을 하는 것이다
> 관련자들은 모두 CA 에만 의존성을 관리받게 하고, CA 는 이를 프록시 및 캐싱해주고, 직접 외부 public artifact repo 로 부터 SW Package 들을 가져온다
>> 장점1: 보안에 좋음. 프록시를 사용하므로 외부 Artifact 를 검증할 수도 있고, 관련자들이 직접 외부로 부터 가져오는 것을 막을 수 있다
>> 장점2: 외부 Repo 에서 지원을 Stop 하더라도, 자체 캐싱되어 있어서 서비스를 지속 제공할 수 있다
> 또한 외부뿐만 아니라 자체 Artifact 를 푸시할 수 있다
> 해당 CA 에 배포하면 Secure 하고, 다른 관련 개발자들이 편리하게 의존하여 사용할 수 있다
> 모든 아티팩트가 VPC 에 있는 구조
> CodeBuild 역시 외부 Repo 가 아닌 같은 VPC 내부에 있는 Artifactory 에서 가져올 수 있다
<EventBridge Integration>
> CodeArtifactory 변경사항이 다른 것들을 어떻게 Trigger 하는지?
> CA에서 pkg 버전이 생성/수정/삭제될 시 Event 를 발생시킨다
>> 추후 람다 invoke, Step Function 활성화, SNS/SQS 등, CodePipeline Trigger
>> CP Trigger: 특정 앱이 의존하고 있었는데 변경 이후에도 제대로 동작하는지 확인해야 하므로 Rebuild & Redeploy 가 필요함
<Resource Policy>
> A 계정 내에 있는 CA는 해당 계정 내에 있는 (IAM Policy 를 가진)어떤 사용자나 역할들은 쉽게 접근할 수 있다
> 다른 계정을 허용해주려면, Resource Policy 를 사용해줘야 한다
> CA Repository 액세스를 누군가에게 부여할 때는 All or Nothing 이다 (일부 패키지만 부여는 지원하지 않음)
> Repository 측의 Resource Policy 에서 같은 계정 내 root 계정과, 타 계정의 bob 란 User 에게는 CA 접근을 허용하는 모습이다
> 지금까지 배운 대부분은 Cross Account 사용을 위해서면 리소스 내의 Resource Policy 측에 꼭 “~~는 나에게 접근할 수 있다” 를 명시하는 방법이였음
--------------------------------
<381 Code Artifact 실습 >
> 지원도 안되는거 그냥 지켜만 봤음 ㅅㅂ (크게 중요한 실습도 아닌 듯. CA가 뭔지, 어떤 목적으로 자주 쓰이는지 정도만 알면 될 듯)
> 생성중에 Domain 없으면 같이 생성할 수 있음 (보통 회사 단위라고 함)
> 내가 Repo 를 만들게 되면, 하나의 Upstream-Repository 가 연동되고, 이 Upstream repo 는 pypi (혹은 초반에 내가 설정한 환경) 로부터 가져오게 된다 (프록시 Repo 와 내부용 Repo 가 같이 생성됨)
> 결과를 보면 두 개의 Repo 가 생성되어 있다.
> 하나는 외부와 연결된 Repo (py-pi store), 하나는 내가 생성한 이를 바라보는 Repo (demo-repo)
> CA 사용을 실습해보기 위해 CloudShell 로 이동
> ㅈㄹㅈㄹ 해서 토큰을 생성하고, CA 에 접근할 토큰을 받음 (내부에서도 인증이 필요하긴 함)
> 그리고 pip 명령어로 repo 들을 가져오는 origin 을 이 CA로부터 가져오라고 명령어를 수행할 수 있음 (gradle 에서 repository 설정하는거 마냥)
>> 가져올 때 방금 발급받은 토큰 필요한듯?
> 잘 모르겠지만 하나 다운받았더니 두 Repo 에 다 다운되었음
> 그리고 이론에서 나왔듯이 Repo 단위로 Policy 권한을 명세할 수 있고, 더 크게 Domain 자체에 대한 Domain Policy 로도 제어할 수 있음 (Repo 단위보다 더 작게는 안되지만 더 크게는 되는 듯)
>> Repo 내부 패키지별 권한은 불가
> 그렇게 중요한 실습은 아니였던 것 같음. 뭔지만 알고 있자
--------------------------------
<382 CodeGuru>
> 머신러닝 기반으로 Coder Review 를 자동화해주고 앱 성능 관련 추천 사항을 제안해줌
>> CodeGuru Reviewer : 정적 코드 분석으로 자동으로 코드를 분석함
>>> Bug, Memory Leak 따위로 자신이 학습한 적이 있는 버그들을 잘 감지한다 (일반 Reviewer 들이 못찾는 것까지 찾기도 함)
>> CodeGuru Profiler : 앱의 런타임 중, 앱 성능에 대한 가시성(visibility) 혹은 권장사항을 제공
>>> Build & Test 를 하면, 비용이 높은 코드들을 감지하고 최적화에 대한 사항을 준비
>>> Prod 도중에는 앱을 지속 모니터링해서 성능 최적화에 대한 제안을 준비
> Reviewer 는 Commit 내역을 살펴보며 검사한다 (java, python 지원, Github, CodeCommit 에 지원)
>> 모범 사례 기반으로 검사, memory leak 따위를 검증, 보안 불안정성, input validation 등을 검사
>> 머신러닝 & automated reasoning 으로 진행
>> 수천 개의 오픈 소스 코드를 분석, AWS 저장소에 대한 코드를 분석 ==> Code Reviewer 로 성장
> Profiler : 앱이 prod & pre-prod 일 때 앱의 run-time behavior 에 대한 이해를 도와준다
>> ex : logging routine 중 CPU 용량을 많이 잡아먹는 것을 분석 (사용하는 Class 에 대한 Usage 등, Heap 메모리 차지하는 정도 이런걸 분석해주는 듯!)
> 코드 비효율성 분석 및 제거
> CPU 사용량 감소 (앱 성능 최적화)
> Compute 비용 감소, Heap 사용량 요약 제공 (메모리 공간을 많이 차지하는 객체 분석)
> 이상 감지
> CodeGuru 를 사용해도 앱에 영향은 많이 최소화 되어 있음
--------------------------------------------------
<383 CodeGuru Agent 구성>
> CodeGuru 는 Agent 기반으로 동작하고, 다음과 같은 사항들을 조정할 수 있다
>> MaxStackDepth - 프로파일에 설정된 코드의 max 양 (depth of stacks) (중요)
>>> method A 가 B를, B가 C를 호출하면 depth stack 이 3이다
>> MemoryUsageLimitPercent - Profiler 가 얼만큼의 Memory 를 사용해도 되는지 지정
>> MinimumTimeForReportingInMiliseconds - Report 전송 간 최소 시간
>> ReportingIntervalInMiliseconds - Profiling 에 대한 보고서를 전송하는 빈도
>> SamplingIntervalInMiliseconds (중요) - Sample 들을 Profiling 을 시도하는 샘플링 주기이다 (외부랑 상관 없이 스스로 하는)
>>> 낮게 설정할 수록 샘플링을 더 많이 얻게 된다 (샘플링 비율이 높음) : 호출되는 함수/메소드를 더 많이 인지할 수도ㅜ 있음
>>> 각 설정들이 CodeGuru Agent 에게 뭘 하게 만드는지는 알아야 함
--------------------------------------------------
<384 Cloud9>
> Cloud Based IDE 를 제공해준다 (교육에서 많이 사용됨)
> 인터넷에 있으면 로컬보다 접근성이 좋아서 어디에서든 프로젝트를 작업할 수 있다
> JS, Python, PHP 등 유명한 언어들에 대해 필수 Tool 들이 패키징 되어 제공됨 (사실 로컬에 컴퓨터 언어 관련된게 없어도 Web IDE 에서 작업 가능)
> 개발팀끼리 환경을 공유할 수 있음 (내가 코드를 작성하는 동안 누군가가 볼 수 있음)
> AWS SAM / Lambda 와 완전히 통합하여 Serverless 앱을 완전히 빌드할 수 있음
> 클라우드 기반 Code Editor ==> 무조건 Cloud9
--------------------------------------------------
<385 Cloud9 실습>
> 환경을 생성할 수 있다. 이 때, EC2 인스턴스로 생성을 선택해야 함 (기존에 하고 있는 EC2 에서도 가능)
> Free Tier 를 사용하려면 t2.micro 사용 (EC2 로 이동하면 실제로 하나 띄워져있음, 네이밍이 마치 k8s 처럼 네이밍되어서 올라감)
> 절전 모드 설정 가능, Connection 방식 설정 가능 (SystemManager 를 통해 하면 따로 인바운드 포트 없이 연결 가능), 런칭하는 EC2에 대한 VPC/Subnet 설정도 가능
> Cloud9 내에서 작업되는 Terminal 을 AWS CLI 도 이미 설치되어 있음
> Git 따위와 연동해서 Code Repository 를 init 할 수도 있음. Clone 등등 모두 가능
>> 그냥 EC2 에 접속해서 해당 컴퓨터 내에 IDE 깔아주고 그거 보여주는거임 ㅋㅋ
> AWS 탐색기도 있음
> Cloud9 콘솔에서 내 환경에 대한(지역) Resource 들을 탐색할 수 있다 (이건 좀 신기한데?)
>> ex: APIGateway, ECR, S3 buckets (객체들을 볼 수 있음)
> 사람들과 Environment 공유가 가능
> 공유 링크가 주어짐. 이에 대한 읽기/쓰기 권한을 누구에게 부여할지 설정 가능 (특정 IAM User 를 초대할 수 있음)
------------------
<퀴즈>
====================================================================================
교육 출처
- AWS Certified Developer Associate 시험 대비 강의 - Udemy
'웹 운영 > AWS' 카테고리의 다른 글
| [CDA] 섹션 26 - 클라우드 개발 키트 (CDK) (0) | 2024.10.03 |
|---|---|
| [CDA] 섹션 25 - AWS 서버리스 : SAM (Serverless Application Model) (0) | 2024.09.20 |
| [CDA] 섹션 23 - AWS 서버리스 : API Gateway (0) | 2024.09.09 |
| [CDA] 섹션 22 - AWS 서버리스 : Dynamo DB (0) | 2024.09.01 |
| [CDA] 섹션 21 - AWS 서버리스 : Lambda (II) (0) | 2024.08.19 |
