제법 어려운 섹션임..
167강 - <Docker 란?>
> 앱 배포를 위한 SW 개발 플랫폼으로, 컨테이너 기술 (앱을 컨테이너에 패키징)
> 컨테이너 형태로 구성되어 있기 때문에 OS 에 종속적이지 않게 배포가 가능하다
>> 장점 : Any Machine with no compatibility issue, less work, easier to maintain & develop 등등
> Use Case : MSA, 본인 HW 머신에서 클라우드 인프라로 앱을 옮기고 싶을 때 등
> MySQL, 자바, Node.js 등등의 앱을 포함한 도커 컨테이너들을 기동시킬 수 있다
> 도커 이미지들은 Docker Repository 에 저장된다
> Public Repository Docker Hub (다양한 OS 베이스의 이미지들을 찾을 수 있음)
> Private Repository ECR (Amazon Elastic Container Registry). 물론 public 공간도 있음
< Docker vs VM : 항상 등장하는 중요한 문제 >
VM (EC2 머신)
> Host OS 위에 Hypervisor 가 있고, 그 위에 VM 이라 불리는 Guest OS 들이 있다.
> 가상 머신은 각자 분리되어 리소스를 공유하지 않는다=
Docker
> 사용하는 리소스들을 Host 와 공유한다 (한 서버에 다수의 컨테이너)
> Host OS 가 있고 (EC2 인스턴스 일 수도 있음), 그 위에 Docker Daemon 이 있고, 그 위에 많은 Container 들이 있는 형태
> 내부적으로 네트워킹, 데이터 공유 등이 가능하다.
> 하나의 서버에 많은 컨테이너를 실행시킬 수 있음
Docker 시작하기
> Dockerfile 을 작성함으로 시작할 수 있다 > 이건 Docker Image 가 된다 > Push 해서 Image 를 보관하는 Repository 에 등록한다 > 기기에서 이를 pull back 해서 run 을 하면 컨테이너가 띄워진다
<AWS에서의 Docker Container Management>
> ECS (Elastic Container Service) > 클러스터링을 위해서라, 기본적으로 k8s 같은 느낌이 좀 있음
> EKS (Elastic K8s Service) > 오픈소스 프로젝트로, Amazon's managed K8s 를 지원한다
> Fargate > 아마존 자체의 서버리스 컨테이너 플랫폼 (ECS, EKS 둘다와 상호작용 가능하다)
> ECR (Elastic Container Registry) > 위에서 설명함
-------------------------------------------------
168강 - <Amazon ECS>
ECS 가 실행되는데에는 두가지 Type 이 있다
1. EC2 Laynch Type
> ECS = Elastic Container Service
> AWS 에서 도커 컨테이너를 띄운다 == "ECS 클러스터에서 ECS Task 를 수행한다" 와 같은 뜻
> ECS 클러스터는 여러 요소로 이루어지는데, 만약 EC2 Launch Type 을 사용한다면 EC2 가 그 요소 이다.
> 따라서 이 유형으로 ECS 클러스터를 사용하는 경우, 인프라를 직접 프로비저닝 및 관리해야 한다
> 그림과 같이, 내 ECS 클러스터는 여러 EC2 인스턴스로 구성된다
> 각 인스턴스가 ECS 에이전트를 실행해야 하고, 이 각 에이전트들은 자신이 실행되고 있는 EC2 를
1) 아마존 ECS 서비스에게
2) 지정된 ECS 클러스터에게
등록하게 된다
> 그 이후로 ECS 태스크를 실행하게 되면 -> AWS는 컨테이너를 띄우거나 내리는 수행을 하게 된다.\
> 우리가 미리 프로비저닝한 EC2 인스턴스를 ECS 서비스가 클러스터링하여 도커 컨테이너들을 배포한다.
2. Farget Launch Type
> 우리가 미리 provision 할 인프라가 없다 (no EC2 인스턴스 관리)
> ALL Serverless!
> 이 타입에서는 우리가 Task 를 정의한다 > 그러면 AWS 에서 CPU 와 RAM 요구사항을 토대로 ECS 태스크를 실행한다
> 우리가 컨테이너를 실행할 때, 우리가 어디서 운영되고 있는지, Ec2 를 생성할 필요 없이 알아서 동작함
> 태스크 수를 늘리면 scaling out 하는거다.
> 시험은 이 Farget 타입을 사용하라고 많이 유도하는 느낌이 있다고 함, EC2 Launch Type 보다 관리하기 훨씬 편하기 때문
<IAM Roles for ECS>
> EC2 Launch Type 내에서 한 Ec2 인스턴스를 보는 중
> EC2 Instance Profile 을 만들 수 있음.
> ECS Agent 만 사용하게 된다. 이 프로파일을 사용해서 Agent 는 ECS 서비스 API 를 호출하게 되고, 컨테이너 로그들을 CloudWatch Log 로 보내는 API 를 쓰게 되고, ECR 로부터 Pull Image 하는 API 를 사용하게 되고, Secret Manager / SSM Parameter Store 에서 민감한 데이터들을 참조하는데 사용된다.
> ECS Task 또한 ECS Task Role 을 사용한다
> 이건 EC2 / Fargate Launch Type 둘다에게 적용된다
> 위 그림처럼 두가지 태스크가 있는데, 각 태스크의 역할을 정할 수 있는 것이다. Task A 는 Role A , Task B 는 Role B
> 각 역할을 서로 다른 ECS 서비스에 연결할 수 있음
> ex: Task A Role 은 S3 를 대상으로 API 호출을 할 수 있다 // Task B Role 은 DynamoDB 를 대상으로 API 호출을 할 수 있다.
> 이런 ECS Task Role 은 태스크를 정의할때 지정한다 (파드 정의서에 정의하듯이 하는 것인듯)
<Load Balancer Integrations>
> 위 예시는 Ec2 Launch Type 의 상황이며 (Fargate 에서도 동작함), 현재 여러 ECS Task 가 실행 중, ECS 클러스터에 모두 포함되어 있다
> 이 태스크를 Http Https 엔드 포인트로 노출하려고 함. (노출시킬때 ALB 로 하기)
> 이 때 ALB 로 연결하는 것
> ALB 로 대부분의 Use Case 를 만족할 수 있다. NLB 는 높은 스루폿이나 성능, 혹은 AWS Private Link 를 요구할 떄 사용된다. ELB 같은 경우 고급 기능을 사용할 수 없으므로 권장되지 않는 LB 이며, Fargate 과는 연동할 수 없다
<Data Persistence / Data Volumes (EFS) >
> ECS 클러스터에 ECS Instance 타입과 Fargate 타입 모두 있다고 해보자 (둘다 지원한다는 뜻)
> 데이터 공유를 위해 ECS 태스크에 EFS 파일 시스템을 마운트하는 것이다 (또한 ECS 태스크에 직접적으로 꽂을 수 있다)
>> 같은 AZ 어떤 곳에서 기동중인 태스크와 EFS 파일 시스템은 동일한 데이터를 공유하기 때문이다. (걍 AZ 내에서 EFS 공유한단 뜻임..)
> Fargate + EFS : ECS 태스크들을 서버리스하게 띄우기 위해 Fargate 를 사용하고, Amazon EFS 를 Data Persistence 방법으로 사용하면 (서버리스) -> 전체적으로 서버리스 솔루션을 만들 수 있다고 함.
> Use Case : Persistent Multi AZ Shared Storage for your ECS system containers
> Note : S3 자체가 File System 으로써 ECS 태스크에 마운트 될 수 없다
-------------------------------------------------
170강 - <실습: ECS 클러스터 생성> 확실히 실습을 좀 보니까 더 이해가 되는 듯
> ECS 페이지에서 새 Cluster 만들기 진행, Fargate, EC2 Type 모두 선택후, ASG 도 t2.micro EC2 를 갖도록 지정함
> 생성을 진행하면 내가 생성 창에서 진행한대로 EC2>ASG그룹에서 자동으로 생성되는 모습을 확인할 수 있음
> 내가 Task 를 띄우면 ASG 에서 자동으로 Ec2 를 띄워서 띄워주는거임.
> 생성된 ECS 클러스터로 이동해서 [infrastructure] 탭으로 이동해보면, 용량 공급자가 3개가 정의된 것을 확인할 수 있다
> Fargate Task 를 띄울 수 있고, Fargate Task 를 Spot 모드로 띄울 수 있음
> ASG Provider 타입은 EC2 인스턴스를 이 ASG 를 통해서 띄울 수 있다는 것임. 현재 Desired 가 0 이라 EC2 가 아무것도 없지만, ASG 로 이동해서 Desired 를 1 로 바꿔주면 EC2 인스턴스가 기동된다.
> 기동이 되는 동시에 같이 띄워진 Agent 가 그 인스턴스를 내가 만든 DemoCluster (ECS Cluster) 에 등록하게 된다
> 이 모습을 위 용량 고급자 아래 [컨테이너 인스턴스] 박스가 있는데 거기에서 등록된 인스턴스라고 뜨는 것을 확인할 수 있다 (Running Task 0), Capacity (CPU, Memory) 값도 확인할 수 있음
> 이제 Service / Task 자난질을 쳐보자!
-------------------------------------------------
171강 <실습: ECS 서비스 생성> - Task, ALB, ECS, Service 등의 관계에 대해 확실히 이해해야함
> K8s 쓸줄 모르면 이거 쓰라는거임 ㅇㅇ. 서비스, 배포 이런거 다 관리해준다
> ECS 태스크 정의 먼저 만들어야 한다
> 인프라-시작유형을 Fargate 로 지정 , OS 는 Linux
> CPU, Memory 사이즈를 조정하여 컨테이너의 규모를 조정할 수 있다
> Task Role - IAM Role 로, AWS 서비스들에게 요청을 날리고 싶을 때 지정하면 된다 (하진 않음, 근데 컨테이너들의 AWS 서비스를 이용한다면 꼭 적합한 Role 을 설정해야 한다)
> Task Executino Role 은 기본으로 둔다, 선택할게 없다면, ECS 가 자동으로 생성할테니 냅두면 된다
> Container-1 을 본다 (이거 Docker File 쓰거나 명령어 실행하는거랑 똑같음)
> nginxdemos-hello 이름으로, image URL 은 nginxdemos/hello 를 가져올건데, 이건 docker hub 에서 자동으로 가져오게 된다 (Docker Agent 이기 때문)
> Storage 또한 기본 설정대로 둔다.
> 이렇게 생성하면 demo-task-1:1 로 1 버전으로 태스크가 생성된다
> 이 태스크를 서비스로 실행시킬 수 있다. (Pod 와 Service 를 묶어서 배포하는 느낌인걸까?)
> Cluster 로 돌아간다. 서비스 탭에서 서비스 생성으로 진입한다
> 서비스의 배포 구성은 두가지 중 하나인데, Service / Task 이다 - Service : 웹앱 같이 계속 실행되어 있는 상태, - Task : 실행하고 종료되어야 하는 독립 실행형 태스크 (배치 작업 등)
> 태스크 정의에 패밀리 / 개정은, 태스크 선택 및 버전 선택을 하는 것이다
> 태스크로 몇 개의 컨테이너를 띄울지도 지정할 수 있음 (Replica)
> 이거 내용들 보면 완전 쿠버네티스임 ㅋㅋㅋ Deployment 세팅하는 느낌
> 네트워킹으로 이동, 새 Security Group 을 만들 것임 (이름 설명 아무렇게나) 그리고 인바운드 규칙 지정, Http, 80 번 포트. 이 컨테이너 클러스터에 진입하기 위한 서비스의 보안그룹 느낌
> 로드밸런싱으로 이동 - ALB 설정, 이걸 하면 서비스 안에서 런닝중인 태스크들 사이에 ALB 가 적용된다
> 상태 검사 유예기간은 0초로 해서 컨테이너들이 기동될 시간을 충분히 준다
> 수신 대상 컨테이너는 연동중인 태스크 내의 컨테이너들중 선택한다
> 그리고 이 컨테이너? 를 기준으로 새 대상 그룹 (ALB 의 Target Group) 을 만든다
> 이제 서비스가 정상적으로 배포된 것을 볼 수 있음
> 서비스 내부로 들어가보면 1 Running, ALB, TG 과 잘 연동되어 있다.
> Target Group 에 들어가보면 아까 설정한 ALB의 TG 임이 명시되어 있고, 1개의 IP 주소가 Targets 탭 안에 들어가 있는 것을 볼 수 있는데, 컨테이너의 IP 이다. (아까 지정한 서비스 내부 컨테이너) - 이 IP 는 단일 컨테이너를 말하는 것일듯.
> 참고로 ALB 에서 생성해준 DNS 이름으로 웹 이동을 해보면 NGINX 가 뜨고, 내가 원하는대로 URI 를 옮기면 NGINX 컨테이너가 이를 인지하는걸 확인할 수 있다
> 서비스 안으로 들어가서 Task 로 이동, 1개의 컨테이너 (Task) 가 실행되고 있음, Task 를 둘러볼 수 있음. (Configuration, private IP, 컨테이너 정보 등)
> 서비스의 Events 로 이동하면, 진행했던 로그들을 살펴볼 수 있음.
> 다시 설정으로 돌아가 Desired Task 를 3개로 늘려보자.
> 새로고침하고 기다리면 두개의 Task 가 더 띄워지는 것을 호가인할 수 있다. (AWS 는 이 Task 를 띄워주기 위한 리소스를 자동으로 프로비저닝 해주는 것이고, 우리는 그 리소스에 대해서 알 필요가 없다 이거임) > Fargate 가 의존성이 훨씬 높은 수준 ㅇㅇ 하지만 권장할듯 편하니까
> 다시 ALB 접속해서 refresh 를 반복하면, Server Address 가 계속 바뀌어서 3개으 컨테이너가 번갈아가면서 ALB 로부터 요청을 수신한고 있는 것을 알 수 있다. (근데 아까 컨테이너 IP 매핑해주지 않음..? ALB 생성할 때? 이게 좀 이해가 안됨) (서비스로 가야하는게 ㅏ닐까? 싶은데 잘 모르겠음, 관계를 좀 정확히 알아야할듯. ㅣ론 강의때 "서비스"란 말이 안나오지 않음?)
> ASG 도 했었는데 이거 왜 했었는지 까먹음 ㅋㅋㅋㅋ 정리가 좀 필요함!! 좀 어려움 (암튼 ASG, 서비스의 desired replica 다 0 으로 해서 비용발생 방지)
> 위에거는 다시 해보면서 복기해보기
172강 - <ECS 서비스 오토 스케일링>
> ECS 태스크들을 AutoScaling 해주는 기능
> ECS 오토 스케일링은 AWS Application Auto Scaling 을 사용한다
> 자동확장지표로 설정 가능한 것들은 다음과 같다
>> CPU 사용률, 메모리 사용률, ALB 의 지표인 ALB req_count / tg
> 다양한 오토스케일링을 설정할 수 있다
>> Target Tracking - CloudWatch 의 특정 지표 (위 세개) 따라 scaling 하는 것
>> Step Scaling - 특정 CloudWatch 알람에 대해 스케일링
>> Schedule Scaling - 변화가능한 포인트에 대해서 특정 date/time 에 ECS 서비스를 미리 확장하는 스케일링
> ECS 서비스 AutoScaling (task level) != EC2 오토 스케일링 (EC2 인스턴스 level) 임을 기억
> 따라서 EC2 백엔드가 없다면, Fargate 을 사용한 서비스로 Auto Scaling 을 활용하는 것이 SU 에 쉬움 (serverless)
> 시험이 Fargate 를 굉장히 좋아하는 편인듯
<EC2 Launch Type 의 EC2 Auto Scaling>
> 프로비저닝된 EC2 인스턴스를 늘리면서 ECS 서비스 스케일링을 진행하는 편
1 > Auto Scaling Group Scaling >> CPU 사용률에 따라 ASG를 스케일 하는것, EC2 인스턴스를 추가한다
2 > ECS Cluster Capacity Provider >> 새 태스크를 실행할 용량 (CPU/RAM) 이 부족하면 자동으로 ASG를 확장한다.
>>> Capacity Provider 는 보통 ASG 와 페어링되어 사용된다
> 두번째 방법이 훨씬 권장되는 EC2 Launch Type 의 Auto 스케일링 방법이라고 한다
<예시>
> Task 두개 붙어있는 Service A 가 있다. 이 서비스는 AWS Application Auto Scaling 으로 자동으로 관리되고 있다.
> 사용자가 많아져서 CPU Usage 가 올라갔다고 해보자.
> CloudWatch Metric > "ECS Service Level 의 CPU Usage" 를 모니터링 하고 있다가 > CloudWatch 알람을 Trigger 한다
> 이 CloudWatch 알람은 그럼 ECS 서비스의 Auto Scaling 을 트리거하게 되고 > ECS 서비스의 desired capacity 가 증가하여 새 Task 가 띄워질 수 있게 된다. (Fargate 은 여기까지 관여하면 되어서, 매우 편함)
> 만약 위 상황이 EC2 Launch Type 이라면, 방금 배웠떤 ECS Capacity Provider 가 붙어서 이런 상황에 EC2 인스턴스를 추가해서 ECS 클러스터를 확장하게 됨
(그래서 지금 Faragte 는 AutoScaling 을 활용하는 것이고, EC2 Launch Type 은 ECS Cluster Capacity Provider 를 활용하는 것임?)
( 또한, 위에서는 마치 두가지 방법인것처럼 설명했는데, 그림에는 왜 Auto Scaling Group 에 Capacity Provider 가 있음?)
-------------------------------------------
173 강 <롤링 업데이트>
> K8s 에서 배웠던 것. 버전 업그레이드 하는 방법
> ECS 서비스를 v1-v2 업그레이드를 하거나 그럴때, 얼마나 많은 태스크들이 start & stop 이 되어야 하고 어떤 순서대로 되어야 하는지 제어 가능
> 두가지를 지정해야함 : Minimum Healthy Percent & Maximum Percent (각각 기본값이 100,200)
> ECS 서비스에 9개의 테스크가 실행중이라면, 100% 는 Actual Running Capacity 를 말한다
> Minimum HP 를 100 보다 적게 설정한다면, 그 설정만큼만 남겨두고 나머지는 Update 를 위해 태스크를 종료해도 된다는 뜻
> Maximum P 는 업데이트 하는데 있어서 v2 태스크를 몇개 만큼 생성할 수 있는지 나타낸다
> 기본적으로 계산할 때는 제거를 먼저 한다고 생각하면 되는 듯.
<시나리오 예시1 - MHP 50 / MP 100>
> 4 개의 태스크를 운영중이다 > 두개가 제거되면 50%로 가용중인것 > 두개가 생성되면 100인것. 두개가 또 제거되면 50인것 > 두개가 더 생성되면 100인것 (Rolling Update 종료)
>두개를 제거한 이유 : MHP 가 50 이니까 // 두개만 추가한 이유: MP 가 100이니까
<시나리오 예시2 - MHP 100 / MP 150>
> 4개의 테스크를 운영중이다 > MHP 가 0 이니까 아무종료도 못하고 > 두개를 추가한다 150%가됨 > 두개를 제거한다 100%가 됨 > 두개를 추가한다 150%가됨 > 두개를 제거한다 100%가 됨 (RU 종료)
> 이걸 다루는건 한 개 이상 나오진 않을 것이다
174강 - ECS의 솔루션 아키텍처 (디자인 패턴같은건가)
<EventBridge에서 호출한 ECS 작업>
> VPC 망 내 ECS 클러스터 내 Fargate 서비스가 있다고 해보자.
> S3 버킷에 유저들이 객체들을 올리면, 발생하는 이벤트들을 Amazon EventBridge 라는 자원으로 보내게 할 수 있다
> EventBridge 는 그런 상황 발생시(?on the go?) ECS 태스크를 실행하라는 규칙을 가질 수 있다 > 그럼 Fargate 내 ECS 태스크가 발생하게 됨
> 작업과 관련된 ECS Task Role 이 있을 것이다 (S3 접근, DynamDB 접근)
> 그러면 그 태스크는 S3 객체를 얻어서 Process (특정 작업을 수행) 하여 Amzon Dynamo DB 에 보낼 수 있다.
> 이렇게 서버리스 아키텍처를 효율적으로 만들 수 있다. Docker Container 를 사용해 S3 버킷의 이미지를 처리하거나 객체를 처리한다.
> ECS Fargate Mode 와 EventBridge 를 활용하는 아키텍처 (ECS 태스크 Role to Access S3 & Dynamo DB)
<EventBridge Schedule 에서 호출한 ECS 작업>
> 아까처럼 클러스터내 AWS Fargate 이 있음
> 이 때, Amazon EventBridge 는 한시간마다 트리거되는 규칙을 만든다. 이 규칙은 Fargate 에서 ECS 작업을 실행한다. (매시간마다 태스크 생성)
> S3 에 접근하는 Task Role 을 가지고 있다고 하자 (예시로)
> 그렇다면 우리의 작업은 (작업 = 내가만든 컨테이너, 내가만든 프로그램이 하는일) S3 에 있는 파일을 대상으로 1시간마다 수행될 수 있다
> 이 아키텍처 역시 서버리스이다
<SQS Queue 와 연동된 ECS>
> 두가지 ECS 작업이 있는 서비스 A가 있고, 외부에는 메세지를 수신하는 SQS Queue 가 있다
> 서비스 A는 SQS 큐로부터 message 를 poll 해 가져와서 그들을 처리한다
> 이 서비스에 ECS 서비스 Auto Scaling 을 얹을 수 있다.
> 즉, SQS 큐에 메시지가 많이 쌓여도, 오토스케일링 덕분에 ECS 서비스에서 더 많은 Task 를 필요에 따라 수행시킬 수 있다 (당연히 언제 띄워라 하는 기준은 정하겠지?)
<EventBridge Usage to Intercept Events From ECS Cluster>
> 뭔소린지 제목만 봐서는 모르겠음
> Task 가 종료되는 거에 대해 트리거를 걸고 싶은 상황 (이게 Event)
> Task 가 종료되거나 시작되거나 하는 따위의 행동은 EventBridge 에게 "Event" 로 동작하라고 설정할 수 있다 (예시 설정 그림에 있음)
>> source 는 ecs 이며, detail 은 ecs 태스크 변화라고 설명을 적고, detail 은 STOPPED 머 이런걸 걸 수 있음.
> 이런걸 SNS Topic 으로 연동시켜서 Admin 에게 이메일을 보내도록 할 수 있다 (ECS 태스크들이 어떤 주기를 가지고 동작하고 있는지 이메일을 통해서 알 수 있게 된다)
--
175강 - <ECS Task Definition :태스크 정의>
> Task Definition 이란 서비스에게 알려주는거다. 너가 있는 클러스터 안에서, 이와 같은 정의대로 Task 를 만들고 관리하면 돼 하고.
> 태스크는 JSON 폼으로 정의를 한다 : Pod 정의서 같은거인듯
> ECS 서비스에게 한개 혹은 여러개의 Docker Container 를 어떤 방식으로 실행하는지 알려준다
> Crucial Info 가 있는데, image Name, Port Binding for Container&host, Memory & CPU, Env Var, Networking Info, IAM Role, Logging Config (ex CloudWatch) 들이 명시되어 있다
> 구체적으로 이해하는게 중요
> 태스크 당 최대 10개의 컨테이너를 정의할 수 있다
<information 이 활용되는 예시>
> EC2 Launch Type 으로 EC2 인스턴스가 있다고 해보자
> Apache 서버를 도커로 띄웠다고 하자. 그리고 이걸 외부로 공개하려고 한다. 80 컨테이너 포트를 노출시키고, 호스트 포트는 8080 포트와 매핑해줬음. 컨테이너에서 맨날 하는거
> 외부에서 EC2 인스턴스 8080 으로 접속하면 컨테이너 아파치에 접근하게 된다
<Load Balancer 가 연동될때 ECS 클러스터 내 태스크들의 Container Port 할당 방법에 대하여>
<EC2 Launch Type 일 경우>
> 로드 밸런싱을 사용하고 있고, EC2 Launch Type 을 사용하고 있다면
> 우리는 "Dynamic Host Port Mapping if you define only the container port in the task definition" 이 제공된다고 함 (걍 알아서 포트 매핑해준다는건듯)
> ECS 태스크를 위에서 수행할 경우, 정의서에 컨테이너 포트가 80 이라고 정의되었는데 호스트 포트가 정의되지 않았다면, Host Port 는 무작위로 지정된다
> 직접 지정해도 되는건가..? ㅋㅋㅋㅋ
> 따라서 각 태스크에 접근하려면 다양한 노드의 포트를 통해서 접근해야한다
> ALB 를 정의한다면, ECS 태스크가 떴다 다운되었다 할 때마다 포트가 계속 변하기 때문에 연동하기 어렵다고 생각할 수는 있다
> 하지만 ALB 가 ECS 와 연동된다면, "dynamic Host Port Mapping" 기능 덕분에 올바른 포트를 항상 자동으로 찾아갈 수 있다 (ㅋㅋ 잘 모르겠음..)
> ELB에선 안된다고 함
> 따라서, EC2 인스턴스 Security Group 에 ALB 로부터 들어오는 건 어떤 포트든지 ALLOW 되어 있어야 한다 (어떤 Host Port 가 될지 모르기 때문)
<Fargate 일 경우>
> 호스트 포트같은게 없기 때문에, container port 만 정의하면 된다
> ECS 태스크는 각각 고유한 private IP 를 부여받게 된다 (Elastic Network Interface (ENI) 를 부여받음?)
> 각 ENI 는 동일한 컨테이너 포트를 갖게 된다. (ENI 가 각 태스크에 (모두 동일 포트) 꽂혀서 해당 private IP 로 들어오는 것을 수신하는듯?)
> ALB 가 있을 경우 Fargate Task 로 연결하려면, 이 태스크들 모두가 같은 포트인 포트 80 으로 연결되게 된다.
> 따라서, ENI Security Group 은 ALB 로부터 오는 요청에 대해 80 번 포트를 열어둬야하고, ALB 보안 그룹은 외부로 부터의 접근을 허용하면 된다
<One IAM Role per Task Definition>
> 시험에 자주나옴
> Task 정의서와 1:1 관계임을 확실하게 알고 있어야 한다
> Task Definition 에 ECS Task Role 을 부여하는데, 이를 통해 Task 는 다른 아마존 서비스들에 접근할 수 있게 된다.
> 아까 ECS 서비스 생성할 때 보면, Task Definitino 을 먼저 생성하고 이 Definition 을 서비스에 물렸다.
> 그러면 서비스는 생성하는 각 ECS 태스크들에게 정의서에 정의된 이 Role 을 자동으로 상속시킨다. (태스크 정의서에 S3 접근 Role 이면, 이걸로 생성되는 모든 Task 는 이 IAM 권한을 갖게됨)
> 약간 TAsk Definition 에 명시되긴 하지만, Service 에게 주는 정의서임. 이거대로 Task 만들라고!
> 단골 문제 : ECS 태스크를 위한 IAM Role 어디에 정의하나요? 하고 물어볼건데, 그러면 Task 정의서요! 하면 된다 ㅇㅇ
<ENV Variables >
> 태스크에게 알려줄 환경 변수들을 정의서에 다양한 방법으로 적을 수 있다
>> Hard Coding (직접 설정, 고정되었고, 노출되어도 상관 없는 값들)
>> SSM Parameter Store (API key, 공용 config 등 Sensitive 한 값들) 여기에서 Fetch 해오라고 할 수 있음
>> Secrets Manager (DB 암호 등) 여기에서 fecth 해오라고 할 수 있다
> 그러면 서비스가 태스크 정의서를 참조하며 태스크를 생성할 때, 그 때 fetch 해서 가져오게되고 (Runtime fetch) 그 후 태스크 내의 환경변수로 주입된다.
> 마지막 옵션으로는 ECS 환경 변수를 S3 버킷으로 부터 직접 로드하는 방법이 있는데, 이건 Bulk Env Loading 이라고 부른다. (말 그대로 대량을 넣을 때 사용되는 듯??)
<Data Volume (Bind Mounts)> - ECS 태스크 간 데이터를 공유하는 법
> 서비스가 Pod 정도 되는듯
> TASK 정의서에 여러 Container 를 정의하는 것도 가능함
> 로깅, 트레이싱 등에 도움을 줄 수 있는 Side Car 컨테이너를 같은 서비스 내에 두는 것은 흔한 패턴이다
> 이런 같이 띄워지는 컨테이너 간에 데이터 공유가 필요하다면, 데이터 볼륨을 두 컨테이너 모두에 마운트 한다 (Bind Mount) - Fargate, EC2 모두 만족
> App Container 에서 이 공유공간의 /var/logs 에 로그나 주의점들을 기록한다
> Metrics & Logs Container (Sidecar) 에서는 이 공유 스토리지로부터 읽어올 수 있다.
> EC2 타입일 경우 EC2 인스턴스 스토리지 자체가 바인드 탑재임 - EC2 인스턴스 lifecycle 동안에는 데이터가 연결이 되어 있음
> Fargate Task - Ephemeral Storgate (임시 스토리지) 를 사용함. - 그들을 사용하는 컨테이너의 lifecycle 동안 에 데이터가 연결이 됨
>> Fargate 같은 경우 이 Storage 가 20GB ~ 200 GB 까지의 용량 설정이 가능함
Bind Mount Use Case
> 위처럼 Multiple Container 간 Data 를 공유할 때
> SIdecar Container 패턴을 사용할 때 ("Sidecar Container" 를 사용해 집계하는 metric/log 를 다른 목적지로 읽어서 보내는 역할) - Separation of Concern
176강 - <ECS 태스크 정의 실습>
> 태스크 정의도 선언적 방식이다. 선언을 하고 싫행하면 Cluster 서비스가 이를 맞추기 위해 따라감
> ECS 이동 > Task 정의 이동
> 참고로 Fargate 을 하면 Network 모드가 awsvpc 뿐이지만, EC2 모드를 하면 더 고급 네트워크를 사용해 설계할 수 있다
> Task Role 은 매우 중요, AWS 리소스들과 소통할 수 있게끔 Task 를 만들어줌 (IAM Role, 너가 원하는대로 설계해야함) - 시험에서 꽤 많이 나오기도 함
> Task Execution Role 은 IAM role 이며, Container Agent 가 AWS API 요청을 대신하게 해준다 - ECS 표준 역할에 가까워서 따로 제어는 잘 안하는 듯
> Container 은 여러개 할 수 있고, 최소 하나는 Essential Container 여야 한다
> Essential Container 가 실패/종료가 발생한다면 다른 컨테이너 및 작업들은 모두 종료된다
> Private Registry ARN 으로 인증만 해준다면, 원하는 이미지를 Private Registry 에서 가져올 수 있다
> 컨테이너 포트를 명시할 수 있고, 앱이 여러개의 포트를 사용할 것이라면 여러개 포트를 연결할 수 있다
> 여러 컨테이너가 함께 기동된다면, CPU, Memory 할당 수준을 제한하는 것도 좋은 설계 포인트라고 한다
> 환경변수
>> Key / Value Foo / Bar 처럼 직접 HardCoding 해서 환경 변수를 넣어줄 수 있다
>> Key 를 SECRET_DB_PW 같은걸로 설정 (저장한 곳에서 지정한 키겠지?) 한 후, ValueFrom 으로 하고 내가 이걸 가져오길 원하는 리소스의 ARN 을 Value 로 적어주면 됨
>> 그러면 위에서 배웠듯이 해당 리소스로부터 환경변수를 읽어오게 된다 (Secret Manager, SSM Param Store 등)
>> Add From File 을 할 수도 있는데, 이 File 은 S3 에 호스팅되고 있는 파일이여야 하고, 그 파일의 위치를 적어주면 된다
> Logging
> Log Collection 으로 진행되며, CloudWatch / Splunk / AWS FireLens/ KinesisStream 등등 많은 곳으로 보낼 수 있다
> 필수 로그값들과 원하는 로그값들을 더 추가해서 구성할 수 있다
> Health Check > 원한다면 컨테이너 상태 검사를 지속 실시하게 구성할 수 있다
> Container Timeout > Start : x 초 안에 시작되지 않으면 컨테이너 종료 // > Stop : 정상적인 종료 x 초 전에 미리 종료
> 컨테이너들은 더 넣어줄 수 있다
> Storage 설정 : 컨테이너에게 더 설정을 해줄 수 있음 (Bind Mount / EFS 등)
> Data 를 어떤식으로 Mount 하고 관리할지 등에 대해서 지정 (Mount 하고 싶은 Path 도 지정)
> monitoring - 이 설정은 자동으로 SideCar 컨테이너를 띄워서 활용된다 (이거 맞나? ㅋㅋ맞는듯) - SideCar 를 추가할 수 있도록 CPU / Memory 가 조정된다고 한다
>> Trace Collection : AWS Distro for open telemetry 라는 사이드카를 통해 데이터를 AWS X-Ray 로 보낼 수 있다
>> Metric Collection : AWS Distro for open telemetry 라는 사이드카를 역시 ECS가 띄운다. Application Metric 을 CLoudWatch 혹은 Amazon Managed Service for Prometheus 로 보낸다 (이런게 뭔지는 난 잘 모름.. 데이터 가지고 하는 일쪽은..)
177강 - <ECS 태스크 배치 - 시험에서 중요> - EC2 Launcy Type 에만 해당하는 내용
> EC2 Launch Type 일 경우, ECS 는 실행한다고 하는 Task 를 어디에 배치할지 결정해야 한다 (ㅈㄴ k8s 랑 똑같음. 근데 어디가 먼저였을까?)
> CPU, Memory, 가용한 Port 등에 따라서 바뀜
> 동일하게, ECS 서비스가 스케일 IN 을 할 때, 어떤 태스크를 종료해야 할지도 유사한 측면에서의 결정이다
> 이를 위해 Task Placement Strategy 와 Task Placement Constraints 가 존재한다 > 이 두 기능을 토대로 Task 가 어디에 추가되거나/삭제되어야 하는지 판단할 수 있다
> Fargate 은 AWS 가 다 알아서 해주니까 상관 없다. EC2 Launcy Type 일 경우에 사용하는 것
<ECS 태스크 배치 과정>
1. 태스크 정의상 해당 태스크가 요구하는 CPU / Memory / Port 요구사항을 수용할 수 있는 EC2 인스턴스를 식별한다
2. Task Placement Constraints 를 확인한다
3. Task Placement Strategy 를 가장 만족하는 인스턴스를 찾는다
4. 인스턴스를 결정하고 태스크를 배치한다
<Task Placement Strategy>
Binpack
> 이 방식은 생각과는 다르게, 가용한 CPU 와 Memroy 가 가장 "낮은" 인스턴스에 배치하려고 한다
> 런닝중인 인스턴스 자체를 최소화하려고 함 (Cost Saving)
> 좌측 그림과 같은 모습으로 명세를 할 수 있다
> 한 EC2 인스턴스를 최고로 많이 채우려고 하고, 더 이상 그 인스턴스에 넣을 수 없을 때 다른 인스턴스에 넣기 시작
> EC2 인스턴스 활용도를 최대로 끌어올림
Random
> Task 를 Random 하게 배치한다. 위에 예시 명세에서 type 을 random 으로 바꾼다. field 는 없음
> 그냥 정말 Random 이다
Spread
> 원하는 필드를 기반으로 가용중인 Ec2 인스턴스 안에서 분산해서 배치한다
> 필드 예시 : instance ID, ecs:availability-zone, 등등
> 예시로는 위에서 field 를 "attribute:ecs.availability-zone" 으로 바꿨고, type 을 "spread" 로 바꿨다
> 이 항목으로 설정하게 되면 인스턴스 AZ 를 기준으로 계속 Spread 해서 배치를 하게 된다 (각 인스턴스의 CPU, Memory 는 크게 신경 안쓰는듯)
> 이 태스크 Strategy 들은 섞여서 ㅏ용될 수도 있다
> spread/az 에다가 spread/instanceID 를 합쳐서 사용할 수도 있고
> spread/az 에다가 binpack/memory 를 합쳐서 사용할 수도 있다
> 시험에는 그냥 세가지의 차이에 ㅐ해 보통 물어본다
<Task Placement Constraints>- 역시 제약 명시하는 방법 JSON 조금씩 적어두기
> 태스크가 배치되는 방식을 제한하는 방법을 명세한다
DistinctInstance
> 태스크 정의에 따라 서비스가 배포를 할 때 각 태스크들이 서로 다른 인스턴스에 배치되도록 하는 제약
> 동일 인스턴스에 두 태스크가 존재할 수는 없는 제약
memberOf
> 심화된 적용으로, Cluster Query Language 를 사용하여 staisfy 하는 instance 에 배치한다
> 예시
>> "expression": "attribute:ecs.instance-type =~ t2.*", ...
>> 인스턴스 유형이 t2 인 곳에 배치해야한다는 쿼리를 두는 것.
>> 이 정의서로 배포할 태스크들은 반드시 t2 인 인스턴스에만 배치되어야 ㅏㄴ다는 것.
178 강은 정리하는거
179강 <Amazon ECR (Elastic Container Registry)>
> AWS 에서 Docker image 를 보관/관리하는 솔루션
> 우린 지금까지 Online Repo 를 썼는데 (Docker Hub), 우리 이미지를 Amazon ECR 에서 보관할 수도 있는 것 (Private /Public 하게 가능)
> ECR 은 ECS 와 상호작용하며, 이미지들은 S3에 보관이된다
> EC2 인스턴스에서 ECR Repo 에 있는 Image 를 pull 하고 싶으면, EC2 인스턴스에 IAM Role 이 필요하다
>> ECR 로의 접근은 IAM Role 로 보호된다
> Image Vulnerability Scanning, Versioning, Tags, Image Lifecycle 등을 지원한다고 한다 (lifecycle 은 뭘깡)
> AWS 리소스 중 Docker Image 를 보관한다? 하면 ECR 생각하면 된다
180 강 <ECR 실습>
> AWS CLI 를 사용해서 제어하는 것이 나올 수도 있음
> Login CMD AWS CLI V2
>> aws ecr get-login-password --region {region} | docker login --username AWS --password-stdin {aws_account_id}.dkr.ecr.{region}.amazonaws.com
>> 앞선 명령어의 결과를 다음 명령어의 input 으로 전달하기 때문에, password 를 입력하게 된다 (aws ecr get-login-password 는 ECR 에 로그인 하기 위한 pw 를 출력한다)
> Docker CMD
>> PUSH Image : docker push {aws_account_id}.dkr.ecr.{region}.amazonaws.com/demo:latest
>> PULL Image : docker pull {aws_account_id}.dkr.ecr.{region}.amazonaws.com/demo:latest
> 너의 EC2 인스턴스에서 Docker CMD 가 동작하지 않으면 IAM 권한 확인이 필요하다 (ECR 로부터 가져오라는 명령어들이기 때문)
<찐 실습>
> nginxdemos hello 라는 docker image 를 이전에 활용했었다
> ECS 이동 > 좌측 탭 중 ECR 이동 >> 생성 >> Private 선택 후 Repository 이름에 따라 경로가 주어진다.
> 다 기본 설정으로 둠
> Public 은 모두가 내 ECR Repo 에 접근해서 image 를 pull 할 수 있다
> 내 Repository 로 들어가게 되면 관련 명령어 보기 창을 열어서 조회할 수 있다 (위에 명령어에서 {} emfdl emfdjrka)
> 내 컴퓨터에서 실습해보자
$ docker --version 으로 도커 러닝을 확인한다
> AWS CLI 는 설치된 상태여야 한다
$ aws ecr get-login-password --region ap-northeast-2 | docker login --username AWS --password-stdin 627662074775.dkr.ecr.ap-northeast-2.amazonaws.com
(내가 위에서 만든 private repo 에 명령어를 그대로 사용할 수 있다
> 뭐 할 이미지가 없기 때문에, nginxdemos/hello 를 공용 Docker Hub 에서 불러와서 업데이트를 할 것이다
> 원래는 뭐 내가 BUILD 하려는 Dockerfile BUILD 해서 IMAGE 로 만들면 되는거 (docker build -t)
$ docker pull nginxdemos/hello - 이 이미지 사용, retag 해서 올려볼 것임
$ docker tag nginxdemos/hello:latest 627662074775.dkr.ecr.ap-northeast-2.amazonaws.com/demomooncake:latest > 저 경로가 진짜 중요함. 저 "/" 가 붙음으로써 앞에 있는 Hub 에 있다는 뜻이 된다. 내가 docker push, pull 을 할 때 어디서 가져오라는 명령어가 없는데, 저 앞에 있는 PATH 가 바로 그 ORIGIN 이 된다
$ docker push 627662074775.dkr.ecr.ap-northeast-2.amazonaws.com/demomooncake:latest >> 내가 로컬에서 작업해서 만든 demomooncake 이란 이미지를 앞에 붙인 origin (위에서 만든 private ecr) 에 올리라는 뜻
> 접근 실패 뜨면 ECR 에 접근할 수 있는 권한이 없다는 뜻
> 근데 궁금한건, 일단 지금 상황이 로컬인건지 아니면 앞선 예처럼 EC2 인건지? 로컬이면 ECR 접근 IAM Role 을 가지고 있는 계정으로 AWS SDK 로 로그인 한 상태여야 하는건지?
> 그리고 AWS CLI 를 이용해 기본적으로 AWS 에 로그인을 먼저 해야 하는게 맞는건지? 아니면 그냥 아무나 aws ecr get-login-apssword region {region} 을 하면 다 이 PW 를 가져올 수 있는건지?
> 그리고 내가 docker login 한 공간이 내 private registriy 같은데, 이 떄 AWS 의 계정으로 로그인을 하는 것 같다. 그냥 ECR 리소스를 사용하기 위해 region 별 공용인 계정으로 접근하는 것?
> 계정 / 권한 부분이 좀 헷갈림
181 강 <AWS CoPilot>
> 운영 준비된 컨테이너화된 앱을 Build / Release / Operate 하는데 도움을 주는 CLI 툴
> AppRunner / Ecs / Fargate 로 앱을 실행할 때의 어려움을 없애기 위해 사용 (CLI Tool 만을 사용해서 해당 환경에 배포를 지원)
> 인프라를 세팅하는 것보다 앱을 만드는데 집중할 수 있게 한다
> 그러면 복잡한 인프라를 (ECS, VPC, ELB, ECR 등) 코파일럿이 준비해준다
> CodePipeline 을 과 통합해서 Automated Deployment 를 형성할 수 있다
> 다양한 환경에 배포할 수 있고, 문제 해결, 로깅, 상태 검사 등도 수행할 수 있다
> MSA 스타일로 개발 -> Copilot 사용 > 잘 설계된 인프라가 셋업되는데 - ECS, Fargate, App Runner 로 셋업되어 배포할 수 있음
182강 <AWS Copilot 실습 > - 좀 복잡했음
> 돈드니까 안해도 됨
> Cloud 9 을 열어 DemoCloud9 을 만든다. (Cloud9 은 Cloud IDE 로, Docker 도 제어할 수 있는 CLI 를 제공해줘서 사용한다)
> EC2 instance 를 활용하고, t2.micro, , 접근은 SSH 가 아닌 SSM 을 사용하도록 만든다
> CMD 창으로 들어가서 Copilot CLI 를 설치한다
$ curl -Lo copilot https://github.com/aws/copilot-cl
$ copilot --version
> 도커 설치되어 있어야함
$ git clone https://github.com/aws-samples/aws-copilot-sample-service example
> 이 샘플 안에 Dockerfile 이 있고, nginx 이미지를 사용하며, index.html 도 가지고 있다
$ copilot init 을 패키지 안에서 실행한다 > 준비하는 명령어
> 이렇게 실행하면 되는데, 이름을 설정할 수 있고, 친절하게 앱이 어떤 형태인지 물어본다 (Scheduled Job, Web Service, Load Balanced Web Service, Backend API Service 등등) > 각각에 적합한 아키텍쳐 형태도 묶여 있다
> 사용할 Dockerfile 선택하고, 셋업이 실행된다 (Dockerfile 안에 있는 내용도 다 한번 확인차 보여준다)
> CloudFormation 으로 이동한다 > CREATE_IN_PROGRESS 가 떠있다
> 완료되면 내가 설정한 이름으로 폴더를 만들고,manifest.yml 을 만들었다. > 이름, type, http root path, image, CPU, Memory, 등등이 포함되어 있고, 여기서 수정을 해도 된다
> 이제는 준비한 애플리케이션을 위한 환경을 만들 것이다.
$ copilot env init --name production --profile default --app copilot-guide (default 프로필은 Cloud9 에 있는 기본 자격 증명을 사용한단 뜻, 앱 이름은 copilot-guide 라고 한다)
> 그럼 무슨 경로를 만들라고 함
$ touch /home/ec2-user/.aws/config 를 해서 파일을 만들어 두고 위 명령어를 다시 실행한다
> 기본 제공 환경을 알려주고, 이대로 하고 싶냐고 물어봄
> 진행하면 그대로 인프라를 SU 해준다
> 이젠 앱을 프로비저닝 해야한다. SU 된 인프라에 내가 준비한 앱을 띄우는 것이다
$ copilot env deploy --name production 을 실행한다
> Cloud9 의 제약 때문에 Client Token ID 오류를 확인할 수 있음 > 자격증명을 생성해야 한다고함.. 좀 복잡
> Preference 로 가서 AWS Setting 으로 가서 Credential 을 해제한다
> IAM 으로 간다 > User 로 등러가서, User 을 만든다 > 이 때, admin 권한을 준다. > 이 유저의 Security Credential 로 이동해, CLI 를 위한 ACcess Key 를 생성한다 > 그러면 AK 랑 SK 를 준다.
> 다시 Cloud9 으로 돌아와서 aws configure 을 입력후 위에서 얻은 AK, SK 를 입력해서 Cloud9 이 copilot 이 SU 해준 인프라에 앱을 띄울 수 있기 충분한 권한을 준다 > 이 때 DefaultRegion 도 명세해준다 ex) eu-central-1, output format 은 json 으로 해준다
> 아까 저 env deploy 를 수행한다
> 이젠 제대로 만들어 줄 수 있다. 이 과정에서 Gate way 연결, Subnet 연결 DNS 연결, VPC 연결 등 많은 작업을 해준다. (ECS 클러스터 형성 및 서비스 형성, security group 자동화 등등)
> ECS 로 이동하면 Cluster 가 형성되어 있는것을 알 수 있다 그리고 $ copilot deploy 를 마지막으로 수행하면 docker build 후 push img to ECR 을 한 다음에 Service 가 ECR 로부터 Pull 해오고, Container 를 띄우는 과정을 확인할 수 있다.
> 이 떄 Load Balancer 등등 라우팅까지 다 준비해준다. AWS 들어가서 리소스들을 보면 다 확인할 수 있음.
> 제일 처음에 만든 manifest 선언서가 중요함. 이건 내가 어떤 서버 스펙을 원하는지 상세히 조절할 수 있기 때문임
모든 것을 제거하려면
$ copilot app delete 를 하면 된다
> 그리고 아까 만든 User 를 삭제해준다
> 그리고 아까 만든 Cloud9 을 삭제해준다
183강 - Amazon EKS
> EKS - Kubernetes Service > 관리될 수 있는 K8s 클러스터를 AWS 를 통해 띄우는 서비스
> K8s 는 말 안해도 뭔지 알지? 컨테이너 시스템을 관리 / 스케일링 / 배포하기 위한 시스템
> ECS 와 유사하지만 다른 API 를 사용한다.
> EKS 는 두 개의 시작 모드를 지원
>> EC2 모드 > 직접 제어하는 노드를 Worker Node 로 띄우고 싶다
>> Fargate 모드 > 서버리스로 컨테이너 앱 측만 관여 하고 싶다
> Use Case : 온 프레미스로 K8s 를 이미 쓰고 있거나 다른 클라우드에서 쓰고 있는데, AWS using K8s 로 이전하고 싶을 때
> 혹은 AWS 를 사용해 그들의 K8s 클러스터를 관리하거나, K8s API 만을 사용하고 싶을때(?)
> 시험 관점에서 K8s 는 Cloud-agnostic 하다 (클라우드와 관계없이 적용가능한, AWS, Gcloud, Azure 등) > Migration 역시 가능
> EKS 워커 노드들을 만들고, EKS Pod 들을 만들 수 있다.
> 이 노드들 역시 Auto Scaling GRoup 으로 관리될 수 있다.
> ECS 처럼 EKS 서비스 (K8s 서비스) 를 외부에 노출하고 싶으면 (원래는 직접 리소스들을 짜서 Service 만들어서 외부에 노출하는걸 제어해야 하지만!) AWS LoadBalancer 를 설정할 수 있다
> Node Types
1-Managed Node Groups :: AWS 가 Node (EC2 인스턴스) 들을 생성/관리해준다
> EKS 서비스 자체에서 관리하는 ASG 그룹의 일부
> On-Demand & Spot Instances 를 지원한다 (이거 뭔소린지 모르겠음)
2-Self Managed Nodes :: 스스로 Node 를 만들고, 직접 EKS 클러스터에 등록하고, ASG로 자신의 노드를 관리한다
> prebuilt AMI 사용 - Amazon EKS Optimized AMI 를 사용할 수 있어서 시간을 절약할 수 있다. (AMI 가 뭐더라?)
> 물론 스스로 AMI 를 만들어도 됨
> On-Demand & Spot Instance 를 지원한다
3- Fargate - 노드라는 것 따위를 관여하기 싫을 때
> 노드에 대한 유지보수가 필요 없음
<Data Volumes >
> EKS 클러스터 정의서에 StorageClass 를 정의해야 한다
> 연동에 직접적으로 자세히 들어가진 않음. 아마 ECS 랑 비슷하겄지
> 이 때 Container Storage Interface (CSI) CSI 호환 드라이버를 활용함 (Leverage 는 활용인듯)
> EKS 와 연동 가능한 볼륨들은 다음과 같다
1. Amazon EBS
2. Amazon EFS (Fargate Mode 와는 무조건 EFS)
3. Amazon FSx for Lustre
4. Amazon FSx for NEtApp ONTAP
이런게 있대..
---------------------
1. 온프레미스 호스팅된 Docker 기반 앱들이 있다. 인프라 따윈 프로비저닝 하지 않고 AWS에서 컨테이너로 하길 원함> ECS Fargate
2. ECS 의 두가지 유형
3. ECS 작업이 S3 버킷에 파일을 업로드하도록 하려는 ECS 클러스터에 호스팅된 앱이 있다. EC2 타입일 때, ECS 작업에 대해 어떤 IAM 역할을 줘야하나? S3 접근 권한을 줘야하니, ECS 에게 줘야함
(ECS Task Role 은 Definition 에 정의되며, 다른 AWS 리소스들과 소통하기 위한 권한을 명세한다)
4. WordPress 컨테이너를 온프레미스에서 AWS 로 이전한다. ECS 에서 실행하는데, 컨테이너가 웹 파일, 이미지, 비디오 등과 같은 동일한 WordPress 웹 사이트 콘텐츠에 엑세스하길 원한다 (?) 어떻게 해야 하나?
>> WordPress 의 콘텐츠를 사용하고 싶다 이거? >> EFS 볼륨 마운트가 정답 : EFS 볼륨은 서로 다른 EC2 인스턴스와 서로 다른 ECS 작업 간에 공유할 수 있습니다. 컨테이너의 영구 다중 AZ 공유 스토리지로 사용할 수 있습니다. (문제를 정확히 이해 못했음..)
5. EC2 타입의 ECS 가 있음. 여기 앱 하나는 Dynamo DB 에 대한 API 호출을 잘 진행한다. S3 에 대한 API 호출을 하는 두번 째 앱을 추가하면 권한 부여 문제가 발생한다 > 다른 태스크 정의서로 다른 태스크 Role 부여가 필요한거 아님? 근데 지금 정의서에 추가하는건 안됨? Task Role 은 한개의 리소스만 접근 가능함? >> 어쨌든 정답은 "새 App 에 대한 IAM 작업 역할 생성"
6. 온프레미스 Docker 앱을 ECS 로 이전중이다. Docker Hub 을 이미지 리포로 사용하고 있는데, 이를 대체할 ECS 와 통합된 서비스는? > ECR
7. ECS 작업에 대해 IAM 역할이 AWS 서비스에 API 요청을 할 수 있도록 하려는 (Classic) ECS 클러스터가 있다. 이는 /etc/ecs/ecs.config 에서 옵션을 활성화해야 하는데? 무엇인가? > Task Role 과 비슷한거지 않을까? // 실습 중에 논의되진 않았지만 ecs.config 의 중요한 설정 중하나다
> 정답 : ECS_ENABLE_TASK_IAM_ROLE 을 활성화한다
8. AWS CodeBuild 로 만든 파이프라인 있음. 빌드시 Docker 이미지 빌드 하고 ECR 에 푸시함. 이 때 빌드가 실패한다 (권한 문제) 왜 그럴까? > 권한 문제 아닐까...
> 정답: AWS CodeBuild 서비스에 대한 IAM 역할 및 권한 다시 확인 (ECR에 대한 모든 권한 문제는 IAM 권한 때문일 가능성이 큽니다. CodeBuild 서비스에는 Docker 이미지를 ECR 리포지토리로 푸시하는 데 필요한 권한이 있어야 합니다.) > 푸시가 아니라 빌드할 때라며... 빌드 실패는 아마 코드를 땡겨오는게 실패하는거일테니 CodeBuild 와 CodePipeline 간의 권한 문제인듯 (둘이 어떻게 동작하는지 모르곘어서 어느쪽의 어느 권한이 문제인지는 잘 모르겠음)
9. EC2 인스턴스로 앱 여러개 실행, LB 로 노출. EC2 인스턴스에서 ㄱㄱ 하면 되니까, ALB + ECS (Benstalk 은 다음강에 ㅏ옴)
10. ECS 에서 실행하려는 이미지가 ECR 레포에 있음. 동일한 EC2 컨테이너 인스턴스에서 두 복사본 시작. 두번째가 실행 안됨. EC2 컨테이너에는 CPU RAM 충분. 왜 안될까 ?? >Host Port 가 정의되어서, 중복되어서 안됨 >> 아 이거때문에 랜덤으로 하라는 거였던거임? ㅋㅋㅋ ALB 연동하면 알아서 매핑해주니까? (해설: 임의의 호스트 포트를 활성화하려면 호스트 포트 = 0(또는 비어 있음)으로 설정하여 동일한 유형의 여러 컨테이너를 동일한 EC2 컨테이너 인스턴스에서 시작할 수 있습니다.)
11. 새로 시작된 EC2 컨테이너 인스턴스는 ECS 클러스터에 등록할 수 없다. 이유 중 아닌 것? > 이거 개틀려버림. 잘 모르겠음..
12. Private ECR 레포에서 Docker pull 을 하려고 함. 사용할 수 있는 명령어는? 2번 같음. 아까 막 개인 AK 이런걸 쓰진 않았던 것 같음 > 1, 2 둘다 아님. 개썅. 정답 이거래 (하긴 AWS 명령어로 비번 가져와서 로그인하고 그랬긴 했다..)
$(aws ecr get-login --no-include-email)
docker pull $ECR_IMAGE_URL
13. ECS 클러스터에 4개의 ECS 서비스. ECS 서비스들은 AWS 서비스와 다양한 상호작용. 모범 사례는?
> 각각 필요한걸 Task Definition 에 Task Role 정의해서 묶어서 부여 ㅇㅇ
14. 가장 비용 효율적인 ECS 작업 배치 전략은? 하나를 조지는거 - 빈팩
15. 각 ECS 작업을 다른 EC2 컨테이너 인스턴스에 배치할 수 ㅣㅆ는 ECS Task 배치 제약은 뭔가? (각각에 대해서 복기하기)
> distinctInstance >>
> memberOf >>
끝!
====================================================================================
교육 출처
- AWS Certified Developer Associate 시험 대비 강의 - Udemy
'웹 운영 > AWS' 카테고리의 다른 글
| [CDA] 섹션 19 - AWS 통합 및 메시징: SQS, SNS (0) | 2024.07.21 |
|---|---|
| [CDA] 섹션 18 - AWS CloudFormation (0) | 2024.07.17 |
| [CDA] 섹션 17 - AWS Elastic Beanstalk (0) | 2024.07.15 |
| [CDA] 섹션 15 - CloudFront (0) | 2024.07.09 |
| [CDA] 섹션 14 - Amazon S3 보안 (0) | 2024.07.08 |
