Zelfstudie: Geautomatiseerde validatietests

Artikel
10/16/2024

Als onderdeel van elke doorvoering die gegevensservices met Arc bouwt, voert Microsoft geautomatiseerde CI/CD-pijplijnen uit die end-to-endtests uitvoeren. Deze tests worden ingedeeld via twee containers die naast het kernproduct worden onderhouden (Data Controller, SQL Managed Instance ingeschakeld door Azure Arc & PostgreSQL-server). Deze containers zijn:

arc-ci-launcher: Bevat implementatieafhankelijkheden (bijvoorbeeld CLI-extensies), evenals productimplementatiecode (met behulp van Azure CLI) voor zowel directe als indirecte connectiviteitsmodi. Zodra Kubernetes is ge onboardd met de gegevenscontroller, maakt de container gebruik van Sonobuoy om parallelle integratietests te activeren.
arc-sb-plugin: Een Sonobuoy-invoegtoepassing met end-to-end integratietests op basis van Pytest, variërend van eenvoudige betrouwbaarheidstests (implementaties, verwijderingen), tot complexe scenario's met hoge beschikbaarheid, chaostests (resourceverwijderingen) enzovoort.

Deze testcontainers worden openbaar beschikbaar gesteld voor klanten en partners om validatietests voor gegevensservices met Arc uit te voeren in hun eigen Kubernetes-clusters die overal worden uitgevoerd, om het volgende te valideren:

Kubernetes-distributie/-versies
Host-disto/versies
Opslag (StorageClass/CSI), netwerken (bijvoorbeeld LoadBalancers, DNS)
Andere Kubernetes- of infrastructuurspecifieke installatie

Voor klanten die data services met Arc willen uitvoeren op een niet-gedocumenteerde distributie, moeten ze deze validatietests uitvoeren om als ondersteund te worden beschouwd. Daarnaast kunnen partners deze benadering gebruiken om hun oplossing te certificeren, voldoet aan Gegevensservices met Arc. Zie Kubernetes-validatie voor Gegevensservices met Azure Arc.

In het volgende diagram wordt dit proces op hoog niveau beschreven:

Diagram met de Kube-systeemeigen integratietests met Arc-functionaliteit.

In deze zelfstudie leert u het volgende:

Implementeren arc-ci-launcher met behulp van kubectl
Validatietestresultaten onderzoeken in uw Azure Blob Storage-account

Vereisten

Referenties:
- Het test.env.tmpl bestand bevat de benodigde referenties en is een combinatie van de bestaande vereisten die nodig zijn voor het onboarden van een met Azure Arc verbonden cluster en een rechtstreeks verbonden gegevenscontroller. De installatie van dit bestand wordt hieronder uitgelegd met voorbeelden.
- Een kubeconfig-bestand naar het geteste Kubernetes-cluster met cluster-admin toegang (vereist voor onboarding van verbonden clusters op dit moment)
Clienthulpprogramma's:
- kubectl geïnstalleerd - minimale versie (Major:"1", Minor:"21")
- git opdrachtregelinterface (of alternatieven op basis van gebruikersinterface)

Kubernetes-manifestvoorbereiding

Het startprogramma wordt beschikbaar gesteld als onderdeel van de microsoft/azure_arc opslagplaats, als een Kustomize-manifest - Kustomize is ingebouwd kubectl - dus er is geen extra hulpprogramma's vereist.

Kloon de opslagplaats lokaal:

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

Navigeer naar azure_arc/arc_data_services/test/launcher, om de volgende mapstructuur weer te geven:

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

In deze zelfstudie gaan we ons richten op stappen voor AKS, maar de bovenstaande overlaystructuur kan worden uitgebreid om extra Kubernetes-distributies op te nemen.

Het manifest gereed voor implementatie vertegenwoordigt het volgende:

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

Er moeten twee bestanden worden gegenereerd om het startprogramma te lokaliseren voor uitvoering in een specifieke omgeving. Elk van deze bestanden kan worden gegenereerd door de bovenstaande sjabloonbestanden (*.tmpl) te kopiëren en in te vullen:

.test.env: invullen vanuit .test.env.tmpl
patch.json: invullen vanuit patch.json.tmpl

Tip

Het .test.env is één set omgevingsvariabelen die het gedrag van het startprogramma aanstuurt. Het genereren ervan met zorg voor een bepaalde omgeving zorgt voor reproduceerbaarheid van het startprogrammagedrag.

Configuratie 1: `.test.env`

Een ingevuld voorbeeld van het .test.env bestand, gegenereerd op .test.env.tmpl basis van, wordt hieronder gedeeld met inlinecommentaar.

Belangrijk

De export VAR="value" onderstaande syntaxis is niet bedoeld om lokaal te worden uitgevoerd naar omgevingsvariabelen van uw computer, maar is er voor het startprogramma. Het startprogramma koppelt dit .test.env bestand als kubernetes secret met behulp van Kustomize (Kustomize secretGenerator neemt een bestand, base64 codeert de inhoud van het hele bestand en wordt omgezet in een Kubernetes-geheim). Tijdens de initialisatie voert het startprogramma de opdracht van bash source uit, waarmee de omgevingsvariabelen worden geïmporteerd uit het bestand dat is gekoppeld .test.env in de omgeving van het startprogramma.

Met andere woorden, na het kopiëren en plakken .test.env.tmpl en bewerken om te maken .test.env, moet het gegenereerde bestand er ongeveer uitzien als in het onderstaande voorbeeld. Het proces voor het invullen van het .test.env bestand is identiek aan besturingssystemen en terminals.

Tip

Er zijn een aantal omgevingsvariabelen die aanvullende uitleg vereisen voor de reproduceerbaarheid. Deze worden met commentaar geplaatst see detailed explanation below [X].

Tip

Houd er rekening mee dat het .test.env onderstaande voorbeeld voor de directe modus is. Sommige van deze variabelen, zoals ARC_DATASERVICES_EXTENSION_VERSION_TAG niet van toepassing op de indirecte modus. Voor het gemak kunt u het bestand het beste instellen .test.env met variabelen in de directe modus, waarbij het CONNECTIVITY_MODE=indirect startprogramma de instellingen voor de directe modus negeert en een subset uit de lijst gebruikt.

Met andere woorden, het plannen van de directe modus stelt ons in staat om te voldoen aan indirecte modusvariabelen.

Voltooid voorbeeld van .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"

Belangrijk

Als u het genereren van het configuratiebestand op een Windows-computer uitvoert, moet u de end-of-line-reeks van CRLF (Windows) naar LF (Linux) converteren als arc-ci-launcher een Linux-container. Als u de regel eindigt, kan CRLF dit een fout veroorzaken bij arc-ci-launcher het starten van de container, zoals: /launcher/config/.test.env: $'\r': command not found Voer bijvoorbeeld de wijziging uit met BEHULP van VSCode (rechtsonder in het venster):
Schermopname die laat zien waar u het einde van de regelreeks (CRLF) kunt wijzigen.

Gedetailleerde uitleg voor bepaalde variabelen

1. `ARC_DATASERVICES_EXTENSION_*` - Extensieversie en -trein

Verplicht: dit is vereist voor direct modusimplementaties.

Het startprogramma kan zowel GA- als pre-GA-releases implementeren.

De extensieversie voor release-train (ARC_DATASERVICES_EXTENSION_RELEASE_TRAIN) toewijzing wordt hier verkregen:

GA: stable - Versielogboek
Pre-GA: preview - testen vóór release

2. `ARC_DATASERVICES_WHL_OVERRIDE` - Download-URL van vorige versie van Azure CLI

Optioneel: laat dit leeg .test.env om de vooraf verpakte standaardwaarde te gebruiken.

De installatiekopieën van het startprogramma zijn vooraf verpakt met de nieuwste arcdata CLI-versie op het moment van elke release van de containerinstallatiekopieën. Als u echter wilt werken met oudere releases en upgradetests, kan het nodig zijn om het startprogramma te voorzien van de downloadkoppeling voor Azure CLI Blob URL om de vooraf verpakte versie te overschrijven; Vul bijvoorbeeld het startprogramma in om versie 1.4.3 te installeren:

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

De CLI-versie naar blob-URL-toewijzing vindt u hier.

3. `CUSTOM_LOCATION_OID` - Object-id van aangepaste locaties van uw specifieke Microsoft Entra-tenant

Verplicht: dit is vereist voor het maken van een aangepaste locatie voor verbonden clusters.

De volgende stappen zijn afkomstig uit Aangepaste locaties inschakelen in uw cluster om de unieke aangepaste locatieobject-id voor uw Microsoft Entra-tenant op te halen.

Er zijn twee manieren om de CUSTOM_LOCATION_OID voor uw Microsoft Entra-tenant te verkrijgen.

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

Een schermopname van een PowerShell-terminal met az ad sp show --id <>.

Ga via Azure Portal naar de blade Microsoft Entra en zoek Custom Locations RPnaar:

4. `SPN_CLIENT_*` - Referenties voor service-principal

Verplicht: dit is vereist voor implementaties in de directe modus.

Het startprogramma meldt zich aan bij Azure met behulp van deze referenties.

Validatietests moeten worden uitgevoerd op niet-productie-/test-Kubernetes-cluster en Azure-abonnementen , waarbij u zich richt op functionele validatie van de Kubernetes/Infrastructuur-installatie. Om het aantal handmatige stappen te voorkomen dat nodig is om lanceringen uit te voeren, is het raadzaam om een SPN_CLIENT_ID/SECRET resourcegroep (of abonnement) op te geven, omdat er meerdere resources in deze resourcegroep worden gemaakt, evenals het toewijzen van machtigingen aan deze resources voor verschillende beheerde identiteiten die Owner zijn gemaakt als onderdeel van de implementatie (deze roltoewijzingen vereisen op hun beurt dat de service-principal Owner).

5. `LOGS_STORAGE_ACCOUNT_SAS` - SAS-URL blobopslagaccount

Aanbevolen: als u dit leeg laat, betekent dit dat u geen testresultaten en logboeken krijgt.

Het startprogramma heeft een permanente locatie (Azure Blob Storage) nodig om resultaten te uploaden, omdat Kubernetes het kopiëren van bestanden niet toestaat van gestopte/voltooide pods . Zie hier. Het startprogramma maakt verbinding met Azure Blob Storage met behulp van een SAS-URL met accountbereik (in tegenstelling tot container- of blobbereik) - een ondertekende URL met een tijdsgebonden toegangsdefinitie - zie Beperkte toegang verlenen tot Azure Storage-resources met behulp van Shared Access Signatures (SAS) om het volgende te doen:

Maak een nieuwe opslagcontainer in het bestaande opslagaccount (LOGS_STORAGE_ACCOUNT), als deze niet bestaat (naam op LOGS_STORAGE_CONTAINERbasis van )
Nieuwe, unieke blobs maken (tar-bestanden voor testlogboeken)

De volgende stappen zijn afkomstig van Beperkte toegang verlenen tot Azure Storage-resources met behulp van Sas (Shared Access Signatures).

Tip

SAS-URL's verschillen van de sleutel van het opslagaccount. Een SAS-URL wordt als volgt opgemaakt.

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

Er zijn verschillende benaderingen voor het genereren van een SAS-URL. In dit voorbeeld ziet u de portal:

Een schermopname van de handtekeningdetails voor gedeelde toegang in Azure Portal.

Als u in plaats daarvan de Azure CLI wilt gebruiken, raadpleegt u az storage account generate-sas

6. `SKIP_*` - het gedrag van het startprogramma beheren door bepaalde fasen over te slaan

Optioneel: laat dit leeg .test.env om alle fasen uit te voeren (gelijk aan 0 of leeg)

Het startprogramma maakt variabelen beschikbaar SKIP_* , om specifieke fasen uit te voeren en over te slaan, bijvoorbeeld om een 'alleen opschonen'-uitvoering uit te voeren.

Hoewel het startprogramma is ontworpen om zowel in het begin als aan het einde van elke uitvoering op te schonen, is het mogelijk voor lancering en/of testfouten om residuresources achter te laten. Als u het startprogramma wilt uitvoeren in de modus Alleen opschonen, stelt u de volgende variabelen in .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

Met de bovenstaande instellingen wordt het startprogramma geïnstrueerd om alle Arc- en Arc Data Services-resources op te schonen en logboeken niet te implementeren/testen/uploaden.

Configuratie 2: `patch.json`

Hieronder vindt u een ingevuld voorbeeld van het patch.json bestand dat is gegenereerd op patch.json.tmpl basis van:

Houd er rekening mee dat de spec.docker.registry, repository, imageTag waarden identiek moeten zijn aan de bovenstaande waarden .test.env

Voltooid voorbeeld van 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"
        }                  
    ]
}

Launcher-implementatie

Het wordt aanbevolen om het startprogramma te implementeren in een cluster dat niet-productie/test is , omdat het destructieve acties uitvoert op Arc en andere gebruikte Kubernetes-resources.

`imageTag` specificatie

Het startprogramma wordt gedefinieerd in het Kubernetes-manifest als een Job, waarvoor Kubernetes moet worden geïnstrueerd waar de installatiekopieën van het startprogramma moeten worden gevonden. Dit is ingesteld in base/kustomization.yaml:

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

Tip

Om samen te vatten, op dit punt - er zijn drie plaatsen die we hebben opgegeven imageTag, voor duidelijkheid, hier volgt een uitleg van de verschillende toepassingen van elk. Normaal gesproken zijn alle drie de waarden bij het testen van een bepaalde release hetzelfde (uitlijnen op een bepaalde release):

#	Bestandsnaam	Variabelenaam	Waarom?	Gebruikt door?
1	`.test.env`	`DOCKER_TAG`	De Bootstrapper-installatiekopie als onderdeel van de installatie van de extensiebronnen	`az k8s-extension create` in het startprogramma
2	`patch.json`	`value.imageTag`	De afbeelding van de gegevenscontroller ophalen	`az arcdata dc create` in het startprogramma
3	`kustomization.yaml`	`images.newTag`	De installatiekopieën van het startprogramma ophalen	`kubectl apply`het startprogramma

`kubectl apply`

Als u wilt controleren of het manifest correct is ingesteld, probeert u validatie aan de clientzijde uit --dry-run=clientte voeren, waarmee de Kubernetes-resources worden afgedrukt die moeten worden gemaakt voor het startprogramma:

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)

Voer het volgende uit om het startprogramma en de tail-logboeken te implementeren:

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

Op dit moment moet het startprogramma worden gestart en ziet u het volgende:

Een schermopname van de consoleterminal nadat het startprogramma is gestart.

Hoewel het het beste is om het startprogramma in een cluster te implementeren zonder bestaande Arc-resources, bevat het startprogramma validatie vooraf om bestaande Arc- en Arc Data Services CRD's en ARM-resources te detecteren en probeert ze op te schonen op basis van best effort (met behulp van de opgegeven service-principalreferenties), voordat de nieuwe release wordt geïmplementeerd:

Een schermopname van de consoleterminal die Kubernetes en andere resources ontdekt.

Dit proces voor het detecteren en opschonen van metagegevens wordt ook uitgevoerd bij het afsluiten van het startprogramma, zodat het cluster zo dicht mogelijk bij de bestaande status ligt voordat het wordt gestart.

Stappen die worden uitgevoerd door het startprogramma

Op hoog niveau voert het startprogramma de volgende reeks stappen uit:

Verifiëren bij kubernetes-API met behulp van een serviceaccount dat is gekoppeld aan pods
Verifiëren bij ARM-API met behulp van een service-principal die is gekoppeld aan een geheim
CrD-metagegevensscan uitvoeren om bestaande aangepaste Arc- en Arc Data Services-resources te detecteren
Verwijder bestaande aangepaste resources in Kubernetes en volgende resources in Azure. Als er geen overeenkomst is tussen de referenties in .test.env vergelijking met resources die in het cluster bestaan, sluit u af.
Genereer een unieke set omgevingsvariabelen op basis van tijdstempel voor arcclusternaam, gegevenscontroller en aangepaste locatie/naamruimte. Hiermee worden de omgevingsvariabelen afgedrukt, gevoelige waarden verborgen (bijvoorbeeld wachtwoord voor service-principal, enzovoort)
a. Voor de directe modus: onboarding van het cluster naar Azure Arc en implementeert vervolgens de controller.

b. Voor indirecte modus: de gegevenscontroller implementeren
Zodra de gegevenscontroller is Ready, genereert u een set Azure CLI-logboeken (az arcdata dc debug) en slaat u deze lokaal op, gelabeld als setup-complete basislijn.
Gebruik de TESTS_DIRECT/INDIRECT omgevingsvariabele van waaruit .test.env u een reeks parallelle Sonobuoy-testuitvoeringen wilt starten op basis van een door spaties gescheiden matrix (TESTS_(IN)DIRECT). Deze uitvoeringen worden uitgevoerd in een nieuwe sonobuoy naamruimte, met behulp van arc-sb-plugin pod die de Pytest-validatietests bevat.
Sonobuoy-aggregator verzamelt de junit testresultaten en logboeken per arc-sb-plugin testuitvoering, die worden geëxporteerd naar de launcherpod.
Retourneer de afsluitcode van de tests en genereert een andere set foutopsporingslogboeken: Azure CLI en sonobuoy - lokaal opgeslagen, gelabeld als test-complete.
Voer een CRD-metagegevensscan uit, vergelijkbaar met stap 3, om bestaande aangepaste Arc- en Arc Data Services-resources te detecteren. Ga vervolgens verder met het vernietigen van alle Arc- en Arc-gegevensbronnen in omgekeerde volgorde van implementatie, evenals CRD's, Role/ClusterRoles, PV/PVC's, enzovoort.
Probeer het SAS-token LOGS_STORAGE_ACCOUNT_SAS te gebruiken dat is opgegeven om een nieuwe opslagaccountcontainer te maken met de naam op LOGS_STORAGE_CONTAINERbasis van, in het bestaande opslagaccount LOGS_STORAGE_ACCOUNT. Als de container van het opslagaccount al bestaat, gebruikt u deze. Upload alle lokale testresultaten en logboeken naar deze opslagcontainer als tarball (zie hieronder).
Uitgang.

Tests uitgevoerd per testsuite

Er zijn ongeveer 375 unieke integratietests beschikbaar, in 27 testsuites: elk test een afzonderlijke functionaliteit.

Suite #	Naam van testpakket	Beschrijving van de test
1	`ad-connector`	Test de implementatie en update van een Active Directory-connector (AD-connector).
2	`billing`	Het testen van verschillende Bedrijfskritiek licentietypen wordt weergegeven in de resourcetabel in de controller, die wordt gebruikt voor het uploaden van facturering.
3	`ci-billing`	Vergelijkbaar met `billing`, maar met meer CPU-/geheugen-permutaties.
4	`ci-sqlinstance`	Langdurige tests voor het maken van meerdere replica's, updates, GP -> BC Update, Back-upvalidatie en SQL Server Agent.
5	`controldb`	Test de controledatabase - SA-geheimcontrole, verificatie van systeemaanmelding, controle maken en sanity-controles voor SQL-buildversie.
6	`dc-export`	Facturerings- en gebruiksupload in indirecte modus.
7	`direct-crud`	Hiermee maakt u een SQL-exemplaar met BEHULP van ARM-aanroepen, valideert u in zowel Kubernetes als ARM.
8	`direct-fog`	Hiermee maakt u meerdere SQL-exemplaren en maakt u er een failovergroep tussen met behulp van ARM-aanroepen.
9	`direct-hydration`	Hiermee maakt u EEN SQL-exemplaar met kubernetes-API en valideert u de aanwezigheid in ARM.
10	`direct-upload`	Hiermee wordt het uploaden van facturering gevalideerd in de directe modus
11	`kube-rbac`	Zorgt ervoor dat de machtigingen voor het Kubernetes-serviceaccount voor Arc Data Services overeenkomen met de verwachtingen voor minimale bevoegdheden.
12	`nonroot`	Zorgt ervoor dat containers worden uitgevoerd als niet-hoofdgebruiker
13	`postgres`	Voltooit verschillende Postgres-creatie-, schaalaanpassings-, back-up- en hersteltests.
14	`release-sanitychecks`	Sanity controleert op maandelijkse releases, zoals SQL Server Build-versies.
15	`sqlinstance`	Kortere versie van `ci-sqlinstance`, voor snelle validaties.
16	`sqlinstance-ad`	Test het maken van SQL-exemplaren met Active Directory Connector.
17	`sqlinstance-credentialrotation`	Test geautomatiseerde referentierotatie voor zowel algemeen gebruik als Bedrijfskritiek.
18	`sqlinstance-ha`	Verschillende stresstests voor hoge beschikbaarheid, waaronder opnieuw opstarten van pods, geforceerde failovers en schorsingen.
19	`sqlinstance-tde`	Verschillende Transparent Data Encryption-tests.
20	`telemetry-elasticsearch`	Valideert logboekopname in Elasticsearch.
21	`telemetry-grafana`	Valideert grafana is bereikbaar.
22	`telemetry-influxdb`	Valideert metrische opname in InstroomDB.
23	`telemetry-kafka`	Verschillende tests voor Kafka met BEHULP van SSL, single/multi-broker setup.
24	`telemetry-monitorstack`	Test bewakingsonderdelen, zoals `Fluentbit` en `Collectd` zijn functioneel.
25	`telemetry-telemetryrouter`	Test Open Telemetry.
26	`telemetry-webhook`	Test Data Services-webhooks met geldige en ongeldige aanroepen.
27	`upgrade-arcdata`	Hiermee werkt u een volledige suite met SQL Instances (GP, BC 2 replica, BC 3 replica, met Active Directory) en upgrades van de release van vorige maand naar de nieuwste build.

Als voorbeeld sqlinstance-haworden de volgende tests uitgevoerd:

test_critical_configmaps_present: Zorgt ervoor dat de ConfigMaps en relevante velden aanwezig zijn voor een SQL-exemplaar.
test_suspended_system_dbs_auto_heal_by_orchestrator: Zorgt ervoor dat master en msdb op welke manier dan ook worden onderbroken (in dit geval gebruiker). Orchestratoronderhoud zorgt ervoor dat het automatisch herstelt.
test_suspended_user_db_does_not_auto_heal_by_orchestrator: Zorgt ervoor dat als een gebruikersdatabase opzettelijk wordt onderbroken door de gebruiker, orchestrator-onderhoud niet automatisch herstelt.
test_delete_active_orchestrator_twice_and_delete_primary_pod: Verwijdert orchestratorpod meerdere keren, gevolgd door de primaire replica en controleert of alle replica's worden gesynchroniseerd. De verwachtingen voor failovertijd voor 2 replica's zijn versoepeld.
test_delete_primary_pod: Hiermee verwijdert u de primaire replica en controleert u of alle replica's worden gesynchroniseerd. De verwachtingen voor failovertijd voor 2 replica's zijn versoepeld.
test_delete_primary_and_orchestrator_pod: Hiermee verwijdert u de primaire replica en orchestratorpod en controleert u of alle replica's worden gesynchroniseerd.
test_delete_primary_and_controller: Hiermee verwijdert u de primaire replica en de gegevenscontrollerpod en controleert u of het primaire eindpunt toegankelijk is en de nieuwe primaire replica wordt gesynchroniseerd. De verwachtingen voor failovertijd voor 2 replica's zijn versoepeld.
test_delete_one_secondary_pod: Hiermee verwijdert u de secundaire replica- en gegevenscontrollerpod en controleert u of alle replica's worden gesynchroniseerd.
test_delete_two_secondaries_pods: Verwijdert secundaire replica's en gegevenscontrollerpods en controleert of alle replica's worden gesynchroniseerd.
test_delete_controller_orchestrator_secondary_replica_pods:
test_failaway: Dwingt ag-failover af van de huidige primaire, zorgt ervoor dat de nieuwe primaire niet hetzelfde is als de oude primaire. Controleert of alle replica's worden gesynchroniseerd.
test_update_while_rebooting_all_non_primary_replicas: Tests controllergestuurde updates zijn tolerant met nieuwe pogingen ondanks verschillende onrustige omstandigheden.

Notitie

Voor bepaalde tests is mogelijk specifieke hardware vereist, zoals bevoegde toegang tot domeincontrollers voor ad tests voor het maken van accounts en DNS-vermeldingen, die mogelijk niet beschikbaar zijn in alle omgevingen die de arc-ci-launcher.

Testresultaten onderzoeken

Een voorbeeldopslagcontainer en -bestand dat door het startprogramma is geüpload:

Een schermopname van de opslagcontainer voor het startprogramma.

Een schermopname van de tarball van het startprogramma.

En de testresultaten die zijn gegenereerd op basis van de uitvoering:

Een schermopname van de testresultaten van het startprogramma.

Resources opschonen

Als u het startprogramma wilt verwijderen, voert u het volgende uit:

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

Hiermee worden de resourcemanifesten opgeschoond die zijn geïmplementeerd als onderdeel van het startprogramma.

Testen vóór de release

Delen via

Zelfstudie: Geautomatiseerde validatietests

Vereisten

Kubernetes-manifestvoorbereiding

Configuratie 1: `.test.env`

Gedetailleerde uitleg voor bepaalde variabelen

1. `ARC_DATASERVICES_EXTENSION_*` - Extensieversie en -trein

2. `ARC_DATASERVICES_WHL_OVERRIDE` - Download-URL van vorige versie van Azure CLI

3. `CUSTOM_LOCATION_OID` - Object-id van aangepaste locaties van uw specifieke Microsoft Entra-tenant

4. `SPN_CLIENT_*` - Referenties voor service-principal

5. `LOGS_STORAGE_ACCOUNT_SAS` - SAS-URL blobopslagaccount

6. `SKIP_*` - het gedrag van het startprogramma beheren door bepaalde fasen over te slaan

Configuratie 2: `patch.json`

Launcher-implementatie

`imageTag` specificatie

`kubectl apply`

Stappen die worden uitgevoerd door het startprogramma

Tests uitgevoerd per testsuite

Testresultaten onderzoeken

Resources opschonen

Feedback

Aanvullende resources

Delen via

Zelfstudie: Geautomatiseerde validatietests

Vereisten

Kubernetes-manifestvoorbereiding

Configuratie 1: .test.env

Gedetailleerde uitleg voor bepaalde variabelen

1. ARC_DATASERVICES_EXTENSION_* - Extensieversie en -trein

2. ARC_DATASERVICES_WHL_OVERRIDE - Download-URL van vorige versie van Azure CLI

3. CUSTOM_LOCATION_OID - Object-id van aangepaste locaties van uw specifieke Microsoft Entra-tenant

4. SPN_CLIENT_* - Referenties voor service-principal

5. LOGS_STORAGE_ACCOUNT_SAS - SAS-URL blobopslagaccount

6. SKIP_* - het gedrag van het startprogramma beheren door bepaalde fasen over te slaan

Configuratie 2: patch.json

Launcher-implementatie

imageTag specificatie

kubectl apply

Stappen die worden uitgevoerd door het startprogramma

Tests uitgevoerd per testsuite

Testresultaten onderzoeken

Resources opschonen

Gerelateerde inhoud

Feedback

Aanvullende resources

Configuratie 1: `.test.env`

1. `ARC_DATASERVICES_EXTENSION_*` - Extensieversie en -trein

2. `ARC_DATASERVICES_WHL_OVERRIDE` - Download-URL van vorige versie van Azure CLI

3. `CUSTOM_LOCATION_OID` - Object-id van aangepaste locaties van uw specifieke Microsoft Entra-tenant

4. `SPN_CLIENT_*` - Referenties voor service-principal

5. `LOGS_STORAGE_ACCOUNT_SAS` - SAS-URL blobopslagaccount

6. `SKIP_*` - het gedrag van het startprogramma beheren door bepaalde fasen over te slaan

Configuratie 2: `patch.json`

`imageTag` specificatie

`kubectl apply`