본문 바로가기
교육

[64일 차] 21.10.25 : DevOps 5

by ballena 2021. 10. 25.

AWS CodeDeploy

AWS CodePipeline


1교시

 

 

저번까지는 CI 도구들

오늘은 CD 도구

 

  • AWS CodeDeploy

EC2, ECS, Lambda 및 온 프레미스 서버와 같은 다양한 컴퓨팅 서비스에 대해 SW 배포를 자동화하여 제공하는 완전 관리형 배포 서비스.

지속적인 배포(CD)를 지원하는 대표적인 CD 도구로, 새로운 기능 및 문제가 되는 코드에 대해 빠르고 신속한 배포가 가능하다.

AWS 콘솔/CLI를 통해 배포를 시작하고, 배포 상태에 대해 추적을 수행할 수 있으며, 상세한 보고서를 통해 앱의 수정 버전이 언제 어디에 배포되었는지 확인할 수 있다. 또한, 진행 과정에서 오류가 발생할 시 손쉽게 SW의 배포를 중단하고 롤백을 수행할 수 있다.

 

 

  • CodeDeploy 실습 순서

1. EC2 Auto Scaling 그룹에 소스 배포를 위해 IAM에 CodeDeploy 서비스 역할과 EC2에 부여할 IAM 인스턴스 프로파일 생성

2. EC2 인스턴스 IAM 역할을 활용해 오토스케일링 시작 구성을 진행

3. 오토스케일링으로 구성된 EC2에 배포할 웹 페이지와 CodeDeploy 배포를 위해 필요한 AppSpec.yml 작성

4. EC2 오토스케일링으로 소스를 배포하기 위해 CodeDeploy 앱을 생성 후 배포

5. 변경된 소스에 대해 EC2에 소스 배포 수행과 오토스케일링에서 서버 추가로 인해 신규 생성된 인스턴스에 대해 소스 배포

 

 

역할을 2개 만들 것이다

1. CodeDeploy-ServiceRole : 모든 리전에서 CodeDeploy 사용

2. CodeDeployEC2-Permissions : EC2 서비스가 S3 버킷 서비스에 접근할 수 있는 권한

 

IAM > 역할 > 역할 생성 > 개체 유형은 AWS 서비스, 사용 사례는 CodeDeploy > 권한 정책 연결(AWSCodeDeployRole) > 이름 작성 후 생성


2교시

 

 

1번 역할에서 CodeDeploy에서 제공되는 모든 엔드포인트에 접속하기 위해 정책 수정이 필요.

만들었던 CodeDeploy-ServiceRole 찾아서 클릭 > 신뢰 관계 탭 > 신뢰 관계 편집 > 받은 파일(CodeDeploy-ServiceRole.json) 내용을 여기에 붙여 넣기 > 이렇게 수정하면 각 리전에서 코드디플로이가 제공하는 엔드포인트를 지정한 것. 이러면 대부분의 리전에서 코드디플로이 엔드포인트로 접근이 가능하다.

편집을 완료하면 '신뢰할 수 있는 개체'에 목록이 쭉 생긴다.

 

2번 역할 작업.

IAM > 정책 > 정책 생성 > JSON 선택, 받은 파일(CodeDeployEC2-Permission.json) 복사해서 여기에 붙여넣기. 모든 리전의 S3 엔드포인트에 접근할 수 있는 정책. 해당 리소스에 대한 특정 액션을 허용하는 코드다 > 정책 이름 작성 후 생성

역할 > 역할 생성 > 개체 유형은 AWS 서비스, 사용 사례는 EC2 > 방금 만든 정책과 AmazonS3FullAccess 정책 연결 > 이름 작성 후 생성

-> 정책 2가지를 연결했는데, 명백히 차이가 있다.

전자의 정책은 모든 리전에서 S3 버킷 엔드포인트에 접근할 권한을 주는 것인데, 버킷에 업로드/다운로드/확인/설정 등은 할 수 없다.

후자의 정책은 EC2 서비스가 S3 버킷 서비스에 Full Access할 수 있는 권한을 주는 것이다. 이걸 추가하면 버킷에 각종 작업을 할 수 있다.

 

여기까지가 실습 1단계.

 

 

AutoScaling Group을 사용해 확장성 적용하기가 가능

-> EC2 좌측 목록에 있는 Auto Scaling과 AWS Auto Scaling은 다르다. 후자는 EC2에 종속된 서비스가 아니다.

 

예전에 로드밸런싱을 할 떄, 로드밸런서 설정이 필요했다 -> 이름은 뭐고, 타입은 뭐고, 어떤 트래픽을 받고, 등

그리고 어떤 EC2에게 이 로드밸런서를 사용할지를 대상 그룹으로 만들었다. 이때 하나의 로드밸런서를 여러 대상 그룹에 연결할 수 있었다.

 

시작 구성에는 오토스케일링이 배포할 EC2에 대한 기본 구성 정보가 담겨 있다.

 


3교시

 

 

인터넷이 끊겼다. KT 네트워크 문제로 전국에서 난리났다.

12:00 인터넷 작동. 일단 3교시는 날아갔다.

서울 쪽은 작동하는데, 다른 지역에는 아직 문제가 좀 있다고 한다.


4교시

 

 

이제 2단계 : EC2 인스턴스 IAM 역할을 활용해서 AutoScaling 시작 구성을 진행

EC2 > 좌측 목록에서 Auto Scaling > 시작 구성 > 시작 구성 생성 > 이름 작성(CodeDeploy-ASC), AMI 검색해서 선택(EC2 생성 화면에서 아마존 리눅스2 ami 긁어서 검색), 인스턴스 유형은 t2.micro, 추가 구성에서 IAM 인스턴스 프로파일에서 만들었던 역할 선택(CodeDeployEC2-Permissions), 고급 세부 정보 탭에서 사용자 데이터 항목에 아까 받은 파일 중 'p.272_shellscript' 파일 내용을 복사해 붙이기

스토리지는 그대로, 보안 그룹 규칙에 0.0.0.0/0에 대한 Http 규칙 추가, 키 페어 선택 > 시작 구성 생성

 

(생성한 시작 그룹 체크, 시작 템플릿에 복사 > 선택 항목 복사 이쪽으로 AS 그룹 생성 진입)

(아니면 우측에서 시작 템플릿으로 전환 누르고 선택)

Auto Scaling 그룹 > 생성 > 이름 작성, 시작 템플릿 선택 > 인스턴스 구매 옵션은 시작 템플릿 준수, VPC는 내버려두고 서브넷은 a, c 2개 선택 > 고급 옵션 구성은 로드 밸런서 없음, 나머지 냅두고 다음 > 그룹 크기 및 조정 정책 구성

-> 원하는 용량(초기값), 최소 용량, 최대 용량

아무튼 다 넘기고 생성. 인스턴스가 생성되면 인스턴스 관리 탭에 나온다.

 

 

이제 3단계. AS로 구성된 EC2에 배포할 웹 페이지와 CodeDeploy 배포를 위해 필요한 AppSpec.yml 작성

Cloud9 > 환경 생성 > 이름 작성 > 다 기본값으로 두고, 네트워크 가용 영역을 a로 지정 > 생성

 

생성된 환경에 작업 폴더 하나 생성(codedeploy-sample) > 그 안에 파일 하나 생성(index.html) 후 받은 파일 중 index.html 내용을 긁어서 붙이기 > 같은 경로에 appspec.yml 파일 생성 이건 배포를 어떻게 할 것인지에 대한 설명서다. 받은 파일에서 내용 긁어서 붙이기

appspec.yml

코드에서 보이듯, 3개 파일(install_dependencies, start_server, stop_server)을 script 경로에 생성할 것이다.

생성하고 각 파일의 내용 복사해서 붙이기.

Cloud9 환경의 파일 구성

클라우드9의 터미널로 가서 작업 디렉터리(codedeploy-sample)로 이동

> zip -r codedeploy-sample.zip * 실행해서 압축

> S3 버킷 하나 생성(codedeploy-s3-jwk). 전부 기본값.

> 클라우드9에서 S3 버킷으로 업로드해야 한다. 클라우드9 인스턴스는 S3로의 접근 권한이 있어야 한다.

> 사용자 자격 증명 필요

IAM > 사용자 > 사용자 추가(액세스 키 방식) > 기존 정책 직접 연결(AdministratorAccess). 실습을 위해 풀 권한 부여 > .csv 파일 받아놓고 생성 완료

클라우드9으로 돌아와서 aws configure 실행, 사용자 정보 입력

> aws s3 cp codedeploy-sample.zip s3://codedeploy-s3-jwk 실행해서 버킷에 업로드


5교시

 

 

CodeDeploy > 배포 > 애플리케이션 > 애플리케이션 생성 > 이름 작성(CodeDeploy-SampleApp), 컴퓨팅 플랫폼은 EC2 선택 > 생성

배포 그룹 탭 > 배포 그룹 생성 > 이름 입력(CodeDeploy-SampleDG), 서비스 역할 입력(CodeDeploy-ServiceRole), 배포 유형은 '현재 위치'(블루/그린은 장애조치failover 관련), 환경 구성에서 Amazon EC2 Auto Scaling 그룹 체크하고 아까 만든 AS 그룹 선택, 로드 밸런서 항목은 활성화 체크 해제 > 배포 그룹 생성

배포 생성 > 나머지는 기본값, 개정 위치에 S3 올린 파일의 URI 복사해서 붙이기

 

이제 EC2가 2개 있다. 하나는 Auto Scaling용, 하나는 Cloud9

Auto Scaling용 EC2의 퍼블릭 DNS로 접속해 보면 배포를 확인할 수 있다.

(나는 에러가 났다. 중간에 뭘 빼먹은 듯)

 

수정 내용이 어떻게 반영되는지 확인하자.

Cloud9 > index.html 파일 수정 후 저장

CodeCommit을 사용했다면 터미널에서 명령어를 실행해서 저장소와 동기화시키겠지만, 지금은 S3 버킷을 사용 중이다.

S3는 기존 파일과 변경된 파일의 차이점을 인지할 수 없다. Cloud9에 있는 기존 압축 파일을 삭제하고, 다시 압축하고 S3에 업로드해야 한다.

 

CodeDeploy > 배포 > 배포 복사 > 파일 URI 등 내용 확인 후 배포 만들기 > 완료되면 다시 확인해보기

(여전히 에러 난다. 뭘 빼먹은 거지?)

 

 

이번에는 5단계 : Auto Scaling에서 서버 추가로 인해 신규 생성된 인스턴스에 소스 배포

AS 그룹 체크 > 편집 > 그룹 크기들을 모두 2로 변경 후 업데이트 > 인스턴스 관리 탭에 인스턴스 하나 추가된다.

기존 인스턴스는 InService 상태, 새로 만들어진 인스턴스는 Pending 상태.

수명 주기 후크에 있는 항목 체크 > 작업 > 편집 > 기본 결과를 CONTINUE로 수정 > 변경 사항 저장

-> Pending 상태의 인스턴스가 InService 상태로 변경된다.


6교시

 

 

CodeDeploy > 이번에는 수정이 아니므로 배포 복사가 아니라 배포 재시도 클릭

 

삭제 과정

CodeDeploy > 애플리케이션 > 배포 그룹 상세 정보로 들어가서 삭제 클릭 > 애플리케이션 삭제

Auto Scaling Group > 만든 거 체크 후 삭제 클릭

시작 구성도 체크 > 작업 > 시작 구성 삭제

Auto Scaling 인스턴스는 자동 삭제된다. 

Cloud9 > 환경 체크 후 삭제

S3 버킷도 내용물 삭제 후 버킷 삭제

 

 

  • AWS CodePipeline

빠르고 안정적으로 앱과 인프라의 업데이트를 위한 릴리스 파이프라인을 자동화할 수 있도록 서비스 형태로 제공되는 완전 관리형 CD를 제공하는 서비스

코드에 변경이 있을 때마다 사용자가 정의한 릴리스 모델을 기반으로 앱 릴리스 프로세스의 빌드, 테스트, 배포 단계에 걸친 프로세스에 대해 자동화를 수행한다. 이를 통해 앱의 변경 사항이나 새로운 기능을 신속하고 안정적으로 제공할 수 있다.


7교시

 

 

  • CodePipeline 실습 순서

1. CodeCommit, CodeDeploy, CodePipeline에서 사용할 사용자 계정과 역할, 정책 생성

2. IAM 계정과 CodeCommit 인증을 활용하여 Cloud9과 CodeCommit에 샘플 코드를 등록하고 CodeDeploy를 이용해서 배포할 수 있도록 사전 준비 작업 진행

3. CodeCommit으로 등록한 소스코드를 업로드할 EC2 생성과 CodeDeploy의 배포 그룹 생성

(여기까진 최초 배포, 아래는 수정 배포)

4. 생성한 EC2와 CodeDeploy를 활용하여 CodePipeline을 생성하고, CodeCommit과 CodeDeploy를 활용하여 소스 배포 파이프라인을 구현

5. CodeCommit으로 새롭게 'git push'가 요청되었을 때 CodepPipeine의 처리 과정 확인

 

 

IAM > 사용자 > 사용자 생성 > 이름 작성, 액세스 유형은 액세스 키 > 기존 정책 연결(AWSCodeCommitFullAccess, AWSCodePipelineFullAccess) > csv 파일 받아놓고 생성 완료

만든 사용자의 상세 정보 > 보안 자격 증명 > AWS CodeCommit에 대한 HTTPS Git 자격 증명 생성 및 파일 받아놓기

아까 만든 것과 동일한 역할 생성(CodeDeploy-ServiceRole, CodeDeployEC2-Permissions)

 

 

Cloud9 환경 생성 > 네트워크 가용 영역을 a로 지정하는 것을 제외하고 모두 기본값으로 해서 생성

터미널에서 aws configure로 자격 증명

sudo git config --global credential.helper '!aws codecommit credential-helper $@'

sudo git config --global credential.UseHttpPath true

실행해서 CodeCommit 자격 증명

(자격 증명 시 Force Update 뜨면 업데이트할 것)

 

CodeCommit 레포지토리 생성 > HTTPS URL 복제

> Cloud9으로 돌아와서 저장소 동기화 : git clone [CodeCommit URL]


8교시

 

 

자격 증명 force Update를 안 하면 뭔 짓을 해도 저장소 동기화가 안된다. 주의

 

어쨌건 동기화한 저장소 폴더에 앱을 작성하고 업로드하면 된다.

저장소 폴더에 새 파일 생성 : 아까 한 실습 그대로 파일들 생성

저장소 디렉터리로 이동해서 업로드 작업 실행

git add . > git status > git commit -m "메시지" > git push > 끝나면 CodeCommit에 업로드된 내용 확인

 

CodeCommit으로 등록한 소스 코드를 배포할 CodeDeploy 준비 시작. 이번에는 단일 인스턴스로 할 예정

인스턴스 기본값으로 생성 > 퍼블릭 IP 할당, IAM 역할에 CodeDeployEC2-Permissions 선택, 사용자 데이터에 내용 추가, 보안 그룹에 HTTP 추가

CodeDeploy > 배포 탭 > 애플리케이션 > 생성 > 이름 작성(devops-codedeploy-sample), 컴퓨팅 플랫폼은 EC2 > 생성

배포 그룹 생성 > 배포 그룹 이름 입력(devops-codedeploy-sample), 서비스 역할 입력(CodeDeploy-ServiceRole), 배포 방법은 '현재 위치', 환경 구성은 Amazon EC2 인스턴스로 체크(태그는 CodeDeploy), 로드 밸런서 비활성화 > 배포 그룹 생성

CodePipeline > 파이프라인 생성 > 이름 입력(devops-codepipeline-sample), 서비스 역할은 새 서비스 역할 > 소스 공급자는 AWS CodeCommit, 리포지토리 이름 작성(devops-sample), 브랜치 이름은 master > 빌드 공급자는 건너뛴다 > 배포 공급자는 AWS CodeDeploy, 리전은 서울, 애플리케이션 이름은 devops-codedeploy-sample, 배포 그룹은 devops-codedeploy-sample > 생성 완료

이러면 전체 구조가 보인다.

 

Deploy가 끝나면 EC2 인스턴스의 퍼블릭 DNS로 애플리케이션 화면 접속 가능

(또 안나온다. 뭐가 문제지?)

 

Cloud9으로 돌아가서 index.html 수정하고 저장소에 업로드

> 따로 뭐 할 필요 없이 CodePipeline이 자동으로 업데이트

 

삭제

파이프라인 삭제 > CodeDeploy 배포 구성 삭제, 애플리케이션 삭제 > EC2 인스턴스 삭제 > Cloud9 환경 삭제 > CodeCommit 삭제

 

 

내일은 CodeStar, S3 상세 내용(Glacier 등), AWS RDS 등을 진행 -> Storage 관련 내용

 

CodeDeploy/CodePipeline 실습 때 결과가 제대로 보이지 않았는데, 동일한 이유일 것 같다.

이번 것은 반드시 다시 해 볼 것.


 

1교시 다시 듣기

2교시 내가 녹화한 영상 36분부터 다시 듣기

-> 다시 듣긴 했는데 한번 더 듣자.

6교시 CodePipeline 설명 훑기

 

요즘 이론 설명 때마다 정신이 빠진다. 집중하자.

'교육' 카테고리의 다른 글

[66일 차] 21.10.27 : DevOps 7  (0) 2021.10.27
[65일 차] 21.10.26 : DevOps 6  (0) 2021.10.26
[63일 차] 21.10.22 : DevOps 4  (0) 2021.10.22
[62일 차] 21.10.21 : DevOps 3  (0) 2021.10.21
[61일 차] 21.10.20 : DevOps 2  (0) 2021.10.20

댓글