learnit

ECS (Elastic Container Service)

7 phút đọcSeries: NoteBook: AWS Certified Solutions Architect Associate SAA-C031 lượt xem

Khi bạn chạy một ECS Task, bạn cần chọn "Launch Type" để quyết định nơi và cách nó sẽ được triển khai

EC2 Launch Type

Bạn phải quản lý hạ tầng (EC2), còn AWS ECS chỉ phụ trách điều phối container trên những EC2 đó. Cần chạy ECS Agent trên mỗi máy EC2 để đăng ký chúng vào cụm ECS.

  • ECS = Elastic Container Service (Dịch vụ Container Linh hoạt)
  • Triển khai các Docker container trên AWS = Triển khai các ECS Task trên ECS Cluster
  • EC2 Launch Type: bạn phải tự cung cấp và duy trì cơ sở hạ tầng (tức là các EC2 instance)
  • Mỗi EC2 Instance bắt buộc phải chạy ECS Agent để đăng ký vào ECS Cluster
  • AWS sẽ xử lý việc khởi tạo/dừng container
  • Task là đơn vị triển khai (deployment unit) cơ bản nhất. Nói cách khác, một ECS Task chính là một hoặc nhiều container chạy cùng nhau trên cùng một máy (EC2 hoặc Fargate).)
    • Ví dụ dễ hiểu:
      • Giả sử bạn có một ứng dụng web đơn giản:
        • 1 container backend (Node.js)
        • 1 container sidecar log (Fluent Bit)
      • Bạn sẽ:
        • Định nghĩa 1 Task Definition với 2 container trên.
        • Mỗi lần ECS tạo một Task, nó sẽ chạy 2 container đó cùng nhau.

Giải thích sơ đồ

  • ECS Cluster:
    • Là một tập hợp các EC2 instance có khả năng chạy các container ECS task.
  • EC2 Instance:
    • Là những máy chủ ảo được bạn quản lý. Bạn có trách nhiệm tạo, cấu hình, scale và vá lỗi hệ điều hành.
    • Trên mỗi EC2 instance:
      • Có ECS Agent (trong hình là biểu tượng Docker + ECS Agent).
      • ECS Agent đóng vai trò như một “bridge” để instance đó có thể giao tiếp và nhận task từ ECS Cluster.
  • New Docker Container:
    • Là ECS Task sắp được triển khai. 
    • ECS sẽ lên lịch task này vào một trong các EC2 instance có tài nguyên phù hợp.
  • Quản lý container:
    • Mặc dù bạn tự quản lý EC2, nhưng AWS vẫn chịu trách nhiệm điều phối việc khởi động và dừng các container Docker thông qua ECS scheduler và ECS Agent.

Fargate Launch Type

  • Triển khai Docker container trên AWS
  • Bạn không cần tự provision cơ sở hạ tầng (không phải quản lý EC2 instance)
  • Mọi thứ đều là Serverless!
  • Bạn chỉ cần tạo task definition
  • AWS sẽ tự chạy ECS Task dựa trên cấu hình CPU/RAM bạn yêu cầu
  • Muốn scale, chỉ cần tăng số lượng task — không cần thêm EC2 instance

Giải thích sơ đồ

  • AWS Fargate / ECS Cluster:
    • Bạn không thấy EC2 instances vì hạ tầng được AWS quản lý 100% (serverless).
    • AWS sẽ tự động provision container runtime environment, đảm bảo task chạy ổn định mà bạn không cần can thiệp.
  • New Docker Container:
    • Là ECS Task mới, được AWS triển khai trực tiếp vào môi trường do Fargate quản lý.
    • Không cần ECS Agent:
    • Vì không có EC2 instance riêng của bạn nên không cần cài ECS Agent như EC2 Launch Type.
  • Scale đơn giản:
    • Muốn tăng công suất? Bạn chỉ cần tăng số lượng task — AWS lo phần còn lại.

IAM Roles của ECS

  • EC2 Instance Profile (chỉ áp dụng với EC2 Launch Type):
    • Được ECS agent sử dụng
    • Thực hiện các API call đến ECS service
    • Gửi log container đến CloudWatch Logs
    • Kéo Docker image từ ECR
    • Truy cập các dữ liệu nhạy cảm trong Secrets Manager hoặc SSM Parameter Store
  • 📝 Giải thích kỹ thuật:
    • EC2 Instance Profile là IAM Role gắn với EC2 instance.
    • Role này cấp quyền cho ECS Agent (chạy bên trong EC2 instance) thực hiện các thao tác cần thiết như đăng ký container, gửi log, lấy image...
  • ECS Task Role:
    • Cho phép mỗi task ECS có IAM Role riêng biệt
    • Bạn có thể dùng các IAM Role khác nhau cho từng ECS Task (service)
    • Task Role được định nghĩa trong task definition
  • 📝 Giải thích kỹ thuật:
    • Mỗi ECS Task (ứng với 1 container app/service) có thể yêu cầu quyền riêng — ví dụ:
      • Task A truy cập S3
      • Task B truy cập DynamoDB
    • Việc này tăng tính bảo mật, tránh cấp quyền quá rộng.
Giải thích sơ đồ
  • EC2 Instance:
    • Là compute resource bạn tự quản lý.
    • Chạy ECS Agent để quản lý và điều phối container.
  • EC2 Instance Profile:
    • IAM Role gắn với EC2 instance, phục vụ cho ECS Agent.
    • Kết nối với:
      • ECS: để ECS Agent thao tác với control plane.
      • ECR: để ECS Agent kéo image về chạy.
      • CloudWatch Logs: để gửi log từ container.
  • Task A và Task B:
    • Mỗi task có IAM Role riêng biệt (EC2 Task A Role, EC2 Task B Role)
    • Task A có quyền truy cập S3, Task B có quyền truy cập DynamoDB
    • Tức là, bạn có thể tách quyền theo chức năng từng microservice — đúng chuẩn principle of least privilege.

Tích hợp Load Balancer

  • Application Load Balancer (ALB)
    • Được hỗ trợ đầy đủ và phù hợp với hầu hết các use case.
    • Là lựa chọn khuyến nghị khi triển khai ECS service cần routing HTTP/HTTPS thông minh (theo path, host...).
  • Network Load Balancer (NLB)
    • Chỉ khuyến nghị sử dụng cho các hệ thống:
      • Cần băng thông cao
      • Cần hiệu năng cao, độ trễ thấp
      • Hoặc tích hợp với AWS PrivateLink
  • Classic Load Balancer (CLB)
    • Có hỗ trợ nhưng không được khuyến nghị
    • Thiếu các tính năng hiện đại:
    • Không hỗ trợ routing nâng cao
    • Không hỗ trợ ECS Fargate
Giải thích sơ đồ
  • Người dùng (Users) gửi request HTTP/HTTPS qua cổng 80/443 đến Application Load Balancer
  • ALB sẽ phân phối request đến các container ECS đang chạy trong cụm ECS Cluster
  • Trong sơ đồ:
    • Có 2 EC2 instances đang chạy ECS Tasks
    • Mỗi instance chứa nhiều ECS Task
  • ALB route đến port của container (do bạn khai báo trong ECS Service + Target Group)

Data Volumes (EFS)

  • Gắn hệ thống file EFS vào các ECS Task
  • Hỗ trợ cho cả hai loại khởi tạo EC2 và Fargate
  • Các task chạy ở bất kỳ Availability Zone (AZ) nào đều sẽ chia sẻ chung dữ liệu trong hệ thống file EFS
  • Fargate + EFS = Serverless
  • Trường hợp sử dụng:
    • Lưu trữ dùng chung nhiều AZ, có tính bền vững cho các container
  • Lưu ý: Amazon S3 không thể được mount như một file system
    • Với Amazon EFS, bạn có thể mount vào container và thao tác như ổ đĩa bình thường (/mnt/efs/...).
    • Còn với Amazon S3, nó không phải là một hệ thống file theo POSIX. Nó là object storage, nên:
      • Không có khái niệm thư mục thực sự.
      • Không hỗ trợ thao tác file-level trực tiếp như open(), read(), ls, v.v. trong môi trường OS thông thường.
      • Để truy cập S3, bạn cần gọi API (GetObject, PutObject,...) hoặc dùng SDK.
Giải thích sơ đồ
  • Mount EFS vào ECS Task
    • Cho phép các container trong ECS Task truy cập shared file system giống như ổ đĩa nội bộ.
    • Giúp lưu trữ dữ liệu bền vững (persistent) qua các lần task bị stop hoặc recreate.
  • Multi-AZ sharing
    • Tasks chạy ở bất kỳ Availability Zone (AZ) nào đều có thể truy cập cùng dữ liệu qua EFS.
    • Phù hợp với kiến trúc HA (High Availability).
  • Fargate + EFS = Serverless
    • Bạn không cần quản lý EC2 hay ổ đĩa.
    • Chỉ cần định nghĩa volume trong task definition là có thể mount EFS vào.

ECS Auto Scaling

  • Tự động tăng/giảm số lượng tác vụ (task) ECS mong muốn.
  • Amazon ECS Auto Scaling sử dụng AWS Application Auto Scaling
    • Sử dụng chỉ số: Mức sử dụng CPU trung bình của ECS service
    • Sử dụng chỉ số: Mức sử dụng RAM trung bình của ECS service – Scale dựa trên RAM
    • Sử dụng chỉ số: Số lượng request trên mỗi target từ ALB (Application Load Balancer) – chỉ số đến từ ALB
  • Target Tracking – scale dựa trên giá trị mục tiêu của một metric cụ thể trong CloudWatch
  • Step Scaling – scale dựa trên cảnh báo (Alarm) cụ thể trong CloudWatch
  • Scheduled Scaling – scale dựa trên ngày/giờ được chỉ định (phù hợp với các thay đổi dự đoán trước)
  • ECS Service Auto Scaling (ở cấp task) ≠ EC2 Auto Scaling (ở cấp instance EC2)
    • Một EC2 instance có thể chạy nhiều task, miễn là còn đủ CPU & RAM theo cấu hình trong task definition.
  • Fargate Auto Scaling dễ cấu hình hơn rất nhiều (do không cần server – serverless)

EC2 Launch Type – Auto Scaling EC2 Instances

  • Đáp ứng việc scale ECS Service bằng cách thêm EC2 instance ở tầng hạ tầng.
  • Auto Scaling Group Scaling
    • Scale Auto Scaling Group (ASG) dựa trên mức sử dụng CPU
    • Tự động thêm EC2 instance theo thời gian
  • ECS Cluster Capacity Provider
    • Dùng để tự động provision (cấp phát) và scale hạ tầng cho các ECS Task
    • Capacity Provider được gắn với một Auto Scaling Group
    • Thêm EC2 Instance khi tài nguyên (CPU, RAM,...) không đủ
Bạn thấy bài này thế nào?