Bởi Angel Pizarro ngày 11 tháng 2 năm 2025 trong AWS Batch, Best Practices, Compute, DevOps, High Performance Computing

Như bạn có thể biết, hiện có hai Terraform provider cho AWS. Terraform AWS provider nguyên bản là một dự án mã nguồn mở với các pull request từ cộng đồng. Provider này là thư viện infrastructure-as-code được code thủ công để gọi trực tiếp thông qua AWS SDK, từ đó gọi tới AWS APIs. Mặc dù cách tiếp cận này mang lại trải nghiệm tốt cho developer, nhưng chúng ta biết rằng việc review và tích hợp các pull request hỗ trợ tính năng mới và dịch vụ mới của AWS có thể mất nhiều thời gian.

Vào giữa năm 2024, HashiCorp đã chính thức ra mắt Terraform AWS Cloud Control (AWSCC) provider. Provider này hoạt động với AWS Cloud Control API – một tập hợp các API chung giúp developers và đối tác dễ dàng quản lý vòng đời của các dịch vụ AWS và bên thứ ba. Khác với AWS Provider nguyên bản, AWSCC provider được tự động tạo ra dựa trên Cloud Control API do AWS phát hành. Điều này có nghĩa là các tính năng và dịch vụ mới nhất từ AWS có thể được hỗ trợ ngay lập tức.

Cho đến gần đây, AWS Batch job definitions chưa được AWS Cloud Control API hỗ trợ như một managed resource. Vì lý do này, team AWS Batch đã tập trung vào AWS provider nguyên bản để cung cấp blueprint cho việc làm việc với AWS Batch trên Amazon EKS. Giờ đây khi AWS Batch job definitions đã được hỗ trợ trong Cloud Control API, bạn có thể sử dụng AWSCC provider để quản lý tất cả Batch resources. Hơn nữa, bạn có thể sử dụng cả hai provider trong cùng một stack, giữ nguyên các resources hiện có được quản lý bởi AWS provider nguyên bản.

Hãy xem một ví dụ về việc quản lý Batch resources với hai provider này.

Quản lý tài nguyên Batch compute environment với Terraform

Đoạn code dưới đây minh họa cách tạo và quản lý AWS Batch compute environment bằng cách sử dụng AWS provider gốc.

JSON

resource “aws_batch_compute_environment” “sample” {

  compute_environment_name_prefix = “mySampleComputeEnv”

  compute_resources {

    type = “EC2”

    allocation_strategy = “BEST_FIT_PROGRESS”

    min_vcpus = 0

    max_vcpus = 256

    instance_type = [

      “c5”,

      “m5”,

      “r5”

    ]

    instance_role = aws_iam_instance_profile.ecs_instance_role.arn

    security_group_ids = [

      aws_security_group.sample.id

    ]

    subnets = [

LLưu ý rằng ví dụ này tham chiếu đến các resources khác trong Terraform stack, như VPC security group và subnet. Bạn có thể tìm thấy một ví dụ triển khai đầy đủ trong blueprint Data on Amazon EKS cho AWS Batch đã đề cập trước đó.

Một chi tiết đáng chú ý là việc sử dụng compute_environment_name_prefix thay vì compute_environment_name để đặt tên cho compute environment. Bằng cách sử dụng prefix, AWS provider có thể xử lý các deployment yêu cầu thay thế hoàn toàn compute environment (CE), tương tự như blue/green deployment cho microservice. Với prefix, provider tạo một CE mới, chuyển các job queue association sang CE mới, sau đó xóa CE cũ. Sử dụng name (không phải prefix) nghĩa là bạn phải tự quản lý thứ tự thao tác để thay thế CE cũ bằng CE mới.

Bây giờ hãy xem resource này sẽ trông như thế nào nếu được quản lý bởi AWSCC provider.

JSON

resource “awscc_batch_compute_environment” “sample” {

  compute_environment_name = “mySampleComputeEnv”

  compute_resources {

    type = “EC2”

    allocation_strategy = “BEST_FIT_PROGRESS”

    min_vcpus = 0

    max_vcpus = 256

    instance_types = [

      “c5”,

      “m5”,

      “r5”

    ]

    instance_role = aws_iam_instance_profile.ecs_instance_role.arn

    security_group_ids = [

      aws_security_group.sample.id

    ]

    subnets = [

         aws_subnet.sample.id

    ]

  type                        = “MANAGED”

  replace_compute_environment = false

  }

}

Như bạn có thể thấy, AWSCC managed resource trông gần như giống hệt, và lưu ý rằng bạn vẫn có thể sử dụng các resources khác được tạo bằng AWS provider nguyên bản trong resource definition.

Sự khác biệt giữa hai đoạn code là:

• Chúng tôi đã thay đổi resource type để phản ánh AWSCC provider resource cho Batch compute environments. 
• AWSCC provider tuân theo Batch API và không có argument để định nghĩa prefix cho tên compute environment. Nếu một deployment yêu cầu thay thế compute environment hiện có, bạn sẽ cần tính đến cách cập nhật các job queue liên quan trong Terraform stack. Ví dụ, bạn sẽ tạo một compute environment mới với tên khác, liên kết các job queue với nó, sau đó vô hiệu hóa và xóa compute environment cũ. 

• instance_types giờ đây ở dạng số nhiều để phản ánh API. Tôi không chắc tại sao AWS provider nguyên bản sử dụng instance_type ở dạng số ít, vì điều này khác với Batch API. 

• Có thêm argument replace_compute_environment được đặt là false. Lý do là vì các CE sử dụng service-linked role có thể cập nhật nhiều attributes hơn mà không cần thay thế CE trong cái gọi là infrastructure update. Nếu argument này là true, bạn sẽ bị giới hạn ở một tập nhỏ hơn các attributes có thể cập nhật trong CE. Để biết thêm thông tin về các cài đặt nào kích hoạt infrastructure update, hãy tham khảo hướng dẫn sử dụng Batch về cập nhật compute environments. 

Ví dụ cho thấy có thể có một số khác biệt trong arguments và hành vi của providers cần sự chú ý kỹ lưỡng của bạn. Vì lý do này, tôi khuyên bạn nên thận trọng khi refactoring các Terraform-managed resources hiện có.

Đối với việc quản lý resources mới, hoặc resources có các cập nhật thường xuyên hơn – như AWS Batch job definitions – tôi chắc chắn khuyên bạn nên sử dụng AWSCC provider. Ví dụ điển hình, configurable namespaces, persistent volume claims, container mount sub-path support, và pod annotations đã được thêm vào job definitions cho Batch trên EKS. Các tính năng này hiện có sẵn trong AWSCC provider được tạo tự động, nhưng AWS provider nguyên bản sẽ cần một thành viên cộng đồng gửi pull request và các maintainer sẽ cần review và chấp nhận request trước khi các tính năng này có sẵn.

Một nhược điểm của việc sử dụng AWSCC provider – theo ý kiến của tôi – là tài liệu của provider về resources khá ít, chỉ bao gồm một chút thông tin về kiểu của resource arguments. Bạn sẽ cần tham khảo tài liệu AWS Cloud Control resource type để biết các arguments đại diện cho cái gì, và bất kỳ lưu ý nào về cách sử dụng chúng trong thực tế. Điều này tạo ra một chút developer friction khi sử dụng AWSCC provider.

Kết luận

Với việc bổ sung hỗ trợ AWS Batch job definition vào AWS Cloud Control API, giờ đây có thể quản lý tất cả AWS Batch resources bằng Terraform AWS Cloud Control provider. Bạn có thể quản lý resources mới hoặc thay đổi nhanh chóng bằng cách sử dụng AWSCC provider song song với AWS provider nguyên bản.

Hãy thử nghiệm trên resources của riêng bạn hoặc bắt đầu với blueprint Data on Amazon EKS AWS Batch. Nếu bạn bắt đầu sử dụng AWSCC provider với Batch, hãy gửi email cho chúng tôi tại ask-hpc@amazon.com và cho chúng tôi biết làm thế nào để cải thiện trải nghiệm.

TAGS: AWS Batch, HPC 

Angel Pizarro 

Angel là Principal Developer Advocate cho HPC và scientific computing. Nền tảng của anh ấy là trong phát triển ứng dụng bioinformatics và xây dựng kiến trúc hệ thống cho điện toán có thể mở rộng trong genomics và các lĩnh vực khoa học đời sống thông lượng cao khác.