Tôi bắt đầu làm việc với Sự hình thành mây 4 năm trước. Kể từ đó tôi đã phá vỡ rất nhiều cơ sở hạ tầng, thậm chí cả những cơ sở đã được đưa vào sản xuất. Nhưng mỗi khi tôi làm hỏng điều gì đó, tôi lại học được điều gì đó mới. Thông qua trải nghiệm này, tôi sẽ chia sẻ một số bài học quan trọng nhất mà tôi đã học được.
Bài 1: Kiểm tra các thay đổi trước khi triển khai chúng
Tôi đã học được bài học này ngay sau khi tôi bắt đầu làm việc với Sự hình thành mây. Tôi không nhớ chính xác lúc đó tôi đã phá vỡ cái gì, nhưng tôi chắc chắn nhớ rằng tôi đã sử dụng lệnh cập nhật thông tin đám mây của aws. Lệnh này chỉ đơn giản triển khai mẫu mà không có bất kỳ xác nhận nào về những thay đổi sẽ được triển khai. Tôi không nghĩ cần có bất kỳ lời giải thích nào về lý do tại sao bạn nên kiểm tra tất cả các thay đổi trước khi triển khai chúng.
Sau thất bại này, tôi lập tức thay đổi đường ống triển khai, thay thế lệnh cập nhật bằng lệnh tạo-thay đổi-set
# OPERATION is either "UPDATE" or "CREATE"
changeset_id=$(aws cloudformation create-change-set
--change-set-name "$CHANGE_SET_NAME"
--stack-name "$STACK_NAME"
--template-body "$TPL_PATH"
--change-set-type "$OPERATION"
--parameters "$PARAMETERS"
--output text
--query Id)
aws cloudformation wait
change-set-create-complete --change-set-name "$changeset_id"
Khi một bộ thay đổi được tạo, nó không có tác dụng gì đối với ngăn xếp hiện có. Không giống như lệnh cập nhật, phương pháp thay đổi không kích hoạt quá trình triển khai thực tế. Thay vào đó, nó tạo danh sách các thay đổi mà bạn có thể xem lại trước khi triển khai. Bạn có thể xem các thay đổi trong giao diện bảng điều khiển aws. Nhưng nếu bạn muốn tự động hóa mọi thứ có thể, hãy kiểm tra chúng trong CLI:
# this command is presented only for demonstrational purposes.
# the real command should take pagination into account
aws cloudformation describe-change-set
--change-set-name "$changeset_id"
--query 'Changes[*].ResourceChange.{Action:Action,Resource:ResourceType,ResourceId:LogicalResourceId,ReplacementNeeded:Replacement}'
--output tableLệnh này sẽ tạo ra kết quả tương tự như sau:
--------------------------------------------------------------------
| DescribeChangeSet |
+---------+--------------------+----------------------+------------+
| Action | ReplacementNeeded | Resource | ResourceId |
+---------+--------------------+----------------------+------------+
| Modify | True | AWS::ECS::Cluster | MyCluster |
| Replace| True | AWS::RDS::DBInstance| MyDB |
| Add | None | AWS::SNS::Topic | MyTopic |
+---------+--------------------+----------------------+------------+Đặc biệt chú ý đến những thay đổi trong đó Hành động Thay thế, Xóa bỏ hoặc ở đâu Cần thay thế - Đúng. Đây là những thay đổi nguy hiểm nhất và thường dẫn đến mất thông tin.
Khi các thay đổi đã được xem xét, chúng có thể được triển khai
aws cloudformation execute-change-set --change-set-name "$changeset_id"
operation_lowercase=$(echo "$OPERATION" | tr '[:upper:]' '[:lower:]')
aws cloudformation wait "stack-${operation_lowercase}-complete"
--stack-name "$STACK_NAME"Bài 2: Sử dụng chính sách ngăn xếp để ngăn chặn việc thay thế hoặc xóa tài nguyên trạng thái
Đôi khi chỉ xem những thay đổi là không đủ. Chúng ta đều là con người và tất cả chúng ta đều phạm sai lầm. Ngay sau khi chúng tôi bắt đầu sử dụng bộ thay đổi, đồng đội của tôi đã vô tình thực hiện quá trình triển khai dẫn đến cập nhật cơ sở dữ liệu. Không có gì xấu xảy ra vì đó là môi trường thử nghiệm.
Mặc dù tập lệnh của chúng tôi hiển thị danh sách các thay đổi và yêu cầu xác nhận, thay đổi Thay thế đã bị bỏ qua vì danh sách các thay đổi quá lớn đến mức không vừa với màn hình. Và vì đây là bản cập nhật bình thường trong môi trường thử nghiệm nên không có nhiều sự chú ý đến những thay đổi.
Có những tài nguyên mà bạn không bao giờ muốn thay thế hoặc loại bỏ. Đây là các dịch vụ có trạng thái đầy đủ, chẳng hạn như phiên bản cơ sở dữ liệu RDS hoặc cụm elaticsearch, v.v. Sẽ thật tuyệt nếu aws tự động từ chối triển khai nếu thao tác đang được thực hiện sẽ yêu cầu xóa tài nguyên đó. May mắn thay, công nghệ đám mây có cách tích hợp sẵn để thực hiện việc này. Đây được gọi là chính sách ngăn xếp và bạn có thể đọc thêm về nó trong :
STACK_NAME=$1
RESOURCE_ID=$2
POLICY_JSON=$(cat <<EOF
{
"Statement" : [{
"Effect" : "Deny",
"Action" : [
"Update:Replace",
"Update:Delete"
],
"Principal": "*",
"Resource" : "LogicalResourceId/$RESOURCE_ID"
}]
}
EOF
)
aws cloudformation set-stack-policy --stack-name "$STACK_NAME"
--stack-policy-body "$POLICY_JSON"Bài 3: Sử dụng UsePreviousValue khi cập nhật ngăn xếp có tham số bí mật
Khi bạn tạo thực thể mysql RDS, AWS yêu cầu bạn cung cấp MasterUsername và MasterUserPassword. Vì tốt hơn hết là không nên giữ bí mật trong mã nguồn và tôi muốn tự động hóa hoàn toàn mọi thứ, nên tôi đã triển khai một "cơ chế thông minh" trong đó trước khi triển khai, thông tin xác thực sẽ được lấy từ s3 và nếu không tìm thấy thông tin xác thực, thông tin xác thực mới sẽ được tạo và được lưu trữ trong s3.
Sau đó, những thông tin xác thực này sẽ được chuyển dưới dạng tham số cho lệnh tạo-thay đổi-set thông tin đám mây. Trong khi thử nghiệm tập lệnh, đã xảy ra trường hợp mất kết nối với s3 và “cơ chế thông minh” của tôi coi đó là tín hiệu để tạo thông tin xác thực mới.
Nếu tôi bắt đầu sử dụng tập lệnh này trong quá trình sản xuất và sự cố kết nối lại xảy ra, nó sẽ cập nhật ngăn xếp bằng thông tin xác thực mới. Trong trường hợp cụ thể này, sẽ không có điều gì xấu xảy ra. Tuy nhiên, tôi đã từ bỏ phương pháp này và bắt đầu sử dụng một phương pháp khác, chỉ cung cấp thông tin xác thực một lần - khi tạo ngăn xếp. Và sau này, khi ngăn xếp cần cập nhật, thay vì chỉ định giá trị bí mật của tham số, tôi chỉ cần sử dụng Sử dụngPreviousValue=true:
aws cloudformation create-change-set
--change-set-name "$CHANGE_SET_NAME"
--stack-name "$STACK_NAME"
--template-body "$TPL_PATH"
--change-set-type "UPDATE"
--parameters "ParameterKey=MasterUserPassword,UsePreviousValue=true"Bài 4: Sử dụng cấu hình rollback
Một nhóm khác mà tôi làm việc cùng đã sử dụng chức năng này Sự hình thành mây, gọi điện cấu hình khôi phục. Tôi chưa từng gặp nó trước đây và nhanh chóng nhận ra rằng nó sẽ khiến việc triển khai ngăn xếp của tôi trở nên thú vị hơn. Bây giờ tôi sử dụng nó mỗi khi tôi triển khai mã của mình lên lambda hoặc ECS bằng cách sử dụng thông tin đám mây.
Cách thức hoạt động: bạn chỉ định Cảnh báo CloudWatch tham số v --cấu hình rollbackkhi bạn tạo một bộ thay đổi. Sau đó, khi bạn thực hiện một loạt thay đổi, aws sẽ giám sát cảnh báo trong ít nhất một phút. Nó sẽ khôi phục quá trình triển khai nếu cảnh báo thay đổi trạng thái thành ALARM trong thời gian này.
Dưới đây là một ví dụ về một đoạn trích mẫu Sự hình thành mâytrong đó tôi tạo ra báo động theo dõi đám mây, theo dõi số liệu người dùng trên đám mây dưới dạng số lỗi trong nhật ký đám mây (số liệu này được tạo thông qua Bộ lọc số liệu):
Resources:
# this metric tracks number of errors in the cloudwatch logs. In this
# particular case it's assumed logs are in json format and the error logs are
# identified by level "error". See FilterPattern
ErrorMetricFilter:
Type: AWS::Logs::MetricFilter
Properties:
LogGroupName: !Ref LogGroup
FilterPattern: !Sub '{$.level = "error"}'
MetricTransformations:
- MetricNamespace: !Sub "${AWS::StackName}-log-errors"
MetricName: Errors
MetricValue: 1
DefaultValue: 0
ErrorAlarm:
Type: AWS::CloudWatch::Alarm
Properties:
AlarmName: !Sub "${AWS::StackName}-errors"
Namespace: !Sub "${AWS::StackName}-log-errors"
MetricName: Errors
Statistic: Maximum
ComparisonOperator: GreaterThanThreshold
Period: 1 # 1 minute
EvaluationPeriods: 1
Threshold: 0
TreatMissingData: notBreaching
ActionsEnabled: yesBây giờ báo động có thể được sử dụng như rollback kích hoạt khi thực thi hộp công cụ:
ALARM_ARN=$1
ROLLBACK_TRIGGER=$(cat <<EOF
{
"RollbackTriggers": [
{
"Arn": "$ALARM_ARN",
"Type": "AWS::CloudWatch::Alarm"
}
],
"MonitoringTimeInMinutes": 1
}
EOF
)
aws cloudformation create-change-set
--change-set-name "$CHANGE_SET_NAME"
--stack-name "$STACK_NAME"
--template-body "$TPL_PATH"
--change-set-type "UPDATE"
--rollback-configuration "$ROLLBACK_TRIGGER"Bài học 5: Đảm bảo bạn triển khai phiên bản mới nhất của mẫu
Thật dễ dàng để triển khai một phiên bản mới nhất của mẫu thông tin đám mây nhưng làm như vậy sẽ gây ra nhiều thiệt hại. Điều này đã xảy ra với chúng tôi một lần: một nhà phát triển đã không đưa ra những thay đổi mới nhất từ Git và vô tình triển khai phiên bản trước của ngăn xếp. Điều này dẫn đến thời gian ngừng hoạt động của ứng dụng sử dụng ngăn xếp này.
Một việc đơn giản như thêm một kiểm tra để xem chi nhánh có được cập nhật hay không trước khi cam kết sẽ ổn (giả sử git là công cụ kiểm soát phiên bản của bạn):
git fetch
HEADHASH=$(git rev-parse HEAD)
UPSTREAMHASH=$(git rev-parse master@{upstream})
if [[ "$HEADHASH" != "$UPSTREAMHASH" ]] ; then
echo "Branch is not up to date with origin. Aborting"
exit 1
fiBài học 6: Đừng phát minh lại cái bánh xe
Có vẻ như việc triển khai với Sự hình thành mây - dễ thôi. Bạn chỉ cần một loạt các tập lệnh bash thực thi các lệnh aws cli.
4 năm trước, tôi đã bắt đầu với các tập lệnh đơn giản được gọi là lệnh tạo ngăn xếp đám mây aws. Chẳng mấy chốc kịch bản đã không còn đơn giản nữa. Mỗi bài học được học làm cho kịch bản ngày càng phức tạp hơn. Nó không chỉ khó mà còn đầy lỗi.
Tôi hiện đang làm việc trong một bộ phận CNTT nhỏ. Kinh nghiệm đã chỉ ra rằng mỗi nhóm có cách triển khai các ngăn xếp thông tin đám mây riêng. Và điều đó thật tệ. Sẽ tốt hơn nếu mọi người có cùng cách tiếp cận. May mắn thay, có rất nhiều công cụ có sẵn để giúp bạn triển khai và định cấu hình ngăn xếp thông tin đám mây.
Những bài học này sẽ giúp bạn tránh được những sai lầm.
Nguồn: www.habr.com