Поделиться через

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

  • Статья

В рамках каждой фиксации, которая создает службы данных с поддержкой 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.

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

Схема, на которую показаны тесты интеграции с поддержкой Arc.

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

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

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

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

    • Файл test.env.tmpl содержит необходимые учетные данные и представляет собой сочетание существующих предварительных требований, необходимых для подключения подключенного кластера Azure Arc и контроллера данных непосредственного подключения. Настройка этого файла описана ниже с примерами.
    • Файл kubeconfig для протестированного кластера Kubernetes с cluster-admin доступом (требуется для подключения подключенного кластера в настоящее время)

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

    • 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 (в нижнем правом углу окна):
Снимок экрана, на котором показано, где изменить конец последовательности строк (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.

    Снимок экрана терминала PowerShell, в котором показан az ad sp show --id <>.

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

    Снимок экрана: RP пользовательских расположений.

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

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

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

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

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

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

Средство запуска требует постоянного расположения (Хранилище BLOB-объектов Azure) для отправки результатов, так как Kubernetes пока не разрешает копирование файлов из остановленных или завершенных модулей pod. См. здесь. Средство запуска обеспечивает подключение к Хранилище BLOB-объектов Azure с помощью URL-адреса SAS с учетной записью (в отличие от url-адреса SAS с областью действия контейнера или большого двоичного объекта) — подписанный 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. В этом примере показан портал:

Снимок экрана: сведения о подписанном URL-адресе портал Azure.

Дополнительные сведения об использовании 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

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

Снимок экрана: терминал консоли после запуска средства запуска.

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

Снимок экрана: терминал консоли с обнаружением Kubernetes и других ресурсов.

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

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

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

  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 Проверяет развертывание и обновление соединителя Active Directory (соединитель AD).
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 Проверка работоспособности для выпусков ежемесячного и месяца, таких как версии сборки 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: гарантирует наличие ConfigMaps и соответствующих полей для экземпляра 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.

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

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

Снимок экрана: контейнер хранилища средства запуска.

Снимок экрана: tarball средства запуска.

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

Снимок экрана: результаты теста средства запуска.

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

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

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

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

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

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