[Udemy][day-33,34,35] Section16 : AWS Elastic Beanstalk

#AWS Certified Developer Associate

 

173. AWS Elastic Beanstalk - 섹션 소개

시험에서 가장 어려운 파트라고 함

앱 배포 관련 서비스인가봄

 

174. Elastic Beanstalk 개요 (상위 수준)

개발자 고려사항

- 인프라 구조 관리

- 코드 배포

- db, lb, etc 정의

- 스케일링

등등

 

Beanstalk

- AWS 에서 애플리케이션 배포에 관한 개발자 중심의 관점

- 기본적으로 단일 인터페이스에서 EC2, ASG, ELB, RDS 같은 요소를 재사용할 수 있게 해줌

- 관리형 서비스

- 각 요소의 구성 제어 가능

- Beanstalk 서비스 자체는 무료지만, asg, elb 등에서 사용하는 인스턴스에 대해서 비용을 지불해야함

 

구성요소

- application : beanstalk 요소의 집합, 환경, 버전, 구성 등이 있음

- application version

- environment : aws 특정 환경에서 실행되는 리소스, 한개 애플리케이션에 하나의 환경이 있음

2개 티어 (웹서버 환경 티어 , worker(작업자) 환경 티어)

여러 환경 생성 가능 - dev,, test, prod 등

 

많은 프로그래밍 언어를 지원한다고 함

 

 

 

175. Beanstalk 첫번째 환경

beanstalk 생성

create beanstalk 에서 플랫폼을 node.js 로 두고 최근 브랜치와 버전을 선택해주고

샘플 애플리케이션을 선택해줬다

 

creating

몇분 걸렸다

 

배포 완료

 

배포 완료된 화면이다

환경 탭에서 볼 수 있다.

 

환경 - 이벤트

환경 탭의 이벤트에서 beanstalk 이벤트를 볼 수 있다

 

ELB

 

ASG

 

EC2

 

Beanstalk 에 의해서 여러 aws 서비스가 자동으로 생성되는 모습

너무 간단하다

 

beanstalk - application

애플리케이션 탭으로 들어가면 환경에 배포되어있는 애플리케이션에 대한 정보가 나온다.

 

 

 

176. Beanstalk 두 번째 환경

첫번째 환경을 만들고 다시 환경 탭에 들어가서 새 환경 생성을 클릭하게되면

환경 티어 선택

이렇게 웹 서버 환경 티어와 작업자 환경을 선택하는 화면이 나옴

웹 서버 환경으로 선택

 

환경 정보

환경 이름을 입력하는 곳에 prod 로 해주고 도메인을 체크해줬다

이후 node.js 버전을 대충 선택해주고

추가 구성 옵션을 클릭하면 화면이 바뀌게 됨

 

사전 설정

사전 설정을 이번엔 고가용성으로 해서 시작한다

사용자 지정 구성으로 모든 옵션을 직접 수정할 수도 있다고 한다.

 

추가 구성 옵션으로 들어가면

소프트웨어 / 인스턴스 / 용량 / 로드밸런서 / 롤링업데이트와 배포 / 보안 / 모니터링 / 관리형 업데이트 / 알림 / 네트워크 / 데이터베이스 / 태그 를 관리할 수 있다

 

로드밸런서를 처음 구성하면 이후 수정은 불가능하고

데이터베이스 옵션을 선택해서 rds 를 생성하게 될때, 이후 beanstalk 를 제거한다면 rds 는 같이 삭제되니 주의하라고 한다

 

이후 고가용성 사전설정의 두번째 환경을 생성해줬다

역시 몇분 걸린다

 

prod instance

prod 환경에 만들어진 인스턴스에 asg 나 여러 key 가 연결된 모습

 

 

177. Beanstalk 배포 모드 (Deployment Modes)

시험에서는 일래스틱 Beanstalk 에서 특정 상황에서 어떤 배포 모드가 더 나은지 고르는 문제가 출제됨

 

Single Instance - Great for dev

High Avilability with Load Balancer - Great for prod

위에 실습에서 구성해본 구조

 

Deployment Option for Updates

4~5개의 배포 유형

• All at once (deploy all in one go - 모든 애플리케이션을 한번에 배포하는 유형) : 

가장 빠름 , 가동 중지 시간이 발생

빠른 반복과 개발 환경에 적합

추가 비용 없음

 

• Rolling : 롤링 방식

애플리케이션이 기본적으로 낮은 용량에서 실행됨

실행 용량처럼 용량을 얼마나 낮출지 설정할 수 있음 (bucket size)

배포중 어느 시점에서는 애플리케이션이 동시에 두가지 버전에서 실행됨

추가 비용 없음

배포에 시간이 오래 걸릴 수 있음

 

• Rolling with additional batches (추가 배치의 롤링 업데이트) : 롤링 업데이트와 비슷하지만 애플리케이션이 사용 가능하고 늘 전체 용량을 사용할 수 있도록 배치를 이동하기 위해 새 인스턴스를 스핀 업 한다

기본적으로 최대 용량에서 실행됨

버킷 크기를 정할 수 있음

배포중 어느 시점에서는 애플리케이션이 동시에 두가지 버전에서 실행됨

추가 요금 발생

추가 배치는 배포가 종료되면 삭제됨

배포하는데 시간이 오래 걸림

good for prod

 

• Immutable (변경할 수 없는 배포 방식) : 새 인스턴스와 asg 를 스핀업한 인스턴스에 버전 업데이트를 배포한다. 그리고 모두 정상일 경우 전체 asg 를 교체하는 방식

zero downtime

새 인스턴스로 새 코드를 배포함

일시적으로 용량이 2배가 되므로 추가요금이 많이 발생

배포에 실패한 경우 빠르게 롤백 가능

가장 긴 배포 시간

비용 지불이 괜찮다면 프로덕션에 적합한 선택

 

• Blue / Green

일래스틱 beanstalk 의 직접적인 기능은 아님

zero downtime and 릴리스 기능 더 많은 테스트 가능

새로운 스테이지 환경을 배포하는 개념 - 또 다른 일래스틱 빈스토크 환경으로 새 v2 를 배포하는 것

새로운 환경은 준비가 되면 독립적으로 승인되며 문제가 생기면 롤백됨

route 53 을 사용하여 트래픽이 두 환경으로 가는 것을 방지함

테스트 환경이 완료되면 빈스토크를 이용해 URL을 교체할 수 있음

실제로는 수동으로 해야함

 

 

• Traffic Splitting (트래픽 분할)

카나리 테스트(Canary Testing)에 사용 됨

- 같은 용량의 임시 ASG 에 새 애플리케이션이 배포 됨

- 소량의 트래픽이 임시 ASG로 향하게 됨

- 새로운 임시 ASG 의 상태가 모니터링 됨 - 문제가 생기면 아주 빠르게 롤백 하도록 함

- zero downtime

- 작동이 잘 되면 임시 ASG의 인스턴스는 기존 ASG 안으로 옮기게 됨

- 모두 자동화 되어있음

- 블루/그린 방식의 자동화 프로세스

 

 

178. Beanstalk 배포 모드 실습

구성 내 롤링 업데이트와 배포 edit

 

배포 방식

beanstalk 에서 제공하는 5개의 배포 방식

 

강의에서는 변경 불가능으로 놓고 넘어갔다

 

환경 업데이트

환경 구성을 수정하면 메인에서 업데이트 중임을 확인할 수 있다.

 

beanstalk sample

aws 공홈에서 nodejs 샘플 파일을 받아서

압축 풀고

html 파일의 배경색을 파란색으로 바꾼 후

다시 압축해줬다

 

새 버전 업로드

beanstalk 환경 메인에서 업로드 및 배포에 새 버전 압축 파일을 올리고 버전 레이블 명도 바꿔줬다

배포 방식은 변경 불가능이고 이 방식에서 배치 크기는 상관없다

 

배포

배포를 누르면 환경이 업데이트 되고

이벤트

이벤트에도 임시 asg 가 생성되었다고 나오고 업데이트가 진행된다

 

immutable stack

immutable stack asg 가 확인된다

 

흠

강의에선 잘 업데이트 되는데 나는 error 가 뜨면서 업데이트가 안된다

그래서 이전 배포 버전으로만 남아있고 새로 생성됬던 asg랑 인스턴스는 모두 다시 삭제되었다

 

환경 URL 교체

환경의 url 을 서로 바꿀 수 있는데

CNAME 작업이라 시간이 오래 걸린다고 한다.

 

원래대로라면 -env 환경의 배경이 녹색, prod 환경 배경이 파랑이라

기존 url 로 그대로 들어갔을때 서로 색깔이 바뀌게 나온다.

 

(11.15 끝)

 

 

(11.17 시작)

 

179. Beanstalk CLI 및 배포 프로세스

Beanstalk CLI - CLI 에서 Beanstalk 가 훨씬 쉽게 실행되도록 함 'EB cli'

 

의존성 정의 (ex- requirements.txt for python , package.json for node.js)

패키징 - package code as zip

console - upload zip file (새로운 버전), 배포

cli - cli 로 새버전 생성 (uploads zip), 배포

 

 

 

180. Beanstalk 수명 주기 정책 개요 + 실습

beanstalk 는 계정 안에 최대 1000개의 애플리케이션을 저장할 수 있음

이전 버전을 삭제하지 않으면 beanstalk 애플리케이션을 배포할 수 없음

따라서 이전 애플리케이션 버전을 단계적으로 삭제 해야함 - beanstalk 수명 주기 정책 사용

- based on time (오래된 버전)

- based on space (버전의 갯수)

 

데이터 손실 방지를 위해 애플리케이션의 소스 번들이 삭제되지 않는 옵션도 있음

 

beanstalk 의 환경 안에 애플리케이션 버전으로 들어가서 설정을 누르면 생명주기규칙을 설정할 수 있음

수명 주기 설정

버전 갯수 제한을 할 수도 있고

사용 기간별로 설정할 수도 있다

 

원본

수명 주기에서 나오는 원본은 beanstalk-region 버킷에 저장되어있다

 

 

 

 

181. beanstalk 확장

zip 파일을 생성하면 일래스틱 beanstalk 에 배포해야 하는 코드가 포함되어 있는데, EB 확장도 추가할 수 있다.

UI 에서 설정한 모든 매게변수는 파일을 사용해서 코드로 구성할 수 있다 - EB extension

요구사항 : 

이런 모든 구성 파일은 반드시 소스코드의 루트의 .ebextensions/ 디렉토리에 있어야함

YAML 또는 JSON 형식이여야 함

해당 파일의 확장자는 반드시 .config 여야 함 (ex: logging.config)

옵션을 사용해서 기본값을 수정할 수 있다.

RDS 나 ElastiCache, DynamoDB와 같은 EB 확장자로 리소스를 추가할 수 있다

설정할 수 없는 다른 모든 사항도 일래스틱 Beanstalk 콘솔에서 설정 가능함

 

환경이 삭제되면 EB 확장자로 관리하던 모든 것이 같이 삭제됨

 

extension

위와 같이 yaml 형식의 .config 파일이 .extension/ 안에 위치해서 압축해야 한다

 

# You must place this file in .ebextensions
# And must have a .config file name 
# So the file is at .ebextensions/environment-variables.config

option_settings:
  # see: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options-general.html#command-options-general-elasticbeanstalkapplicationenvironment
  aws:elasticbeanstalk:application:environment:
    DB_URL: "jdbc:postgresql://rds-url-here.com/db"
    DB_USER: username

# This format works too:
# option_settings:
#   - namespace:  namespace
#     option_name:  option name
#     value:  option value

# See: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/ebextensions-optionsettings.html

코드 전문

 

이렇게 해서 zip 파일로 압축한 후 환경에 새 애플리케이션으로 배포한다

 

배포가 완료되면 해당 애플리케이션 구성으로 들어가서

소프트웨어 수정에서 스크롤을 내리면 환경 속성 쪽에 name : value 로 자동으로 설정되어있다.

위에선 db_url 과 db_user 가 들어가있게 됨

 

 

 

182. Beanstalk 및 CloudFormation

beanstalk 는 이면에서 cloudformation을 기반으로 한다.

CloudFormation 은 다른 AWS 서비스를 프로비저닝하는 코드형 인프라 서비스

 

.extensions 폴더의 CloudFormation 리소스를 사용하면 모든 것을 프로비저닝 할 수 있음

 

cloudformation 스택

아래 3개는 이전 실습때문에 생긴거고

위 2개가 beanstalk 의 환경에 의해 생겨난 스택이다

 

resource

들어가보면 전체 코드를 볼 수도 있고

여러 작업을 할 수 있는데

리소스탭에는 환경에 어떤 리소스들이 있는지도 모두 볼 수 있다.

 

나중에 배운다고 함

 

 

 

183. Beanstalk 복제

기존 환경을 새 환경으로 복제할때 정확히 같은 구성을 갖도록 할 수 있음

이미 애플리케이션에 대한 프로덕션 버전이 있고 동일한 설정으로 테스트 버전을 배포하고자 할 때 아주 유용함

 

기존 환경의 모든 리소스와 구성은 그대로 유지됨

- 로드밸런서 타입+구성

- RDS DB 유형 (데이터는 보존되지 않음)

- 환경변수 등

 

환경 복제

환경 메인 화면의 작업에 있다

 

새 환경

보면 이름, URL, 플랫폼 버전 역할 밖에 바꿀 수 없다

완전히 동일한 구성으로 환경이 생성되고

이후 생성된 환경 안에 들어가서 구성을 바꿀 수 있다.

 

 

 

184. Beanstalk 마이그레이션

• 로드밸런서 교체

beanstalk 환경을 한번 생성하고 나면 일래스틱 로드 밸런서 유형은 변경이 불가능하고 구성만 바꿀 수 있다.

만약 Classic LB 를 생성했었다면 ALB 나 NLB 로 업그레이드 할 수 없다는 뜻

To Migrate : 

- 로드밸런서를 제외하고 동일한 구성으로 새로운 환경을 생성함

- 애플리케이션을 새 환경에 배포함

- 이전 환경으로 가던 트래픽을 돌리기 위해 CNAME 교체나 Route 53을 이용해 dns 업데이트를 수행함

 

 

• RDS

RDS 는 Beanstalk 애플리케이션을 이용해서 프로비저닝이 가능함 - 개발이나 테스트를 하고자 하는 경우에 유용

프로덕션 개발을 위해서는 유용하지 못함 - db의 수명 주기가 beanstalk 환경의 수명 주기와 연결되어있기 때문

 

프로덕션 시 RDS를 Beanstalk 환경에서 분리한 다음 환경 변수 등을 이용하여 이를 연결 문자열로 참조하는 것

 

Decouple RDS (beanstalk 스택에 있는 RDS 분리)

- 문제가 발생할 경우를 대비해 rds 에 대한 스냅샷 생성

- rds 콘솔에서 rds db가 삭제되지 않도록 보호해줌

- 새로운 일래스틱 beanstalk 환경을 rds 를 제외하고 생성해줌 : 환경 변수 등을 사용해서 애플리케이션을 기존의 rds db로 지정함

- CNAME 교체나 Route 53 dns 업데이트

- 제대로 작동하면 기존 트래픽을 새로운 버전으로 돌림

- 기존 환경 삭제 : rds 보호했으니 rds는 삭제되지 않음

- delete_failed 상태일 리소스들은 수동 삭제

 

 

(11.17 끝 - section 조금 남았는데 프로젝트 할게 있고 지금 밤 12시임 ㅋㅋ)

 

(11.30 시작 - 구름 k8s 과정 끝나고 일주일 쉬었음 ㅋㅋ)

 

 

185. 도커가 있는 Beanstalk

단일 도커 컨테이너용으로 애플리케이션을 실행할 수 있음

dockerfile 을 제공하는 경우

dockerrun.aws.json v1 정의 - 이미 구축된 도커 이미지가 어디 있는지 그 위치를 서술함

단일 도커 컨테이너를 사용하는 beanstalk 의 경우 ecs 가 기반이 되지 않고 ec2 에서만 도커를 사용함

 

다중 도커 컨테이너 (multi docker container)

Elastic Beanstalk 내 EC2 인스턴스 당 여러 컨테이너를 실행 가능

- ECS Cluster

- ECS 클러스터를 이용해 구성된 EC2 인스턴스

- 고가용성 모드의 로드 밸런서

- 태스크 정의 및 실행

 

Dockerrun.aws.json (v2) 를 직접 작성해서 실행함

해당 파일은 ECS 태스크 정의를 생성할 때에도 사용됨

 

• Beanstalk 도커 환경 실습

beanstalk 의 새 환경 생성 - 웹서버 환경 

플랫폼 - docker

강의에서는 single 도커 환경과 multi 도커 환경 플랫폼이 나눠져 있었지만

실제 만들땐 docker 환경과 ecs 환경으로 나누어져있었다.

 

나중에 통합된듯 하다

 

강의에서는 multi docker 플랫폼으로 놓고 넘어갔는데

docker 로 해놓고 환경을 새로 생성해줬다.

아마 다중 컨테이너 환경으로 실행하려면 ecs 환경을 선택해야 하나 보다

 

sample application zip

multicontainer docker

{
  "AWSEBDockerrunVersion": 2,
  "volumes": [
    {
      "name": "php-app",
      "host": {
        "sourcePath": "/var/app/current/php-app"
      }
    },
    {
      "name": "nginx-proxy-conf",
      "host": {
        "sourcePath": "/var/app/current/proxy/conf.d"
      }
    }
  ],
  "containerDefinitions": [
    {
      "name": "php-app",
      "image": "php:fpm",
      "essential": true,
      "memory": 128,
      "mountPoints": [
        {
          "sourceVolume": "php-app",
          "containerPath": "/var/www/html",
          "readOnly": true
        },
        {
          "sourceVolume": "awseb-logs-php-app",
          "containerPath": "/var/log/sample-app"
        }
      ]
    },
    {
      "name": "nginx-proxy",
      "image": "nginx",
      "essential": true,
      "memory": 128,
      "portMappings": [
        {
          "hostPort": 80,
          "containerPort": 80
        }
      ],
      "links": [
        "php-app"
      ],
      "mountPoints": [
        {
          "sourceVolume": "php-app",
          "containerPath": "/var/www/html",
          "readOnly": true
        },
        {
          "sourceVolume": "awseb-logs-nginx-proxy",
          "containerPath": "/var/log/nginx"
        },
        {
          "sourceVolume": "nginx-proxy-conf",
          "containerPath": "/etc/nginx/conf.d",
          "readOnly": true
        }
      ]
    }
  ]
}

Dockerrun.aws.json 파일

 

php-app 과 nginx-proxy 2개의 멀티 컨테이너로 동작함을 정의한 dockerrun.aws.json 파일을 다운 받을 수 있다

 

실행 완료된 beanstalk

약 5분정도 기다리면 single docker 환경의 beanstalk 환경이 배포된다

 

 

 

186. Beanstalk 고급 개념

 

• Beanstalk 에서의 HTTPS

간단히 SSL 인증서를 로드밸런서에 로드 하기만 하면 됨

- SSL 인증서를 Elastic Beanstalk 콘솔에서 로드밸런서 구성으로 직접 로드

- securellistener-alb.config 라고 하는 .extensions 에서 직접 파일을 생성

- 인증서 자체는 ACM(AWS Certificate Manager) 혹은 CLI 이다.

- 포트 443의 로드 밸런서로 http 트래픽을 허용하는 보안 그룹 규칙을 구성해야 함

 

 

• Beanstalk 에서의 HTTPS 로 HTTP를 리디렉트

따로 특별한 EC2 구성을 만들거나

ALB , 즉 로드밸런서만을 구성해서 ALB 에만 HTTP를 HTTPS 로 리디렉트 하는 규칙을 설정

상태 확인까지 리디렉트 되지는 않으며 상태 확인 값에서 지속적으로 200 OK 가 표시됨

 

 

Web Server vs Worker Environment (웹서버 vs 작업자 환경)

 완료되기까지 소요시간이 아주 긴 작업을 수행하는 경우, 해당 태스크를 전용 환경으로 오프로드 하고자 할텐데 이때 환경을 작업자 환경 이라 함

긴 시간이 소요되는 태스크 - 동영상 처리, zip 파일 생성 등

주기적인 태스크를 cron.yaml 로 정의하고 애플리케이션에 해당 처리 태스크를 정의한다고 하면 

 

 

• 사용자 지정 플랫폼 (Custom Platform)

운영체제, 추가 소프트웨어, Beanstalk 가 실행하는 스크립트들을 정의할 수 있음

Use case : beanstalk 와 호환되지 않는 언어를 사용하며 도커도 없는 경우에 사용

사용자 지정 플랫폼 사용

- platform.yaml 파일을 사용해 자체 AMI 를 정의해야 함

- Packer 소프트웨어 사용

 

사용자 지정 플랫폼과 사용자 지정 AMI 차이

- 사용자 지정 AMI 는 기존 beanstalk 플랫폼을 사용자 지정 AMI 로 조정할 수 있음

- 사용자 지정 플랫폼은 beanstalk 플랫폼을 생성할 수 있어 조금 더 심화돤 개념

 

 

 

 

187. beanstalk 정리

asg 용량 수정

ci/cd 파트에서 다시 사용할건가보다

 

끝!