___
bởi Dan Blanco | 26 tháng 11, 2023 | AWS CloudFormation, Hướng dẫn kĩ thuật| Liên kết cố định | Chia sẻ
AWS CloudFormation, một dịch vụ Cơ sở hạ tầng dạng Code (IaC) cho phép bạn lập mô hình, và quản lý tài nguyên AWS và tài nguyên thứ ba, hiện hỗ trợ sử dụng Git sync để tự động kích hoạt triển khai bất cứ khi nào kho lưu trữ Git được cập nhập. Điều này cho phép các nhà phát triển tăng tốc vòng đời phát triển cho Cloudformation bằng cách tích hợp vào quy trình làm việc của Git và giảm thời gian ra mắt đi khi chuyển đổi bối cảnh. Sự tích hợp mới làm việc trực tiếp với GitHub, GitHub Enterprise, GitLab, và Bitbucket.
Trong bài đăng này, bạn sẽ khám phá trải nghiệm phát triển hiện đại trông như thế nào khi sử dụng của công cụ gốc GitHub cũng như tích hợp đồng bộ CloudFormation Git sync. Bạn sẽ tạo môi trường phát triển sử dụng GitHub CodeSpaces, tích hợp phản hồi trực tiếp vào Pull Requests sử dụng GitHub Actions và CloudFormation Linter, đồng thời tự động hóa quá trình triển khai an toàn.
Yêu cầu
- Một tài khoản AWS. Bạn sẽ triển khai các tài nguyên Amazon Virtual Private Cloud (Amazon VPC), cái được cung cấp miễn phí. Tài khoản AWS chỉ có thể có 5 VPC mà không tăng giới hạn.
- Một tài khoản GitHub có quyền truy cập vào Codespaces và Actions. Chúng có cấp độ miễn phí nhưng phải chịu phí nếu vượt quá.
- Một CodeStar Connection to GitHub.
Tạo một repository trống
Để làm điều này, bạn sẽ bắt đầu với repository GitHub mới. GitHub cho phép bạn tạo một repositories Git mới miễn phí. Trong ví dụ này, bạn sẽ tạo một repo gọi là git-sync.
Thiết lập một Codespace
Sau khi tạo repo, bạn sẽ có tùy chọn một Codespace. Codespace là môi trường phát triển từ xa do Github quản lý cho phép bạn phát triển từ bất cứ đâu trên các máy ảo được tiêu chuẩn hóa.
Codespaces sử dụng Visual Studio Code làm trình soạn thảo mã. Visual Studio Code là trình soạn thảo mã nguồn mở có tính linh hoạt và khả năng mở rộng tuyệt vời nhờ khả năng cài đặt tiện ích mở rộng.
Bạn sẽ thêm tiện ích CloudFormation Linter để nhận phản hồi nhanh trong trình soạn thảo khi phát triển mẫu của bạn. Điều này giúp bạn tránh việc phải gửi mẫu của mình cho CloudFormation để kiểm tra và thay vào đó có niềm tin tốt rằng mẫu của bạn hợp lệ trước khi bạn gửi chúng để cung cấp. Bạn sẽ cài đặt nó cả bằng cách sử dụng dòng lệnh và một tiện ích mở rộng cho chính Visual Studio Code. Trong cửa sổ terminal, chạy:
pip3 install cfn-lint
Sau khi cài đặt, bạn có thể cài linter trong bảng tiện ích mở rộng
Tiếp theo, bạn sẽ tạo mậu của mình trong thư mục gốc tên vpc.yaml. Khi bạn bắt đầu nhập, tiện ích linter sẽ đề xuất tự động hoàn thành cho bạn.
Copy theo mẫu sau vào tệp vpc.yaml mới tạo:
YAML
| AWSTemplateFormatVersion: “2010-09-09″Resources: VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 |
Mẫu này tạo một VPC với một khối CIDR là 10.0.0.0/16.
Bạn có thể xác minh mẫu không có lỗi bằng cách chạy cfn-lint trong terminal và xác thực rằng nó không có lỗi.
cfn-lint -t vpc.yaml
Thêm tệp triển khai
Để hỗ trợ nhiều loại triển khai khác nhau, Git sync hỗ trợ một deployment file để mang lại sự linh hoạt cho quản lý CloudFormation Stacks từ bên trong repo Git. Tệp cấu hình quản lý vị trí của tệp mẫu và mọi tham số hoặc thẻ bạn có thể muốn sử dụng. Tôi đặc biệt khuyến khích bạn sử dụng config file cho quản lý tham số và thẻ của bạn và nó cho phép dễ dàng kiểm tra và triển khai xác định.
Bạn sẽ tạo một file mới có tên là deployment-file.yaml trong repo của bạn. Vì stack này không có tham số hoặc thẻ, nó sẽ tương đối đơn giản.
YAMl
| template-file-path: ./vpc.yaml |
Bạn cũng có khả năng thêm tệp này vào bảng điều khiển sau.
Thêm hành động Pull Request
Bây giờ bạn có thể cấu hình môi trường phát triển của mình theo cách bạn muốn, bạn muốn đảm bảo rằng bất cứ ai người yêu cầu pull-request sẽ nhận phản hồi chất lượng cao tương tự như phản hồi bạn nhận được tại local. Bạn có thể thực hiện sử dụng Github Action. Actions là một công cụ luồng làm việc có thể tùy chỉnh mà bạn có thể tận dụng để kích hoạt phản hồi pull-request và xây dựng CI.
Để làm điều đó, bạn sẽ phải tạo theo cấu trúc thư mục: .github/workflows/pull-request.yaml . Nội dung của tập tin này như sau:
YAML
| name: Pull Request workflowon: – pull requestjobs: cloudformation-linter: runs-on: ubuntu-latest steps: – name: Checkout uses: actions/checkout@v3 – name: Linter install uses: scottbrenner/cfn-lint-action@v2 with: command: cfn-lint -t ./vpc.yaml |
Với cấu hình này, bạn sẽ nhận được phản hồi về pull-request với các phát hiện linter. Đẩy công việc của bạn đến nhánh từ xa.
Bash
| git add -Agit commit -m “add pull request linting workflow, add base vpc template”git push origin main |
Bây giờ bạn thêm một subnet đến VPC của bạn và cố tính mắc lỗi bởi thêm thuộc tính không hợp lệ có tên là VpcName , thay vì VpcId.
YAML
| AWSTemplateFormatVersion: “2010-09-09″Resources: VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 Subnet: Type: AWS::EC2::Subnet Properties: VpcName: !Ref VPC CidrBlock: 10.0.0.1/16 |
Liter sẽ ngay lập tức thông báo cho bạn rằng điều này là không hợp lệ:
Bạn có thể bỏ quy những điều này bây giờ. Để tạo pull request của bạn, bạn phải tạo một nhánh mới và xác nhận thay đổi cục bộ của mình. Bạn có thể làm điều này bằng cách sử dụng:
Bash
| git switch -c add-subnetgit add -Agit commit -m “add subnet”git push origin add-subnet |
Khi bạn đẩy các commit, GitHub sẽ cho phép bạn tạo pull request với nhánh main. Tuy nhiên, sau khi tạo, bạn sẽ nhận thấy rằng quá trình kiểm tra thông báo không thành công khi Tác vụ GitHub của bạn chạy thành công.
Bạn có thể xem cái điều gì xảy ra bằng cách kiểm tra tab “File changed”. Hành động linter của bạn sẽ cung cấp phản hồi trực tiếp trên pull request và chặn hành động merge nếu bạn đã thiết lập branch protection. Repo này yêu cầu ít nhất một người đánh giá và tất cả các bước kiểm tra để vượt qua, vì vậy bạn phải giải quyết cả hai lối này.
Bây giờ bạn có phản hồi chất lượng cao cũng như số dòng vi phạm, bạn có thể quay lại mẫu của mình và thực hiện sửa đổi cần thiết VpcName thành VpcId.
YAML
| AWSTemplateFormatVersion: “2010-09-09″Resources: VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 Subnet: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: 10.0.0.1/16 |
Linter local rất vui và sau khi bạn commit lại bạn sẽ thấy rằng remote linter của bạn cũng hạnh phúc không kém. Sau khi có được người phê duyệt khác, bạn có thể merge commit của bạn vào nhánh
main của mình.
Kích hoạt Git sync
Giờ đây bạn có môi trường phát triển đám mây chất lượng cao và quy trình pull request của bạn đảm bảo các mẫu của bạn được được lọc trước khi merging. Bạn có thể chắc chắn rằng mẫu CloudFormation
được đưa vào nhánh main đã sẵn sàng để triển khai. Tiếp theo, bạn sẽ tận dụng tính năng Git sync mới được phát hành của CloudFormation để tự động đồng bộ stack đã triển khai của bạn với mẫu mới này.
Đầu tiên, create the role sẽ triển khai mẫu CloudFormation của chúng tôi. Chắc chắn ghi lại tên bạn chọn cho điều này vì bạn sẽ sử dụng nó để quản lý stack của mình sau này. Ví dụ sử dụng vpc-example-cloudformation-deployment-role.
JSON
| { “Version”: “2012-10-17”, “Statement”: [ { “Effect”: “Allow”, “Action”: [ “ec2:CreateVpc”, “ec2:CreateSubnet”, “ec2:DescribeVpcs”, “ec2:DescribeSubnets”, “ec2:DeleteVpc”, “ec2:DeleteSubnet”, “ec2:ModifySubnetAttribute”, “ec2:ModifyVpcAttribute” ], “Resource”: “*”, “Condition”: { “ForAnyValue:StringEquals”: { “aws:CalledVia”: [“cloudformation.amazonaws.com”] } } } ]} |
Khi vai trò đã được tạo, bạn sẽ phải tạo thêm một stack mới:
Tại đây, bạn có thể thấy tùy chọn mới để chọn Sync from Git nguồn mẫu, cái bạn có thể cấu hình trên màn hình tiếp theo. Vì bạn đã tạo tệp triển khai của mình nên bạn có thể chọn I am providing my own file in my repository.
Tiếp theo bạn có thể cấu hình tích hợp Git để có thể chọn repo của bạn. Vì đây là lần đầu tiên của bạn nên bạn sẽ cần sử dụng CodeStar Connection bạn đã tạo trước đó và chọn repo của mình.
Chọn Github, connection, repo, và branch, vị trí deployment file.
Cuối cùng, bạn sẽ chọn New IAM Role để tạo một role được quản lý dịch vụ. Vai trò này sẽ cho phép đồng bộ hóa Git kết nối với repo của bạn. Bạn chỉ cần thực hiện điều này một lần; trong tương lai bạn sẽ có thể sử dụng role hiện có mà bạn tạo ở đây.
Trên trang tiếp theo, bạn sẽ chọn IAM Role bạn đã tạo để quản lý stack này. Role này kiểm soát tài nguyên mà CloudFormation sẽ triển khai. Các stack được quản lý bởi Git sync phải có một role được tạo.
Cuối cùng, bạn có thể xem trạng thái đồng bộ của mình trong tab “Git sync”, bao gồm cấu hình bạn cung cấp trước đó cũng như trạng thái đồng bộ hóa, các triển khai trước đó, và tùy chọn thử lại hoặc ngắt kết nối đồng bộ hóa nếu cần.
Kết luận
Tại thời điểm này, bạn đã cấu hình môi trường phát triển từ xa để nhận phản hồi chất lượng cao khi tạo và cập nhập mẫu CloudFormation của mình. Bạn cũng có thể phản hồi chất lượng cao tương tự khi tạo một pull request. Cuối cùng, khi một template được hợp và nhánh main , nó sẽ tự động triển khai đến stack của bạn. Điều này thể hiện một hệ thống CI/CD mạnh mẽ và có thể mở rộng để quản lý cơ sở hạn tầng dưới dạng code. Tôi rất vui khi nghe phản hồi của bạn về tính năng này!
Dan Blanco
Dan là Người hỗ trợ nhà phát triển AWS cấp cao có trụ sở tại Atlanta cho nhóm AWS IaC. Khi anh ấy không ủng hộ các công cụ IaC, bạn có thể thấy anh ấy đang ở trong bếp đang chế biến món gì đó ngon lành hoặc bay trên bầu trời Georgia. Hãy tìm anh ấy trên twitter (@TheDanBlanco) hoặc trong AWS CloudFormation Discord .
Link Blog:
AWS Study Group 