Share via

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

  • Článek

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ě:

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

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:

  • 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
  1. 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ě):
Screenshot that shows where to change the end of line sequence (CRLF).

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:

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 Připojení vytvoření vlastního umístění 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.

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

  2. Prostřednictvím webu Azure Portal přejděte do okna Microsoft Entra a vyhledejte Custom Locations RP:

    A screenshot of the 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:

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

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í:

A screenshot of the console terminal after the launcher starts.

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:

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

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. Ukončit.

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.

Suite # Název testovací sady Popis testu
0 ad-connector Otestuje nasazení a aktualizaci Připojení oru služby Active Directory (AD Připojení or).
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í služby Active Directory Připojení or.
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 konfiguraci Mapy a příslušná pole 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 screenshot of the launcher storage container.

A screenshot of the launcher tarball.

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

A screenshot of the launcher test results.

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