Návod: Automatizované ověřování testů

V rámci každého potvrzení, které vytváří datové služby s podporou Arc, spouští Microsoft automatizované CI/CD pipeline, které provádějí komplexní testy. Tyto testy se orchestrují prostřednictvím dvou kontejnerů, které jsou udržovány vedle základního produktu (kontroler dat, SQL Managed Instance s povolenou serverem Azure Arc &PostgreSQL). Tyto kontejnery jsou:

• arc-ci-launcher: Obsahuje závislosti nasazení (například rozšíření rozhraní příkazového řádku) a kód nasazení produktu (pomocí Azure CLI) pro režimy přímého i nepřímého připojení. Jakmile se Kubernetes nasadí pomocí kontroleru dat, kontejner využívá Sonobuoy k aktivaci paralelních integračních testů.
• arc-sb-plugin: Plugin Sonobuoy obsahující integrační testy založené na Pytestu, od jednoduchých základních testů (nasazení, odstranění) až po komplexní scénáře vysoké dostupnosti, chaos testy (odstranění prostředků) atd.

Tyto testovací kontejnery jsou veřejně dostupné zákazníkům a partnerům za účelem ověření datových služeb s podporou Arc ve svých vlastních clusterech Kubernetes spuštěných kdekoli a ověřují:

• Distribuce nebo verze Kubernetes
• Host disto/versions
• Úložiště (StorageClass/CSI), sítě (např. LoadBalancers, DNS)
• Jiné nastavení specifické pro Kubernetes nebo infrastrukturu

Pro zákazníky, kteří mají v úmyslu provozovat datové služby s podporou Arc na nezdokumentované distribuci, je nutné úspěšně provést tyto ověřovací testy, aby byly považovány za podporované. Partneři navíc můžou tento přístup použít k certifikaci, že jejich řešení splňuje požadavky na shodu s Arc povolenými datovými službami - viz ověření Kubernetes pro datové služby s podporou Azure Arc.

Následující diagram popisuje tento proces vysoké úrovně:

V tomto kurzu se naučíte:

• Nasazení arc-ci-launcher pomocí kubectl
• Prozkoumání výsledků ověřovacího testu v účtu služby Azure Blob Storage

Požadavky

• Přihlašovací údaje:

  • Soubor test.env.tmpl obsahuje požadované přihlašovací údaje a je kombinací stávajících požadavků potřebných pro připojení připojeného clusteru Azure Arc a přímo připojeného kontroleru dat. Nastavení tohoto souboru je vysvětleno níže s ukázkami.
  • Soubor kubeconfig pro otestovaný cluster Kubernetes s cluster-admin přístupem (vyžaduje se pro onboarding připojeného clusteru v tuto chvíli)

• Klientské nástroje:

  • kubectl nainstalováno - minimální verze (Hlavní:"1", Vedlejší:"21")
  • git Rozhraní příkazového řádku (nebo alternativy založené na uživatelském rozhraní)

Příprava manifestu Kubernetes

Spouštěč je k dispozici jako součást microsoft/azure_arc úložiště, jako manifest Kustomize – Kustomize je začleněn do kubectl – takže nejsou nutné žádné další nástroje.

1. Naklonujte úložiště místně:

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

2. Přejděte do azure_arc/arc_data_services/test/launchersložky, abyste viděli následující strukturu složek:

├── 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

V tomto kurzu se zaměříme na kroky pro AKS, ale výše uvedená struktura překrytí se dá rozšířit tak, aby zahrnovala další distribuce Kubernetes.

Manifest připravený k nasazení bude představovat následující:

├── 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

Existují dva soubory, které je potřeba vygenerovat, aby se spouštěč lokalizoval, aby se spustil v určitém prostředí. Každý z těchto souborů může být generován zkopírováním a vyplněním každého z výše uvedených souborů šablony*.tmpl:

• .test.env: vyplňte z .test.env.tmpl
• patch.json: vyplňte podle patch.json.tmpl

Tip

Jedná se .test.env o jednu sadu proměnných prostředí, které řídí chování spouštěče. Vytvoření s ohledem na dané prostředí zajistí reprodukovatelnost chování spouštěče.

Konfigurace 1: .test.env

Vyplněný vzorek souboru .test.env, který je vygenerovaný na základě .test.env.tmpl, je níže sdílen s vloženými komentáři.

Důležité

Následující export VAR="value" syntaxe není určena pro lokální načítání proměnných prostředí na vašem počítači, ale slouží pro spouštěč. Spouštěč připojí tento .test.env soubor tak, jak je jako Kubernetes secret pomocí Kustomize (Kustomize secretGenerator přebírá soubor, kóduje celý obsah souboru pomocí base64 a převede ho na tajemství Kubernetes). Během inicializace spustí spouštěč příkaz Bash source , který importuje proměnné prostředí z připojeného .test.env souboru do prostředí spouštěče.

Jinými slovy, po zkopírování .test.env.tmpl a úpravách vytvoření .test.envby vygenerovaný soubor měl vypadat podobně jako v ukázce níže. Proces vyplnění .test.env souboru je identický napříč operačními systémy a terminály.

Tip

Existuje několik proměnných prostředí, které vyžadují další vysvětlení pro zajištění přehlednosti a reprodukovatelnosti. Budou komentovány s see detailed explanation below [X].

Tip

Všimněte si, že následující .test.env příklad je určený pro přímý režim. Některé z těchto proměnných, například ARC_DATASERVICES_EXTENSION_VERSION_TAG se nevztahují na nepřímý režim. Kvůli jednoduchosti je nejlepší nastavit .test.env soubor s proměnnými pro režim přímý. V případě přepnutí CONNECTIVITY_MODE=indirect bude spouštěč ignorovat specifická nastavení režimu přímý a použije podmnožinu ze seznamu.

Jinými slovy, plánování přímého režimu nám umožňuje uspokojovat proměnné nepřímého režimu.

Hotový vzorek .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"

Důležité

Pokud provádíte generování konfiguračních souborů na počítači s Windows, budete muset převést sekvenci end-of-Line z CRLF (Windows) na LF (Linux), jak arc-ci-launcher běží jako kontejner Linuxu. Ponechání konce řádku jako CRLF může způsobit chybu při spuštění arc-ci-launcher kontejneru, například: /launcher/config/.test.env: $'\r': command not found Proveďte změnu pomocí VSCode (vpravo dole v okně):

Podrobné vysvětlení určitých proměnných

1. ARC_DATASERVICES_EXTENSION_* – Verze rozšíření a trénink

Povinné: To je nezbytné pro nasazení v režimech direct.

Spouštěč může nasazovat verze GA i předběžné verze GA.

Verze rozšíření k mapování release-train (ARC_DATASERVICES_EXTENSION_RELEASE_TRAIN) se získávají odsud:

• Obecná dostupnost: stable - Protokol verzí
• Před vydáním: preview - Testování před vydáním

2. ARC_DATASERVICES_WHL_OVERRIDE – Adresa URL pro stažení předchozí verze Azure CLI

Volitelné: Ponechte toto prázdné .test.env , pokud chcete použít předpřipravené výchozí nastavení.

Spouštěcí obraz je předinstalován s nejnovější verzí rozhraní příkazového řádku arcdata v době vydání každého image kontejneru. Pokud ale chcete pracovat se staršími verzemi a testováním upgradu, může být nutné poskytnout spouštěči odkaz URL pro stažení Blobu v Azure CLI, aby nahradila předinstalovanou verzi. Například, dát spouštěči pokyn, aby nainstaloval verzi 1.4.3, vyplňte:

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

Tady najdete verzi rozhraní příkazového řádku pro mapování adres URL objektu blob.

3. CUSTOM_LOCATION_OID – ID objektu vlastních umístění z vašeho konkrétního tenanta Microsoft Entra

Povinné: To se vyžaduje pro vytvoření vlastního umístění připojeného clusteru.

Následující kroky pocházejí z Enable custom locations on your cluster k získání jedinečného ID objektu vlastního umístění pro vašeho Microsoft Entra tenant.

Existují dva přístupy k získání tenanta CUSTOM_LOCATION_OID Microsoft Entra.

1. Přes 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. Prostřednictvím webu Azure Portal přejděte do okna Microsoft Entra a vyhledejte Custom Locations RP:

   

4. SPN_CLIENT_* – Přihlašovací údaje servisního účtu

Povinné: To je povinné pro nasazení v režimu Direct Mode.

Spouštěč se přihlásí k Azure pomocí těchto přihlašovacích údajů.

Ověřovací testování je určeno k provedení na neprodukčním/testovacím clusteru Kubernetes a předplatných Azure - se zaměřením na funkční ověření nastavení Kubernetes/infrastruktury. Proto se doporučuje, aby se zabránilo počtu ručních kroků potřebných k provedení spuštění. Proto se doporučuje poskytnout SPN_CLIENT_ID/SECRET úroveň Owner skupiny prostředků (nebo předplatného), protože v této skupině prostředků vytvoří několik prostředků a také přiřadí oprávnění k těmto prostředkům proti několika spravovaným identitám vytvořeným v rámci nasazení (tato přiřazení rolí zase vyžadují, aby Ownerměl instanční objekt).

5. LOGS_STORAGE_ACCOUNT_SAS – Adresa URL SAS účtu služby Blob Storage

Doporučeno: Ponechání tohoto prázdného znamená, že nebudete získávat výsledky testů a protokoly.

Spouštěč potřebuje trvalé umístění (Azure Blob Storage) k nahrání výsledků, protože Kubernetes zatím nepovoluje kopírování souborů ze zastavených nebo dokončených podů – viz tady. Spouštěč dosahuje připojení ke službě Azure Blob Storage pomocí adresy URL SAS s vymezeným účtem (na rozdíl od kontejneru nebo objektu blob s vymezeným oborem objektů blob) – podepsanou adresu URL s definicí časového přístupu – viz Udělení omezeného přístupu k prostředkům azure Storage pomocí sdílených přístupových podpisů (SAS) s cílem:

1. Vytvoření nového kontejneru úložiště v před existujícím účtu úložiště (LOGS_STORAGE_ACCOUNT), pokud neexistuje (na LOGS_STORAGE_CONTAINERzákladě názvu)
2. Vytvoření nových, jedinečně pojmenovaných objektů blob (testovací logovací soubory ve formátu tar)

Následující kroky pocházejí z udělení omezeného přístupu k prostředkům Azure Storage pomocí sdílených přístupových podpisů (SAS).

Tip

Adresy URL SAS se liší od klíče účtu úložiště, adresa URL SAS je naformátovaná následujícím způsobem.

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

Existuje několik přístupů k vygenerování adresy URL SAS. Tento příklad ukazuje portál:

Pokud chcete místo toho použít Azure CLI, přečtěte si téma az storage account generate-sas

6. SKIP_* - řízení chování spouštěče přeskočením určitých fází

Volitelné: Nechte toto pole prázdné v .test.env, aby se spustily všechny fáze (ekvivalentní k 0 nebo prázdné).

Spouštěč zveřejňuje SKIP_* proměnné, aby bylo možné spouštět a přeskakovat konkrétní fáze – například provést "pouze vyčištění".

I když je spouštěč navržen tak, aby čistil jak na začátku, tak na konci každého spuštění, je možné, že při spuštění nebo selhání testu zůstávají zůstatkové prostředky. Pokud chcete spustit spouštěč v režimu "pouze vyčištění", nastavte následující proměnné v .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

Výše uvedená nastavení dává spouštěči pokyn, aby vyčistil všechny prostředky služby Arc a Arc Data Services a nenasazoval/testoval/nahrál protokoly.

Konfigurace 2: patch.json

Vyplněná ukázka souboru patch.json, vygenerovaná na základě patch.json.tmpl, je sdílena níže:

Všimněte si, že spec.docker.registry, repository, imageTag hodnota by měla být stejná jako hodnoty uvedené výše .test.env .

Hotový vzorek 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"
        }                  
    ]
}

Nasazení spouštěče

Doporučuje se nasadit spouštěč v neprodukčním nebo testovacím clusteru , protože provádí destruktivní akce na Arc a dalších používaných prostředcích Kubernetes.

imageTag specifikace

Spouštěč je definovaný v manifestu Kubernetes jako Job, a vyžaduje pokyn pro Kubernetes, kde najít obraz spouštěče. Toto nastavení je nastaveno v base/kustomization.yaml:

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

Tip

Pro rekapitulaci, nyní existují 3 místa, která jsme určili imageTag, pro přehlednost uvádíme vysvětlení jednotlivých použití. Obvykle – při testování dané verze by všechny tři hodnoty byly stejné (v souladu s danou verzí):

#	Název souboru	Název proměnné	Proč?	Používá se?
1	.test.env	DOCKER_TAG	Získání Bootstrapper image v rámci instalace rozšíření	az k8s-extension create ve spouštěči
2	patch.json	value.imageTag	Získání obrazu správce dat	az arcdata dc create ve spouštěči
3	kustomization.yaml	images.newTag	Získání obrazu spouštěče	kubectl apply Spouštění spouštěče

kubectl apply

Pokud chcete ověřit, že je manifest správně nastavený, zkuste ověření na straně klienta pomocí --dry-run=client, který vytiskne prostředky Kubernetes, jež se vytvoří pro spouštěč.

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)

Pokud chcete nasadit spouštěč a sledovat záznamy protokolu, spusťte následující příkaz:

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

V tomto okamžiku by měl spouštěč začít – a měl by se zobrazit následující:

I když je nejlepší nasadit spouštěč v clusteru bez předem existujících prostředků Arc, spouštěč obsahuje ověření před zahájením ke zjišťování předem existujících CRDs a prostředků Arc a Arc Data Services a prostředků ARM a pokusí se je co nejlépe vyčistit (s využitím poskytnutých přihlašovacích údajů hlavního objektu služby) před nasazením nové verze:

Stejný proces zjišťování a čištění metadat se také spouští při ukončení spouštěče, aby se cluster co nejvíce přiblížil svému původnímu stavu před spuštěním.

Kroky prováděné spouštěčem

Spouštěč na vysoké úrovni provede následující posloupnost kroků:

1. Ověření k API Kubernetes pomocí účtu služby namontovaného na Podu

2. Ověření vůči API ARM s použitím služebního principála a tajných kódů.

3. Proveďte skenování metadat CRD pro objevení stávajících vlastních prostředků Arc a Arc Data Services.

4. Vyčistěte všechny existující vlastní zdroje v Kubernetes a související prostředky v Azure. Pokud dojde k neshodě mezi přihlašovacími údaji ve .test.env a prostředky existujícími v clusteru, ukončete proces.

5. Vygenerujte jedinečnou sadu proměnných prostředí na základě časového razítka pro název clusteru Arc, kontroler dat a vlastní umístění nebo obor názvů. Vypíše proměnné prostředí a skryje citlivé hodnoty (např. heslo služebního účtu atd.).

6. a. Pro přímý režim se nejprve provede onboardingu clusteru do služby Azure Arc, a potom se nasadí kontroler.

   b. Pro nepřímý režim: Nasazení kontroleru dat

7. Jakmile je Správce dat Ready, vygenerujte sadu protokolů Azure CLI (az arcdata dc debug) a uložte ji místně, označenou jako setup-complete jako základní nastavení.

8. TESTS_DIRECT/INDIRECT Pomocí proměnné prostředí spusťte .test.env sadu paralelizovaných testovacích běhů Sonobuoy na základě pole odděleného mezerou (TESTS_(IN)DIRECT). Tyto běhy se provádějí v novém sonobuoy oboru názvů s pomocí arc-sb-plugin podu, který obsahuje validační testy pro Pytest.

9. Agregátor Sonobuoy hromadí junit výsledky testů a protokoly pro každý arc-sb-plugin testovací běh, které jsou exportovány do podu spouštěče.

10. Vraťte ukončovací kód testů a vygenerujte další sadu protokolů ladění – Azure CLI a sonobuoy – uložené místně, označené jako test-complete.

11. Proveďte skenování metadat CRD, podobně jako v kroku 3, a zjistěte existující vlastní prostředky Arc a Arc Data Services. Pak pokračujte zničením všech prostředků Arc a Arc Data v obráceném pořadí od nasazení, stejně jako CRD, Role/ClusterRoles, PV/PVCs atd.

12. Pokusit se použít poskytnutý token SAS LOGS_STORAGE_ACCOUNT_SAS k vytvoření nového kontejneru v účtu úložiště, pojmenovaného podle LOGS_STORAGE_CONTAINER, v již existujícím účtu úložiště LOGS_STORAGE_ACCOUNT. Pokud kontejner účtu úložiště již existuje, použijte ho. Nahrajte všechny výsledky místních testů a protokoly do tohoto kontejneru úložiště jako tarball (tar archiv) (viz níže).

13. Východ.

Testy prováděné v sadě testů

K dispozici je přibližně 375 jedinečných integračních testů v rámci 27 testovacích sad – každé testování má samostatnou funkčnost.

Apartmá #	Název testovací sady	Popis testu
1	ad-connector	Otestuje nasazení a aktualizaci konektoru služby Active Directory (konektor AD).
2	billing	Testování různých typů licencí Pro důležité obchodní informace se projeví v tabulce prostředků v kontroleru, která se používá k nahrání fakturace.
3	ci-billing	Podobá se billingtomu, ale s více permutací procesoru a paměti.
4	ci-sqlinstance	Dlouhotrvající testy pro vytváření více replik, aktualizace, GP –> aktualizace BC, ověřování zálohování a agenta SQL Serveru
5	controldb	Řídicí databáze testů – ověření tajných kódů SA, ověření přihlášení k systému, vytvoření auditu a kontroly integrity pro verzi sestavení SQL.
6	dc-export	Nahrání fakturace a využití v nepřímém režimu.
7	direct-crud	Vytvoří instanci SQL pomocí volání ARM, ověří se v Kubernetes i ARM.
8	direct-fog	Vytvoří několik instancí SQL a pomocí volání ARM vytvoří mezi nimi Failover Group.
9	direct-hydration	Vytvoří instanci SQL s rozhraním Kubernetes API a ověří přítomnost v ARM.
10	direct-upload	Ověřuje nahrávání fakturace v přímém režimu.
11	kube-rbac	Zajišťuje, že Kubernetes služební účet pro Arc Data Services splňuje zásady minimálních oprávnění.
12	nonroot	Zajišťuje, že kontejnery běží jako uživatel, který není root.
13	postgres	Dokončí různé testy vytváření Postgres, škálování, zálohování a obnovení.
14	release-sanitychecks	Sanity kontroluje verze od měsíců do měsíce, jako jsou verze sestavení SQL Serveru.
15	sqlinstance	Kratší verze ci-sqlinstance, pro rychlé ověření.
16	sqlinstance-ad	Testuje vytváření instancí SQL pomocí konektoru služby Active Directory.
17	sqlinstance-credentialrotation	Testuje automatizovanou obměnu přihlašovacích údajů pro obecné účely i pro kritické obchodní účely.
18	sqlinstance-ha	Různé zátěžové testy zaměřené na vysokou dostupnost, včetně restartování modulů, nuceného převzetí při selhání a pozastavení.
19	sqlinstance-tde	Různé testy transparentního šifrování dat.
20	telemetry-elasticsearch	Ověřuje přijímání logů do Elasticsearch.
21	telemetry-grafana	Ověří, že Grafana je dosažitelná.
22	telemetry-influxdb	Ověří příjem metrik do InfluxDB.
23	telemetry-kafka	Různé testy pro Kafka s využitím SSL, nastavení s jedním nebo více zprostředkovateli.
24	telemetry-monitorstack	Testy monitorovacích komponent, jako jsou Fluentbit a Collectd, jsou funkční.
25	telemetry-telemetryrouter	Testuje otevřenou telemetrii.
26	telemetry-webhook	Testuje webhooky datových služeb s platnými a neplatnými voláními.
27	upgrade-arcdata	Upgraduje úplnou sadu instancí SQL (GP, REPLIKA BC 2, replika BC 3 se službou Active Directory) a upgraduje z verze za poslední měsíc na nejnovější build.

Například pro , sqlinstance-hanásledující testy jsou provedeny:

• test_critical_configmaps_present: Zajišťuje, že objekty ConfigMap a příslušná pole jsou k dispozici pro instanci SQL.
• test_suspended_system_dbs_auto_heal_by_orchestrator: Zajišťuje, zda master a msdb jsou pozastaveny jakýmkoli způsobem (v tomto případě uživatel). Údržba orchestrátoru ji opravuje automaticky.
• test_suspended_user_db_does_not_auto_heal_by_orchestrator: Zajišťuje, že pokud je uživatelská databáze záměrně pozastavena uživatelem, údržba Orchestratoru ji automaticky neobnoví.
• test_delete_active_orchestrator_twice_and_delete_primary_pod: Několikrát odstraní orchestrátorový pod, poté primární repliku, a ověří, že všechny repliky jsou synchronizované. Očekávaná doba převzetí služeb při selhání je pro 2 repliky zmírněna.
• test_delete_primary_pod: Odstraní primární repliku a ověří, že jsou všechny repliky synchronizované. Uvolní se očekávaná doba převzetí služeb při selhání pro 2 repliky.
• test_delete_primary_and_orchestrator_pod: Odstraní primární repliku a pod orchestrátoru a ověří, že jsou všechny repliky synchronizované.
• test_delete_primary_and_controller: Odstraní primární repliku a pod datového kontroleru a ověří, že primární koncový bod je přístupný a nová primární replika je synchronizována. Uvolní se očekávaná doba převzetí služeb při selhání pro 2 repliky.
• test_delete_one_secondary_pod: Odstraní sekundární repliku a pod kontroleru dat a ověří, že jsou všechny repliky synchronizované.
• test_delete_two_secondaries_pods: Odstraní sekundární repliky a pod řadiče dat a ověří, že všechny repliky jsou synchronizované.
• test_delete_controller_orchestrator_secondary_replica_pods:
• test_failaway: Vynutí přesun skupiny dostupnosti (AG) z aktuálního primárního serveru a zajistí, že nový primární server není stejný jako původní primární. Ověřuje, jestli jsou všechny repliky synchronizované.
• test_update_while_rebooting_all_non_primary_replicas: Testy aktualizace řízené ovladačem jsou odolné i při opakovaných pokusech, navzdory různým turbulentním okolnostem.

Poznámka:

Některé testy mohou vyžadovat určitý hardware, například privilegovaný přístup k řadičům domény pro testy vytváření položek účtu a DNS, které nemusí být dostupné ve všech prostředích, jež se snaží používat arc-ci-launcher.

Zkoumání výsledků testu

Ukázkový kontejner úložiště a soubor nahraný spouštěčem:

A výsledky testů vygenerované z běhu:

Vyčištění prostředků

Pokud chcete spouštěč odstranit, spusťte:

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

Tím se vyčistí manifesty prostředků, které jsou nasazené jako součást spouštěče.

Související obsah

Testování před vydáním