#AWS Certified Developer Associate
160. Docker 란?
도커는 앱 배포를 위한 소프트웨어 개발 플랫폼
앱이 패키징되면 어느 운영체제에서든 같은 방식으로 실행됨
마이크로서비스에 이용됨
도커 이미지는 도커 리포지토리에 저장됨
- hub.docker.com (public repository)
- Amazon ECR (private repository / Amazon ECR Public Gallery 옵션 사용 가능)
도커와 가상머신의 차이점
리소스가 호스트와 공유되어 한 서버에 다수 컨테이너 실행 가능
컨테이너끼리 데이터와 네트워크를 쉽게 공유 가능
도커 시작하기
Dockerfile - build - docker image - push - docker repository - pull image - run - docker container
Amazon ECS (Elastic Container Service)
- 아마존 고유 컨테이너 플랫폼
Amazon EKS (Elastic Kubernetes Service)
- kubernetes 의 관리형 버전 / 오픈소스 프로젝트
AWS Fargate
- 아마존 서버리스 컨테이너 플랫폼
- ECS 와 EKS 둘 다 함께 작동할 수 있음
Amazon ECR (Elastic Container Repository)
- 컨테이너 이미지 저장 용도
161. Amazon ECS
- ec2 시작 유형
ECS = Elastic Container Service
AWS 에서 컨테이너를 실행하면 ECS 클러스터에 ECS 태스크를 실행하는 것
EC2 Launch Type (ec2 시작 유형) : 인프라를 직접 프로비저닝하고 유지해야 함
각 ec2 인스턴스에 ECS 에이전트를 실행해야 함
AWS가 컨테이너의 starting / stopping 을 관리해줌
- Fargate 시작 유형
인프라를 프로비저닝 하지 않아 관리할 ec2 인스턴스가 없는 유형
it's all Serverless
ECS 태스크를 정의하는 태스크 정의(task definitions)만 생성하면 AWS가 필요한 CPU 나 RAM 에 따라 ECS 태스크를 대신 실행함
To scale - 간단하게 태스크 수만 늘리면 됨 - ec2 인스턴스를 관리할 필요가 없음
- ECS 태스크의 IAM 역할
EC2 Instance profile (ec2 launch type only)
used by the ECS agent
makes API call to ECS service
send container logs to CloudWatch logs
pull docker image from ECR
reference sensitive data in Secrets Manager or SSM parameter Store
ECS 태스크는 ECS 태스크 역할(ECS Task Role)을 가짐
이는 EC2와 Fargate 시작 유형 모두 해당됨
두 개의 태스크가 있다면 각자 특정 역할을 만들 수도 있음
- 역할이 각자 다른 ecs 서비스에 연결할 수 있게 하기 때문
ex) task a role - acess s3 / task b role - access dynamoDB
ECS 서비스의 태스크 정의에서 태스크 역할을 정의함
- 로드 밸런서 통합 (Load Balancer Intergrations)
ALB - ECS 컨테이너 환경에 적합한 use cases
NLB - 처리량이 매우 많거나 높은 성능이 요구될 때만 권장함
ELB - 예전버전이라 권장되지 않음 , Fargate 와도 연동 안됨
- 데이터 지속성 (data volumes (EFS) )
ECS tasks 에 EFS 파일 시스템 마운트
- ec2와 fargate 시작 유형 모두 호환됨
- ec2 태스크에 파일 시스템을 직접 마운트 할 수 있음
- 어떤 가용존에 있던 EFS 와 연결되어 있다면 데이터를 공유할 수 있음
Fargate + EFS = Serverless
파일 시스템 지속성을 위해 Amazon EFS를 사용하는게 권장됨
use cases : EFS + ECS 의 다중 AZ가 공유하는 컨테이너 영구 스토리지
시험 주의 사항 :
현재 ECS가 Lustre용 FSx 를 지원하지 않음
ECS 태스크의 파일 시스템으로 Amazon S3 버킷을 마운트 할 수 없음
162. ECS 클러스터 생성 - 실습
기존 화면은 뭔가 옛날 화면같았는데
강의에서도 새로운 ecs 환경을 이용하라고 나와서 클릭해줬다
기본 vpc를 사용했고
여러 가용존을 사용하는 것이 좋다고 나와있다
fargate 는 기본 인프라로서 설정되어있고
추가로 ec2 인스턴스를 선택해줬다
용량 공급자 (Capacity provider) 에 3개가 있다고 나오는데
첫번째 FARGATE 는 ECS 클러스터에 Fargate 태스크를 실행하는데 사용된다.
FARGATE_SPOT 은 스팟 모드로 Fargate 태스크를 실행해 EC2 클러스터에 스팟 인스턴스를 선택할 수 있다는 것이다
세번째는 ASGProvider 인데 asg 를 통해 클러스터에 바로 EC2 인스턴스를 실행할 수 있는 것
ASG의 현재 크기와 원하는 크기가 0 인데
이걸 바꾸게 되면
EC2 인스턴스가 생성되고
바로 만들었던 DemoCluster 에 등록되며
ECS 탭 아래의 Container Instances 부분에서 확인 가능 하다
즉 ECS 태스크를 생성하면 FARGATE 혹은 FARGATE_SPOT 에 실행되거나 ASG의 일부로 실행한 컨테이너 인스턴스에 실행된다.
(11.10 끝)
(11.13 시작)
163. ECS 서비스 생성 - 실습
태스크 정의는 ECS 태스크 생성 방식을 나타냄
태스크 정의 생성은 AWS 콘솔로 진행할 수도 있고, JSON 문서로 정의할 수도 있다.
컨테이너를 더 추가할 수도 있고 hub.dcker.com 에서 이미지 url 을 불러올 수 있다
앱 환경에서 fargate 혹은 ec2 를 선택할 수 있고
태스크 크기를 설정하면 앞으로 실행되는 테스크의 cpu 및 메모리의 양을 설정할 수 있다.
스토리지도 선택할 수 있는데, 임시 스토리지로 20GiB 를 준다고 한다
alb에 적용시킬 sg 생성
nginx 컨테이너?에 적용시킬 sg
이제 테스크 배포를 생성해본다
이름을 대충 demo 입력해주고
애플리케이션 유형의 서비스는 계속 실행되는 유형인것 같고
태스크는 실행하고 조오료하는 batch 시스템이라고 한다
패밀리 쪽에 아까 생성한 태스크 정의를 설정해주고
서비스 이름을 입력해준다
서비스 유형의 복제본이나 데몬은 강의에서 설명이 없었다
로드밸런싱을 하나 새로 만들어 준다
fargate 는 nlb 가 안된다고 했었던것 같은데 검색해보니까 된다고 한다
로드밸런서 이름 선택해주고
포트도 설정해준다
target 그룹 이름을 설정해주고 프로토콜은 똑같이 http 로 해준다
상태 확인경로는 자동으로 root 로 들어가있고
유예 기간은 20초로 강의랑 똑같이 해줬다
vpc 와 서브넷은 자동으로 기본값으로 설정되어져있고
보안그룹에서 아까 만든 sg for nginx 를 선택해준다
nginx-demo-sg 의 인바운드 소스는 alb-sg 이다
alb 에 연결된 sg가 잘못되어서 수정해줬다
sg for nginx 가 기존에 연결되어있었는데
alb for ecs sg 보안그룹으로 변경해줬다
alb endpoint 로 접속해보니
새로 만든 태스크의 nginx 컨테이너로 접속되는 모습
원하는 태스킄 숫자를 4로 늘려보면
원하는 태스크 수 만큼의 태스크가 새로 빠르게 생성되는 모습
fargate 라서 유연하다
164. ECS 서비스 - 오토 스케일링
- Fargate Luanch Type
태스크 수를 자동으로 늘리거나 줄일 수도 있음
AWS Auto Scaling 사용시 3개의 지표에 의해 확장/축소가 가능함
- ECS 서비스의 CPU 사용률
- ECS 서비스의 메모리(RAM) 사용률
- ALB Request Count Per Target (타겟당 요청수)
다양한 오토 스케일링 설정
- Target Tracking (대상 추적) - 특정 타겟 추적
- Step Scaling (단계)
- Scheduled Scaling (예약)
EC2 시작 유형이라면 태스크 레벨에서의 ECS 서비스 확장이 EC2 인스턴스 클러스터의 확장과 상이함을 기억해야함
EC2 오토 스케일링이 필요하지 않다면 Fargate 를 사용하는 것이 서비스 오토스케일링에 유리함
- EC2 Launch Type - Auto Scaling EC2 Instances
Auto Scaling Group Scaling
- cpu 사용량 기준 스케일링
- ec2 추가
ECS Cluster Capacity provider (용량 공급자)
- 새 태스크를 실행할 용량이 부족하면 자동으로 ASG 를 확장함
- 용량 공급자는 오토스케일링 그룹과 함께 사용되며
- RAM 이나 CPU 가 모자랄 때 EC2 인스턴스를 추가함
EC2 시작 유형의 경우 위 두가지 방법으로 스케일링 할 수 있는데 강의에선 Capacity provider 를 사용하여 오토 스케일링 하는 것을 권장한다
165. Amazon ECS - 롤링 업데이트
EX case ( Min 50%, Max 100%, starting number of tasks : 4 )
1 - 기존 100% 돌아가던 v1 을
2 - 최소 50%까지 종료하게 되고
3 - 이후 새로 v2 버전이 실행되어 최대 수치인 100%까지 맞춘 후
4 - 기존 v1 을 최소 수치인 50%까지 되도록 종료되면
5 - 새 v2 버전의 태스크를 최대 수치인 100% 까지 되도록 실행시킨다
EX case 2 ( Min 100% , Max 150% , starting number of tasks : 4 )
1 - 기존 최소 수치인 100% 로 돌아가던 태스크를
2 - 최대 수치인 150% 까지 새 태스크로 실행시키고
3 - 기존 v1 을 최소 수치인 100% 이 되도록 종료시키고
4 - 다시 최대 수치까지 새 v2 태스크를 실행 시킨 후
5 - 기존 v1 태스크를 종료시켜 최소 수치인 100% 까지 v2 태스크가 실행되도록 함
이론만 다루고 넘어가는 챕터
166. Amazon ECS - 솔루션 아키텍쳐
EventBridge 로 작동되는 ECS 태스크
- 작동 흐름
client 가 s3 에 객체를 업로드 하면
amazon EventBridge 로 이벤트가 발생 되게 되고
EventBridge 에서 새로운 ECS task 를 fargate 에서 실행시키게 된다.
그럼 ecs 안에서 ecs task role 이 부여되고
태스크는 객체를 받아 처리하고 s3 로 get object 를 반환하고
결과를 dynamoDB 에 저장하게 된다.
EventBridge Schedule
한시간마다 트리거되는 일정을 만듬
한시간마다 fargate 클러스터에 새 태스크가 생성됨
s3에 액세스 할 수 있는 ecs task role 이 할당되고
amazon s3의 파일에 대해 한시간 마다 batch 처리를 하게 됨
SQS Queue
sqs 대기열에 메세지를 보내면
서비스 자체적으로 sqs 대기열로부터 메세지를 가져와서(poll) 처리함
여기에 ecs service auto scaling 을 활성화 하면
sqs 대기열에 메세지가 많아질 수록 더 많은 task 가 활성화 되게 됨
167. Amazon ECS 태스크 정의 - 심화 학습
ECS 태스크 정의는 AWS 콘솔로도 할 수 있지만 JSON 문서 형식으로 생성할 수도 있음
태스크 정의에서의 중요한 정보
- 이미지 이름
- 컨테이너에 바인딩된 포트 (EC2상에 있는 경우엔 호스트)
- 컨테이너에 요구되는 메모리와 CPU
- 환경 변수 및 네트워킹 정보
- 태스크 정의로 연결된 IAM 역할
- CloudWatch 와 같은 로깅 구성
태스크 정의 당 최대 열 개의 컨테이너를 정의할 수 있음
- Load Balancing (EC2 Launch Type) - 동적 호스트 포트 매핑
태스크 정의로 컨테이너 포트만 정의해놓은 태스크가 ec2 안에서 동작한다고 할때
ec2 는 자동으로(랜덤하게) 남는 포트를 컨테이너 들에게 할당하게 되는데
이때 alb 가 ecs 서비스에 연결되어있다면 동적 호스트 매핑 기능 덕분에 올바른 호스트 포트를 찾을 수 있게 됨
ECS 서비스 덕분에 ALB는 두개의 다른 인스턴스 상에 있는 두개의 다른 포트에 자동으로 연결 됨
ELB 는 이런 기능이 없고 ALB 에서만 작동함
동적 호스트 포트 매핑을 사용하려면 EC2 보안그룹은 ALB 보안그룹으로부터의 모든 포트를 허용해야 함
- Load Balancing (Fargate)
각 ECS 태스크는 고유한 private IP 를 가지게 됨
fargate 에는 호스트가 없기 때문에 컨테이너 포트만을 정의하면 됨
ALB 를 fargate에 뿌려진 task 에 연결한다고 하면 이들 모두가 같은 80 포트로 연결되게 됨
ECS ENI SG
- ALB 보안그룹으로 부터 포트 80을 허용해야 함 (Allow port 80 from the ALB)
ALB SG
- ALB 보안 그룹은 웹으로 부터 SSL 이 활성화된 경우 포트 80 혹은 443만을 허용하면 됨
(Allow port 80/443 from web)
- ECS 내의 IAM Role per Task Definition
태스크 정의 당 IAM 역할이 할당됨
태스크 정의 레벨에서 IAM 역할이 할당되므로 서비스 단계에선 IAM 역할을 추측해서 태스크들에 할당하게 됨
- Environment Variables (환경 변수)
태스크 정의는 환경변수를 가질 수 있음
- 하드코딩 : 태스크 정의 내에 직접 설정을 해 고정된, 퍼블릭 URL을 가질 수 있는 것
- SSM Parameter Store (or Secrets Manager) - API 키, 혹은 공유 구성이나 데이터베이스 비밀번호와 같이 민감한 변수인 경우 ECS 태스크를 시작할 때 ECS 태스크 정의 내에서 참조 가능
- Environment Files (bulk) - Amazon S3 : ecs 환경변수를 s3 버킷으로부터 직접 로드하는 방법 - 'bulk 환경 변수 로딩' 이라고 부름
- ECS 태스크 간 데이터 공유 (Bind Mounts)
동일 태스크 정의 내 다수 컨테이너를 정의하는 것도 가능
종종 사이드 카 라고 칭하는 이 보조 컨테이너가 로깅이나 추적 등에 도움을 줌 - 흔한 패턴임
데이터 볼륨을 두 컨테이너 모두에 마운팅해 이들이 데이터를 공유할 수 있도록 해야 함
즉, 이 데이터 볼륨인 바인드 탑재(Bind Mounts)에는 ec2와 fargate 태스크 모두에 사용이 가능함
168. Amazon ECS 태스크 정의 실습
필수 컨테이너로 지정된 컨테이너가 꺼지면 task 가 종료됨
no 로 하면 꺼지던 말던 task 는 계속 실행됨
현재 UI 상에서의 환경변수 등록에는 SSM 파라미터 스토어나 시퀸스 관리자 서비스로부터 데이터를 가져오는 항목이 없음
JSON 이나 CloudFormation 에서는 가능하다고 함
사진 설명 대로 태스크 컨테이너가 aws 서비스에 api 요청을 위해서 역할을 정의하는 것
볼륨 추가를 눌러서 바인드 탑재 형식으로 지정할 수 있음
탑재 지점으로 탑재할 컨테이너들을 설정할 수 있나봄
사이드카를 사용하지 않는다면 모니터링 및 로깅을 이용할 수 있고
로그 수집 사용에서 cloudwatch 나 kinesis 등을 사용할 수 있다고 함
169. Amazon ECS - 태스크 배치
ECS Tasks Placement
EC2 시작 유형의 태스크를 생성하게 되면, ECS는 대상 EC2 인스턴스의 사용 가능한 메모리와 CPU, 포트를 확인할 수 있어야 함
만약 ECS 서비스에 EC2 인스턴스 상으로 배치하고자 하는 새로운 컨테이너 태스크가 생긴 경우 어디에 배치될지 알아야 하는데,
Scales in 할때도 이와 유사한 상황 발생 - ECS 서비스가 어떤 ECS 태스크를 종료할지 판단해야함
이를 위해 ECS 배치 전략과 태스크 제한이라는 기능이 존재함
이 두 기능을 통해 새로운 컨테이너가 어디에 추가되고 어디에서 삭제될지 판단 할 수 있게 됨
이는 EC2 인스턴스 상에서 시작된 ECS 가 있을 때만 유효
- ECS Task Placement Process
1. 태스크 정의 내의 cpu, 메모리, 포트 조건을 만족하는 인스턴스를 식별
2. 태스크 배치 제한 확인
3. 태스크 배치 전략에 최대한 적합한 인스턴스를 식별하기 위한 시도를 한 후
4. 태스크 배치를 위한 인스턴스를 선택해 그 인스턴스에 태스크를 배치함
태스크 배치 전략
- Binpack
- 가장 많이 채워져있는 CPU, 메모리에 태스크를 배치하려 시도함
- 이를 통해 사용중인 인스턴스 수를 최소화 할 수 있어 비용 절감 가능
- 사용중인 EC2 인스턴스의 수를 최소화 하고, EC2 인스턴스의 활용도를 최대로 끌어올리기 때문에 가장 큰 비용 절감 효과를 누릴 수 있음
- Random
- 무작위 태스크 배치
- Spread
- 분산 전략을 사용하면, 태스크가 특정 값을 기반으로 해 분산되어 배치됨
- 특정값 예시 : instance-ID, ecs 가용존 등
태스크 배치 전략을 합쳐서 사용하는 것도 가능
ex) 가용 영역과 instanceID 모두에 분산 전략을 사용
ex) 가용 영역에는 분산 전략, 메모리에는 binpack 을 사용
ECS 태스크 배치 제한 (ECS Task Placement Constraints)
- distinct Instance : ECS 서비스 전반에 걸쳐 태스크들이 각각 다른 컨테이너 인스턴스에 배치가 되게끔 하는 전략
동일 인스턴스 상에 두개의 태스크를 배치할 수 없게 되는 것
- memberOF : 상당히 심화된 언어인 클러스터 쿼리 언어를 사용해 정의된 표현식을 만족하는 인스턴스 상에만 태스크를 배치하는 전략
ex) instance-type 이 t2 인 인스턴스에만 태스크를 배치 하도록 제한
170. Amazon ECR
ECR = Elastic Container Registry
AWS에 도커 이미지를 저장하고 관리하는 데 사용됨
private and public repository (Amazon ECR Public Gallery)
ECR은 Amazon ECS 와 완전히 통합되어있음
이미지는 백그라운드에서 Amazon S3에 저장됨
ECS 클러스터 에서 ECR 의 이미지를 pull 해오려면 IAM Role 이 할당되야함
ECR 에 대한 모든 접근은 IAM 이 보호하고 있음
이미지의 취약점 스캐닝, 버저닝, 태그 및 수명 주기 확인도 지원함
171. Amazon ECR 실습
ECR 에 이미지를 push 하거나 등록된 이미지를 pull 해오려면 cli 상에서 ecr docker 로그인을 해야함
private 으로 만들어 줬음
태그 변경 불가능 기능으로 이미지가 자동으로 덮어씌워지는 것을 방지할 수도 있다고 함
scanonpush 구성은 사용되지 않는다고 함, 레지스트리 수준 스캔 필터로 대체된다고 하네요
암호화도 설정할 수 있나봄
os 별로 push 명령을 확인할 수 있음
172. Amazon EKS
Amazon Elastic Kubernetes Service
kubernetes - 오픈 소스 프로젝트, docker 애플리케이션의 자도오 배포, 스케일링 및 관리에 사용됨
ECS 대신 사용할 수 있는 서비스로 목적은 유사하지만 API는 완전히 상이함
kubernetes is cloud-agnostic (can be used in any cloud - Azure, GCP ...)
'AWS > AWS Certified Developer Associate' 카테고리의 다른 글
| [Udemy][day-36,37] Section17 : AWS CI/CD-1 (0) | 2022.12.03 |
|---|---|
| [Udemy][day-33,34,35] Section16 : AWS Elastic Beanstalk (0) | 2022.11.15 |
| [Udemy][day-29,30] Section14 : CloudFront (0) | 2022.11.04 |
| [Udemy][day-26,27,28] Section13 : 고급S3 및 Athena (1) | 2022.09.23 |
| [Udemy][day-25] AWS 강의 복습 (0) | 2022.09.14 |