Người dùng Amazon Web Services (AWS) đã hỏi là làm cách nào để tăng tốc quá trình triển khai với nhóm của họ trên AWS trong khi vẫn duy trì tuân thủ các biện pháp kiểm soát bảo mật. Trong bài đăng trên blog này, chúng tôi mô tả các mô hình quản trị phổ biến được giới thiệu trong các tổ chức lớn để quản lý việc triển khai AWS với nhóm của họ. Các mô hình này được sử dụng tốt nhất để tăng cường độ hoàn thiện của việc triển khai cơ sở hạ tầng trên cloud của bạn.
Các mô hình quản trị cho việc triển khai AWS
Chúng tôi có ba mô hình phổ biến thường được các chuyên gia sử dụng để quản lý việc triển khai cơ sở hạ tầng của họ trên AWS. Các mô hình khác nhau về những gì chúng kiểm soát: mã cơ sở hạ tầng, chuỗi công cụ triển khai hoặc tài nguyên AWS được cung cấp. Chúng tôi xác định các mô hình như sau:
- Central pattern library, Central pattern library, cung cấp một kho lưu trữ các template triển khai được quản lý mà các nhóm ứng dụng có thể sử dụng lại với các triển khai của họ.
- Continuous Integration/Continuous Delivery (CI/CD) as a service, tích hợp liên tục / Phân phối liên tục (CI / CD) như một dịch vụ, cung cấp tiêu chuẩn chuỗi công cụ để các nhóm ứng dụng sử dụng lại.
- Centrally managed infrastructure, cơ sở hạ tầng được quản lý tập trung, cho phép các nhóm ứng dụng triển khai các tài nguyên AWS do các nhóm vận hành trung tâm quản lý.
Quyết định về mức độ trách nhiệm mà bạn chuyển giao cho các nhóm ứng dụng phụ thuộc vào quyền tự chủ, mô hình hoạt động, loại ứng dụng và tốc độ thay đổi của họ. Ba mô hình có thể được sử dụng song song để giải quyết các trường hợp sử dụng khác nhau và tối đa hóa tác động. Thông thường, các tổ chức bắt đầu bằng cách thu thập các template triển khai đã được phê duyệt trước trong một Central pattern library.
Mô hình 1: Central pattern library
Với mô hình này, các kỹ sư nền tảng đám mây xuất bản một thư viện trung tâm các template mà từ đó các nhóm có thể tham chiếu cơ sở hạ tầng dưới dạng các template code. Các nhóm ứng dụng sử dụng lại các template bằng cách phân nhánh kho lưu trữ trung tâm hoặc bằng cách sao chép các template vào kho lưu trữ của riêng họ. Các nhóm ứng dụng cũng có thể quản lý tài khoản và đường dẫn AWS triển khai của riêng họ với AWS CodePipeline), cũng như quy trình cung cấp tài nguyên, đồng thời sử dụng lại các template từ Central pattern library với một dịch vụ như AWS CodeCommit. Hình 1 cung cấp một cái nhìn tổng quan về mô hình quản trị này.
Hình 1. Quản trị triển khai với Central pattern library
Central pattern library đại diện cho hình thức hỗ trợ ít xâm nhập nhất thông qua các tài sản có thể tái sử dụng. Các nhóm ứng dụng đánh giá cao mô hình Central pattern library, vì nó cho phép họ duy trì quyền tự chủ đối với quy trình triển khai và chuỗi công cụ của họ. Việc sử dụng lại các template hiện có giúp tăng tốc độ tạo các template cơ sở hạ tầng đầu tiên của nhóm bạn và giảm bớt việc tuân thủ chính sách, chẳng hạn như các chính sách gắn thẻ và kiểm soát bảo mật.
Sau khi các template có thể sử dụng lại nằm trong kho lưu trữ của nhóm ứng dụng, các bản cập nhật gia tăng có thể được lấy từ thư viện trung tâm khi template đã được nâng cao. Điều này cho phép các nhóm kéo khi họ thấy phù hợp. Các thay đổi đối với kho lưu trữ của nhóm sẽ kích hoạt quy trình triển khai mã cơ sở hạ tầng được liên kết.
Với mô hình Central pattern library, các nhóm ứng dụng cần tự quản lý cấu hình tài nguyên và chuỗi công cụ CI / CD để đạt được lợi ích của việc triển khai tự động. Mô hình 2 giải quyết vấn đề này.
Mô hình 2: CI / CD dưới dạng dịch vụ
Trong Mô hình 2, các nhóm ứng dụng khởi chạy một pipeline triển khai có quản lý từ AWS Service Catalog. Điều này bao gồm mã cơ sở hạ tầng cần thiết để chạy ứng dụng và mã nguồn “hello world” để hiển thị luồng triển khai end-to-end.
Các kỹ sư nền tảng đám mây phát triển danh mục AWS Service Catalog (trong trường hợp này là chuỗi công cụ CI / CD). Sau đó, các nhóm ứng dụng có thể khởi chạy các sản phẩm AWS Service Catalog, triển khai một phiên bản của mã pipeline và kho lưu trữ Git phổ biến (Hình 2).
Pipeline được bắt đầu ngay sau khi kho lưu trữ được điền, dẫn đến ứng dụng “hello world” được triển khai tới môi trường đầu tiên. Mã cơ sở hạ tầng (ví dụ: Amazon Elastic Compute Cloud [Amazon EC2] và AWS Fargate) sẽ nằm trong kho lưu trữ của nhóm ứng dụng. Các bản cập nhật gia tăng có thể được thực hiện bằng cách khởi chạy bản cập nhật sản phẩm từ AWS Service Catalog. Điều này cho phép các nhóm ứng dụng kéo khi họ thấy phù hợp.
Hình 2. Quản trị triển khai với CI / CD như một dịch vụ
Mô hình quản trị này đặc biệt phù hợp với các tổ chức nhà phát triển trưởng thành với trách nhiệm toàn bộ hoặc các dự án nền tảng, vì nó cung cấp khả năng tự động hóa triển khai từ đầu đến cuối để cung cấp tài nguyên cho nhiều nhóm và tài khoản AWS. Mô hình này cũng bổ sung các kiểm soát bảo mật đối với quá trình triển khai.
Vì có rất ít chỗ cho các nhóm thích ứng với tiêu chuẩn chuỗi công cụ, mô hình có thể được coi là rất cố chấp. Mô hình mong đợi các nhóm ứng dụng tự quản lý cơ sở hạ tầng của họ. Mô hình 3 giải quyết vấn đề này.
Mô hình 3: Cơ sở hạ tầng được quản lý tập trung
Mô hình này cho phép các nhóm ứng dụng cung cấp các tài nguyên do một nhóm vận hành trung tâm quản lý dưới dạng tự phục vụ. Các kỹ sư nền tảng đám mây xuất bản danh mục cơ sở hạ tầng lên AWS Service Catalog với cấu hình được phê duyệt trước bởi các nhóm trung tâm (Hình 3). Các danh mục đầu tư này có thể được chia sẻ với tất cả các tài khoản AWS được sử dụng bởi các kỹ sư ứng dụng.
Việc cung cấp tài nguyên AWS thông qua các sản phẩm AWS Service Catalog đảm bảo cấu hình tài nguyên đáp ứng các yêu cầu hoạt động trung tâm. So với Mô hình 2, các template cơ sở hạ tầng được điền trước khởi chạy các sản phẩm AWS Service Catalog, thay vì tham chiếu trực tiếp đến API của dịch vụ AWS tương ứng (ví dụ: Amazon EC2). Điều này khóa cách cấu hình và cung cấp cơ sở hạ tầng.
Hình 3. Quản trị triển khai với cơ sở hạ tầng được quản lý tập trung
Theo kinh nghiệm của chúng tôi, điều cần thiết là phải quản lý nhiều sản phẩm Danh mục dịch vụ AWS. Điều này giúp tránh sự gia tăng của các sản phẩm có nhiều template hơi khác nhau. Cơ sở hạ tầng được quản lý tập trung truyền bá tư duy “tại chỗ” vì vậy nó chỉ nên được sử dụng trong trường hợp các nhóm ứng dụng không thể sở hữu toàn bộ stack.
Mô hình 2 và 3 có thể được kết hợp để các kỹ sư ứng dụng khởi chạy cả chuỗi công cụ và tài nguyên triển khai dưới dạng các sản phẩm Danh mục dịch vụ AWS (Hình 4), đồng thời duy trì cơ hội cung cấp từ các template cơ sở hạ tầng được điền sẵn trong kho nhóm. Sau khi mã có trong kho lưu trữ của chúng, có thể lấy các bản cập nhật gia tăng bằng cách chạy bản cập nhật từ sản phẩm Danh mục dịch vụ AWS được cấp phép. Điều này cho phép nhóm ứng dụng cập nhật khi cần thiết trong khi tránh triển khai thủ công các sản phẩm danh mục dịch vụ.
Hình 4. Sử dụng Danh mục dịch vụ AWS để tự động hóa việc cung cấp tài nguyên cơ sở hạ tầng và CI / CD
So sánh các mô hình
Ba mô hình quản trị khác nhau ở các khía cạnh sau (xem Bảng 1):
- Cấp độ quản trị: Thành phần nào được quản lý tập trung bởi các kỹ sư nền tảng đám mây?
- Vai trò của kỹ sư ứng dụng: Phân chia trách nhiệm và mô hình hoạt động là gì?
- Trường hợp sử dụng: Mỗi mô hình được áp dụng khi nào?
Bảng 1. Các mô hình quản trị để quản lý việc triển khai cơ sở hạ tầng
| Mô hình 1: Central pattern library | Mô hình 2: CI / CD dưới dạng dịch vụ | Mô hình 3: Cơ sở hạ tầng được quản lý tập trung | |
| Cấp quản trị | Các template cơ sở hạ tầng được xác định tập trung | Chuỗi công cụ triển khai được xác định tập trung | Cấp phép và quản lý tài nguyên AWS được xác định tập trung |
| Vai trò của kỹ sư nền tảng đám mây | Quản lý thư viện template và kiểm tra policy | Quản lý chuỗi công cụ triển khai và kiểm tra giai đoạn | Quản lý cung cấp tài nguyên (bao gồm CI / CD) |
| Vai trò của nhóm ứng dụng | Quản lý chuỗi công cụ triển khai và cung cấp tài nguyên | Quản lý việc cung cấp tài nguyên | Quản lý tích hợp ứng dụng |
| Trường hợp sử dụng | Quản trị liên kết với các nhóm ứng dụng duy trì quyền tự chủ đối với ứng dụng và cơ sở hạ tầng | Các dự án nền tảng hoặc tổ chức phát triển có ưu tiên mạnh mẽ đối với các tiêu chuẩn triển khai được xác định trước bao gồm chuỗi công cụ | Các ứng dụng không có nhóm phát triển (ví dụ: “thương mại sẵn có”) hoặc có sự tách biệt về nhiệm vụ (ví dụ: nhóm vận hành cơ sở hạ tầng) |
Kết luận
Trong bài đăng trên blog này, chúng tôi đã phân biệt ba mô hình quản trị phổ biến để quản lý việc triển khai các tài nguyên AWS. Ba mô hình có thể được sử dụng song song để giải quyết các trường hợp sử dụng khác nhau và tối đa hóa tác động trong tổ chức của bạn. Quyết định về mức độ trách nhiệm được chuyển cho các nhóm ứng dụng tùy thuộc vào trường hợp sử dụng và thiết lập tổ chức của bạn.
Want to learn more?
- Why Deployment Requirements are Important When Making Architectural Choices
- Making Effective Decisions for Your V1 AWS Design
- Introduction to DevOps on AWS
- Practicing Continuous Integration and Continuous Delivery on AWS
Bài được dịch từ bài viết trên AWS Blogs, bạn có thể xem bài viết gốc tại đây.
AWS Study Group 