[교육] DevOps Engineering on AWS 2일차

소감

실습 환경이 주어지니 직접 서비스를 구축하고 경험할 수 있어서 너무 좋았다!

 

이론

CD 

∙ Continuous Delivery / Continuous Deploy  → 둘의 차이는 관리자의 승인 유무

 

S3

∙ 파일시스템이 아니므로, 버킷 내 오브젝트들은 사실은 평면으로 존재하는 파일

∙ 폴더를 프리픽스(prefix)라 지칭

 

암호화

∙ SSE-KMS (서버에서 저장할 때 암호화 & AWS KMS에서 키 관리)

 

Chef

∙ Ruby 기반 IT 인프라 관리 및 배포 자동화 도구

∙ 레시피(Recipes)과 쿡북(Cookbooks)으로 구성

 

Puppet

∙ IT 인프라 관리 및 배포 자동화 도구

∙ 매니페스트(Manifests)와 모듈(Modules)으로 구성

 

AWS CodePipeline

3단계 간단한 파이프라인

Stage	소스	빌드	배포
Tool	AWS CodeCommit	AWS CodeBuild	AWS CodeDeploy

 

∙ AWS CloudFormation으로 AWS CodePipeline 생성 가능

∙ AWS Lambda 호출 가능

∙ 교차 리전 및 교차 계정 파이프라인 생성 가능

 

Service Mesh 

 

∙ MSA 에서 서비스 간 통신을 제어하고 관리하는 아키텍처 구성

∙ Control Plane은 Data Plane의 사이드카 프록시에 구성을 배포

∙ sidecar container(proxy 역할)를 통해 서비스 간 통신을 제어

 

 

AWS App Mesh

∙ AWS에서 제공하는 관리형 Service Mesh 서비스

∙ Envoy 프록시를 사용하여 트래픽을 관리

 

 

Docker 용어

 

Dockerfile

∙ Docker 이미지를 생성할 때 사용되는 파일

 

이미지

∙ 런타임 시 Docker 컨테이너용 파일

 

레지스트리(Registry)

∙ Docker 이미지를 저장하고 퍼블릭 or 프라이빗일 수 있음

∙ Docker Hub를 기본 레지스트리로 설정되어 있음

∙ ex. ECR, Docker Hub

 

레포지토리(Repository)

∙ 레지스트리 내 Docker 이미지가 저장되는 공간

∙ 이미지 이름이 사용되기도 함

∙ GitHub의 레포지토리와 비슷한 역할

 

 

Docker에서의 버전 고나리

∙ 버전은 태그를 사용하여 지정

    ex. jh-registry/jiho-app:v1.0

          jh-registry/jiho-app:latest  (기본값)

 

 

ECS  vs   EKS  용어 비교

	ECS	EKS
작업 단위	Task	Pod
	Service	Service
work node 에게 work 지시자	ECS Agent	kubelet
	task definitions	PodSpec

 

ECS

∙ Control Plane을 못 봄

∙ Data Plane으로만 접근 및 관리

∙ task = eks의 Pod

∙ task 내 한 개 이상의 container 존재

 

 

EKS   &   Fargate

∙ EKS는 Farget를 못 알아보므로 Hook을 통해 Farget Scheduler에게 전달하여 

 

eksctl     vs   kubectl

	eksctl	kubectl
작업 단위	eks 클러스터 관련 명령줄 도구	클러스터 내 파드, 서비스 등의 리소스 관리할 때 상호작용하는 명령줄 도구
	cluster , node group 생성	Pod, Service, Deployment 생성
work node 에게 work 지시자		kubelet
	task definitions	PodSpec

 

API Gateway

∙ SAM(서버리스 서비스)를 외부 인터넷에 안전하게 노출되도록 함

∙ HTTP 요청을 Lambda 함수 호출로 변환하여 특정 API 엔드포인트로 들어오는 요청을 처리

Lambda

∙ 트리거(trigger)를 통해 호출

∙ Lambda를 호출할 때 Event(.json)를 전달

 

∙ 계층(layer)

       공유 가능

       공유 라이브러리

 

 

구성도

Amazon S3    ---->   Lambda   ----> DynamoDB

 

필요한 Role

∙ S3: Lambda를 호출할 권한

∙ Lambda: Lambda가 DynamoDB를 접근할 권한

 

동기식

∙ Lambda에서 호출 줄 때까지 Wait

 

AWS 서비스 health status

∙ https://health.aws.amazon.com

∙ 실제 CSP에서는 리전마다 제공하는 서비스 현재 상태를 제공하는 대시보드가 있다.

 

AWS SAM(Serverless Application Model)

∙ 모두 CLI로 통신

∙ 명령어

       pip install --user aws-sam-cli

       sam init        → 새 AWS SAM 프로젝트를 초기화

 

       sam build    →구축 - 컨테이너 내에서 빌드를 시작할 수 있음

 

       sam local invoke "HelloworldFunction" -e event.json

 

       sam deploy

 

 

AWS Serverless Application Repository

∙SAM을 위한 관리형 리포지토리

∙일반적으로 사용되는 public한 SAM applications을 가져와서 사용

 

 

AWS Step Functions

∙ 서버리스 오케스트레이션

∙ 역할별 Lambda들이 연결되어 순차적 또는 병렬적으로 실행함

∙ 기능 = state machine

∙ 조건문(Choice)을 통해 입력 데이터에 따라 워크플로우 경로를 동적으로 결정할 수 있음

∙ ex. 사용자의 승인 

∙ 구성도

 

EC2 Fleet(여러 개)

∙ EC2 여러 개

 

전환 (Cutover)

∙ 기존 시스템을 새 시스템으로 교체하는 시점

 

 

지속적 배포 전략 (Continuous Deploy)

	현재 위치 배포(In-place)	롤링 배포	변경 불가능한 배포	블루/그린 배포
방식	새 인스턴스로 교체하는 대신, 기존 인스턴스에서 애플리케이션 업데이트	프로덕션 플릿의 일정 부분에 애플리케이션 업데이트를 점진적 롤아웃	새 어플리케이션 버전으로 새 인프라를 가동	시스템이 동일한 백엔드(병렬 환경)를 사용하며, 병렬 환경을 복제하고 스와핑하면 가동 중단 시간이 단축됨

 

배포 구성을 위한 AWS CodeDeploy 옵션

1) Amazon EC2/온프레미스

∙ AllAtOnce

∙ HalfAtATime

∙ OneAtATime

 

2) Amazon ECS

∙ All-at-once

∙ Canary

∙ Linear

 

3) AWS Lambda

∙ All-at-once

∙ Canary

∙ Linear

 

CodeDeploy 배포 구성

 

In-place

∙ 한번에 모두 신규 시스템으로 전환

∙ 중단 있음

 

Canary

∙ 신규 시스템으로 10%만 트래픽을 보내다, 이후에 90% 를 전달

 

Linear

∙ 신규 시스템으로 10% 씩 점점 증가하며 트래픽 전달

 

 

ElasticBeanstalk

∙ 변경 불가능한 업데이트 (Immutable updates)

 

변경 불가능한 업데이트 (Immutable updates)

∙ 기존 시스템과 다르게 새 판을 짜고 최소한 트랜잭션을 처리할 수 있는 서버 개수만 배포하여 테스트

 

 

Blue/Green 배포

∙ 일부는 Blue로 일부는 Green으로 가게끔 Route53에서 제어 가능

 

ECS

∙ AWS CodeDeploy를 활용한 블루/그린 배포 가능

 

 

실습

실습 3: AWS CodePipeline을 사용하여 코드 배포 자동화

과제 1: HeartBeat 애플리케이션을 S3 버킷에 업로드

 

AWS Cloud9 서버가 실행중인 리전 확인

$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/placement/region

 

 

이후 명령에서 사용할 myRegion 변수 생성

myRegion=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/placement/region)

 

wget 명령과 함께 변수를 사용하여 zip 파일을 환경에 다운로드

$ wget https://$myRegion-tcprod.s3.amazonaws.com/courses/ILT-TF-200-DEVOPS/v3.6.6.prod-698244af/lab-3-CodePipeline/bundles/CodeDeployHeartbeatDemo.zip -P CodeDeployHeartbeatDemo

 

 

애플리케이션 코드가 복사된 폴더로 디렉터리를 변경

$ cd ~/environment/CodeDeployHeartbeatDemo

 

 

버킷 리스트 확인 (applicationsourcebucket 이름이 포함된)

$ aws s3api list-buckets --output text --query 'Buckets[?contains(Name,`applicationsourcebucket`)].Name'

 

해당 버킷 이름으로 변수 생성

$ myAppSrcBucket=$(aws s3api list-buckets --output text --query 'Buckets[?contains(Name,`applicationsourcebucket`)].Name')

 

압축 파일을 Amazon S3 버킷에 복사

$ aws s3 cp ~/environment/CodeDeployHeartbeatDemo/CodeDeployHeartbeatDemo.zip s3://$myAppSrcBucket/HeartBeat-App.zip

 

과제 2: AWS CodePipeline 생성

 

* Build는 이미 되어있으므로 Build 단계는 하지 않고 Skip하였다.

 

과제 3: CodePipeline 배포 확인 

EC2(Windows) 서버에서 테스트

EC2(Windows) 서버 SSM으로 접속하면 Windows Powershell로 접속된다.

 

Heartbeat 서비스 정상 실행 확인

$ Service "AWSHeartbeat*"

 

로그 출력

$ Content C:\Logs\HeartBeatService.log -last 10

 

 

과제 4: 업데이트된 애플리케이션을 검색하여 AMAZON S3 애플리케이션 소스 버킷에 업로드

AWS Cloud9 IDE에 연결하고 소스 S3 버킷의 Heartbeat 애플리케이션 코드를 변경합니다. 작업을 간소화하기 위해 약간 변경된 새 소스 코드가 이미 번들로 제공되었습니다. 새 코드 변경에서는 Heartbeat Service - Updated!!! 를 로그에 대한 출력으로 나타냅니다.

 

S3 CP 명령을 사용하여 업데이트된 HeartBeat 애플리케이션을 다음 명령으로 파이프라인의 소스 버킷에 복사

$ aws s3 cp s3://$myRegion-tcprod/courses/ILT-TF-200-DEVOPS/v3.6.6.prod-698244af/lab-3-CodePipeline/bundles/updated-HeartBeat-App.zip s3://$myAppSrcBucket/HeartBeat-App.zip

 

AWS CodePipeline 배포 확인

AWS CodePipeline 콘솔에서 업데이트된 HeartBeat 애플리케이션이 대상 EC2 플릿에 배포되는 과정을 관찰한다.

 

---

실습 4: AWS Serverless Application Model(AWS SAM)과 CI/CD 파이프라인을 사용하여 서버리스 애플리케이션 배포

이 실습에서는 SAM을 사용하여 웹 사이트를 Lambda에 배포합니다. 또한 CodeDeploy를 활용해 웹 사이트를 구성하여 블루/그린 배포 모델을 지원합니다.

 

 

과제 1: AWS SAM을 사용하여 애플리케이션 빌드

 

SAM 프로젝트 초기화

$ sam init --runtime python3.9

 

Enter 키를 눌러 제안된 Project name [sam-app] 을 수락한다.

 

SAM Build 수행

$ cd ./sam-app

$ sam build

 

빌드가 성공하면 로컬에서 애플리케이션 테스트

$ sam local invoke HelloWorldFunction --event events/event.json

AWS SAM을 사용하여 애플리케이션을 테스트합니다. 테스트 출력에서 상태 코드 200을 찾으면 된다.

 

 

애플리케이션 시작

$ sam local start-api -p 8080

AWS SAM 명령 start-api를 사용하면 애플리케이션이 로컬에서 임시 컨테이너에 배포되어 웹 애플리케이션을 살펴볼 수 있다. 

애플리케이션을 탐색하면서 간단한 수동 테스트를 수행할 수 있다.

 

* start-api 명령은 로컬 시스템 루프백 주소(127.0.0.1)의 포트 8080으로 이동시킨다. 

 

 

 

브라우저를 통해 서비스 실행 확인

Preview > Preview Running Application 클릭

 

정상적으로 서드 파티 쿠키가 비활성화되었다는 SAM 메시지를 보여준다.

/ 뒤에 hello를 입력한다.

 

이 이미지는 hello world 메시지가 표시된 브라우저의 예를 보여준다.

 

 

과제 1.1:AWS SAM을 사용하여 애플리케이션 배포

 

사용자 정보와 버킷 이름이 포함된 변수를 생성

$ labBucket=lab4-sam-[YOUR-INITIALS]-[YOUR-POSTAL-CODE]

 

전역적으로 고유한 버킷 생성

$ aws s3 mb s3://$labBucket

 

 

Lab4/sam-app/samconfig.toml

[default.package.parameters] 섹션에서 resolve_s3 = true를 resolve_s3 = false로 변경한다.

 

 

애플리케이션을 패키징하고 앞서 생성한 S3 버킷에 푸시

$ sam package --output-template-file packaged.yaml --s3-bucket $labBucket

 

애플리케이션 패키지를 stack으로 배포

$ sam deploy --template-file packaged.yaml --stack-name sam-app --capabilities CAPABILITY_IAM

 

 

Deploy this changeset ?  [y/N]를 묻는 메시지가 표시되면 y를 입력한다.

API Gateway endpoint URL을 찾아 OutputValue를 복사합니다. URL을 새 브라우저 탭이 또는 창에 붙여넣는다.

 

다음과 같이 출력됨을 확인할 수 있다.