雲端資源煙霧測試與最佳實踐

在雲端環境佈署應用程式時，確保服務的健康狀態至關重要。煙霧測試作為一種快速驗證機制，能有效確認佈署的資源是否按預期運作。本文以 AWS CloudFormation 為例，說明如何實施煙霧測試，並結合 CI/CD 流程強化 IaC 的可靠性。首先，我們會以 Auto Scaling Group 的組態驗證作為切入點，示範如何撰寫 Python 指令碼來檢查 AMI ID、UserData 等關鍵設定。接著，會進一步探討 VPC 資源的驗證，例如確認私有子網與路由表的正確關聯，並提供相關的 Python 指令碼範例。最後，文章將總結 CloudFormation 堆積疊發布管理的最佳實踐，包含版本控制、依賴項管理以及專案目錄結構的規劃，以提升團隊協作效率和程式碼的可維護性。

在您的堆積疊上執行煙霧測試

在佈署應用程式時，如何確定我們的應用程式是健康的？除了監控、紀錄和警示外，還有一種稱為煙霧測試的方法。

煙霧測試

煙霧測試是一種在應用程式釋出期間或之後進行的測試方法。它幫助我們瞭解目前的釋出版本是否功能正常，或者是否包含需要立即回復的錯誤或故障。

自動擴充套件群組的煙霧測試

例如，我們使用一個Elastic Load Balancer（ELB）來佈建一個自動擴充套件群組（ASG）。ASG將根據啟動組態或啟動範本執行一個或多個例項。在佈建過程中，我們可以在EC2例項上安裝網頁伺服器軟體，並設定ASG在ELB健康檢查失敗時替換例項。這些都可以使用CloudFormation進行佈建。

以下是一個範例範本（部分資源遺失，因為我使用的是預設VPC）。完整的範本請參閱以下原始碼： // broken_asg.yaml（部分）

AWSTemplateFormatVersion: "2010-09-09"
Parameters:
  # ...
Resources:
  Lc:
    Type: "AWS::AutoScaling::LaunchConfiguration"
    Properties:
      ImageId: !Ref AmiId
      InstanceType: "t2.micro"
      UserData: 
        Fn::Base64: |
          #!/bin/bash
          yum -y install yolo
          systemctl start yolo
      SecurityGroups:
        - !Ref Sg
  Asg:
    Type: "AWS::AutoScaling::AutoScalingGroup"
    Properties:
      # ...
      LaunchConfigurationName: !Ref Lc
      # ...
# The rest of the resources...
Outputs:
  Dns:
    Value: !GetAtt Elb.DNSName

內容解密：

此範本定義了一個自動擴充套件群組（ASG）和一個啟動組態（LaunchConfiguration）。啟動組態中包含了一個UserData指令碼，該指令碼試圖安裝名為yolo的軟體包並啟動它。然而，這個軟體包可能不存在，導致例項啟動失敗。

當我們佈署這個範本時，CloudFormation會報告堆積疊建立成功：

$ aws cloudformation deploy \
  --template-file broken_asg.yaml \
  --stack-name broken \
  --parameter-overrides VpcId=vpc-12345678 \
  SubnetIds=subnet-123,subnet-456,subnet-789,subnet-012,subnet-345,subnet-678
Waiting for changeset to be created..
Waiting for stack create/update to complete
Successfully created/updated stack - broken

然而，如果我們嘗試透過ELB的URL進行存取，會看到503錯誤：

$ aws cloudformation describe-stacks \
  --stack-name broken \
  --query 'Stacks[0].Outputs[0].OutputValue' \
  --output text
broken-Elb-157OHF7S5UYIC-1875871321.us-east-1.elb.amazonaws.com
$ curl broken-Elb-157OHF7S5UYIC-1875871321.us-east-1.elb.amazonaws.com
<html>
<head><title>503 Service Temporarily Unavailable</title></head>
<body bgcolor="white">
<center><h1>503 Service Temporarily Unavailable</h1></center>
</body>
</html>

這是因為啟動組態中的UserData指令碼執行失敗，導致例項無法正常啟動。ASG嘗試啟動和終止例項，但CloudFormation並未意識到這一點。

煙霧測試指令碼

為瞭解決這個問題，我們可以編寫一個小的Python指令碼來進行煙霧測試：

// asg_test.py
import sys
import boto3
import requests
from time import sleep

try:
    stack = sys.argv[1]
except IndexError:
    print('Please provide a stack name')
    sys.exit(1)

cfn_client = boto3.client('cloudformation')

try:
    stack = cfn_client.describe_stacks(StackName=stack)
except botocore.exceptions.ClientError:
    print('This stack does not exist or region is incorrect')
    sys.exit(1)

elb_dns = stack['Stacks'][0]['Outputs'][0]['OutputValue']

for _ in range(0, 2):
    resp = requests.get(f'http://{elb_dns}')
    if resp.status_code == 200:
        print('Test succeeded')
        sys.exit(0)
    sleep(5)

print(f'Result of test: {resp.content}')
print(f'HTTP Response code: {resp.status_code}')
print('Test did not succeed')
sys.exit(1)

內容解密：

此指令碼接受一個堆積疊名稱作為引數，查詢CloudFormation API取得ELB的DNS名稱，然後對該DNS名稱發起HTTP請求。如果收到200 OK的回應，則測試成功；否則，測試失敗。

當我們對broken堆積疊執行此指令碼時，會看到測試失敗的結果：

$ python asg_test.py broken
Result of test: b'<html>\r\n<head><title>503 Service Temporarily Unavailable</title></head>\r\n<body bgcolor="white">\r\n<center><h1>503 Service Temporarily Unavailable</h1></center>\r\n</body>\r\n</html>\r\n'
HTTP Response code: 503
Test did not succeed

修正範本

修正範本中的錯誤後，我們可以重新佈署堆積疊並再次進行測試： // working_asg.yaml

# Parameters section...
Resources:
  Lc:
    Type: "AWS::AutoScaling::LaunchConfiguration"
    Properties:
      ImageId: !Ref AmiId
      InstanceType: "t2.micro"
      UserData: 
        Fn::Base64: |
          #!/bin/bash
          yum -y install httpd
          systemctl start httpd
      SecurityGroups:
        - !Ref Sg
  Asg:
    Type: "AWS::AutoScaling::AutoScalingGroup"
    Properties:
      # ...
      LaunchConfigurationName: !Ref Lc
      # ...

內容解密：

在修正後的範本中，我們將UserData指令碼修改為安裝httpd軟體包並啟動它，這樣例項就可以正常啟動並提供網頁服務。

透過煙霧測試，我們可以及時發現堆積疊佈署中的問題並進行修正，確保我們的應用程式健康執行。

煙霧測試的重要性

煙霧測試是確保應用程式佈署成功的關鍵步驟。它可以幫助我們及時發現問題，避免因佈署失敗而導致的損失。

未來，我們可以進一步完善煙霧測試的流程，例如增加更多的測試案例、使用更先進的測試工具等，以確保我們的應用程式佈署更加穩定可靠。

煙霧測試的最佳實踐

定期進行煙霧測試：定期進行煙霧測試可以幫助我們及時發現問題，避免因佈署失敗而導致的損失。
使用自動化測試工具：使用自動化測試工具可以幫助我們簡化煙霧測試的流程，提高測試效率。
增加測試案例：增加測試案例可以幫助我們更全面地測試應用程式，確保應用程式的穩定性。

煙霧測試的挑戰

測試案例的編寫：編寫有效的測試案例是煙霧測試的關鍵挑戰之一。
測試工具的選擇：選擇合適的測試工具是煙霧測試的另一個挑戰。
測試結果的分析：分析測試結果是煙霧測試的重要步驟，需要仔細分析測試結果以確定問題所在。

煙霧測試流程

  graph LR
    A[開始] --> B[佈署堆積疊]
    B --> C[執行煙霧測試]
    C --> D{測試成功?}
    D -->|是| E[結束]
    D -->|否| F[修正錯誤]
    F --> B

圖表翻譯： 此圖表展示了煙霧測試的流程。首先，我們佈署堆積疊，然後執行煙霧測試。如果測試成功，則流程結束；如果測試失敗，則修正錯誤並重新佈署堆積疊。

雲端資源煙霧測試與持續整合佈署的最佳實踐

在現代化的雲端基礎設施管理中，確保資源組態正確是至關重要的。煙霧測試（Smoke Testing）是一種有效的驗證方法，用於確認基礎設施資源是否正確組態及運作。本文將探討如何使用AWS CloudFormation進行煙霧測試，並結合持續整合/持續佈署（CI/CD）流程，確保基礎設施即程式碼（Infrastructure as Code, IaC）的正確性和可靠性。

煙霧測試的必要性

煙霧測試的主要目標是驗證佈署的資源是否符合預期功能。對於使用AWS CloudFormation的基礎設施，這意味著檢查資源的屬性、關聯和組態是否正確。例如，在佈署一個包含Auto Scaling Group的堆積疊時，我們需要確保啟動組態（Launch Configuration）正確設定了AMI ID、例項型別和使用者資料（UserData）。

示例：驗證Auto Scaling Group的組態

Type: "AWS::AutoScaling::LaunchConfiguration"
Properties:
  ImageId: !Ref AmiId
  InstanceType: "t2.micro"
  UserData:
    Fn::Base64: |
      #!/bin/bash
      amazon-linux-extras install -y epel
      yum -y install nginx
      systemctl start nginx
  SecurityGroups:
    - !Ref Sg

煙霧測試指令碼

為了驗證上述組態，我們可以編寫一個煙霧測試指令碼，檢查堆積疊中的資源是否正確組態。以下是一個簡單的Python指令碼示例：

# asg_test.py
import boto3
import sys

try:
    stack = sys.argv[1]
except IndexError:
    print('請提供堆積疊名稱')
    sys.exit(1)

cfn_client = boto3.client('cloudformation')
try:
    resources = cfn_client.describe_stack_resources(StackName=stack)
except botocore.exceptions.ClientError:
    print('該堆積疊不存在或區域不正確')
    sys.exit(1)

# 進一步的資源驗證邏輯

內容解密：

此指令碼首先解析命令列引數，驗證堆積疊是否存在，然後使用describe_stack_resources方法取得堆積疊中的資源。接下來，我們可以新增邏輯來驗證特定資源的組態，例如檢查Auto Scaling Group的啟動組態是否正確。

VPC資源的煙霧測試

對於VPC資源，例如子網（Subnet），我們需要確保私有子網與正確的路由表（Route Table）關聯。以下步驟展示瞭如何進行這種驗證：

標記子網：為公有和私有子網新增不同的標籤。
- 公有子網：Key: "Private", Value: "False"
- 私有子網：Key: "Private", Value: "True"
篩選資源：使用AWS SDK篩選出AWS::EC2::Subnet型別的資源，並檢查其標籤。
驗證關聯：檢查私有子網是否與私有路由表關聯。

示例程式碼：驗證私有子網與路由表的關聯

# core_subnets.py
import boto3
import sys

# 取得堆積疊資源並篩選私有子網
cfn_client = boto3.client('cloudformation')
ec2_client = boto3.client('ec2')

try:
    stack = sys.argv[1]
    resources = cfn_client.describe_stack_resources(StackName=stack)
except IndexError:
    print('請提供堆積疊名稱')
    sys.exit(1)
except botocore.exceptions.ClientError:
    print('該堆積疊不存在或區域不正確')
    sys.exit(1)

subnets_in_stack = []
private_route_table = None

for resource in resources['StackResources']:
    if resource['ResourceType'] == 'AWS::EC2::Subnet':
        subnets_in_stack.append(resource['PhysicalResourceId'])
    elif resource['LogicalResourceId'] == 'PrivateRouteTable':
        private_route_table = resource['PhysicalResourceId']

# 檢查私有子網的標籤並驗證路由表關聯
subnets_to_check = []
for subnet in subnets_in_stack:
    resp = ec2_client.describe_subnets(SubnetIds=[subnet])
    for tag in resp['Subnets'][0]['Tags']:
        if tag['Key'] == 'Private' and tag['Value'] == 'True':
            subnets_to_check.append(subnet)

route_table = ec2_client.describe_route_tables(RouteTableIds=[private_route_table])
private_subnets = [assoc['SubnetId'] for assoc in route_table['RouteTables'][0]['Associations']]

for subnet in subnets_to_check:
    if subnet not in private_subnets:
        print('一個或多個私有子網未與正確的路由表關聯！')
        sys.exit(1)

print('所有子網均符合規範！')
exit(0)

內容解密：

此指令碼首先取得堆積疊中的資源，篩選出子網和私有路由表。然後，它檢查每個子網的標籤，篩選出私有子網。最後，驗證這些私有子網是否與正確的私有路由表關聯。如果發現任何未正確關聯的子網，指令碼將輸出錯誤並離開。

CloudFormation堆積疊的發布管理最佳實踐

在進行持續整合和持續佈署（CI/CD）時，遵循最佳實踐對於確保基礎設施的穩定性和可維護性至關重要。

使用版本控制系統：將CloudFormation範本儲存在版本控制系統（如Git）中，以便跟蹤變更歷史並協同工作。
確保依賴項易於檢索：對於自定義的linter規則和煙霧測試指令碼，確保其依賴項（如pip包）易於安裝和解析。
保持程式碼函式庫整潔：合理組織CloudFormation範本和相關指令碼，例如將煙霧測試存放在tests資料夾中，將自定義linter規則存放在custom_rules目錄中。

示例：目錄結構

cloudformation-repo/
├── templates/
│   ├── core.yaml
│   └── network.yaml
├── tests/
│   ├── asg_test.py
│   └── core_subnets.py
├── custom_rules/
│   └── custom_linter_rule.py
└── requirements.txt

內容解密：

此目錄結構清晰地組織了CloudFormation範本、測試指令碼和自定義linter規則。requirements.txt檔案列出了所有必要的Python包，以便於環境設定。

整合更多測試工具：探索並整合更多測試工具和框架，以增強測試覆寫率和效率。
自動化測試流程：將煙霧測試和單元測試自動化整合到CI/CD管道中，實作快速反饋和迭代。
增強視覺化：使用視覺化工具呈現測試結果和基礎設施狀態，提高可讀性和決策效率。

透過持續改進和最佳化，我們可以確保雲端基礎設施的穩定性和可靠性，滿足不斷變化的業務需求。

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。