Docker
- 앱을 배포하기 위한 소프트웨어 개발 플랫폼
- 앱은 컨테이너에 패키지화되어 어떤 운영 체제에서든 실행할 수 있게 됨
- 앱은 실행되는 위치와 관계없이 동일하게 작동됨
- 어떤 기기(머신)에서든 실행 가능
- 호환성 문제 없음
- 예측 가능한 동작
- 작업량 감소
- 유지 및 배포가 쉬움
- 모든 언어, 운영 체제, 기술과 호환됨
- 사용 사례: 마이크로서비스 아키텍처, 온프레미스에서 AWS 클라우드로의 앱 이동 등
Docker on an OS
- 첫 번째 도커 컨테이너는 Java 애플리케이션을 포함, 두 번째 도커 컨테이너에는 Node.js 애플리케이션이 있음.
- 다수의 도커 컨테이너가 동시에 실행될 수 있어서 Java 혹은 Node.js 애플리케이션을 가진 여러 도커 컨테이너가 있을 수 있음.
- 도커 내에서 MySQL 등의 데이터베이스도 실행 가능. 다용도로 활용 가능.
- 서버 관점에서는 모두 도커 컨테이너로 보임!
Where are Docker images stored?
도커에서 이미지는 애플리케이션과 그 실행 환경을 포함하는 패키지이다. 이미지는 컨테이너화된 애플리케이션을 구축하고 배포하기 위해 필요한 모든 파일, 라이브러리, 종속성 및 설정을 포함한다. 이 이미지는 컨테이너의 기반이 되며, 컨테이너를 실행하기 위한 실행 환경을 제공한다.
- 도커 이미지는 도커 리포지토리에 저장됨
- Docker Hub (https://hub.docker.com)
- 퍼블릭 리포지토리
- 다양한 기술 또는 운영 체제에 맞는 기본 이미지를 찾을 수 있음 (ex. Ubuntu, MySQL)
- Amazon ECR (Amazon Elastic Container Registry)
- 프라이빗 리포지토리
- 퍼블릭 리포지토리로도 제공됨 (Amazon ECR Public Gallery https://gallery.ecr.aws)
Docker vs. Virtual Machines
- 도커는 "어떤 의미로는" 가상화 기술이지만 정확히는 아님
- 리소스는 호스트와 공유됨 → 따라서 한 서버에서 다수의 컨테이너를 공유할 수 있음
(왼) 가상 머신 아키텍처 - 인프라, 호스트 운영체제, 하이퍼바이저, 앱, Guest 운영체제가 있음
- 즉 EC2의 원리임. 다시 말해 EC2 머신은 하이퍼바이저에 실행되는 가상 머신과도 같음
- 그래서 Amazon이 EC2 인스턴스를 다양한 소비자에게 제공할 수 있으며 가상 머신의 EC2 인스턴스는 각자 분리되어 있음
- 즉, 리소스를 공유하지 않음
(오) 도커 컨테이너
- 인프라, EC2 인스턴스 같은 호스트 OS, 도커 Daemon 위에 많은 컨테이너가 있음
- 도커 Daemon에서 가볍게 실행되는 컨테이너라 공존할 수 있음
- 네트워킹이나 데이터 등을 공유할 수 있음
- 가상 머신보다 덜 안전하지만 하나의 서버에 많은 컨테이너를 실행할 수 있기 때문에 도커 컨테이너를 많이 사용함
Getting Started with Docker
1.Dockerfile 작성 - 도커 컨테이너를 구성하는 파일 작성
2.도커 이미지 구축 - 작성한 Dockerfile을 사용하여 도커 이미지를 구축. 도커 이미지는 베이스 이미지에 추가 파일 및 설정을 포함하여 생성
3.도커 이미지 Push - 구축한 도커 이미지를 도커 리포지토리(Docker Hub, Amazon ECR 등)에 저장하기 위해 Push
4.도커 이미지 Pull - 도커 리포지토리에서 필요한 이미지를 Pull하여 가져옴
5.도커 컨테이너 실행 - Pull한 도커 이미지를 실행하여 도커 컨테이너로 실행. 이때, 도커 이미지를 구축할 때 사용한 코드와 설정이 실행됨
Docker Containers Management on AWS
- Amazon Elastic Container Service (Amazon ECS): 도커 관리를 위한 Amazon의 전용 플랫폼
- Amazon Elastic Kubernetes Service (Amazon EKS): 쿠버네티스의 관리형 버전 (오픈 소스)
- AWS Fargate: Amazon의 서버리스 컨테이너 플랫폼. ECS, EKS 둘 다 함께 작동할 수 있음
- Amazon ECR: 컨테이너 이미지를 저장하는데 사용
Amazon ECS
- ECS = Elastic Container Service
- ECS 클러스터에서 ECS 태스크를 실행하여 AWS 상에서 Docker 컨테이너를 실행할 수 있음
Launch Type
EC2 Launch Type
- ECS Launch Type으로 ECS 클러스터를 사용할 때는 인프라 (EC2 인스턴스)를 직접 프로비저닝하고 관리해야 함
- 각 EC2 인스턴스는 ECS 에이전트를 실행하여 ECS 클러스터에 등록해야 함
- 컨테이너의 시작과 종료는 AWS가 관리
Fargate LaunchType
- Docker 컨테이너를 AWS에서 실행하는 또 다른 옵션
- 인프라 (EC2 인스턴스)를 직접 프로비저닝하거나 관리할 필요가 없음
- 서버리스 (서버를 관리하지 않기 때문. 서버가 없는 것은 아님)
- 단순히 태스크 정의(Task Definitions)를 생성하기만 하면 됨
- AWS는 CPU 및 RAM 요구 사항에 따라 ECS Task를 자동으로 실행해 줌
- 확장하기 위해서는 단순히 태스크의 수만 늘리면 됨 - EC2 인스턴스를 사용하지 않으므로 훨씬 간단하게 확장할 수 있음
IAM Roles for ECS
EC2 Instance Profile (EC2 Launch Type 전용)
- ECS 에이전트에 의해 사용됨
- ECS 서비스에 API 호출
- 컨테이너 로그를 CloudWatch Logs로 전송
- ECR에서 Docker 이미지를 가져옴
- Secrets Manager나 SSM Parameter Store에 저장된 민감한 데이터를 참조할 수 있음
ECS Task Role
- 각각의 ECS 태스크에 특정 역할을 할당함
- 다른 ECS 서비스에 대해 다른 역할을 사용할 수 있음
- 태스크 정의 (Task definition)에서 태스크 역할 정의
- 컨테이너가 SQS, S3 등 다른 AWS 서비스를 호출하려고 할 때 사용
Load Balancer Integrations
ECS 클러스터 안에서 여러 ECS 태스크들이 실행되고 있다. HTTP나 HTTPS 엔드포인트로 태스크를 활용하기 위해 Application Load Balancer (ALB)를 앞에서 실행하면 모든 사용자가 ALB 및 백엔드의 ECS 태스크에 직접 연결된다.
- 애플리케이션 로드 밸런서 (ALB)는 대부분의 사용 사례를 지원한다
- 네트워크 로드 밸런서 (NBL)는 처리량이 매우 많거나 높은 성능이 요구될 때, 또는 AWS Private Link와 연동할 때 권장됨
- Elastic Load Balancer (ELB)는 지원은 되지만 권장하지 않음 (고급 기능이 없으며 Fargate와 호환되지 않음)
Data Volumes (EFS)
- EFS 파일 시스템을 ECS 태스크에 마운트해서 데이터를 공유
- EC2 Lanch Type과 Fargate Lanch Type 모두 호환됨
- 어떤 가용 영역에서 실행되는 작업이든 EFS 파일 시스템에서 동일한 데이터를 공유함
- Fargate + EFS = Serverless
- 사용 사례: 다중 AZ가 공유하는 컨테이너의 영구 스토리지
참고: Amazon S3는 ECS 태스크에 파일 시스템으로 마운트될 수 없음
ECS Service Auto Scaling
- 원하는 ECS 작업 수를 자동으로 증가/감소
- Amazon ECS Auto Scaling은 AWS Application Auto Scaling을 사용
- ECS 서비스 평균 CPU 사용률
- ECS 서비스 평균 메모리 사용률 - RAM에 대한 스케일링
- ALB에서 나오는 타겟당 요청 수 - ALB에서 제공하는 메트릭
- Target Tracking: 특정 CloudWatch 메트릭의 타켓 값에 따라 스케일링을 수행
- Step Scaling: 지정된 CloudWatch 알람에 따라 스케일링을 수행
- Scheduled Scaling: 지정된 날짜/시간에 따라 스케일링을 수행 (predictable changes)
- ECS Service Auto Scaling (task level) ≠ EC2 Auto Scaling (EC2 instance level)
- EC2 오토 스케일링이 필요하지 않다면 (백엔드에 EC2 인스턴스가 없다면) Fargate를 사용하는 것이 서비스 오토 스케일링에 도움이 됨 (서버리스이기 때문)
EC2 Launch Type – Auto Scaling EC2 Instances
ECS 서비스의 스케일링을 지원하기 위해 기반이 되는 EC2 인스턴스를 추가한다.
- Auto Scaling Group Scaling
- CPU 사용률에 따라 ASG를 기준으로 스케일링
- 시간이 지남에 따라 EC2 인스턴스를 추가
- ECS Cluster Capacity Provider
- ECS 태스크의 인프라를 자동으로 프로비저닝하고 확장함
- 용량 공급자(Capacity Provider)는 Auto Scaling Group과 함께 사용됨
- 용량이 부족한 경우 (CPU, RAM 등) EC2 인스턴스를 추가
ECS Scaling – Service CPU Usage Example
ECS tasks invoked by Event Bridge
ECS tasks invoked by Event Bridge Schedule
ECS – SQS Queue Example
Amazon ECR
- ECR = Elastic Container Registry
- AWS에 도커 이미지를 저장하고 관리하는데 사용됨
- 프라이빗 및 퍼블릭 저장소 (Amazon ECR Public Gallery https://gallery.ecr.aws)
- ECR은 Amazon ECS와 완전히 통합되어 있고 이미지는 백그라운드에서 Amazon S3에 저장됨
- IAM을 통해 액세스 제어 (권한 에러가 생긴다면 정책을 살펴볼 것)
- 이미지 취약점 스캐닝, 버전 관리, 이미지 태그, 이미지 수명 주기 확인 지원
Amazon EKS
- Amazon EKS = Amazon Elastic Kubernetes Service
- AWS에서 관리되는 Kubernetes 클러스터를 실행할 수 있는 서비스
- Kubernetes는 (일반적으로 Docker로 구성된) 컨테이너화된 애플리케이션의 자동 배포, 확장 및 관리를 위한 오픈 소스 시스템
- 컨테이너를 실행한다는 목적은 ECS와 비슷하지만 사용하는 API가 다름
- EKS에는 두 가지 실행 모드가 있다.
- EC2: 워커 노드(worker nodes) 배포
- Fargate: 서버리스 컨테이너 배포
- 사용 사례: 회사가 이미 온프레미스나 다른 클라우드에서 Kubernetes를 사용하고 있으며, Kubernetes를 사용하여 AWS로 마이그레이션하려는 경우
- Kubernetes는 클라우드에 구애받지 않는 기술(cloud-agnostic)이다. (Azure, GCP 등 어떤 클라우드에서도 사용할 수 있음).
- 여러 리전에 대해, 리전 당 하나의 EKS 클러스터를 배포합니다.
- CloudWatch Container Insights를 사용하여 로그 및 메트릭을 수집할 수 있다.
Amazon EKS – Node Types
관리형 노드 그룹
- 노드(EC2 인스턴스)를 생성하고 관리
- 노드는 EKS에서 관리하는 ASG(Auto Scaling Group)의 일부
- 온디맨드 또는 스팟 인스턴스를 지원
자체 관리형 노드
- 사용자가 생성하고 EKS 클러스터에 등록한 노드로, ASG에 의해 관리
- Amazon EKS 최적화된 AMI와 같은 미리 빌드된 AMI를 사용할 수 있음
- 온디맨드 또는 스팟 인스턴스를 지원
AWS Fargate
- 유지 관리가 필요하지 않으며, 노드 관리가 없음
Data Volumes
- EKS 클러스터에 데이터 볼륨을 연결하려면 EKS 클러스터에 스토리지 클래스 매니페스트를 지정해야 함
- 컨테이너 스토리지 인터페이스(CSI) 호환 드라이버를 활용
- Amazon EBS, Amazon EFS (Fargate 모드), Amazon FSx for Lustre, Amazon FSx for NetApp ONTAP 지원
AWS App Runner
- 웹 애플리케이션과 API를 대규모로 배포하기 쉽게 만드는 완전 관리형 서비스
- 인프라 경험이 필요하지 않음
- 소스 코드나 Docker 컨테이너 이미지로 시작함
- 웹 앱을 자동으로 빌드하고 배포함
- 오토 스케일링, 고가용성, 로드 밸런싱, 암호화 기능 지원
- VPC 액세스 지원
- 데이터베이스, 캐시, 메시지 대기열 서비스에 연결 가능
- 사용 사례: 웹 앱, API, 마이크로서비스, 신속한 프로덕션 배포 등
안녕하세요