컨테이너(docker)
- 도커: 컨테이너 기술을 통해 앱 배포 서비스
표준화된 컨테이너에 앱이 패키징되어 다양한 운영체제에서 빠르게 실행 환경 제공
사용 사례)
- 마이크로서비스 아키텍처
- 온프레미스에서 클라우드로 앱을 lift-and-shift - 도커의 OS 작동
- 1) 서버에서 도커 에이전트를 실행
- 2) 도커 컨테이너는 여러 언어의 애플리케이션을 포함
- 3) 서버 관점에서는 모두 도커 컨테이너이다.
- 도커 이미지
도커 이미지는 도커 레포지토리에 저장된다.- 도커 허브
public 레포지토리
-> 여러 기술의 기본 이미지를 찾을 수 있다.(ubuntu, MySQL등등) - Amazon ECR(Amazon Elastic Container Registry)
- private repository
-> 비공개 이미지 실행 - Amazon ECR Public Gallery
퍼블릭 레포지토리 옵션
- private repository
- 도커 허브
Docker vs VM
- EC2와 같은 가상 머신
- 하이퍼바이저에 실행되는 가상 머신들
- Amazon이 EC2 인스턴스를 다양한 소비자에게 제공 가능하고
- 가상 머신의 인스턴스는 각자 분리되어 있다.
-> 리소스 공유 X
- 도커
- 도커 데몬 위에 많은 컨테이너 실행
- 리소스가 호스트와 공유되어 한 서버에서 다수의 컨테이너를 공유할 수 있다.
-> 네트워킹, 데이터 등 공유 가능 - 가상머신보다 덜 안전하지만 하나의 서버에 많은 컨테이너 실행 가능
도커 시작하기
- 도커 파일
도커 컨테이너를 구성하는 파일
기본 도커 이미지에 몇 가지 파일을 추가해 구축하면 도커 이미지 생성. - 도커 이미지 푸시
도커 이미지푸시로 도커 리포지토리에 저장
-> 도커 허브에 푸시하거나, ECR에 푸시 - 필요할떄 도커 이미지를 풀
이미지 풀로 도커 이미지를 실행시 도커 컨테이너 생성됨.
-> 도커 구축할때 사용했던 코드 실행
AWS의 도커 컨테이너 관리
- Amazon ECS(Elastic Container Service)
도커 관리를 위한 아마존의 전용 플렛폼 - Amazon EKS(Elastic Kubernetes Service)
k8s의 관리형 버전(오픈소스 프로젝트) - AWS Fargate
아마존의 서버리스 컨테이너 플렛폼
ECS와 EKS 둘 다 함께 작동할 수 있다. - Amazon ECR(Elastic Container Registry)
컨테이너 이미지 저장 공간.
ECS(Elastic Container Service)
EC2 시작 유형
- AWS에서 컨테이너를 실행
-> ECS 클러스터에 ECS 태스크 실행 - ECS 클러스터
- EC2 시작 유형을 사용하면 EC2 인스턴스가 들어감.
- EC2 시작 유형으로 ECS 클러스터를 사용하면 인프라를 직접 프로비저닝해야한다.
-> ECS 인스턴스는 각각 ECS 에이전트를 실행해야 하고
-> ECS 에이전트가 각각의 EC2 인스턴스를 ECS 서비스와 지정된 ECS 클러스터에 등록
-> 이후 ECS 태스크를 수행하면 AWS가 컨테이너를 시작 - 즉, 새 도커 컨테이너가 생기면 시간에 따라 EC2 인스턴스에 지정
-> ECS 태스크를 시작하거나 멈추면 자동으로 위치 지정
- EC2 시작 유형으로 ECS 클러스터를 사용하면 인프라를 직접 프로비저닝해야한다.
- EC2 시작 유형을 사용하면 EC2 인스턴스가 들어감.
Fargate 시작 유형
- AWS에 도커 컨테이너 실행
- 인프라 프로비저닝하지 않아도된다.(관리할 ec2 인스턴스가 없음)
-> 서버리스(서버는 있지만 관리하지 않음) - Fargate 유형[v]
- ECS 클러스터가 있는 경우 ECS 태스크 정의를 생성해 AWS가 필요한만큼 자원(CPU,RAM)을 실행해준다.
-> 즉, 새 도커 컨테이너를 실행하면 어디서 실행되는지 알리지 않고 그냥 실행됨.
->작업을 위해 백엔드에 인스턴스가 생성될 필요도 없음 - 확장하려면 태스크 수만 늘려주면 된다.
- ECS 클러스터가 있는 경우 ECS 태스크 정의를 생성해 AWS가 필요한만큼 자원(CPU,RAM)을 실행해준다.
ECS 태스크의 IAM 역할
EC2 인스턴스 프로파일 역할과 ECS 태스크 역할의 차이점 [v]
- EC2 시작 유형
- EC2 인스턴스 프로파일
(ㄱ) 인스턴스가 도커에 ECS 에이전트를 실행한다.
(ㄴ) EC2 인스턴스 프로파일 생성되고(ECS 에이전트만이 EC2 인스턴스 프로파일을 사용)
(ㄷ) 그 인스턴스 프로파일을 이용해 API를 호출
(ㄹ) 인스턴스가 저장된 ECS 서비스가 CloudWatch 로그에 API 호출을 해 컨테이너에 로그를 보냄
(ㅁ) 그러면 ECR로부터 도커 이미지를 가져온다.
(ㅂ) Secret Manager이나 SSM Parameter Store에서 민감한 데이터를 참고하기도 함. - ECS 태스크 역할(EC2,Fargate 시작유형 모두 해당)
(ㄱ) 태스크 마다 각각의 특정 역할을 만들 수 있다.
(ㄴ) 역할이 각자 다른 ECS서비스에 연결할 수 있도록 역할을 다르게 설정한다.
ex) 태스크 A 역할은 S3 API를 가져오게 설정
태스크 B는 DynamoDB에 API 호출하도록 설정
(ㄷ) ECS 서비스의 태스크 정의에서 태스크의 역할을 정의한다.
- EC2 인스턴스 프로파일
ECS - 로드 밸런서 통합
EC2 시작 유형과 Fargate 시작 유형 동일
- ECS 클러스터 안에 여러 ECS 태스크들이 실행중
- HTTP나 HTTPS 엔드 포인트로 태스크를 활용하기 위해 ALB를 앞에서 실행하면 모든 사용자가 ABL 및 백엔드의 ECS 태스크에 직접 연결된다. - ALB는 대부분의 사용 사례를 지원한다.
- NLB는 처리량이 많거나 높은 성능을 요구할때만 권장한다.
- 구세대 ELB는 사용할 수 있지만 권장하지 않음.
ELB는 Fargate에 연결할 수 없음.
ECS - 데이터 볼륨(EFS)
- ECS 클러스터에 EC2 인스턴스와 Fargate 시작 유형 모두 구현되어있는 상태
- EC2 태스크에 파일 시스템을 마운트해 데이터를 공유하려 한다.(이때 EFS 파일 시스템을 사용)
- 네트워크 파일시스템이라 EC2/Fargate 유형 모두 호환되고 EC2 태스크에 파일 시스템을 직접 마운트할 수 있다.
- 어느 AZ에 실행되는 태스크든 EFS에 연결되어 있다면 데이터를 공유할 수 있다.
파일 시스템을 통해 다른 태스크와 연결할 수 있다.
따라서 Fargate + EFS로 서버리스 방식이 가장 좋다.(Fargate,EFS 모두 서버리스이다.)
-> ECS 태스크를 실행하고, 파일 시스템 지속성을 위해 EFS를 사용하는 방식이 가장 좋다.
-> 서버리스이기 때문에 서버를 관리할 필요가 없고 미리 비용을 지불한다.(미리 프로비저닝하기만 하면 바로 사용 가능.)
- 사용 사례
EFS와 ECS를 함께 사용해 다중 AZ가 공유하는 컨테이너의 영구 스토리지 - 알아두어야 할 점.
S3는 ECS 태스크에 파일 시스템으로 마운트될 수 없다.
ECS - 실습(ECS 클러스터 생성)
[참고] 인프라 옵션
1) AWS Fargate(서버리스)
- AWS에 컨테이너를 제공하도록 허용 -> 사용자가 원할 때 컨테이너들을 운영
- AWS가 대신 계산해주고 서버 관리 필요없음.
- 단, 과정을 직접 보지 못한다.
2) Amazon EC2 instances
- 컨테이너를 운영하기 위한 계산을 위해 사용자의 인스턴스를 제공
3) External instances using ECS Anywhere
- 자신의 데이터 센터를 이용해 그 위에 ECS 컨테이너를 운영하는 옵션
* ECS 콘솔 > 클러스터 생성 > 이름, 인프라 옵션(Fargate, EC2 인스턴스, 외부 인스턴스) 선택(Fargate, EC2 인스턴스) > [EC2 인스턴스] - 새로운 ASG 생성(리눅스,t2.micro,나머지 기본값) > [네트워크 세팅] - VPC 설정, 서브넷, 보안 그룹 설정 > 생성
* Auto Scaling Groups 콘솔 > 생성된 ASG 선택해 설정 확인
* ECS 콘솔 > 인프라 탭 > 3개의 용량 제공자 확인
[참고] 용량 제공자
- FARGATE: ECS 클러스터에 Fargate tasks를 보낼 수 있다.
- FARGATE_SPOT: Fargate tasks를 spot mode 상태(spot 인스턴스)로 보낼 수 있다.
- ASG Provider: ASG를 통해 EC2 인스턴스를 바로 이 클러스터로 보낼 수 있다.
* 동작 과정
- 인스턴스가 생성되면, 스스로 DemoCluster 안에 자신을 등록한다.
- 등록이 되면 Container Instances 창에서 확인 가능
즉, ECS task를 생성하면 Fargate로 보내지거나,
Fargate spot 또는 ASG의 일부로 보낸 컨테이너 인스턴스에 보내진다.
ECS - 실습(ECS 서비스 생성)
도커 허브에 있는 nginxdemos/hello 사용
-
- task definition(작업 정의하기)
작업 정의하기 메뉴 > 새로운 작업 정의 생성 > 이름(ex: nginxdemos-hello) > 인프라 요구사항(여기선 AWS Fargate만 체크), 작업 사이즈 최소로 설정, 작업 룰(task에 부여할 IAM 역할 - AWS 서비스로 API 요청시 사용(컨테이너들이 AWS를 사용해야 할 때), 여기선 사용 x), 나머지 기본값으로 설정 > 컨테이너 - 1(이름: nginxdemos-hello, 이미지 URL: nginxdemos/hello 필수 컨테이너: YES), 나머지 기본값 > 스토리지(기본값으로 설정) > 생성
- task definition(작업 정의하기)
-
- task definition을 서비스로 시작하기
클러스터 메뉴 > DemoCluster 들어가기 > Services 탭에서 생성 > 컴퓨팅 옵션 - Launch type, 타입 - FARGATE, 플랫폼 버전 - 최신 > 애플리케이션 타입 - 서비스, Family - nginxdemos-hello , Revision - 최신 버전 , 서비스 이름 - nginxdemos-hello, 나머지 기본값 > 네트워킹, VPC,서브넷 설정, 보안 그룹(HTTP) , public ip - 활성화 > 로드밸런서 ALB 선택, ALB 생성(DemoALBForECS, 나머지 기본값 , Target group name: tg-nginxdemos-hello > 생성
- task definition을 서비스로 시작하기
[참고] 애플리케이션 타입
1) 서비스: 웹 서비스
2) task: 완료되면 종료되는 작업(ex: batch job)
-
- 생성된 서비스, Target 그룹, 로드밸런서 확인
로드 밸런서 콘솔 > 생성된 로드밸런서의 DNS로 접속 > nginx 페이지 확인
클러스터로 여러 정보 확인 가능.
- 생성된 서비스, Target 그룹, 로드밸런서 확인
-
- Fargate로 task 더 시작하기
클러스터 콘솔 > 작업 탭 > 서비스 업데이트 클릭 > desired tasks (1 -> 3) > 수정
그러면 Fargate 엔진에서 프로비전되어 3개의 task 생성
-> 새로고침하면서 IP 주소 변화를 확인하기(ALB가 ECS에 있는 컨테이너를 로드 밸런싱)
-> desired tasks를 0으로 하면 서비스는 있지만 컨테이너/인스턴스는 없는상태로 돌릴 수 있다.
- Fargate로 task 더 시작하기
ECS Auto Scaling
-
확장 가능한 지표
1) ECS 서비스의 CPU 사용률
2) 메모리 사용률
3) ALB 관련 지표(타겟당 요청 수를 확장) -
스케일링 종류
- 대상 추적(Target Tracking) 스케일링
특정 타겟 추적 스케일링 - 단계(step) 스케일링
- 예약(Scheduled) 스케일링
미리 ECS 서비스 확장을 설정
- 대상 추적(Target Tracking) 스케일링
-
태스크 레벨에서의 ECS 서비스 확장 != EC2 인스턴스 레벨에서의 EC2 서비스 확장
-
EC2 오토 스케일링이 필요하지 않다면(백엔드에 EC2 인스턴스가 없다면) Fargate사용이 오토 스케일링에 도움이 된다.
서버리스 이기 때문
EC2 Launch Type - EC2 인스턴스 오토스케일링
- 백엔드의 EC2 인스턴스 자동 확장 방법
- 1) 오토 스케일링 그룹(ASG)
- CPU 사용률에 따라 ASG를 확장
- 2) ECS 클러스터 용량 제공자(Capacity Provider) 사용 [권장]
- 새 태스크를 실행할 용량이 부족하면 용량 제공자가 자동으로 확장
- 용량 제공자는 ASG와 함께 사용되고, RAM이나 CPU가 부족할때 EC2 인스턴스 확장
- 1) 오토 스케일링 그룹(ASG)
ECS 솔루션 아키텍처
- 1) EventBridge에 의해 호출된 ECS 태스크
- 2) EventBridge Schedule에 의해 호출된 ECS 태스크
- 3) SQS Queue
- 4) EventBridge에 의해 중지된 작업 차단
ECS 클러스터에서 나가거나 시작되는 모든 태스크는 EventBridge에서 이벤트로서 트리거 될 수 있다.
SNS 토픽으로 경보하거나 관리자에게 이메일을 전송할 수 있다.
Amazon ECR(Elastie Container Registry)
- AWS에 도커 이미지를 저장하고 관리에 사용
도커 허브 외에도 ECR에 저장할 수 있다. - ECR 옵션
- 1) 계정에 한해 이미지를 비공개로 저장
여러 계정으로 설정할 수 있다. - 2) 퍼블릭 저장소를 사용
Amazon ECR Public Gallery에 게시
- 1) 계정에 한해 이미지를 비공개로 저장
- ECR은 ECS와 완전히 통합되어 있다.
이미지는 백그라운드에서 S3에 저장된다. - ECR 이미지 끌어오기
ECR에 이미지가 저장되어있고, ECS 클러스터안에 EC2 인스턴스가 있을때
EC2 인스턴스에 IAM 역할을 지정해 도커 이미지를 인스턴스에 끌어오게 함.
-> ECR에 대한 모든 접근은 IAM이 보호하고 있음.
EC2 인스턴스에 이미지를 끌어온 후에는 컨테이너가 시작된다.
- ECR은 단순 저장소 외의 기능들
- 이미지 취약점 스캐닝
- 버저닝
- 태그
- 수명 주기 확인
Amazon EKS(Elastic Kubernetes Service)
- AWS에 관리형 k8s 클러스터를 실행할 수 있다.
[참고] k8s pods == ECS tasks - k8s?
- 오픈 소스 시스템
- 도커로 컨테이너화한 애플리케이션의 자동 배포, 확장, 관리를 지원.
- 컨테이너 실행의 목적은 ECS와 같이면 사용하는 API가 다르다.
ECS = 오픈소스 x , k8s = 오픈소스, 여러 클라우드 제공자가 사용으로 표준화를 기대
- EKS의 실행 모드
- 1) EC2 시작 모드
EC2 인스턴스처럼 작업자 노드를 배포할 때 사용 - 2) Fargate 모드
EKS 클러스터에 서버리스 컨테이너를 배포할 때 사용
- 1) EC2 시작 모드
- 사용 사례
회사가 온프레미스나 클라우드나 k8s나 k8s API를 사용 중일 때 k8s클러스터를 관리하기 위해 EKS 사용 - k8s는 여러 클라우드에서 지원
Azure, GCP등..
즉, 클라우드 또는 컨테이너 간 마이그레이션을 실행하는 경우 EKS가 솔루션이 될 수 있다.
EKS - 노드 타입
- 1) 관리형 노드 그룹
- AWS로 노드(ec2 인스턴스)를 생성하고 관리
- 노드는 EKS 서비스로 관리되는 오토 스케일링 그룹의 일부이다.
- 온디맨드 인스턴스와 스팟 인스턴스를 지원
- 2) 자체 관리형 노드
- 사용자 지정 사항이 많고 제어 대상이 많은 경우 사용
- 직접 노드를 생성하고, EKS 클러스터에 등록한 후 ASG의 일부로 관리해야 한다.
- 사전 빌드된 AMI인 Amazon EKS 최적화 AMI를 사용하면 시간을 절약한다.
자체 AMI를 빌드해도 상관없지만 복합하다. - 온디맨드 인스턴스와 스팟 인스턴스를 지원한다.
- 3) AWS Fargate
- 노드를 원치 않는 경우 사용
- 유지 관리와 노드 관리가 필요 없다.
- EKS에서 컨테이너만 실행하면 된다.
EKS - 데이터 볼륨
- EKS에 데이터 볼륨을 연결하고 싶다면
- EKS 클러스터에 스토리지 클래스 매니패스트를 지정
- CSI(Container Storage Interface)라는 규격 드라이버 활용[v]
- 지원 목록
- Amazon EBS
- Amazon EFS(Fargate 모드)
- Amazon FSx for Lustre
- Amazon FSx for NetApp ONTAP
EKS - 실습(유료)
-
- EKS 클러스터 생성
이름: DemoEKS
버전: 기본값
서비스 역할: 역할 생성 > AWS 서비스[v], eks - cluster 선택 > 역할 이름: eksClusterRole > 생성 후 서비스역할 eksClusterRole 선택
암호화: KMS 비활성화(보안을위해 나중에 사용)
VPC: 배포할 지역
서브넷: "
보안 그룹: 기본 보안그룹
IP 주소 유형: IPv4
클러스터 엔드포인트 액세스: 퍼블릭 <- 컴퓨터에서 액세스 가능
네트워크 추가 기능: 기본 설정으로 사용
프록시,DNS: 기본 설정
제어 영역 로깅 : 기본 설정
> 정보 확인 후 생성
- EKS 클러스터 생성
-
2-1 관리형 노드 그룹 추가 or Fargate 프로필 생성
EKS 클러스터 > 컴퓨팅 탭 > 노드 그룹 설정 > 노드 그룹 추가
이름: DemoNodeGroup
IAM 역할: EC2 인스턴스용 IAM 역할 생성 후 추가
>> IAM 콘솔 > 역할 생성 > EC2 > "AmazonEKSWorkerNodePolicy", "AmazonEC2ContainerRegistryReadOnly" 선택 > 이름: AmazonEKSNodeRole 설정 후 생성
시작 탬플릿: 비활성화
노드 그룹 유형: 기본값
[참고] 노드 그룹 업데이트 구성
업데이트 시 중단 상태를 용인할 노드 수 설정하는 것
\ > 생성 -
EBS 볼륨을 사용하고자 하는 경우 추가 기능 설치
EKS 클러스터 > Add-ons 탭 > 새로 추가 > Amazon EBS CSI Driver등 필요한 것 선택
[참고] EBS CSI Driver
Amazon EKS 클러스터에서 EBS를 사용할 수 있게 하는 기능
FSx나 EFS등에서 사용할 수 있는 CSI 드라이버도 있다. -
삭제 순서
노드 그룹 삭제 > 클러스터 삭제
AWS App Runner
- 완전 관리형 서비스
- 규모에 따라 웹 애플리케이션과 API 배포를 돕는다.
- 인프라나 컨테이너, 소스 코드 등을 알필요없이 누구나 AWS에 배포 가능하다.
- 방법
- 1) 소스코드나 도커 컨테이너 이미지를 가지고 원하는 구성을 설정한다.
- 2) 다음 작업은 자동으로 이뤄진다.
App Runner 서비스가 웹 앱을 빌드하고 배포
컨테이너 생성되고 배포됨. - 3) API나 웹 앱이 배포된 후 URL을 통해 바로 액세스 가능.
- 장점
- 1) 오토 스케일링 가능
- 2) 가용성이 높다.
- 3) 로드 밸런싱 지원
- 4) 암호화 기능 지원
- 5) 애플리케이션이 VPC에 액세스할 수 있다.
- 6) DB와 캐시, 메시지 대기열 서비스에 연결 가능.
- 사용 사례
- 웹 앱, API, 마이크로서비스를 빨리 배포해야 할때 사용
- 빠른 프로덕션 배포가 필요할 때 사용
AWS App Runner 실습(유료)
vCPU,GB 시간당 비용 지불
- AWS App Runner 서비스 생성
배포 소스: [컨테이너 레지스트리 | 소스코드 레포지토리] -> 컨테이너 선택
제공자: [Amazon ECR | Amazon ECR Public] -> ECR Public 선택
[참고] ECR vs ECR Public
ECR: 인프라 내부 프라이빗 도커 컨테이너
ECR Public: 퍼블릭 이미지 배포
컨테이너 이미지 URI: >> ECR Public Gallery로 들어가 이미지 주소를 복사해 컨테이너 이미지 URI에 붙여넣는다
배포 설정: [수동 | 자동] -> 소스 코드 저장소, Amazon ECR 선택시에만 자동 배포 가능
서비스 이름: DemoHTTP
vCPU & mem: 원하는 만큼
포트: 80
오토 스케일링 구성: 기본 구성 선택
상태 체크: 기본값
나머지 기본값으로 설정
> 확인 후 생성 및 배포 클릭 - 도메인으로 잘 만들어졌는지 확인.
