Kurz: Automatizované ověřování testování

V rámci každého potvrzení, které vytváří datové služby s podporou arc, spouští Microsoft automatizované kanály CI/CD, které provádějí kompletní 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: Modul plug-in Sonobuoy obsahující komplexní integrační testy založené na Pytestu, od jednoduchých orientačních testů (nasazení, odstranění), až po komplexní scénáře s vysokou dostupností, 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ě (/CSI), sítě (StorageClassnapř. LoadBalancers, DNS)
• Jiné nastavení specifické pro Kubernetes nebo infrastrukturu

Pro zákazníky, kteří mají v úmyslu spouštět datové služby s podporou arc v nezdokumentované distribuci, musí tyto ověřovací testy úspěšně spouštět, aby se považovaly za podporované. Partneři navíc můžou tento přístup použít k certifikaci řešení, které vyhovuje datovým službám s podporou arc – viz ověření datových služeb 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 installed – minimální verze (Major:"1", Minor:"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ě, protože manifest Kustomize – Kustomize je integrovaný kubectl – takže není nutné provádět žá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 z patch.json.tmpl

Tip

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

Konfigurace 1: .test.env

Vyplněný vzorek .test.env souboru vygenerovaný na .test.env.tmpl základě níže se sdílí s vloženým komentářem.

Důležité

Následující export VAR="value" syntaxe není určená k místnímu spuštění do zdrojových proměnných prostředí z vašeho počítače , ale je tam pro spouštěč. Spouštěč připojí tento .test.env soubor jako Kubernetes secret pomocí Kustomize (Kustomize secretGenerator přebírá soubor, base64 zakóduje celý obsah souboru a převede ho na tajný kód 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ěkolikproměnných 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 přímého režimu, přepínání CONNECTIVITY_MODE=indirect bude mít spouštěč ignorovat nastavení specifické pro přímý režim a použít 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. Konec řádku, který CRLF může způsobit chybu při arc-ci-launcher spuštění kontejneru, například: /launcher/config/.test.env: $'\r': command not found Provedení změny pomocí VSCode (vpravo dole v okně):

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

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

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

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

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

• Obecná dostupnost: stable - Protokol verzí
• Předběžná dostupnost: preview - Předběžné testování

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í image je předem zabalená s nejnovější verzí rozhraní příkazového řádku arcdata v době vydání každé verze 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 ke stažení adresy URL objektu blob v Azure CLI, aby se přepsal předem zabalená verze; 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 jsou zdrojové z možnosti Povolit vlastní umístění v clusteru a načíst jedinečné ID objektu vlastního umístění pro vašeho tenanta Microsoft Entra.

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 instančního objektu

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ů.

Testování ověřování je určené k provedení v clusteru Kubernetes mimo produkční/testovací prostředí a předplatných Azure – se zaměřením na funkční ověřování 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í soubory tar protokolu)

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 prázdné .test.env , aby se spustily všechny fáze (ekvivalentní 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 vyčistil jak na začátku, tak na konci každého spuštění, je možné, že spouštěcí a/nebo testovací selhání opustí prostředky reziduí. 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 patch.json souboru vygenerovaná na patch.json.tmpl základě níže sdíleného souboru:

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 Jobspouštěč, který vyžaduje pokyn Kubernetes, kde najít image 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 rekapitulace, v tomto okamžiku - existují 3 místa, která jsme zadali imageTag, pro přehlednost zde je vysvětlení různých použití jednotlivých. 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?
0	.test.env	DOCKER_TAG	Získání image Bootstrapperu v rámci instalace rozšíření	az k8s-extension create ve spouštěči
2	patch.json	value.imageTag	Získání image kontroleru dat	az arcdata dc create ve spouštěči
3	kustomization.yaml	images.newTag	Získání image spouštěče	kubectl applyinging the launcher

kubectl apply

Pokud chcete ověřit, že je manifest správně nastavený, zkuste provést ověření na straně klienta a --dry-run=clientvytisknout prostředky Kubernetes, které 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 koncové protokoly, 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 předběžné ověření testovací verze ke zjišťování předpřipravených prostředků Arc a Arc Data Services a prostředků ARM a pokusí se je vyčistit na základě nejlepšího úsilí (pomocí poskytnutých přihlašovacích údajů instančního objektu), než nasadíte novou verzi:

Stejný proces zjišťování a čištění metadat se také spouští při ukončení spouštěče, aby se cluster před spuštěním co nejblíže opustil.

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

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

1. Ověřování v rozhraní Kubernetes API pomocí účtu připojeného ke službě s podem

2. Ověřování v rozhraní API ARM pomocí instančního objektu připojeného k tajným kódům

3. Provedení kontroly metadat CRD za účelem zjištění existujících vlastních prostředků služby Arc a Arc Data Services

4. Vyčistěte všechny existující vlastní prostředky v Kubernetes a následné prostředky v Azure. Pokud dojde k neshodě mezi přihlašovacími údaji ve .test.env srovnání s prostředky existujícími v clusteru, ukončete ho.

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ů. Vytiskne proměnné prostředí, obfuskuje citlivé hodnoty (např. heslo instančního objektu atd.).

6. a. V případě přímého režimu – Onboarding clusteru do Služby Azure Arc a pak nasadí kontroler.

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

7. Jakmile je Readykontroler dat , vygenerujte sadu protokolů Azure CLI (az arcdata dc debug) a uložte je místně, označená jako setup-complete standardní hodnoty.

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 spuštění se spustí v novém sonobuoy oboru názvů pomocí arc-sb-plugin podu, který obsahuje ověřovací testy Pytestu.

9. Agregátor Sonobuoy hromadí junit výsledky testů a protokoly na arc-sb-plugin testovací běh, které se exportují 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 kontrolu metadat CRD, podobně jako krok 3, a zjistěte existující vlastní prostředky služby 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. Pokus o použití tokenu LOGS_STORAGE_ACCOUNT_SAS SAS poskytnutého k vytvoření nového kontejneru účtu úložiště pojmenovaného na LOGS_STORAGE_CONTAINERzákladě , v předem existujícím účtu LOGS_STORAGE_ACCOUNTúložiště . Pokud kontejner účtu úložiště již existuje, použijte ho. Nahrajte všechny výsledky místního testu a protokoly do tohoto kontejneru úložiště jako tarball (viz níže).

13. Východ.

Testy prováděné na sadu 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
0	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	Testovací řídicí databáze – kontrola tajných kódů SA, ověření přihlášení systému, vytvoření auditu a kontroly sanity pro verzi sestavení SQL
6	dc-export	Nahrání využití a fakturace nepřímého 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 vytvoří mezi nimi skupinu převzetí služeb při selhání pomocí volání ARM.
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 oprávnění účtu služby Kubernetes Service pro službu Arc Data Services odpovídají očekáváním s nejnižšími oprávněními.
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 Pro důležité obchodní informace.
18	sqlinstance-ha	Různé zátěžové testy vysoké dostupnosti, včetně restartování podů, vynucených převzetí služeb při selhání a pozastavení
19	sqlinstance-tde	Různé transparentní šifrování dat testy.
20	telemetry-elasticsearch	Ověřuje příjem protokolů 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 Fluentbit jsou 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 neupraví.
• test_delete_active_orchestrator_twice_and_delete_primary_pod: Odstraní pod orchestrátoru několikrát, za ním následuje primární replika 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_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 kontroleru dat a ověří, že primární koncový bod je přístupný a nová primární replika se synchronizuje. 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 kontroleru dat a ověří, že jsou všechny repliky synchronizované.
• test_delete_controller_orchestrator_secondary_replica_pods:
• test_failaway: Vynutí převzetí služeb při selhání skupiny dostupnosti mimo aktuální primární server, zajistí, že nová primární služba není stejná jako stará primární. Ověřuje, jestli jsou všechny repliky synchronizované.
• test_update_while_rebooting_all_non_primary_replicas: Testy aktualizace řízené kontrolerem jsou odolné proti opakovaným pokusům i přes různé turbulentní okolnosti.

Poznámka:

Některé testy mohou vyžadovat určitý hardware, například privilegovaný přístup k řadičům domény pro ad testy vytváření položek účtu a DNS , které nemusí být dostupné ve všech prostředích, která hledají použití 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ů nasazené jako součást spouštěče.

Související obsah

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