Condividi tramite

Esercitazione: Test di convalida automatizzati

  • Articolo

Come parte di ogni commit che crea servizi dati abilitati per Arc, Microsoft esegue pipeline CI/CD automatizzate che eseguono test end-to-end. Questi test vengono orchestrati tramite due contenitori gestiti insieme al prodotto principale (Controller di dati, Istanza gestita di SQL abilitata dal server Azure Arc & PostgreSQL). Questi contenitori sono:

  • arc-ci-launcher: contenente le dipendenze di distribuzione (ad esempio, estensioni dell'interfaccia della riga di comando), nonché il codice di distribuzione del prodotto (usando l'interfaccia della riga di comando di Azure) per le modalità di connettività diretta e indiretta. Dopo l'onboarding di Kubernetes con il controller di dati, il contenitore sfrutta Sonobuoy per attivare test di integrazione paralleli.
  • arc-sb-plugin: un plug-in Sonobuoy contenente pytesttest di integrazione end-to-end basati su semplici test di fumo (distribuzioni, eliminazioni), scenari complessi a disponibilità elevata, chaos-test (eliminazioni di risorse) e così via.

Questi contenitori di test vengono resi disponibili pubblicamente per i clienti e i partner per eseguire test di convalida dei servizi dati abilitati per Arc nei propri cluster Kubernetes in esecuzione ovunque, per convalidare:

  • Distribuzione/versioni di Kubernetes
  • Distribuzione/versioni host
  • Archiviazione (StorageClass/CSI), rete (ad esempio, LoadBalancer, DNS)
  • Altre configurazioni specifiche di Kubernetes o dell'infrastruttura

Per i clienti che intendono eseguire Servizi dati abilitati per Arc in una distribuzione non documentata, devono eseguire correttamente questi test di convalida per essere considerati supportati. Inoltre, i partner possono usare questo approccio per certificare che la propria soluzione è conforme ai Servizi dati abilitati per Arc. Vedere Convalida kubernetes abilitata per Azure Arc.

Il diagramma seguente illustra questo processo generale:

Diagramma che mostra i test di integrazione kube-native di Servizi dati abilitati per Arc.

In questa esercitazione apprenderai a:

  • Distribuire arc-ci-launcher usando kubectl
  • Esaminare i risultati dei test di convalida nell'account di Archiviazione BLOB di Azure

Prerequisiti

  • Credenziali:

  • Client-tooling:

    • kubectl installato - versione minima (Maggiore:"1", Minore:"21")
    • Interfaccia della riga di comando git (o alternative basate sull'interfaccia utente)

Preparazione del manifesto Kubernetes

L'utilità di avvio viene resa disponibile come parte del repository di microsoft/azure_arc, come manifesto Kustomize - Kustomize è incorporata in kubectl, quindi non sono necessari strumenti aggiuntivi.

  1. Clonare il repository in locale:
git clone https://github.com/microsoft/azure_arc.git
  1. Passare a azure_arc/arc_data_services/test/launcher per visualizzare la struttura di cartelle seguente:
├── 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 questa esercitazione verranno illustrati i passaggi per il servizio Azure Kubernetes, ma la struttura di sovrapposizione precedente può essere estesa per includere distribuzioni Kubernetes aggiuntive.

Il manifesto pronto per la distribuzione rappresenterà quanto segue:

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

Esistono due file che devono essere generati per localizzare l'utilità di avvio da eseguire all'interno di un ambiente specifico. Ognuno di questi file può essere generato copiando e incollando e compilando ognuno dei file del modello (*.tmpl) sopra:

  • .test.env: compilare da .test.env.tmpl
  • patch.json: compilare da patch.json.tmpl

Suggerimento

Il .test.env è un singolo set di variabili di ambiente che determina il comportamento dell'utilità di avvio. La generazione con attenzione per un determinato ambiente garantirà la riproducibilità del comportamento dell'utilità di avvio.

Config 1: .test.env

Un esempio compilato del file .test.env generato in base a .test.env.tmpl viene condiviso di seguito con commenti inline.

Importante

La sintassi export VAR="value" seguente non deve essere eseguita in locale per le variabili di ambiente di origine dal computer, ma è disponibile per l'utilità di avvio. L'utilità di avvio monta questo file .test.env così com'è come Kubernetes secret usando secretGenerator di Kustomize (Kustomize accetta un file, base64 codifica il contenuto dell'intero file e lo trasforma in un segreto Kubernetes). Durante l'inizializzazione, l'utilità di avvio esegue il comando source di Bash, che importa le variabili di ambiente dal file .test.env montato così com'è nell'ambiente dell'utilità di avvio.

In altre parole, dopo aver incollato .test.env.tmpl e modificato per creare .test.env, il file generato dovrebbe essere simile all'esempio seguente. Il processo di compilazione del file .test.env è identico tra sistemi operativi e terminali.

Suggerimento

Esistono alcune variabili di ambiente che richiedono spiegazioni aggiuntive per maggiore chiarezza nella riproducibilità. Queste verranno commentate con see detailed explanation below [X].

Suggerimento

Si noti che l'esempio .test.env riportato di seguito è dedicato alla modalità diretta. Alcune di queste variabili, ad esempio ARC_DATASERVICES_EXTENSION_VERSION_TAG, non si applicano alla modalità indiretta. Per semplicità, è consigliabile configurare il file di .test.env con variabili di modalità diretta tenendo presente che se si cambia CONNECTIVITY_MODE=indirect l'utilità di avvio ignorerà le impostazioni specifiche della modalità diretta e userà un subset dall'elenco.

In altre parole, la pianificazione per la modalità diretta consente di soddisfare le variabili della modalità indiretta.

Esempio completato di .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"

Importante

Se si esegue la generazione di file di configurazione in un computer Windows, sarà necessario convertire la sequenza end-of-line da CRLF (Windows) a LF (Linux), dal momento che arc-ci-launcher viene eseguito come contenitore Linux. Lasciare la riga terminare con CRLF può causare un errore all'avvio del contenitore arc-ci-launcher, ad esempio: /launcher/config/.test.env: $'\r': command not found Ad esempio, eseguire la modifica usando VSCode (in basso a destra della finestra):
Screenshot che mostra dove modificare la sequenza di riga (CRLF).

Spiegazione dettagliata per determinate variabili

1. ARC_DATASERVICES_EXTENSION_* - Versione dell'estensione e training

Obbligatorio: obbligatorio per le distribuzioni della modalità direct.

L'utilità di avvio può distribuire sia versioni GA che versioni precedenti a GA.

Il mapping della versione di estensione per release-train (ARC_DATASERVICES_EXTENSION_RELEASE_TRAIN) è ottenuto da qui:

2. ARC_DATASERVICES_WHL_OVERRIDE - URL di download della versione precedente dell'interfaccia della riga di comando di Azure

Facoltativo: lasciare vuoto in .test.env per usare l'impostazione predefinita preconfezionata.

L'immagine dell'utilità di avvio è preconfezionata con la versione più recente dell'interfaccia della riga di comando arcdata al momento della versione di ogni immagine del contenitore. Tuttavia, per lavorare con le versioni precedenti e i test di aggiornamento, potrebbe essere necessario fornire all'utilità di avvio il collegamento di download dell'URL BLOB dell'interfaccia della riga di comando di Azure, per eseguire l'override della versione preassemblata; ad esempio, per indicare all'utilità di avvio di installare la versione 1.4.3, compilare:

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

La versione dell'interfaccia della riga di comando per il mapping degli URL BLOB è disponibile qui.

3. CUSTOM_LOCATION_OID - ID oggetto Percorsi personalizzati dal tenant specifico di Microsoft Entra

Obbligatorio: è obbligatorio per la creazione della posizione personalizzata del cluster connesso.

I passaggi seguenti vengono originati da Abilitare percorsi personalizzati nel cluster per recuperare l'ID oggetto percorso personalizzato univoco per il tenant di Microsoft Entra.

Esistono due approcci per ottenere il CUSTOM_LOCATION_OID per il tenant di Microsoft Entra.

  1. Tramite l'interfaccia della riga di comando di Azure:

    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.

    Uno screenshot di un terminale di PowerShell che mostra az ad sp show --id <>.

  2. Tramite il portale di Azure, passare al pannello Microsoft Entra e cercare Custom Locations RP:

    Uno screenshot del punto di conservazione delle posizioni personalizzate.

4. SPN_CLIENT_* - Aggiunta delle credenziali dell'entità servizio

Obbligatorio: obbligatorio per le distribuzioni in modalità diretta.

L'utilità di avvio accede ad Azure usando queste credenziali.

I test di convalida devono essere eseguiti in cluster Kubernetes non di produzione/test e sottoscrizioni di Azure, concentrandosi sulla convalida funzionale della configurazione di Kubernetes/Infrastruttura. Pertanto, per evitare il numero di passaggi manuali necessari per eseguire i lanci, è consigliabile fornire un SPN_CLIENT_ID/SECRET con Owner a livello di gruppo di risorse (o sottoscrizione), in quanto creerà diverse risorse in questo gruppo di risorse, nonché l'assegnazione di autorizzazioni a tali risorse per diverse identità gestite create come parte della distribuzione (queste assegnazioni di ruolo richiedono che l'entità servizio abbia Owner).

5. LOGS_STORAGE_ACCOUNT_SAS - URL di firma di accesso condiviso dell'account di archiviazione BLOB

Consigliato: lasciare vuoto questo significa che non si otterranno i risultati e i log dei test.

L'utilità di avvio richiede un percorso permanente (Archiviazione BLOB di Azure) per caricare i risultati, perché Kubernetes non consente ancora la copia di file da pod arrestati/completati. Vedere qui. L'utilità di avvio consente di ottenere la connettività all'Archiviazione BLOB di Azure usando un URL di firma di accesso condiviso con ambito account (anziché contenitore o BLOB con ambito) - un URL firmato con una definizione di accesso con associazione a tempo - vedere Concedere l'accesso limitato alle risorse di Archiviazione di Azure usando firme di accesso condiviso (SAS), per:

  1. Creare un nuovo contenitore di archiviazione nell'account di archiviazione preesistente (LOGS_STORAGE_ACCOUNT), se non esiste (nome basato su LOGS_STORAGE_CONTAINER)
  2. Creare nuovi BLOB denominati in modo univoco (file tar di log di test)

I passaggi seguenti sono originati da Concedere l'accesso limitato alle risorse di Archiviazione di Azure usando firme di accesso condiviso (SAS).

Suggerimento

Gli URL di firma di accesso condiviso sono diversi dalla chiave dell'account di archiviazione, un URL di firma di accesso condiviso viene formattato come segue.

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

Esistono diversi approcci alla generazione di un URL di firma di accesso condiviso. Questo esempio mostra il portale:

Screenshot dei dettagli della firma di accesso condiviso nel portale di Azure.

Per usare invece l'interfaccia della riga di comando di Azure, vedere az storage account generate-sas

6. SKIP_* - controllo del comportamento dell'utilità di avvio ignorando determinate fasi

Facoltativo: lasciare vuoto in .test.env per eseguire tutte le fasi (equivalente a 0 o vuoto)

L'utilità di avvio espone SKIP_* variabili, per eseguire e ignorare fasi specifiche, ad esempio per eseguire un'esecuzione "solo pulizia".

Anche se l'utilità di avvio è progettata per pulire sia all'inizio che alla fine di ogni esecuzione, è possibile che l'avvio e/o gli errori di test lascino le risorse residui dietro. Per eseguire l'utilità di avvio in modalità "solo pulizia", impostare le variabili seguenti 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

Le impostazioni precedenti indicano all'utilità di avvio di pulire tutte le risorse di Arc e Servizi dati Arc e di non distribuire/testare/caricare i log.

Config 2: patch.json

Un esempio compilato del file patch.json generato in base a patch.json.tmpl viene condiviso di seguito.

Notare che il spec.docker.registry, repository, imageTag deve essere identico ai valori in .test.env sopra

Esempio completato di 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"
        }                  
    ]
}

Distribuzione dell'utilità di avvio

È consigliabile distribuire l'utilità di avvio in un cluster non di produzione/test, perché esegue azioni distruttive su Arc e altre risorse Kubernetes usate.

Specifiche di imageTag

L'utilità di avvio viene definita all'interno del manifesto di Kubernetes come Job, che richiede di indicare a Kubernetes dove trovare l'immagine dell'utilità di avvio. Questa opzione è impostata in base/kustomization.yaml:

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

Suggerimento

Per riepilogare, a questo punto, ci sono 3 posizioni specificate imageTag, per maggiore chiarezza, ecco una spiegazione dei diversi usi di ognuno di essi. In genere, quando si testa una determinata versione, tutti e 3 i valori sono gli stessi (allineati a una determinata versione):

# Filename Nome variabile Perché? In uso da?
1 .test.env DOCKER_TAG Origine dell'immagine del programma di avvio automatico nell'ambito dell'installazione dell'estensione az k8s-extension create nell'utilità di avvio
2 patch.json value.imageTag Origine dell'immagine del titolare del trattamento dei dati az arcdata dc create nell'utilità di avvio
3 kustomization.yaml images.newTag Origine dell'immagine dell'utilità di avvio kubectl apply nell'utilità di avvio

kubectl apply

Per verificare che il manifesto sia stato configurato correttamente, tentare la convalida lato client con --dry-run=client, che stampa le risorse Kubernetes da creare per l'utilità di avvio:

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)

Per distribuire l'utilità di avvio e i log della parte finale, eseguire quanto segue:

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

A questo punto, l'utilità di avvio dovrebbe essere avviata e dovrebbe essere visualizzato quanto segue:

Screenshot del terminale della console dopo l'avvio dell'utilità di avvio.

Anche se è consigliabile distribuire l'utilità di avvio in un cluster senza risorse Arc preesistenti, l'utilità di avvio contiene la convalida preliminare per individuare i CD e le risorse ARM di Arc e Servizi dati Arc preesistenti e tenta di pulirli in modo ottimale (usando le credenziali dell'entità servizio fornite), prima di distribuire la nuova versione:

Uno screenshot del terminale della console che individua Kubernetes e altre risorse.

Questo stesso processo di individuazione e pulizia dei metadati viene eseguito anche all'uscita dell'utilità di avvio, per lasciare il cluster il più vicino possibile allo stato preesistente prima dell'avvio.

Passaggi eseguiti dall'utilità di avvio

A livello generale, l'utilità di avvio esegue la sequenza di passaggi seguente:

  1. Eseguire l'autenticazione all'API Kubernetes usando l'account del servizio montato su pod

  2. Eseguire l'autenticazione all'API ARM usando un'entità servizio montata su segreto

  3. Eseguire l'analisi dei metadati CRD per individuare le risorse personalizzate di Arc e Servizi dati Arc

  4. Pulire le risorse personalizzate esistenti in Kubernetes e le risorse successive in Azure. Se una mancata corrispondenza tra le credenziali in .test.env rispetto alle risorse esistenti nel cluster, uscire.

  5. Generare un set univoco di variabili di ambiente in base al timestamp per il nome del cluster Arc, il controller di dati e la posizione/spazio dei nomi personalizzati. Stampa le variabili di ambiente, offuscando i valori sensibili (ad esempio, password dell'entità servizio e così via)

  6. a. Per la modalità diretta: eseguire l'onboarding del cluster in Azure Arc, quindi distribuisce il controller.

    b. Per la modalità indiretta: distribuire il titolare del trattamento dei dati

  7. Quando il titolare del trattamento dei dati viene Ready, generare un set di log dell'interfaccia della riga di comando di Azure (az arcdata dc debug) e archiviare localmente, etichettati come setup-complete, come baseline.

  8. Usare la variabile di ambiente TESTS_DIRECT/INDIRECT da .test.env per avviare un set di esecuzioni di test Sonobuoy parallelizzate in base a una matrice separata da spazi (TESTS_(IN)DIRECT). Queste esecuzioni vengono eseguite in un nuovo spazio dei nomi sonobuoy, usando il pod arc-sb-plugin che contiene i test di convalida Pytest.

  9. aggregatore Sonobuoy accumulare i junit risultati dei test e i log per ogni esecuzione di test arc-sb-plugin, che vengono esportati nel pod dell'utilità di avvio.

  10. Restituire il codice di uscita dei test e generare un altro set di log di debug, l'interfaccia della riga di comando di Azure e sonobuoy, archiviati in locale, etichettati come test-complete.

  11. Eseguire un'analisi dei metadati CRD, simile al passaggio 3, per individuare le risorse personalizzate di Arc e Servizi dati Arc esistenti. Quindi, procedere per eliminare tutte le risorse Arc e Arc Data in ordine inverso dalla distribuzione, nonché CRD, Ruolo/ClusterRoles, PV/PVC e così via.

  12. Provare a usare il token di firma di accesso condiviso LOGS_STORAGE_ACCOUNT_SAS fornito per creare un nuovo contenitore dell'account di archiviazione denominato in base a LOGS_STORAGE_CONTAINER, nel account di archiviazione preesistente LOGS_STORAGE_ACCOUNT. Se il contenitore dell'account di archiviazione esiste già, usarlo. Caricare tutti i risultati e i log dei test locali in questo contenitore di archiviazione come tarball (vedere di seguito).

  13. Uscire.

Test eseguiti per gruppo di test

Sono disponibili circa 375 test di integrazione univoci, in 27 gruppi di test, ognuno dei quali testa una funzionalità separata.

Suite # Nome gruppo di test Descrizione del test
1 ad-connector Verifica la distribuzione e l'aggiornamento di un connettore Active Directory (AD Connector).
2 billing Il test di vari tipi di licenza business critical si riflette nella tabella delle risorse nel controller, usata per il caricamento della fatturazione.
3 ci-billing Simile a billing, ma con più permutazioni CPU/memoria.
4 ci-sqlinstance Test a esecuzione prolungata per la creazione di più repliche, aggiornamenti, aggiornamento GP -> BC, convalida del backup e SQL Server Agent.
5 controldb Test Database di controllo : controllo del segreto SA, verifica dell'accesso di sistema, creazione di controlli e verifica della integrità per la versione della build SQL.
6 dc-export Fatturazione in modalità indiretta e caricamento dell'utilizzo.
7 direct-crud Crea un'istanza SQL usando le chiamate ARM, convalida sia in Kubernetes che in ARM.
8 direct-fog Crea più istanze DI SQL e crea un gruppo di failover tra di essi usando le chiamate ARM.
9 direct-hydration Crea un'istanza SQL con l'API Kubernetes, convalida la presenza in ARM.
10 direct-upload Convalida il caricamento della fatturazione in modalità diretta
11 kube-rbac Assicura che le autorizzazioni dell'account del servizio Kubernetes per Servizi dati Arc corrispondano alle aspettative con privilegi minimi.
12 nonroot Assicura che i contenitori vengano eseguiti come utente non radice
13 postgres Completa vari test di creazione, ridimensionamento, backup/ripristino di Postgres.
14 release-sanitychecks L’integrità controlla le versioni da mese a mese, ad esempio le versioni di compilazione di SQL Server.
15 sqlinstance Versione più breve di ci-sqlinstance, per le convalide veloci.
16 sqlinstance-ad Verifica la creazione di istanze DI SQL con Active Directory Connector.
17 sqlinstance-credentialrotation Verifica la rotazione automatica delle credenziali sia per utilizzo generico che per business critical.
18 sqlinstance-ha Vari test di stress a disponibilità elevata, inclusi i riavvii dei pod, i failover forzati e le sospensioni.
19 sqlinstance-tde Vari test di Transparent Data Encryption.
20 telemetry-elasticsearch Convalida l'inserimento dei log in Elasticsearch.
21 telemetry-grafana Verifica che Grafana sia raggiungibile.
22 telemetry-influxdb Convalida l'inserimento delle metriche in InfluxDB.
23 telemetry-kafka Vari test per Kafka tramite SSL, configurazione a broker singolo/multi-broker.
24 telemetry-monitorstack Verifica i componenti di monitoraggio, ad esempio Fluentbit e Collectd, sono funzionali.
25 telemetry-telemetryrouter Verifica Apri telemetria.
26 telemetry-webhook Verifica i webhook di Servizi dati con chiamate valide e non valide.
27 upgrade-arcdata Aggiorna una suite completa di istanze SQL (GP, replica BC 2, replica BC 3 con Active Directory) e aggiornamenti dalla versione del mese precedente alla build più recente.

Ad esempio, per sqlinstance-ha vengono eseguiti i test seguenti:

  • test_critical_configmaps_present: garantisce che ConfigMaps e i campi pertinenti siano presenti per un'istanza di SQL.
  • test_suspended_system_dbs_auto_heal_by_orchestrator: garantisce se master e msdb vengono sospesi con qualsiasi mezzo (in questo caso, utente). La manutenzione dell'agente di orchestrazione riconcilia la guarigione automatica.
  • test_suspended_user_db_does_not_auto_heal_by_orchestrator: assicura se un database utente viene deliberatamente sospeso dall'utente, la manutenzione dell'agente di orchestrazione non lo risolve automaticamente.
  • test_delete_active_orchestrator_twice_and_delete_primary_pod: elimina più volte il pod dell'agente di orchestrazione, seguito dalla replica primaria e verifica che tutte le repliche siano sincronizzate. Le aspettative del tempo di failover per 2 repliche sono flessibili.
  • test_delete_primary_pod: elimina la replica primaria e verifica che tutte le repliche siano sincronizzate. Le aspettative del tempo di failover per 2 repliche sono flessibili.
  • test_delete_primary_and_orchestrator_pod: elimina la replica primaria e il pod dell'agente di orchestrazione e verifica che tutte le repliche siano sincronizzate.
  • test_delete_primary_and_controller: elimina la replica primaria e il pod del controller dati e verifica che l'endpoint primario sia accessibile e la nuova replica primaria sia sincronizzata. Le aspettative del tempo di failover per 2 repliche sono flessibili.
  • test_delete_one_secondary_pod: elimina la replica secondaria e il pod del controller dati e verifica che tutte le repliche siano sincronizzate.
  • test_delete_two_secondaries_pods: elimina le repliche secondarie e il pod del controller dati e verifica che tutte le repliche siano sincronizzate.
  • test_delete_controller_orchestrator_secondary_replica_pods:
  • test_failaway: forza il failover del gruppo di disponibilità dall'istanza primaria corrente, garantisce che il nuovo database primario non sia uguale al database primario precedente. Verifica che tutte le repliche siano sincronizzate.
  • test_update_while_rebooting_all_non_primary_replicas: gli aggiornamenti basati su controller sono resilienti con tentativi nonostante varie circostanze turbolente.

Nota

Alcuni test possono richiedere hardware specifico, ad esempio l'accesso con privilegi ai controller di dominio per test ad per la creazione di account e voce DNS, che potrebbero non essere disponibili in tutti gli ambienti che cercano di usare il arc-ci-launcher.

Esame dei risultati dei test

Contenitore e file di archiviazione di esempio caricati dall'utilità di avvio:

Uno screenshot del contenitore di archiviazione dell'utilità di avvio.

Uno screenshot del tarball dell'utilità di avvio.

E i risultati del test generati dall'esecuzione:

Uno screenshot dei risultati del test dell'utilità di avvio.

Pulire le risorse

Per eliminare l'utilità di avvio, eseguire:

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

In questo modo vengono puliti i manifesti delle risorse distribuiti come parte dell'utilità di avvio.

Contenuto correlato

Test delle versioni non definitive