자습서: 자동화된 유효성 검사 테스트
Arc 지원 데이터 서비스를 빌드하는 각 커밋의 일부로 Microsoft는 엔드투엔드 테스트를 수행하는 자동화된 CI/CD 파이프라인을 실행합니다. 이러한 테스트는 코어 제품(데이터 컨트롤러, Azure Arc 및 PostgreSQL 서버를 통해 사용하도록 설정된 SQL Managed Instance)과 함께 유지 관리되는 두 개의 컨테이너를 통해 오케스트레이션됩니다. 이러한 컨테이너는 다음과 같습니다.
arc-ci-launcher: 직접 및 간접 연결 모드 모두에 대한 배포 종속성(예: CLI 확장) 및 제품 배포 코드(Azure CLI 사용)를 포함합니다. Kubernetes가 데이터 컨트롤러와 함께 온보딩되면 컨테이너는 Sonobuoy를 활용하여 병렬 통합 테스트를 트리거합니다.arc-sb-plugin: 간단한 스모크 테스트(배포, 삭제)에서 복잡한 고가용성 시나리오, 카오스 테스트(리소스 삭제) 등에 이르는 Pytest 기반 엔드투엔드 통합 테스트가 포함된 Sonobuoy 플러그 인.
이러한 테스트 컨테이너는 고객과 파트너가 어디에서나 실행되는 자체 Kubernetes 클러스터에서 Arc 지원 데이터 서비스 유효성 검사 테스트를 수행하여 다음의 유효성을 검사할 수 있도록 공개적으로 제공됩니다.
- Kubernetes 배포판/버전
- 호스트 disto/버전
- 스토리지(
StorageClass/CSI), 네트워킹(예:LoadBalancers, DNS) - 기타 Kubernetes 또는 인프라별 설정
문서화되지 않은 배포에서 Arc 지원 Data Services를 실행하려는 고객의 경우 이러한 유효성 검사 테스트를 성공적으로 실행해야 지원되는 것으로 간주됩니다. 또한 파트너는 이 방식을 사용하여 솔루션이 Arc 지원 Data Services를 준수하는지 인증할 수 있습니다. Azure Arc 지원 Data Services Kubernetes 유효성 검사를 참조하세요.
다음 다이어그램은 이 상위 수준 프로세스를 간략하게 보여 줍니다.
이 자습서에서는 다음을 하는 방법을 알아볼 수 있습니다.
kubectl을 사용하여arc-ci-launcher배포- Azure Blob Storage 계정에서 유효성 검사 테스트 결과 검토
필수 조건
자격 증명:
test.env.tmpl파일에는 필수 자격 증명이 포함되어 있으며 Azure Arc 연결 클러스터 및 직접 연결된 데이터 컨트롤러를 온보딩하는 데 필요한 기존 필수 조건의 조합입니다. 이 파일의 설정은 샘플과 함께 아래에 설명되어 있습니다.cluster-admin액세스 권한이 있는 테스트된 Kubernetes 클러스터에 대한 kubeconfig 파일(현재 연결된 클러스터 온보딩에 필요함)
클라이언트 도구:
kubectl설치됨 - 최소 버전(메이저:"1", 마이너:"21")git명령줄 인터페이스(또는 UI 기반 대안)
Kubernetes 매니페스트 준비
시작 관리자는 Kustomize 매니페스트로 microsoft/azure_arc 리포지토리의 일부로 제공됩니다. Kustomize는 기본 제공kubectl되어 있으므로 추가 도구가 필요하지 않습니다.
- 리포지토리를 로컬로 복제합니다.
git clone https://github.com/microsoft/azure_arc.git
- 다음 폴더 구조를 보려면
azure_arc/arc_data_services/test/launcher로 이동합니다.
├── 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
이 자습서에서는 AKS에 대한 단계에 중점을 두지만 위의 오버레이 구조를 확장하여 추가 Kubernetes 배포를 포함할 수 있습니다.
배포할 준비가 된 매니페스트는 다음을 나타냅니다.
├── 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
특정 환경 내에서 실행되도록 시작 관리자를 지역화하기 위해 생성해야 하는 두 개의 파일이 있습니다. 이러한 각 파일은 위의 각 템플릿(*.tmpl) 파일을 복사하여 붙여넣고 작성하여 생성할 수 있습니다.
.test.env:.test.env.tmpl에서 작성patch.json:patch.json.tmpl에서 작성
팁
.test.env는 시작 관리자의 동작을 구동하는 환경 변수의 단일 집합입니다. 지정된 환경에 주의하여 생성하면 시작 관리자 동작의 재현성이 보장됩니다.
Config 1: .test.env
.test.env.tmpl을 기반으로 생성된 .test.env 파일의 채워진 샘플이 인라인 설명과 함께 아래에 공유됩니다.
Important
아래의 export VAR="value" 구문은 컴퓨터의 원본 환경 변수에 대해 로컬로 실행하기 위한 것이 아니라 시작 관리자를 위한 것입니다. 시작 관리자는 Kustomize의 secretGenerator를 사용하여 이 .test.env 파일을 있는 그대로 Kubernetes secret으로 탑재합니다(Kustomize는 파일을 가져오고, base64는 전체 파일의 콘텐츠를 인코딩하고 이를 Kubernetes 비밀로 바꿉니다). 초기화하는 동안 시작 관리자는 bash의 source 명령을 실행하여 탑재된 .test.env 파일의 환경 변수를 시작 관리자의 환경으로 가져옵니다.
즉, .test.env.tmpl을 복사하여 붙여넣고 편집하여 .test.env를 만들면 만들어진 파일이 아래 샘플과 유사해야 합니다. .test.env 파일을 작성하는 프로세스는 운영 체제와 터미널에서 동일합니다.
팁
재현성의 명확성을 위해 추가 설명이 필요한 소수의 환경 변수가 있습니다. 이들은 see detailed explanation below [X]로 주석 처리됩니다.
팁
아래의 .test.env 예는 직접 모드에 대한 것입니다. ARC_DATASERVICES_EXTENSION_VERSION_TAG와 같은 일부 변수는 간접 모드에 적용되지 않습니다. 간단히 하기 위해 직접 모드 변수를 염두에 두고 .test.env 파일을 설정하는 것이 가장 좋습니다. CONNECTIVITY_MODE=indirect를 전환하면 실행기가 직접 모드 특정 설정을 무시하고 목록의 하위 집합을 사용하게 됩니다.
즉, 직접 모드를 계획하면 간접 모드 변수를 충족할 수 있습니다.
.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"
Important
Windows 컴퓨터에서 구성 파일 생성을 수행하는 경우 arc-ci-launcher가 Linux 컨테이너로 실행되므로 End-of-Line 시퀀스를 CRLF(Windows)에서 LF(Linux)로 변환해야 합니다. 줄 끝을 CRLF로 두면 arc-ci-launcher 컨테이너 시작 시 /launcher/config/.test.env: $'\r': command not found 오류가 발생할 수 있습니다. 예를 들어, VSCode(창 오른쪽 하단)를 사용하여 변경을 수행합니다.
특정 변수에 대한 자세한 설명
1. ARC_DATASERVICES_EXTENSION_* - 확장 버전 및 학습
필수:
direct모드 배포에 필요합니다.
시작 관리자는 GA 및 pre-GA 릴리스를 모두 배포할 수 있습니다.
릴리스 트레인(ARC_DATASERVICES_EXTENSION_RELEASE_TRAIN) 매핑에 대한 확장 버전은 여기에서 가져옵니다.
2. ARC_DATASERVICES_WHL_OVERRIDE - Azure CLI 이전 버전 다운로드 URL
선택 사항: 미리 패키지된 기본값을 사용하려면
.test.env에서 이 항목을 비워 둡니다.
시작 관리자 이미지는 각 컨테이너 이미지 릴리스 시점에 최신 arcdata CLI 버전으로 사전 패키지됩니다. 그러나 이전 릴리스를 사용하고 테스트를 업그레이드하려면 미리 패키지된 버전을 재정의하기 위해 시작 관리자에 Azure CLI Blob URL 다운로드 링크를 제공해야 할 수 있습니다. 예를 들어, 시작 관리자가 버전 1.4.3을 설치하도록 지시하려면 다음을 입력합니다.
export ARC_DATASERVICES_WHL_OVERRIDE="https://azurearcdatacli.blob.core.windows.net/cli-extensions/arcdata-1.4.3-py2.py3-none-any.whl"
Blob URL 매핑에 대한 CLI 버전은 여기에서 찾을 수 있습니다.
3. CUSTOM_LOCATION_OID - 특정 Microsoft Entra 테넌트의 사용자 지정 위치 개체 ID
필수: 연결된 클러스터 사용자 지정 위치 만들기에 필요합니다.
다음 단계는 클러스터에서 사용자 지정 위치 사용에서 제공되어 Microsoft Entra 테넌트에 대한 고유한 사용자 지정 위치 개체 ID를 검색합니다.
Microsoft Entra 테넌트에 대한 CUSTOM_LOCATION_OID를 가져오는 방법에는 두 가지가 있습니다.
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.
Azure Portal을 통해 Microsoft Entra 블레이드로 이동하고
Custom Locations RP를 검색합니다.
4. SPN_CLIENT_* - 서비스 주체 자격 증명
필수: 직접 모드 배포에 필요합니다.
시작 관리자는 이러한 자격 증명을 사용하여 Azure에 로그인합니다.
유효성 검사 테스트는 비프로덕션/테스트 Kubernetes 클러스터 및 Azure 구독에서 수행되며 Kubernetes/인프라 설정의 기능 유효성 검사에 중점을 둡니다. 따라서 시작을 수행하는 데 필요한 수동 단계의 수를 피하려면 리소스 그룹(또는 구독) 수준에서 Owner가 있는 SPN_CLIENT_ID/SECRET을 제공하는 것이 좋습니다. 이 리소스 그룹에 여러 리소스를 만들고 배포의 일부로 만들어진 여러 관리 ID에 대해 해당 리소스에 권한을 할당하기 때문입니다(이러한 역할 할당에는 Owner가 있는 서비스 주체가 필요함).
5. LOGS_STORAGE_ACCOUNT_SAS - Blob Storage 계정 SAS URL
권장: 이 항목을 비워두면 테스트 결과 및 로그를 가져올 수 없습니다.
실행 프로그램은 결과를 업로드할 영구 위치(Azure Blob Storage)가 필요합니다. Kubernetes는 중지/완료된 Pod에서 파일을 복사하는 것을 (아직) 허용하지 않기 때문입니다. 여기 참조. 시작 관리자는 계정 범위 SAS URL(컨테이너 또는 blob 범위가 아님)을 사용하여 Azure Blob Storage에 연결합니다(시간 제한 액세스 정의가 있는 서명된 URL). 다음을 수행하려면 SAS(공유 액세스 서명)를 사용하여 Azure Storage 리소스에 대한 제한된 액세스 권한 부여를 참조하세요.
- 존재하지 않는 경우 기존 스토리지 계정(
LOGS_STORAGE_ACCOUNT)에 새 스토리지 컨테이너 만들기(LOGS_STORAGE_CONTAINER기반 이름) - 고유한 이름의 새 Blob 만들기(테스트 로그 tar 파일)
다음 단계는 SAS(공유 액세스 서명)를 사용하여 Azure Storage 리소스에 대한 제한된 액세스 권한 부여에서 제공됩니다.
팁
SAS URL은 스토리지 계정 키와 다르며 SAS URL 형식은 다음과 같습니다.
?sv=2021-06-08&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=...&spr=https&sig=...
SAS URL을 생성하는 방법에는 여러 가지가 있습니다. 이 예는 포털을 보여 줍니다.
대신 Azure CLI를 사용하려면 az storage account generate-sas를 참조하세요.
6. SKIP_* - 특정 단계를 건너뛰어 시작 관리자 동작 제어
선택 사항: 모든 단계를 실행하려면
.test.env에서 비워 둡니다(0과 동등하거나 비워둠).
시작 관리자는 SKIP_* 변수를 노출하여 특정 단계를 실행하고 건너뜁니다(예: "정리 전용" 실행 수행).
시작 관리자는 각 실행의 시작과 끝에서 모두 정리하도록 설계되었지만 시작 및/또는 테스트 실패로 인해 잔여 리소스가 남을 수 있습니다. 시작 관리자를 "정리 전용" 모드로 실행하려면 .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
위의 설정은 시작 관리자가 모든 Arc 및 Arc Data Services 리소스를 정리하고 로그를 배포/테스트/업로드하지 않도록 지시합니다.
Config 2: patch.json
patch.json.tmpl을 기반으로 생성된 patch.json 파일의 채워진 샘플이 아래에 공유됩니다.
spec.docker.registry, repository, imageTag는 위의.test.env의 값과 동일해야 합니다.
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"
}
]
}
시작 관리자 배포
시작 관리자는 Arc 및 기타 사용된 Kubernetes 리소스에 파괴적인 작업을 수행하므로 비프로덕션/테스트 클러스터에 배포하는 것이 좋습니다.
imageTag 사양
실행기는 Kubernetes 매니페스트 내에서 Job으로 정의되며, 실행기의 이미지를 찾을 위치를 Kubernetes에 지시해야 합니다. 이는 base/kustomization.yaml에서 설정됩니다.
images:
- name: arc-ci-launcher
newName: mcr.microsoft.com/arcdata/arc-ci-launcher
newTag: v1.11.0_2022-09-13
팁
이 시점에서 요약하면 imageTag를 지정한 3개의 장소가 있습니다. 명확성을 위해 각각의 다양한 용도에 대한 설명이 있습니다. 일반적으로 - 지정된 릴리스를 테스트할 때 3개의 값이 모두 동일합니다(지정된 릴리스에 맞춰 정렬).
| # | Filename | 변수 이름 | 이유는 무엇입니까? | 사용 대상? |
|---|---|---|---|---|
| 1 | .test.env |
DOCKER_TAG |
확장 설치의 일부로 부트스트래퍼 이미지 소싱 | 시작 관리자의 az k8s-extension create |
| 2 | patch.json |
value.imageTag |
데이터 컨트롤러 이미지 소싱 | 시작 관리자의 az arcdata dc create |
| 3 | kustomization.yaml |
images.newTag |
시작 관리자 이미지 소싱 | kubectl apply시작 관리자에서 |
kubectl apply
매니페스트가 제대로 설정되었는지 유효성을 검사하려면 시작 관리자용으로 만들 Kubernetes 리소스를 출력하는 --dry-run=client로 클라이언트 쪽 유효성 검사를 시도합니다.
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)
시작 관리자 및 비상 로그를 배포하려면 다음을 실행합니다.
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
이 시점에서 시작 관리자가 시작되고 다음이 표시되어야 합니다.
기존 Arc 리소스가 없는 클러스터에 시작 관리자를 배포하는 것이 가장 좋지만, 시작 관리자에는 기존 Arc 및 Arc Data Services CRD 및 ARM 리소스를 검색하기 위한 비행 전 유효성 검사가 포함되어 있으며 새 릴리스를 배포하기 전에 최선의 활동을 다해 이를 정리하려고 시도합니다(제공된 서비스 주체 자격 증명 사용).
이 동일한 메타데이터 검색 및 정리 프로세스는 시작 관리자 종료 시에도 실행되어 클러스터를 런칭 전의 기존 상태에 최대한 가깝게 둡니다.
시작 관리자에서 수행하는 단계
대략적으로 시작 관리자는 다음과 같은 일련의 단계를 수행합니다.
Pod 탑재 서비스 계정을 사용하여 Kubernetes API에 인증
Secret-mounted Service Principal을 사용하여 ARM API에 인증
CRD 메타데이터 검사를 수행하여 기존 Arc 및 Arc Data Services 사용자 지정 리소스를 검사합니다.
Kubernetes의 기존 사용자 지정 리소스와 Azure의 후속 리소스를 정리합니다. 클러스터에 있는 리소스와 비교하여
.test.env의 자격 증명이 일치하지 않으면 종료합니다.Arc 클러스터 이름, 데이터 컨트롤러 및 사용자 지정 위치/네임스페이스에 대한 타임스탬프를 기반으로 고유한 환경 변수 집합을 생성합니다. 중요한 값(예: 서비스 주체 암호 등)을 난독 처리하여 환경 변수를 출력합니다.
a. 직접 모드의 경우 - Azure Arc에 클러스터를 온보딩한 다음 컨트롤러를 배포합니다.
b. 간접 모드의 경우: 데이터 컨트롤러 배포
데이터 컨트롤러가
Ready이면 Azure CLI(az arcdata dc debug) 로그 집합을 생성하고 기준으로setup-complete레이블이 지정된 로컬에 저장합니다..test.env의TESTS_DIRECT/INDIRECT환경 변수를 사용하여 공백으로 구분된 배열(TESTS_(IN)DIRECT)을 기반으로 일련의 병렬화된 Sonobuoy 테스트 실행을 시작합니다. 이러한 실행은 Pytest 유효성 검사 테스트가 포함된arc-sb-pluginPod를 사용하여 새로운sonobuoy네임스페이스에서 실행됩니다.Sonobuoy 집계는
junit테스트 결과와arc-sb-plugin테스트 실행당 로그를 축적하여 시작 관리자 Pod로 내보냅니다.테스트의 종료 코드를 반환하고 다른 디버그 로그 집합(Azure CLI 및
sonobuoy)를 생성하고 로컬에 저장되며test-complete로 레이블이 지정됩니다.3단계와 유사한 CRD 메타데이터 검사를 수행하여 기존 Arc 및 Arc Data Services 사용자 지정 리소스를 검사합니다. 그런 다음 CRD, Role/ClusterRoles, PV/PVC 등 모든 Arc 및 Arc 데이터 리소스를 배포에서 역순으로 제거합니다.
제공된 SAS 토큰
LOGS_STORAGE_ACCOUNT_SAS를 사용하여 기존 스토리지 계정LOGS_STORAGE_ACCOUNT에서LOGS_STORAGE_CONTAINER를 기반으로 이름이 지정된 새 스토리지 계정 컨테이너를 만들려고 시도합니다. 스토리지 계정 컨테이너가 이미 있으면 사용합니다. 모든 로컬 테스트 결과 및 로그를 이 스토리지 컨테이너에 tarball로 업로드합니다(아래 참조).종료합니다.
테스트 도구 모음당 수행되는 테스트
각각 별도의 기능을 테스트하는 27개의 테스트 도구 모음에서 약 375개의 고유한 통합 테스트를 사용할 수 있습니다.
| Suite # | 테스트 도구 모음 이름 | 테스트 설명 |
|---|---|---|
| 1 | ad-connector |
AD 커넥터(Active Directory 커넥터)의 배포 및 업데이트를 테스트합니다. |
| 2 | billing |
다양한 중요 비즈니스용 라이선스 유형 테스트는 컨트롤러의 리소스 테이블에 반영되며 청구 업로드에 사용됩니다. |
| 3 | ci-billing |
billing과 비슷하지만 CPU/메모리 순열이 더 깁니다. |
| 4 | ci-sqlinstance |
다중 복제본 만들기, 업데이트, GP -> BC 업데이트, 백업 유효성 검사 및 SQL Server 에이전트에 대한 장기 실행 테스트입니다. |
| 5 | controldb |
테스트 제어 데이터베이스 - SQL 빌드 버전에 대한 SA 비밀 검사, 시스템 로그인 확인, 감사 만들기 및 온전성 검사. |
| 6 | dc-export |
간접 모드 청구 및 사용량 업로드. |
| 7 | direct-crud |
ARM 호출을 사용하여 SQL 인스턴스를 만들고 Kubernetes와 ARM 모두에서 유효성을 검사합니다. |
| 8 | direct-fog |
여러 SQL 인스턴스를 만들고 ARM 호출을 사용하여 장애 조치(failover) 그룹을 만듭니다. |
| 9 | direct-hydration |
Kubernetes API를 사용하여 SQL 인스턴스를 만들고 ARM에서 현재 상태의 유효성을 검사합니다. |
| 10 | direct-upload |
직접 모드에서 청구 업로드 유효성 검사 |
| 11 | kube-rbac |
Arc Data Services에 대한 Kubernetes 서비스 계정 권한이 최소 권한 기대치와 일치하는지 확인합니다. |
| 12 | nonroot |
컨테이너가 루트가 아닌 사용자로 실행되도록 보장 |
| 13 | postgres |
다양한 Postgres 만들기, 크기 조정, 백업/복원 테스트를 완료합니다. |
| 14 | release-sanitychecks |
Sanity는 SQL Server 빌드 버전과 같은 월별 릴리스를 확인합니다. |
| 15 | sqlinstance |
빠른 유효성 검사를 위한 ci-sqlinstance의 짧은 버전입니다. |
| 16 | sqlinstance-ad |
Active Directory 커넥터를 사용하여 SQL 인스턴스 만들기를 테스트합니다. |
| 17 | sqlinstance-credentialrotation |
범용 및 중요 비즈니스용 모두에 대해 자동화된 자격 증명 회전을 테스트합니다. |
| 18 | sqlinstance-ha |
Pod 재부팅, 강제 장애 조치(failover) 및 일시 중단을 비롯한 다양한 고가용성 스트레스 테스트. |
| 19 | sqlinstance-tde |
다양한 투명한 데이터 암호화 테스트. |
| 20 | telemetry-elasticsearch |
Elasticsearch에 대한 로그 수집의 유효성을 검사합니다. |
| 21 | telemetry-grafana |
Grafana에 연결할 수 있는지 확인합니다. |
| 22 | telemetry-influxdb |
InfluxDB에 대한 메트릭 수집의 유효성을 검사합니다. |
| 23 | telemetry-kafka |
SSL, 단일/다중 broker 설정을 사용하는 Kafka에 대한 다양한 테스트. |
| 24 | telemetry-monitorstack |
테스트 모니터링 구성 요소(예: Fluentbit 및 Collectd)가 작동합니다. |
| 25 | telemetry-telemetryrouter |
개방형 원격 분석을 테스트합니다. |
| 26 | telemetry-webhook |
유효한 호출과 유효하지 않은 호출로 Data Services 웹후크를 테스트합니다. |
| 27 | upgrade-arcdata |
전체 SQL 인스턴스 제품군(GP, BC 2 복제본, BC 3 복제본, Active Directory 포함)을 업그레이드하고 지난 달 릴리스에서 최신 빌드로 업그레이드합니다. |
예를 들어 sqlinstance-ha의 경우 다음 테스트가 수행됩니다.
test_critical_configmaps_present: ConfigMaps 및 관련 필드가 SQL 인스턴스에 있는지 확인합니다.test_suspended_system_dbs_auto_heal_by_orchestrator:master및msdb가 어떤 방법으로든 일시 중단되는지 확인합니다(이 경우 사용자). 오케스트레이터 유지 관리는 자동 복구를 조정합니다.test_suspended_user_db_does_not_auto_heal_by_orchestrator: 사용자 데이터베이스가 사용자에 의해 의도적으로 일시 중지된 경우 Orchestrator 유지 관리 조정이 자동으로 복구되지 않도록 합니다.test_delete_active_orchestrator_twice_and_delete_primary_pod: 오케스트레이터 Pod를 여러 번 삭제한 후 기본 복제본을 삭제하고 모든 복제본이 동기화되는지 확인합니다. 2개의 복제본에 대한 장애 조치(failover) 시간 기대치가 완화되었습니다.test_delete_primary_pod: 기본 복제본을 삭제하고 모든 복제본이 동기화되는지 확인합니다. 2개의 복제본에 대한 장애 조치(failover) 시간 기대치가 완화되었습니다.test_delete_primary_and_orchestrator_pod: 기본 복제본 및 오케스트레이터 Pod를 삭제하고 모든 복제본이 동기화되는지 확인합니다.test_delete_primary_and_controller: 기본 복제본 및 데이터 컨트롤러 Pod를 삭제하고 기본 엔드포인트에 액세스할 수 있고 새 기본 복제본이 동기화되었는지 확인합니다. 2개의 복제본에 대한 장애 조치(failover) 시간 기대치가 완화되었습니다.test_delete_one_secondary_pod: 보조 복제본 및 데이터 컨트롤러 Pod를 삭제하고 모든 복제본이 동기화되는지 확인합니다.test_delete_two_secondaries_pods: 보조 복제본 및 데이터 컨트롤러 Pod를 삭제하고 모든 복제본이 동기화되는지 확인합니다.- :
test_failaway: AG 장애 조치(failover)를 현재 주 복제본에서 강제로 제거하여 새 주 복제본이 이전 주 복제본과 동일하지 않도록 합니다. 모든 복제본이 동기화되는지 확인합니다.test_update_while_rebooting_all_non_primary_replicas: 테스트 컨트롤러 기반 업데이트는 다양한 난류 상황에도 불구하고 재시도를 통해 복원력을 발휘합니다.
참고 항목
특정 테스트에는 계정 및 DNS 항목 생성용 ad 테스트를 위한 도메인 컨트롤러에 대한 권한 있는 액세스와 같은 특정 하드웨어가 필요할 수 있습니다. 이는 arc-ci-launcher를 사용하려는 모든 환경에서는 사용 가능하지 않을 수 있습니다.
테스트 결과 검토
시작 관리자에서 업로드한 샘플 스토리지 컨테이너 및 파일:
실행에서 생성된 테스트 결과:
리소스 정리
시작 관리자를 삭제하려면 다음을 실행합니다.
kubectl delete -k arc_data_services/test/launcher/overlays/aks
이렇게 하면 시작 관리자의 일부로 배포된 리소스 매니페스트가 정리됩니다.