Quản lý các stage và environment

cloudFun

Để tận dụng tối đa hướng dẫn này, hãy đăng ký (miễn phí) tài khoản Serverless Framework Dashboard
https://dashboard.serverless.com

img-blog-environment-stages.png


Ngay từ đầu, Serverless Framework đã có khái niệm về các stage; khả năng tạo các stack khác nhau của cùng một service. Khái niệm này hoạt động thực sự tốt khi cần cung cấp các loại environment khác nhau cho vòng đời phát triển phần mềm của nhóm hoặc tổ chức, vì nó cho phép triển khai các development code đến development environment bằng cách sử dụng development stage:
serverless deploy --stage develop

Điều này đi kèm với một vài vấn đề. Làm thế nào để quản lý các biến environment khác nhau giữa các môi trường khác nhau? Nếu muốn triển khai nhiều tài khoản AWS thì sao? Làm thế nào để đảm bảo rằng code được triển khai cho môi trường khác nhau đáp ứng các yêu cầu chính sách tối thiểu?

Serverless Framework Pro bổ sung khái niệm profile bên cạnh khái niệm stage cho phép giải quyết một số vấn đề này.



Thiết lập ban đầu


Hãy cùng CloudFUN bắt đầu với thiết lập cơ bản!

Trước tiên, hãy truy cập Serverless Framework Pro Dashboard và tạo một tài khoản mới nếu chưa có tài khoản, hoặc đăng nhập vào tài khoản hiện có. Nếu đã tạo một tài khoản mới, quy trình on-board sẽ giới thiệu các khái niệm trong Dashboard. Tiếp tục xem hết hoặc bỏ qua nó cũng được.

Sau khi hoàn thành, hãy chắc chắn rằng một ứng dụng đã được tạo ra như sau:
New-org-and-app.png


Bây giờ hãy chuyển đến phần profiles, menu trên cùng bên trái, đã có một hồ sơ mặc định được tạo. Giả định cần có một development profile cho môi trường phát triển, Nhấp vào profile mặc định và cho phép đổi tên nó thành development và lưu:
Development-profile-edited.png


Trước khi bắt đầu xem xét các tính năng khác, hãy thực hiện một thay đổi cấu hình cuối cùng:
1. Chọn apps trong menu trên cùng bên phải
2. Chọn ứng dụng đã tạo
3. Nhấp vào app settings sau đó vào stages trong menu bar.

Đây là nơi sẽ liên kết profile phát triển mới đã tạo với một giai đoạn cụ thể có thể triển khai. Nhấp vào add stage sau đó có thể đặt dev stage được liên kết với development profile:
DevStageToDevelopmentProfile.png


Với thiết lập này, các lệnh như serverless deploy --stage dev sẽ liên kết development profile sắp cấu hình trong toàn bộ quá trình triển khai để công việc thuận lợi hơn!
Bây giờ hãy quay lại profiles và xem những gì có thể làm với profiles mới này.


Phân tách tài khoản AWS


Tách các environment khác nhau ( ví dụ ở đây là giữa developmentproduction) vào các tài khoản AWS thay thế là một thực tế khá phổ biến. Nếu muốn environment development chạy trên một tài khoản AWS hoàn toàn khác environment production, thì đây là nơi để thực hiện điều đó. Việc chọn tab AWS account cho phép tùy chọn sử dụng thông tin xác thực AWS cục bộ, vì vậy nếu không thực sự muốn thay đổi cách triển khai hiện tại thì có thể bỏ qua. Nhưng nếu chọn tùy chọn Add an organization AWS account to deploy ngay lập tức được chuyển đến một liên kết có nhãn Open the AWS console dẫn đến một trình hướng dẫn mà chỉ cần nhấp vào tiếp theo.

Sau khi hoàn thành, sẽ có một vai trò mới được tạo. Sao chép ARN cho vai trò đó và dán nó vào hộp văn bản được cung cấp trong Dashboard, nhấn nút lưu và công việc đã hoàn tất. Dịch vụ hiện có thể triển khai vào tài khoản AWS khi sử dụng dev stage.
AWSAccountAddedToProfile.png

Nhưng có nhiều lợi ích khác cũng được xây dựng theo mặc định. Có thể triển khai AWS thông qua Serverless Framework Dashboard, không còn cần phải phân phối Access Keys hay Secrets cho developers để họ có thể triển khai từ các máy cục bộ của mình. Khi triển khai được thực hiện thông qua Dashboard, tại thời điểm triển khai, Serverless Framework yêu cầu thông tin truy cập tạm thời được tạo thông qua vai trò vừa thiết lập. Khi triển khai hoàn tất, những thông tin đó sẽ không còn được sử dụng.

Thông số environment

Ứng dụng nào cũng cần config data. Cho dù kết nối với nguồn dữ liệu hoặc API của bên thứ ba, nó cần những chi tiết này để chạy ứng dụng. Tuy nhiên, các chi tiết này thường khác nhau tùy thuộc vào việc đang chạy trong môi trường phát triển hay trong sản xuất, hoặc thậm chí tại địa phương.

Rất may, Dashboard Serverless Framework Pro có một tính năng trong profiles giúp giải quyết điều đó. Nhìn vào profile, nếu nhấp vào tab parameters, sẽ thấy chức năng thêm các cặp khóa-giá trị mà sau đó có thể được nhập vào ứng dụng tại thời điểm triển khai
parameters.png

Thiết lập các tham số theo cách này, sau đó chúng có thể được thêm vào dự án trong tệp serverless.yml dưới dạng các biến environment được nhập bằng hàm Lambda hoặc thậm chí được sử dụng ở bất kỳ đâu trong tệp serverless.yml, vì chúng được thay thế bởi giá trị thực tế tại thời điểm triển khai. Ví dụ:
Mã:
org: garethsorg
app: my-new-app
service: my-new-service
provider:
  name: aws
  runtime: node12.x
  environment:   
    DB_HOST: ${param:DB_HOST}
    DB_NAME: ${param:DB_NAME}
    DB_PASSWORD: ${param:DB_PASSWORD}
    DB_USERNAME: ${param:DB_USERNAME}
Cú pháp ${param:} lấy giá trị được lưu tương ứng với khóa khi chạy. Nhưng kết hợp với cú pháp biến hiện có của Serverless Framework, có thể đảm bảo rằng sự phát triển cục bộ có các giá trị bắt buộc:
Mã:
environment:   
    DB_HOST: ${param:DB_HOST, 'localhost'}
    DB_NAME: ${param:DB_NAME, 'localdbname'}
    DB_PASSWORD: ${param:DB_PASSWORD, 'localdbpass'}
    DB_USERNAME: ${param:DB_USERNAME, 'localdbusername'}
Nếu param không tồn tại ( có thể xảy ra trong local environment ) các giá trị mặc định sau , sẽ được sử dụng thay thế.

Hãy làm cho team cơ sở hạ tầng hạnh phúc

Còn được gọi là safeguards. Tab cuối cùng chưa được xem xét tới này là cách Serverless Framework chèn thêm một lớp thực thi chính sách bổ sung vào tất cả các bước triển khai.

Giả sử một tổ chức đã có một nhóm cơ sở hạ tầng hiện hữu và muốn tạo ra một đường dẫn Serverless mới, họ đưa ra một số yêu cầu về việc các tài nguyên được triển khai vào AWS như thế nào. Ví dụ như yêu cầu không có chính sách IAM nào được xác định với một tập hợp quyền quá rộng.

Khi xây dựng ứng dụng Serverless, có thể xác định một số chính sách IAM như:
Mã:
iamRoleStatements:
    - Effect: "Allow"
      Resource:
        - arn:aws:dynamodb:*:*:table/*
      Action:
        - "dynamodb:*"
Nhưng nhóm cơ sở hạ tầng có thể không hài lòng với tất cả các ký tự đại diện đó. Họ thích những thứ như thế này:
Mã:
iamRoleStatements:
    - Effect: "Allow"
      Resource:
        - arn:aws:dynamodb:#{AWS::Region}:#{AWS::AccountId}:table/${self:custom.dynamodb.myTable}
      Action:
        - "dynamodb:Query"
        - "dynamodb:PutItem"
Điều này sẽ yêu cầu sự can thiệp của con người tại thời điểm triển khai để thực thi, trừ khi sử dụng biện pháp bảo vệ để kiểm tra điều này. Mở tab safeguard trong development profile, có thể thấy một vài biện pháp bảo vệ được thêm theo mặc định:
DefaultSafeguards.png

Kéo xuống sâu hơn một chút, có thể thấy đã có no-unsafe-wildcard-iam-permissions, nó sẽ kiểm tra các ký tự đại diện được sử dụng trong iamRoleStatements và đưa ra cảnh báo hoặc lỗi chưa hoàn thành trong thời gian triển khai, tùy thuộc vào cài đặt. Chắc chắn khi cài đặt thiết lập production file, phải cài đặt nó như một lỗi nếu muốn nó đưa ra cảnh báo.
EnforcementLevel.png


Có một loạt các Safeguards để lựa chọn. Có rất nhiều kết hợp có thể đã được cung cấp javascript safeguard cho phép tự viết. thậm chí có thể giao phó các biện pháp bảo vệ như là một phần của mã của sẽ được thực thi tại thời điểm triển khai.

Đây là một chủ đề lớn để có thể nói chi tiết đầy đủ ở đây, vì vậy hãy xem thêm tài liệu chính thức về Safeguards cho tất cả các chi tiết.

Với tất cả các bước ví dụ trên, hãy tưởng tượng kết hợp điều đó với môi trường sản xuất và sau đó lặp lại trong Serverless Framework CI/CD sử dụng tất cả các tính năng này theo mặc định. Nó có thể giúp quản lý vòng đời phát triển phần mềm liền mạch qua nhiều giai đoạn và kịch bản triển khai. Tất cả những gì cần để bắt đầu là vào Serverless Framework Pro Dashboard và đăng ký!

Nguồn: https://serverless.com/
 
Top