教程：自动验证测试

作为构建已启用 Arc 的数据服务的每个提交的一部分，Microsoft 会运行执行端到端测试的自动化 CI/CD 管道。 这些测试通过两个容器进行协调，这些容器与核心产品一起维护。 这些容器包括：

• arc-ci-launcher：包含直接和间接连接模式的部署依赖项（例如 CLI 扩展）以及产品部署代码（使用 Azure CLI）。 Once Kubernetes is onboarded with the Data Controller, the container leverages Sonobuoy to trigger parallel integration tests.
• arc-sb-plugin: A Sonobuoy plugin containing Pytest-based end-to-end integration tests, ranging from simple smoke-tests (deployments, deletes), to complex high-availability scenarios, chaos-tests (resource deletions) etc.

这些测试容器公开提供给客户和合作伙伴，用于在他们自己的 Kubernetes 群集中执行已启用 Arc 的数据服务验证测试，以验证以下内容：

• Kubernetes distro/versions
• Host disto/versions
• 存储 (StorageClass/CSI)、网络（例如 LoadBalancer、DNS）
• Kubernetes 或基础结构特定的其他设置

对于打算在未记录的分发版上运行已启用 Arc 的数据服务的客户，必须成功运行这些验证测试才能确认支持这些服务。 此外，合作伙伴可以使用此方法来验证其解决方案是否符合已启用 Arc 的数据服务 - 请参阅已启用 Azure Arc 的数据服务 Kubernetes 验证。

下图概述了该过程：

在本教程中，你将了解如何执行以下操作：

Prerequisites

• Credentials:

  • test.env.tmpl 文件包含所需的必要凭据，并且是加入 Azure Arc 已连接群集和直接连接数据控制器所需的现有先决条件的组合。 下面的示例介绍如何设置此文件。
  • A kubeconfig file to the tested Kubernetes cluster with cluster-admin access (required for Connected Cluster onboarding at this time)

• Client-tooling:

  • 已安装 kubectl - 最低版本（主要版本：“1”，次要版本：“21”）
  • git 命令行接口（或基于 UI 的替代方法）

准备 Kubernetes 清单

The launcher is made available as part of the microsoft/azure_arc repository, as a Kustomize manifest - Kustomize is built into kubectl - so no additional tooling is required.

1. 在本地克隆存储库：

git clone https://github.com/microsoft/azure_arc.git

2. 导航到 azure_arc/arc_data_services/test/launcher，查看以下文件夹结构：

├── base                                         <- Comon base for all Kubernetes Clusters
│   ├── configs
│   │   └── .test.env.tmpl                       <- To be converted into .test.env with credentials for a Kubernetes Secret
│   ├── kustomization.yaml                       <- Defines the generated resources as part of the launcher
│   └── launcher.yaml                            <- Defines the Kubernetes resources that make up the launcher
└── overlays                                     <- Overlays for specific Kubernetes Clusters
    ├── aks
    │   ├── configs
    │   │   └── patch.json.tmpl                  <- To be converted into patch.json, patch for Data Controller control.json
    │   └── kustomization.yaml
    ├── kubeadm
    │   ├── configs
    │   │   └── patch.json.tmpl
    │   └── kustomization.yaml
    └── openshift
        ├── configs
        │   └── patch.json.tmpl
        ├── kustomization.yaml
        └── scc.yaml

在本教程中，我们将重点介绍设置 AKS 的步骤，但上述覆盖结构可以扩展为包含其他 Kubernetes 分发版。

部署准备清单如下所示：

├── base
│   ├── configs
│   │   ├── .test.env                           <- Config 1: For Kubernetes secret, see sample below
│   │   └── .test.env.tmpl
│   ├── kustomization.yaml
│   └── launcher.yaml
└── overlays
    └── aks
        ├── configs
        │   ├── patch.json.tmpl
        │   └── patch.json                      <- Config 2: For control.json patching, see sample below
        └── kustomization.yam

需要生成两个文件来本地化启动器，以便在特定环境中运行。 可以通过复制粘贴和填写上述的每个模板 (*.tmpl) 文件来生成这些文件：

• .test.env：在 .test.env.tmpl 进行填写
• patch.json：在 patch.json.tmpl 进行填写

Config 1：.test.env

基于 .test.env 生成的 .test.env.tmpl 文件的填写示例分享在下面的内联注释中。

换句话说，复制粘贴 .test.env.tmpl 并编辑以创建 .test.env 后，生成的文件应类似于以下示例。 填写 .test.env 文件的过程在操作系统和终端上是相同的。

.test.env 的已完成示例：

# ======================================
# Arc Data Services deployment version =
# ======================================

# Controller deployment mode: direct, indirect
# For 'direct', the launcher will also onboard the Kubernetes Cluster to Azure Arc
# For 'indirect', the launcher will skip Azure Arc and extension onboarding, and proceed directly to Data Controller deployment - see `patch.json` file
export CONNECTIVITY_MODE="direct"

# The launcher supports deployment of both GA/pre-GA trains - see detailed explanation below [1]
export ARC_DATASERVICES_EXTENSION_RELEASE_TRAIN="stable"
export ARC_DATASERVICES_EXTENSION_VERSION_TAG="1.11.0"

# Image version
export DOCKER_IMAGE_POLICY="Always"
export DOCKER_REGISTRY="mcr.microsoft.com"
export DOCKER_REPOSITORY="arcdata"
export DOCKER_TAG="v1.11.0_2022-09-13"

# "arcdata" Azure CLI extension version override - see detailed explanation below [2]
export ARC_DATASERVICES_WHL_OVERRIDE=""

# ================
# ARM parameters =
# ================

# Custom Location Resource Provider Azure AD Object ID - this is a single, unique value per Azure AD tenant - see detailed explanation below [3]
export CUSTOM_LOCATION_OID="..."

# A pre-rexisting Resource Group is used if found with the same name. Otherwise, launcher will attempt to create a Resource Group
# with the name specified, using the Service Principal specified below (which will require `Owner/Contributor` at the Subscription level to work)
export LOCATION="eastus"
export RESOURCE_GROUP_NAME="..."

# A Service Principal with "sufficient" privileges - see detailed explanation below [4]
export SPN_CLIENT_ID="..."
export SPN_CLIENT_SECRET="..."
export SPN_TENANT_ID="..."
export SUBSCRIPTION_ID="..."

# Optional: certain integration tests test upload to Log Analytics workspace:
# https://free.blessedness.top/azure/azure-arc/data/upload-logs
export WORKSPACE_ID="..."
export WORKSPACE_SHARED_KEY="..."

# ====================================
# Data Controller deployment profile =
# ====================================

# Samples for AKS
# To see full list of CONTROLLER_PROFILE, run: az arcdata dc config list
export CONTROLLER_PROFILE="azure-arc-aks-default-storage"

# azure, aws, gcp, onpremises, alibaba, other
export DEPLOYMENT_INFRASTRUCTURE="azure"

# The StorageClass used for PVCs created during the tests 
export KUBERNETES_STORAGECLASS="default"

# ==============================
# Launcher specific parameters =
# ==============================

# Log/test result upload from launcher container, via SAS URL - see detailed explanation below [5]
export LOGS_STORAGE_ACCOUNT="<your-storage-account>"
export LOGS_STORAGE_ACCOUNT_SAS="?sv=2021-06-08&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=...&spr=https&sig=..."
export LOGS_STORAGE_CONTAINER="arc-ci-launcher-1662513182"

# Test behavior parameters
# The test suites to execute - space seperated array, 
# Use these default values that run short smoke tests, further elaborate test suites will be added in upcoming releases
export SQL_HA_TEST_REPLICA_COUNT="3"
export TESTS_DIRECT="direct-crud direct-hydration controldb"
export TESTS_INDIRECT="billing controldb kube-rbac"
export TEST_REPEAT_COUNT="1"
export TEST_TYPE="ci"

# Control launcher behavior by setting to '1':
#
# - SKIP_PRECLEAN: Skips initial cleanup
# - SKIP_SETUP: Skips Arc Data deployment
# - SKIP_TEST: Skips sonobuoy tests
# - SKIP_POSTCLEAN: Skips final cleanup
# - SKIP_UPLOAD: Skips log upload
#
# See detailed explanation below [6]
export SKIP_PRECLEAN="0"
export SKIP_SETUP="0"
export SKIP_TEST="0"
export SKIP_POSTCLEAN="0"
export SKIP_UPLOAD="0"

特定变量的详细说明

1. ARC_DATASERVICES_EXTENSION_* - 扩展版本和训练

必需：对于 direct 模式部署是必需的。

启动器可以部署正式发布版本和预正式发布版本。

可从此处获取发布训练 (ARC_DATASERVICES_EXTENSION_RELEASE_TRAIN) 映射的扩展版本：

• GA: stable - Version log
• Pre-GA: preview - Pre-release testing

2. ARC_DATASERVICES_WHL_OVERRIDE - Azure CLI 以前版本的下载 URL

可选：在 .test.env 中将此留空以使用预打包的默认值。

启动器映像在每个容器映像发布时使用最新的 arcdata CLI 版本进行预打包。 However, to work with older releases and upgrade testing, it may be necessary to provide the launcher with Azure CLI Blob URL download link, to override the pre-packaged version; e.g to instruct the launcher to install version 1.4.3, fill in:

export ARC_DATASERVICES_WHL_OVERRIDE="https://azurearcdatacli.blob.core.windows.net/cli-extensions/arcdata-1.4.3-py2.py3-none-any.whl"

The CLI version to Blob URL mapping can be found here.

3. CUSTOM_LOCATION_OID - 特定 Microsoft Entra 租户的自定义位置对象 ID

必需：对于创建连接的群集自定义位置是必需的。

以下步骤来自在群集上启用自定义位置，用于检索 Microsoft Entra 租户的唯一自定义位置对象 ID。

有两种方法来获取 Microsoft Entra 租户的 CUSTOM_LOCATION_OID。

1. 通过 Azure CLI：

   az ad sp show --id bc313c14-388c-4e7d-a58e-70017303ee3b --query objectId -o tsv
   # 51dfe1e8-70c6-4de...      <--- This is for Microsoft's own tenant - do not use, the value for your tenant will be different, use that instead to align with the Service Principal for launcher.
   

   

2. 通过 Azure 门户 - 导航到 Microsoft Entra 边栏选项卡，然后搜索 Custom Locations RP：

   

4. SPN_CLIENT_* - 服务主体凭据

必需：对于 Direct 模式部署是必需的。

启动器使用这些凭据登录到 Azure。

验证测试旨在针对“非生产/测试 Kubernetes 群集和 Azure 订阅”执行——主要对 Kubernetes/基础结构设置进行功能验证。 因此，为避免执行启动所需的大量手动步骤，建议在资源组（或订阅）级别提供具有 SPN_CLIENT_ID/SECRET 的 Owner，因为它也会在此资源组中创建多个资源，并根据在部署过程中创建的多个托管标识为这些资源分配权限（这些角色分配转而要求服务主体具有 Owner）。

5. LOGS_STORAGE_ACCOUNT_SAS - Blob 存储帐户 SAS URL

建议：将此项保留为空意味着不会获得测试结果和日志。

The launcher needs a persistent location (Azure Blob Storage) to upload results to, as Kubernetes doesn't (yet) allow copying files from stopped/completed pods - see here. 启动器使用“帐户范围的 SAS URL”（相对于容器或 blob 范围）实现与 Azure Blob 存储的连接 - 具有时间限制访问定义的签名 URL - 请参阅使用共享访问签名 (SAS) 授予对 Azure 存储资源的有限访问权限，以执行以下操作：

1. 在预先存在的存储帐户 (LOGS_STORAGE_ACCOUNT) 中创建新的存储容器（如果容器不存在（名称基于 LOGS_STORAGE_CONTAINER））
2. 创建新的、唯一命名的 blob（测试日志 tar 文件）

以下步骤源自使用共享访问签名 (SAS) 授予对 Azure 存储资源的有限访问权限。

?sv=2021-06-08&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=...&spr=https&sig=...

有多种方法可以生成 SAS URL。 此示例显示门户：

若要改用 Azure CLI，请参阅 az storage account generate-sas

6. SKIP_* - 通过跳过某些阶段来控制启动器的行为

可选：在 .test.env 中将此留空以运行所有阶段（等效于 0 或空白）

启动器公开 SKIP_* 变量，以运行和跳过特定阶段 - 例如，执行“仅清理”运行。

尽管启动器旨在在每次运行的开始和结束时进行清理，但启动和/或测试失败可能会留下剩余资源。 若要在“仅清理”模式下运行启动器，请在 .test.env 中设置以下变量：

export SKIP_PRECLEAN="0"         # Run cleanup
export SKIP_SETUP="1"            # Do not setup Arc-enabled Data Services
export SKIP_TEST="1"             # Do not run integration tests
export SKIP_POSTCLEAN="1"        # POSTCLEAN is identical to PRECLEAN, although idempotent, not needed here
export SKIP_UPLOAD="1"           # Do not upload logs from this run

上述设置指示启动器清理所有 Arc 和 Arc 数据服务资源，且不部署/测试/上传日志。

Config 2：patch.json

基于 patch.json 生成的 patch.json.tmpl 文件的填写示例如下所示：

请注意，spec.docker.registry, repository, imageTag 应与上述 .test.env 中的值相同

patch.json 的已完成示例：

{
    "patch": [
        {
            "op": "add",
            "path": "spec.docker",
            "value": {
                "registry": "mcr.microsoft.com",
                "repository": "arcdata",
                "imageTag": "v1.11.0_2022-09-13",
                "imagePullPolicy": "Always"
            }
        },        
        {
            "op": "add",
            "path": "spec.storage.data.className",
            "value": "default"
        },  
        {
            "op": "add",
            "path": "spec.storage.logs.className",
            "value": "default"
        }                  
    ]
}

Launcher deployment

It is recommended to deploy the launcher in a Non-Production/Test cluster - as it performs destructive actions on Arc and other used Kubernetes resources.

imageTag 规范

启动器在 Kubernetes 清单中定义为一个 Job，这需要指示 Kubernetes 在哪里查找启动器映像。 在 base/kustomization.yaml 中对其进行设置：

images:
- name: arc-ci-launcher
  newName: mcr.microsoft.com/arcdata/arc-ci-launcher
  newTag: v1.11.0_2022-09-13

kubectl apply

若要验证清单是否已正确设置，请尝试使用 --dry-run=client 进行客户端验证，这会输出要为启动器创建的 Kubernetes 资源：

kubectl apply -k arc_data_services/test/launcher/overlays/aks --dry-run=client
# namespace/arc-ci-launcher created (dry run)
# serviceaccount/arc-ci-launcher created (dry run)
# clusterrolebinding.rbac.authorization.k8s.io/arc-ci-launcher created (dry run)
# secret/test-env-fdgfm8gtb5 created (dry run)                                        <- Created from Config 1: `patch.json`
# configmap/control-patch-2hhhgk847m created (dry run)                                <- Created from Config 2: `.test.env`
# job.batch/arc-ci-launcher created (dry run)

若要部署启动器和结尾日志，请运行以下命令：

kubectl apply -k arc_data_services/test/launcher/overlays/aks
kubectl wait --for=condition=Ready --timeout=360s pod -l job-name=arc-ci-launcher -n arc-ci-launcher
kubectl logs job/arc-ci-launcher -n arc-ci-launcher --follow

此时，启动器应会启动 - 可以看到以下内容：

尽管最好在没有预先存在的 Arc 资源的群集中部署启动器，但在部署新版本之前，启动器会包含预运行验证以发现预先存在的 Arc 和 Arc 数据服务 CRD 和 ARM 资源，并尝试（使用提供的服务主体凭据）对其进行清理：

启动器退出时也会运行相同的元数据发现和清理过程，使群集尽可能接近启动前处于的状态。

启动器执行的步骤

启动器大致按以下步骤顺序执行：

1. 使用 Pod 装载的服务帐户向 Kubernetes API 进行身份验证

2. 使用机密装载的服务主体向 ARM API 进行身份验证

3. 执行 CRD 元数据扫描以发现现有的 Arc 和 Arc 数据服务自定义资源

4. 清理 Kubernetes 中的任何现有自定义资源，以及 Azure 中的后续资源。 如果 .test.env 中的凭据与群集中现有的资源存在任何不匹配，请退出。

5. 根据 Arc 群集名称、数据控制器和自定义位置/命名空间的时间戳生成唯一的环境变量集。 输出环境变量、模糊处理敏感值（例如服务主体密码等）

6. a. 对于直接模式 - 将群集加入 Azure Arc，然后部署控制器。

   b. 对于间接模式：部署数据控制器

7. 数据控制器 Ready 后，生成一组 Azure CLI (az arcdata dc debug) 日志并在本地存储，标记为 setup-complete - 作为基线。

8. 使用 TESTS_DIRECT/INDIRECT 的 .test.env 环境变量来启动一组基于空格分隔数组 (TESTS_(IN)DIRECT) 的并行化 Sonobuoy 测试运行。 这些运行使用包含 Pytest 验证测试的 sonobuoy Pod 在新的 arc-sb-plugin 命名空间中执行。

9. Sonobuoy aggregator accumulate the junit test results and logs per arc-sb-plugin test run, which are exported into the launcher pod.

10. 返回测试的退出代码，并生成另一组调试日志 - Azure CLI 和 sonobuoy - 存储在本地，标记为 test-complete。

11. 执行步骤 3 类似的 CRD 元数据扫描，以发现现有的 Arc 和 Arc 数据服务自定义资源。 然后，继续按照与部署过程相反的顺序销毁所有 Arc 和 Arc 数据资源，以及 CRD、Role/ClusterRoles、PV/PVC 等。

12. Attempt to use the SAS token LOGS_STORAGE_ACCOUNT_SAS provided to create a new Storage Account container named based on LOGS_STORAGE_CONTAINER, in the pre-existing Storage Account LOGS_STORAGE_ACCOUNT. 如果存储帐户容器已存在，请使用它。 将所有本地测试结果和日志作为 tarball 上传到此存储容器（见下文）。

13. Exit.

每个测试套件执行的测试

There are approximately 375 unique integration tests available, across 27 test suites - each testing a separate functionality.

例如，对于 sqlinstance-ha，执行以下测试：

• test_critical_configmaps_present：确保存在 SQL 实例的 ConfigMaps 和相关字段。
• test_suspended_system_dbs_auto_heal_by_orchestrator：确保 master 和 msdb 是否以任何方式挂起（在本例中为用户）。 Orchestrator 维护协调会自动修复它。
• test_suspended_user_db_does_not_auto_heal_by_orchestrator：确保如果用户故意挂起用户数据库，Orchestrator 维护协调不会自动修复它。
• test_delete_active_orchestrator_twice_and_delete_primary_pod：多次删除业务流程协调程序 pod，然后删除主要副本，并验证所有副本是否同步。 放宽了对 2 个副本的故障转移时间预期。
• test_delete_primary_pod：删除主要副本并验证所有副本是否同步。 放宽了对 2 个副本的故障转移时间预期。
• test_delete_primary_and_orchestrator_pod：删除主要副本和业务流程协调程序 pod，并验证所有副本是否已同步。
• test_delete_primary_and_controller：删除主要副本和数据控制器 pod，并验证主终结点是否可访问以及新的主要副本是否已同步。 放宽了对 2 个副本的故障转移时间预期。
• test_delete_one_secondary_pod：删除次要副本和数据控制器 pod，并验证所有副本是否已同步。
• test_delete_two_secondaries_pods：删除次要副本和数据控制器 pod，并验证所有副本是否已同步。
• test_delete_controller_orchestrator_secondary_replica_pods:
• test_failaway：强制 AG 故障转移远离当前主要副本，确保新主要副本与旧主要副本不同。 验证所有副本是否已同步。
• test_update_while_rebooting_all_non_primary_replicas：测试控制器驱动的更新在各种动荡的情况下都有重试的可复原性。

检查测试结果

启动器上传的示例存储容器和文件：

以及运行中生成的测试结果：

清理资源

若要删除启动器，请运行：

kubectl delete -k arc_data_services/test/launcher/overlays/aks

这会清理作为启动器一部分部署的资源清单。

Related content