Share via

Руководство. Автоматическое тестирование проверки

  • Статья

В рамках каждой фиксации, которая создает службы данных с поддержкой Arc, корпорация Майкрософт запускает автоматизированные конвейеры CI/CD, выполняющие комплексные тесты. Эти тесты управляются двумя контейнерами, которые поддерживаются вместе с основным продуктом (контроллер данных, Управляемый экземпляр SQL включен сервером Azure Arc и PostgreSQL). Эти контейнеры:

  • arc-ci-launcher: содержит зависимости развертывания (например, расширения CLI), а также код развертывания продукта (с помощью Azure CLI) для режимов прямого и косвенного подключения. После подключения Kubernetes к контроллеру данных контейнер использует Sonobuoy для запуска параллельных тестов интеграции.
  • arc-sb-plugin: подключаемый модуль Sonobuoy, содержащий сквозные тесты интеграции Pytest, начиная от простых тестов дыма (развертывания, удаления), до сложных сценариев высокой доступности, хаос-тестов (удаление ресурсов) и т. д.

Эти контейнеры тестирования становятся общедоступными для клиентов и партнеров для тестирования служб данных с поддержкой Arc в собственных кластерах Kubernetes, работающих в любом месте, для проверки:

  • Дистрибутивы и версии Kubernetes
  • Disto/versions узла
  • служба хранилища (/CSI), сети (StorageClassнапримерLoadBalancer, DNS)
  • Другие настройки Kubernetes или инфраструктуры

Для клиентов, намеревающихся запускать службы данных с поддержкой Arc в незадокументированных дистрибутивах, они должны успешно выполнять эти тесты проверки, чтобы считаться поддерживаемыми. Кроме того, партнеры могут использовать этот подход для сертификации своего решения, совместимого с службами данных с поддержкой Arc. См . проверку Kubernetes с поддержкой Azure Arc.

На следующей схеме описывается этот высокоуровневый процесс:

Diagram that shows the Arc-enabled data services Kube-native integration tests.

В этом руководстве описано следующее:

  • Развертывание arc-ci-launcher с помощью kubectl
  • Проверка результатов проверки в учетной записи Хранилище BLOB-объектов Azure

Необходимые компоненты

  • Учетные данные:

  • Клиентские инструменты:

    • kubectl установленный — минимальная версия (основной:"1", дополнительный:"21")
    • git интерфейс командной строки (или альтернативные варианты на основе пользовательского интерфейса)

Подготовка манифеста Kubernetes

Средство запуска становится доступным как часть microsoft/azure_arc репозитория, так как манифест Kustomize — Kustomizeвстроен kubectl в - поэтому дополнительные средства не требуются.

  1. Клонируйте репозиторий локально:
git clone https://github.com/microsoft/azure_arc.git
  1. Перейдите к разделу 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

Совет

Это .test.env один набор переменных среды, который управляет поведением средства запуска. Создание его с осторожностью для данной среды обеспечит воспроизводимость поведения средства запуска.

Конфигурация 1. .test.env

Заполненный пример .test.env файла, созданный на .test.env.tmpl основе данных ниже, используется в строковый комментарий ary.

Важно!

Приведенный export VAR="value" ниже синтаксис не предназначен для локального запуска в исходные переменные среды с компьютера, но есть для средства запуска. Средство запуска подключает этот .test.env файл как kubernetes secret с помощью Kustomize ( secretGenerator Kustomize принимает файл, base64 кодирует содержимое всего файла и превращает его в секрет Kubernetes). Во время инициализации средство запуска запускает команду Bash source , которая импортирует переменные среды из подключенного .test.env файла в среду средства запуска.

Другими словами, после копирования и редактирования .test.env.tmpl для создания .test.envсозданный файл должен выглядеть примерно так же, как в приведенном ниже примере. Процесс заполнения .test.env файла идентичен в операционных системах и терминалах.

Совет

Существует несколько переменных среды, требующих дополнительного объяснения для ясности в воспроизводимости. Они будут закомментированы.see detailed explanation below [X]

Совет

Обратите внимание, что приведенный .test.env ниже пример предназначен для прямого режима. Некоторые из этих переменных, например ARC_DATASERVICES_EXTENSION_VERSION_TAG не применяются к косвенному режиму. Для простоты рекомендуется настроить .test.env файл с переменными прямого режима, переключение CONNECTIVITY_MODE=indirect будет игнорировать параметры прямого режима и использовать подмножество из списка.

Другими словами, планирование прямого режима позволяет удовлетворить переменные косвенного режима.

Готовый пример .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://learn.microsoft.com/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"

Важно!

При создании файла конфигурации на компьютере Windows необходимо преобразовать последовательность завершения строки из CRLF (Windows) в (Linux) LF в качестве arc-ci-launcher контейнера Linux. Выход из конец строки, как CRLF может привести к ошибке при arc-ci-launcher запуске контейнера, например/launcher/config/.test.env: $'\r': command not found: например, выполните изменение с помощью VSCode (в нижнем правом углу окна):
Screenshot that shows where to change the end of line sequence (CRLF).

Подробное описание определенных переменных

1. ARC_DATASERVICES_EXTENSION_* — версия расширения и обучение

Обязательный: это необходимо для direct развертываний в режиме.

Средство запуска может развертывать выпуски общедоступной версии и предварительной версии.

Версия расширения для сопоставления выпуска (ARC_DATASERVICES_EXTENSION_RELEASE_TRAIN) для обучения () получена здесь:

2. ARC_DATASERVICES_WHL_OVERRIDE — URL-адрес скачивания предыдущей версии Azure CLI

Необязательно. Оставьте его пустым, .test.env чтобы использовать предварительно упакованный по умолчанию.

Образ средства запуска предварительно упаковается с последней версией интерфейса командной строки arcdata во время каждого выпуска образа контейнера. Однако для работы с более старыми выпусками и тестированием обновлений может потребоваться предоставить средству запуска ссылку на скачивание URL-адреса BLOB-объектов Azure CLI, чтобы переопределить предварительно упаковаемую версию; Например, чтобы указать средство запуска установить версию 1.4.3, заполните следующую команду:

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

Здесь можно найти версию CLI для сопоставления URL-адресов BLOB-объектов.

3. CUSTOM_LOCATION_OID — идентификатор объекта custom Locations из конкретного клиента Microsoft Entra

Обязательный: это необходимо для создания Подключение пользовательского расположения кластера.

Ниже описано, как включить пользовательские расположения в кластере , чтобы получить уникальный идентификатор объекта пользовательского расположения для клиента Microsoft Entra.

Существует два подхода к получению CUSTOM_LOCATION_OID клиента Microsoft Entra.

  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.

    A screenshot of a PowerShell terminal that shows az ad sp show --id <>.

  2. Через портал Azure — перейдите в колонку Microsoft Entra и выполните поиск:Custom Locations RP

    A screenshot of the custom locations RP.

4. SPN_CLIENT_* Учетные данные субъекта-службы

Обязательный: это необходимо для развертываний в режиме direct.

Средство запуска войдите в Azure с помощью этих учетных данных.

Тестирование проверки предназначено для кластера Kubernetes, отличного от рабочей среды и тестирования Kubernetes и подписок Azure, в фокусе на функциональной проверке установки Kubernetes/Infrastructure. Поэтому, чтобы избежать количества ручных шагов, необходимых для запуска, рекомендуется указать SPN_CLIENT_ID/SECRETOwner уровень группы ресурсов (или подписки), так как он создаст несколько ресурсов в этой группе ресурсов, а также назначать разрешения для этих ресурсов для нескольких управляемых удостоверений, созданных в рамках развертывания (эти назначения ролей, в свою очередь, требуют наличия субъекта-службы Owner).

5. LOGS_STORAGE_ACCOUNT_SAS — URL-адрес SAS учетной записи служба хранилища BLOB-объектов

Рекомендуется: выход из этого пустого означает, что вы не получите результаты теста и журналы.

Средство запуска требует постоянного расположения (Хранилище BLOB-объектов Azure) для отправки результатов, так как Kubernetes пока не разрешает копирование файлов из остановленных или завершенных модулей pod. См. здесь. Средство запуска обеспечивает подключение к Хранилище BLOB-объектов Azure с помощью URL-адреса SAS область учетной записи (в отличие от URL-адреса SAS для контейнера или большого двоичного объекта область d) — подписанный URL-адрес с определением доступа с привязкой к времени. См. раздел "Предоставление ограниченного доступа к служба хранилища Azure ресурсы с помощью подписанных URL-адресов (SAS) для:

  1. Создайте новый контейнер служба хранилища в существующей учетной записи служба хранилища (LOGS_STORAGE_ACCOUNT), если она не существует (имя на LOGS_STORAGE_CONTAINERоснове )
  2. Создание новых, уникально именованных BLOB-объектов (тестовые файлы tar журнала)

Следующие действия создаются из предоставления ограниченного доступа к ресурсам служба хранилища Azure с помощью подписанных URL-адресов (SAS).

Совет

URL-адреса SAS отличаются от ключа учетной записи служба хранилища, URL-адрес SAS форматируется следующим образом.

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

Существует несколько подходов к созданию URL-адреса SAS. В этом примере показан портал:

A screenshot of the shared access signature details on the Azure portal.

Дополнительные сведения об использовании 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 Data Services, а также не развертывать или тестировать или отправлять журналы.

Конфигурация 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"
        }                  
    ]
}

Развертывание средства запуска

Рекомендуется развернуть средство запуска в непроизводственных и тестовых кластерах , так как он выполняет разрушительные действия в Arc и других используемых ресурсах Kubernetes.

imageTag Спецификация

Средство запуска определяется в манифесте Kubernetes как a 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

Совет

Чтобы вернуться, на этом этапе - есть 3 места, которые мы указали imageTag, для ясности, вот объяснение различных использования каждого из них. Как правило, при тестировании данного выпуска все 3 значения будут одинаковыми (выравнивающимися с заданным выпуском):

# Имя файла Имя переменной Почему? Используется?
1 .test.env DOCKER_TAG Подключение образа Bootstrapper в рамках установки расширения az k8s-extension create в средство запуска
2 patch.json value.imageTag Выбор образа контроллера данных az arcdata dc create в средство запуска
3 kustomization.yaml images.newTag Определение образа средства запуска kubectl applying the launcher

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

На этом этапе средство запуска должно начаться, и вы увидите следующее:

A screenshot of the console terminal after the launcher starts.

Хотя рекомендуется развернуть средство запуска в кластере без существующих ресурсов Arc, средство запуска содержит предварительную проверку, чтобы обнаружить предварительно существующие crD Arc и Arc Data Services CRD и ресурсы ARM, и пытается очистить их на основе лучших усилий (используя предоставленные учетные данные субъекта-службы), прежде чем развертывать новый выпуск:

A screenshot of the console terminal discovering Kubernetes and other resources.

Этот же процесс обнаружения метаданных и очистки также выполняется при выходе средства запуска, чтобы оставить кластер как можно ближе к существующему состоянию перед запуском.

Действия, выполняемые средствами запуска

На высоком уровне средство запуска выполняет следующую последовательность шагов:

  1. Проверка подлинности в API Kubernetes с помощью учетной записи службы, подключенной к pod

  2. Проверка подлинности в API ARM с помощью субъекта-службы, подключенного к секрету

  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 запуска набора параллельных тестов Sonobuoy на основе разделенного пробелом массива (TESTS_(IN)DIRECT). Эти запуски выполняются в новом sonobuoy пространстве имен с помощью arc-sb-plugin pod, содержащего тесты проверки Pytest.

  9. Агрегатор Sonobuoy накапливает результаты теста и журналы для каждого arc-sb-plugin тестового выполнения, которые экспортируются junit в модуль модуля запуска.

  10. Возвращает код выхода тестов и создает другой набор журналов отладки — Azure CLI и sonobuoy — хранящийся локально, помеченный как test-complete.

  11. Выполните проверку метаданных CRD, аналогичную шагу 3, чтобы обнаружить существующие пользовательские ресурсы служб Arc и Arc. Затем перейдите к уничтожению всех ресурсов Arc и Arc Data в обратном порядке от развертывания, а также CRD, Role/ClusterRoles, PV/PVCs и т. д.

  12. Попытайтесь использовать маркер LOGS_STORAGE_ACCOUNT_SAS SAS, предоставленный для создания нового контейнера учетной записи служба хранилища с именем на основе LOGS_STORAGE_CONTAINERсуществующей учетной записи LOGS_STORAGE_ACCOUNTслужба хранилища. Если контейнер учетной записи служба хранилища уже существует, используйте его. Отправьте все локальные результаты теста и журналы в этот контейнер хранилища в виде тарбола (см. ниже).

  13. Выход.

Тесты, выполняемые для каждого набора тестов

Существует приблизительно 375 уникальных тестов интеграции, доступных в 27 наборах тестов— каждый тестирует отдельную функциональность.

Люкс # Имя набора тестов Описание теста
1 ad-connector Проверяет развертывание и обновление Подключение or Active Directory (AD Подключение or).
2 billing Тестирование различных типов лицензий критически важный для бизнеса отражается в таблице ресурсов в контроллере, используемой для отправки счетов.
3 ci-billing billingАналогично, но с большим числом перемечений ЦП или памяти.
4 ci-sqlinstance Длительные тесты для создания нескольких реплика, обновлений, GP —> обновления BC, проверки резервного копирования и агент SQL Server.
5 controldb Тесты базы данных управления — секрет SA проверка, проверка входа в систему, создание аудита и проверка для версии сборки SQL.
6 dc-export Отправка непрямого режима выставления счетов и использования.
7 direct-crud Создает экземпляр SQL с помощью вызовов ARM, проверяется как в Kubernetes, так и в ARM.
8 direct-fog Создает несколько экземпляров SQL и создает группу отработки отказа между ними с помощью вызовов ARM.
9 direct-hydration Создает экземпляр SQL с помощью API Kubernetes, проверяет наличие в ARM.
10 direct-upload Проверяет отправку выставления счетов в режиме direct
11 kube-rbac Гарантирует, что разрешения учетной записи службы Kubernetes для служб Данных Arc соответствуют ожиданиям наименьших привилегий.
12 nonroot Гарантирует, что контейнеры выполняются от имени пользователя, не являющегося корневым пользователем
13 postgres Выполняет различные тесты создания Postgres, масштабирования, резервного копирования и восстановления.
14 release-sanitychecks Sanity проверка для выпусков ежемесячной сборки, таких как версии сборки SQL Server.
15 sqlinstance Более короткая версия для быстрой ci-sqlinstanceпроверки.
16 sqlinstance-ad Проверяет создание экземпляров SQL с помощью Подключение active Directory.
17 sqlinstance-credentialrotation Проверяет автоматическую смену учетных данных для общего назначения и критически важный для бизнеса.
18 sqlinstance-ha Различные тесты высокой доступности, включая перезагрузки pod, принудительные отработки отказа и приостановки.
19 sqlinstance-tde Различные прозрачное шифрование данных тесты.
20 telemetry-elasticsearch Проверяет прием журналов в Elasticsearch.
21 telemetry-grafana Проверяет, доступен Grafana.
22 telemetry-influxdb Проверяет прием метрик в MetricDB.
23 telemetry-kafka Различные тесты для Kafka с помощью SSL, настройки с одним или несколькими брокерами.
24 telemetry-monitorstack Тесты компонентов мониторинга, такие как Fluentbit и Collectd функциональные.
25 telemetry-telemetryrouter Проверяет открытые данные телеметрии.
26 telemetry-webhook Проверяет веб-перехватчики служб данных с допустимыми и недопустимыми вызовами.
27 upgrade-arcdata Обновляет полный набор экземпляров SQL (GP, BC 2 реплика, BC 3 реплика с Active Directory) и обновляется с выпуска в прошлом месяце до последней сборки.

Например, для sqlinstance-haпримера выполняются следующие тесты:

  • test_critical_configmaps_present: гарантирует наличие конфигурации Карты и соответствующих полей для экземпляра SQL.
  • test_suspended_system_dbs_auto_heal_by_orchestrator: гарантирует, если master и msdb приостановлены любым способом (в данном случае пользователь). Обслуживание оркестратора примиряет автоматическое исцеление его.
  • 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: принудительное отработка отказа группы доступности от текущей первичной, гарантирует, что новый первичный объект не совпадает со старым первичным. Проверяет синхронизацию всех реплика.
  • test_update_while_rebooting_all_non_primary_replicas: обновления, управляемые контроллером, устойчивы с повторными попытками, несмотря на различные турбулентные обстоятельства.

Примечание.

Для некоторых тестов может потребоваться определенное оборудование, например привилегированный доступ к контроллерам домена для тестов для ad создания записи учетной записи и DNS, которые могут быть недоступны во всех средах, которые хотят использовать arc-ci-launcher.

Проверка результатов теста

Пример контейнера хранилища и файла, отправленного средством запуска:

A screenshot of the launcher storage container.

A screenshot of the launcher tarball.

И результаты теста, созданные из выполнения:

A screenshot of the launcher test results.

Очистка ресурсов

Чтобы удалить средство запуска, выполните следующую команду:

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

Это очищает манифесты ресурсов, развернутые в рамках средства запуска.

Связанный контент

Предварительное тестирование