Tutorial: teste de validação automatizado

Como parte de cada commit que compila os serviços de dados habilitados para Arc, a Microsoft executa pipelines automatizados de CI/CD que executam testes de ponta a ponta. Esses testes são orquestrados por meio de dois contêineres que são mantidos junto com o produto principal (Controlador de Dados, Instância Gerenciada de SQL habilitada pelo servidor Azure Arc e pelo servidor PostgreSQL). Esses contêineres são:

• arc-ci-launcher: contendo dependências de implantação (por exemplo, extensões de CLI), bem como código de implantação de produto (usando a CLI do Azure) para modos de conectividade direta e indireta. Depois que o Kubernetes é integrado ao Controlador de Dados, o contêiner aproveita o Sonobuoy para disparar testes de integração paralelos.
• arc-sb-plugin: um plug-in Sonobuoy que contém testes de integração de ponta a ponta baseados em Pytest, que vão desde smoke-tests simples (implantações, exclusões), até cenários complexos de alta disponibilidade, testes do caos (exclusões de recursos) etc.

Esses contêineres de teste são disponibilizados publicamente para clientes e parceiros realizarem testes de validação de serviços de dados habilitados para Arc em seus próprios clusters do Kubernetes em execução em qualquer lugar, para validar:

• Distribuição/versões do Kubernetes
• Distribuição/versões do host
• Armazenamento (StorageClass/CSI), rede (por exemplo LoadBalancers, DNS)
• Outra configuração específica do Kubernetes ou da infraestrutura

Para clientes que pretendem executar os Serviços de Dados habilitados para Arc em uma distribuição não documentada, eles devem executar esses testes de validação com êxito para serem considerados com suporte. Além disso, os parceiros podem usar essa abordagem para se certificar de que sua solução está em conformidade com os Serviços de Dados habilitados para Arc - consulte a validação do Kubernetes dos serviços de dados habilitados para Azure Arc.

O diagrama a seguir descreve este processo de alto nível:

Neste tutorial, você aprenderá a:

• Implantar arc-ci-launcher usando kubectl
• Examinar os resultados do teste de validação em sua conta Armazenamento de Blobs do Azure

Pré-requisitos

• Credenciais:

  • O test.env.tmpl arquivo contém as credenciais necessárias e é uma combinação dos pré-requisitos existentes necessários para integrar um Cluster Conectado do Azure Arc e um Controlador de Dados Conectado Diretamente. A instalação desse arquivo é explicada abaixo com exemplos.
  • Um arquivo kubeconfig para o cluster do Kubernetes testado com cluster-admin acesso (necessário para integração do cluster conectado no momento)

• Ferramentas do cliente:

  • kubectl instalado - versão mínima (Major:"1", Minor:"21")
  • git interface de linha de comando (ou alternativas baseadas em interface do usuário)

Preparação do manifesto do Kubernetes

O inicializador é disponibilizado como parte do microsoft/azure_arc repositório, pois um manifesto Kustomize - Kustomize é incorporado em kubectl - portanto, nenhuma ferramenta adicional é necessária.

1. Clonar o repositório localmente:

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

2. Navegue até azure_arc/arc_data_services/test/launcher, para ver a seguinte estrutura de pastas:

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

Neste tutorial, vamos nos concentrar nas etapas do AKS, mas a estrutura de sobreposição acima pode ser estendida para incluir distribuições adicionais do Kubernetes.

O manifesto pronto para implantar representará o seguinte:

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

Há dois arquivos que precisam ser gerados para localizar o inicializador para serem executados dentro de um ambiente específico. Cada um desses arquivos pode ser gerado copiando e colando e preenchendo cada um dos arquivos de modelo (*.tmpl) acima:

• .test.env: preencher de .test.env.tmpl
• patch.json: preencher de patch.json.tmpl

Dica

O .test.env é um único conjunto de variáveis de ambiente que impulsiona o comportamento do inicializador. Gerá-lo com cuidado para um determinado ambiente garantirá a reprodutibilidade do comportamento do inicializador.

Config 1: .test.env

Um exemplo preenchido do arquivo .test.env, gerado com base em .test.env.tmpl é compartilhado abaixo com comentários embutidos.

Importante

A export VAR="value" sintaxe abaixo não deve ser executada localmente para variáveis de ambiente de origem do computador , mas está lá para o inicializador. O inicializador monta esse .test.env arquivo como está como um Kubernetes secret usando do Kustomize secretGenerator (Kustomize usa um arquivo, base64 codifica todo o conteúdo do arquivo e o transforma em um segredo do Kubernetes). Durante a inicialização, o inicializador executa o comando source do bash, que importa as variáveis de ambiente do arquivo montado como está .test.env no ambiente do inicializador.

Em outras palavras, depois de copiar e colar .test.env.tmpl e editar para criar .test.env, o arquivo gerado deve ser semelhante ao exemplo abaixo. O processo para preencher o arquivo .test.env é idêntico entre sistemas operacionais e terminais.

Dica

Há um punhado de variáveis de ambiente que exigem explicação adicional para clareza na reprodutibilidade. Estes serão comentados com see detailed explanation below [X].

Dica

Observe que o exemplo abaixo .test.env é para o modo direto . Algumas dessas variáveis, como ARC_DATASERVICES_EXTENSION_VERSION_TAG não se aplicam ao modo indireto. Para simplificar, é melhor configurar o arquivo .test.env com variáveis de modo direto em mente, alternar CONNECTIVITY_MODE=indirect fará com que o inicializador ignore as configurações específicas do modo direto e use um subconjunto da lista.

Em outras palavras, planejar o modo direto nos permite atender variáveis de modo indireto.

Exemplo concluído de .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 estiver realizando a geração de arquivos de configuração em um computador Windows, você precisará converter a sequência de Fim de Linha do CRLF (Windows) para LF (Linux), conforme arc-ci-launcher executa como um contêiner do Linux. Deixar a linha terminando em CRLF pode causar um erro noarc-ci-launcher início do contêiner, como: /launcher/config/.test.env: $'\r': command not found por exemplo, executar a alteração usando o VSCode (parte inferior direita da janela):

Explicação detalhada para determinadas variáveis

1. ARC_DATASERVICES_EXTENSION_* – Versão de extensão e treinamento

Obrigatório: isso é necessário para implantações de modo direct.

O inicializador pode implantar versões GA e pré-GA.

A versão de extensão para o mapeamento da release-train (ARC_DATASERVICES_EXTENSION_RELEASE_TRAIN) é obtida a partir daqui:

• GA: stable - log de versão
• Pré-GA: preview - teste de pré-lançamento

2. ARC_DATASERVICES_WHL_OVERRIDE – URL de download da versão anterior da CLI do Azure

Opcional: deixe isso vazio em .test.env para usar o padrão pré-empacotado.

A imagem do inicializador é pré-empacotada com a versão mais recente da CLI arcdata no momento de cada versão de imagem de contêiner. No entanto, para trabalhar com versões anteriores e testes de atualização, talvez seja necessário fornecer ao inicializador o link de download da URL de Blob da CLI do Azure para substituir a versão pré-empacotada; por exemplo, para instruir o inicializador a instalar a versão 1.4.3, preencha:

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

A versão da CLI para o mapeamento de URL do Blob pode ser encontrada aqui.

3. CUSTOM_LOCATION_OID - ID de Objeto de Locais Personalizados do seu locatário específico do Microsoft Entra

Obrigatório: isso é necessário para a criação do Local Personalizado do Cluster Conectado.

As etapas a seguir são originadas de Habilitar locais personalizados no seu cluster para recuperar a ID de Objeto Local Personalizada exclusiva para seu locatário do Microsoft Entra ID.

Existem duas abordagens para obter o CUSTOM_LOCATION_OID para seu locatário do Microsoft Entra.

1. Via CLI do 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.
   

   

2. Pelo portal do Microsoft Azure, navegue até sua folha do Microsoft Entra e pesquise Custom Locations RP:

   

4. SPN_CLIENT_* – Credenciais principais de serviço

Obrigatório: isso é necessário para implantações de Modo Direto.

O inicializador faz logon no Azure usando essas credenciais.

O teste de validação deve ser executado em cluster Kubernetes de não produção/teste e assinaturas do Azure – com foco na validação funcional da instalação do Kubernetes/Infraestrutura. Portanto, para evitar o número de etapas manuais necessárias para executar inicializações, é recomendável fornecer um SPN_CLIENT_ID/SECRET que tenha Owner no nível do Grupo de Recursos (ou Assinatura), pois ele criará vários recursos neste Grupo de Recursos, bem como atribuir permissões a esses recursos em relação a várias Identidades Gerenciadas criadas como parte da implantação (essas atribuições de função, por sua vez, exigem que a Entidade de Serviço tenha Owner).

5. LOGS_STORAGE_ACCOUNT_SAS – URL SAS da conta de armazenamento de Blobs

Recomendado: deixar isso vazio significa que você não obterá resultados e logs de teste.

O inicializador precisa de um local persistente (Armazenamento de Blobs do Azure) para carregar resultados, pois o Kubernetes não permite (ainda) copiar arquivos de pods parados/concluídos - confira aqui. O inicializador obtém conectividade com Armazenamento de Blobs do Azure usando uma URL SAS com escopo de conta (em oposição ao escopo de contêiner ou blob) – URL assinada com uma definição de acesso com limite de tempo – consulte Conceder acesso limitado aos recursos de Armazenamento do Azure usando SAS (assinaturas de acesso compartilhado) para:

1. Criar um novo contêiner de armazenamento na conta de armazenamento pré-existente (LOGS_STORAGE_ACCOUNT), se ele não existir (nome baseado em LOGS_STORAGE_CONTAINER)
2. Criar blobs novos e nomeados exclusivamente (arquivos tar de log de teste)

As etapas a seguir são originadas de Conceder acesso limitado aos recursos de armazenamento do Azure usando SAS (assinaturas de acesso compartilhado).

Dica

AS URLs SAS são diferentes da Chave da Conta de Armazenamento, uma URL SAS é formatada da seguinte maneira.

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

Há várias abordagens para gerar uma URL SAS. Este exemplo mostra o portal:

Para usar a CLI do Azure em vez disso, consulte az storage account generate-sas

6. SKIP_* – controlar o comportamento do inicializador ignorando determinados estágios

Opcional: deixe isso vazio em .test.env para executar todos os estágios (equivalente a 0 ou em branco)

O inicializador expõe variáveis SKIP_*, para executar e ignorar estágios específicos. Por exemplo, para realizar uma execução "somente limpeza".

Embora o inicializador tenha sido projetado para limpar tanto no início quanto no final de cada execução, é possível iniciar e/ou testar falhas para deixar recursos de resíduos para trás. Para executar o inicializador no modo "cleanup only", defina as seguintes variáveis em .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

As configurações acima instruem o inicializador a limpar todos os recursos do Arc e do Serviços de Dados Arc e a não implantar/testar/carregar logs.

Config 2: patch.json

Um exemplo preenchido do arquivo patch.json, gerado com base em patch.json.tmpl é compartilhado abaixo:

Observe que os spec.docker.registry, repository, imageTag devem ser idênticos aos valores acima em.test.env

Exemplo concluído de 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"
        }                  
    ]
}

Implantação do inicializador

É recomendável implantar o inicializador em um cluster de não produção/teste. Desse modo, ele executa ações destrutivas no Arc e em outros recursos usados do Kubernetes.

imageTag especificação

O inicializador é definido dentro do Manifesto do Kubernetes como um Job, o que requer instruir o Kubernetes onde localizar a imagem do inicializador. Isso é definido em base/kustomization.yaml:

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

Dica

Para recapitular, neste ponto, há 3 locais que especificamos imageTag, para deixar claro, aqui está uma explicação dos diferentes usos de cada um. Normalmente, ao testar uma determinada versão, todos os três valores seriam os mesmos (alinhando-se a uma determinada versão):

#	Nome de arquivo	Nome da variável	Por quê?	Usado por?
1	.test.env	DOCKER_TAG	Fornecer a imagem bootstrapper como parte da instalação da extensão	az k8s-extension create no inicializador
2	patch.json	value.imageTag	Fornecer a imagem do Controlador de Dados	az arcdata dc create no inicializador
3	kustomization.yaml	images.newTag	Fornecer a imagem do inicializador	kubectl apply no inicializador

kubectl apply

Para validar se o manifesto foi configurado corretamente, tente a validação do lado do cliente com --dry-run=clientque imprime os recursos do Kubernetes a serem criados para o inicializador:

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)

Para implantar os logs do inicializador e da parte final, execute o seguinte:

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

Neste ponto, o inicializador deve ser iniciado e você deverá ver o seguinte:

Embora seja melhor implantar o inicializador em um cluster sem recursos do Arc pré-existentes, o inicializador contém validação pré-versão piloto para descobrir CRDs e recursos do ARM pré-existentes do Arc e Serviços de Dados Arc e tenta limpá-los com base no melhor esforço (usando as credenciais fornecidas da Entidade de Serviço), antes de implantar a nova versão:

Esse mesmo processo de descoberta e limpeza de metadados também é executado após a saída do inicializador, para deixar o cluster o mais próximo possível do estado pré-existente antes do lançamento.

Etapas executadas pelo inicializador

Em um nível alto, o inicializador executa a seguinte sequência de etapas:

1. Autenticar na API do Kubernetes usando a Conta de Serviço montada em Pod

2. Autenticar na API do ARM usando a Entidade de Serviço Montada em Segredo

3. Executar a verificação de metadados do CRD para descobrir recursos personalizados existentes do Arc e dos Serviços de Dados Arc

4. Limpar todos os recursos personalizados existentes no Kubernetes e os recursos subsequentes no Azure. Se houver alguma incompatibilidade entre as credenciais em .test.env em comparação com os recursos existentes no cluster, encerre.

5. Gere um conjunto exclusivo de variáveis de ambiente com base no carimbo de data/hora para o nome do Cluster Arc, controlador de dados e local/namespace personalizado. Imprima as variáveis de ambiente, ofuscando valores sensíveis (por exemplo, Senha da Entidade de Serviço etc.)

6. a. Para o Modo Direto: integre o Cluster no Azure Arc e implante o controlador.

   b. Para Modo Indireto: implantar o Controlador de Dados

7. Depois que o Controlador de Dados for Ready, gere um conjunto de logs da CLI do Azure (az arcdata dc debug) e armazene localmente, rotulado conforme setup-complete, como uma linha de base.

8. Use a TESTS_DIRECT/INDIRECT variável de ambiente do .test.envpara iniciar um conjunto de execuções de teste sonobuoy paralelizadas com base em uma matriz separada por espaço (TESTS_(IN)DIRECT). Essas execuções são executadas em um novo namespace sonobuoy, usando o pod arc-sb-plugin que contém os testes de validação Pytest.

9. O agregador sonobuoy acumula os junitresultados do teste e os logs por arc-sb-plugin execução de teste, que são exportados para o pod inicializador.

10. Retornar o código de saída dos testes e gerar outro conjunto de logs de depuração – CLI do Azure e sonobuoy, armazenados localmente, rotulados como test-complete.

11. Execute uma varredura de metadados CRD, semelhante à Etapa 3, para descobrir os recursos personalizados do Arc e Serviços de Dados Arc existentes. Em seguida, prossiga para destruir todos os recursos Arc e dados Arc em ordem inversa da implantação, bem como CRDs, Role/ClusterRoles, PV/PVCs etc.

12. Tente usar o token SAS LOGS_STORAGE_ACCOUNT_SAS fornecido para criar um novo contêiner da Conta de Armazenamento nomeado com base em LOGS_STORAGE_CONTAINER na contade armazenamento pré-existenteLOGS_STORAGE_ACCOUNT. Se o contêiner da Conta de Armazenamento já existir, use-o. Carregue todos os resultados e logs de teste locais para esse contêiner de armazenamento como uma tarball (veja abaixo).

13. Sair.

Testes executados por conjunto de testes

Há aproximadamente 375 testes de integração exclusivos disponíveis, em 27 conjuntos de testes, cada um testando uma funcionalidade separada.

Conjunto #	Nome do conjunto de testes	Descrição do teste
1	ad-connector	Testa a implantação e a atualização de um Active Directory Connector (AD Connector).
2	billing	O teste de vários tipos de licença Comercialmente Críticas é refletido na tabela de recursos no controlador, usada para carregamento de cobrança.
3	ci-billing	Semelhante a billing, mas com mais permutações de CPU/Memória.
4	ci-sqlinstance	Testes de execução prolongada para criação de várias réplicas, atualizações, GP –>Atualização BC, Validação de backup e SQL Server Agent.
5	controldb	Testa o Banco de dados de controle – verificação de segredo SA, verificação de logon do sistema, criação de auditoria e verificações de sanidade para a versão de build do SQL.
6	dc-export	Carregamento de uso e cobrança do Modo Indireto.
7	direct-crud	Cria uma instância SQL usando chamadas do ARM, valida no Kubernetes e no ARM.
8	direct-fog	Cria várias instâncias SQL e cria um Grupo de Failover entre elas usando chamadas do ARM.
9	direct-hydration	Cria a Instância SQL com a API do Kubernetes, valida a presença no ARM.
10	direct-upload	Valida o carregamento de cobrança no Modo Direto
11	kube-rbac	Garante que as permissões da Conta de Serviço do Kubernetes para os Serviços de Dados do Arc correspondam às expectativas de privilégios mínimos.
12	nonroot	Garante que os contêineres sejam executadas como um usuário não raiz
13	postgres	Conclui vários testes de criação, dimensionamento, backup/restauração do Postgres.
14	release-sanitychecks	Verificações de sanidade para versões mês a mês, como versões de build do SQL Server.
15	sqlinstance	Versão mais curta de ci-sqlinstance, para validações rápidas.
16	sqlinstance-ad	Testa a criação de Instâncias SQL com o Active Directory Connector.
17	sqlinstance-credentialrotation	Testa a Rotação de Credenciais automatizadas para Uso Geral e Comercialmente Crítico.
18	sqlinstance-ha	Vários testes de estresse de Alta Disponibilidade, incluindo reinicializações de pod, failovers forçados e suspensões.
19	sqlinstance-tde	Vários testes de Transparent Data Encryption.
20	telemetry-elasticsearch	Valida a ingestão de logs no Elasticsearch.
21	telemetry-grafana	Valida se o Grafana está acessível.
22	telemetry-influxdb	Valida a ingestão de métricas no InfluxDB.
23	telemetry-kafka	Vários testes para Kafka usando SSL, configuração de agente único/vários agentes.
24	telemetry-monitorstack	Testar componentes de monitoramento, como Fluentbit e Collectd são funcionais.
25	telemetry-telemetryrouter	Testa o Open Telemetry.
26	telemetry-webhook	Testa webhooks dos Serviços de Dados com chamadas válidas e inválidas.
27	upgrade-arcdata	Atualiza um conjunto completo de Instâncias SQL (GP, réplica BC 2, réplica BC 3, com Active Directory) e atualizações da versão do mês anterior para o build mais recente.

Por exemplo, para sqlinstance-ha, os seguintes testes são executados:

• test_critical_configmaps_present: garante que ConfigMaps e os campos relevantes estejam presentes em uma Instância SQL.
• test_suspended_system_dbs_auto_heal_by_orchestrator: garante que master e msdb sejam suspensos por qualquer meio (nesse caso, usuário). A reconciliação da manutenção do Orchestrator o recupera automaticamente.
• test_suspended_user_db_does_not_auto_heal_by_orchestrator: garante que, se um banco de dados de usuário for deliberadamente suspenso pelo usuário, a reconciliação da manutenção do Orchestrator não o recuperará.
• test_delete_active_orchestrator_twice_and_delete_primary_pod: exclui o pod do orquestrador várias vezes, seguido pela réplica primária e verifica se todas as réplicas estão sincronizadas. As expectativas de tempo de failover para réplica 2 foram relaxadas.
• test_delete_primary_pod: exclui a réplica primária e verifica se todas as réplicas estão sincronizadas. As expectativas de tempo de failover para réplica 2 foram relaxadas.
• test_delete_primary_and_orchestrator_pod: exclui a réplica primária e o pod do orquestrador e verifica se todas as réplicas estão sincronizadas.
• test_delete_primary_and_controller: exclui a réplica primária e o pod do controlador de dados e verifica se o ponto de extremidade primário está acessível e se a nova réplica primária está sincronizada. As expectativas de tempo de failover para réplica 2 foram relaxadas.
• test_delete_one_secondary_pod: exclui a réplica secundária e o pod do controlador de dados e verifica se todas as réplicas estão sincronizadas.
• test_delete_two_secondaries_pods: exclui as réplicas secundárias o pod do controlador de dados e verifica se todas as réplicas estão sincronizadas.
• test_delete_controller_orchestrator_secondary_replica_pods:
• test_failaway: força o failover do AG para longe da primária atual, garante que a nova primária não seja a mesma que a primária antiga. Verifica se todas as réplicas estão sincronizadas.
• test_update_while_rebooting_all_non_primary_replicas: testa se as atualizações orientadas pelo controlador são resilientes com repetições, apesar de várias circunstâncias turbulentas.

Observação

Determinados testes podem exigir hardware específico, como acesso privilegiado a Controladores de Domínio para testes ad para criação de Conta e Entrada DNS, que podem não estão disponíveis em todos os ambientes que pretendem usar o arc-ci-launcher.

Examinar resultados de teste

Um contêiner de armazenamento de exemplo e um arquivo carregados pelo inicializador:

E os resultados do teste gerados a partir da execução:

Limpar os recursos

Para excluir o inicializador, execute:

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

Isso limpa os manifestos de recurso implantados como parte do inicializador.

Conteúdo relacionado

Teste de pré-lançamento