5.11. 스코어 카드 툴을 사용하여 Operator 검증
Operator 작성자는 Operator SDK의 스코어 카드 툴을 사용하여 다음 작업을 수행할 수 있습니다.
- Operator 프로젝트에 구문 오류가 없고 올바르게 패키지되었는지 확인합니다.
- Operator를 개선할 수 있는 방법에 대한 제안 사항 검토
Operator 프로젝트의 관련 스캐폴딩 및 테스트 툴을 포함한 Red Hat 지원 버전의 Operator SDK CLI 툴은 더 이상 사용되지 않으며 향후 OpenShift Container Platform 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 라이프사이클 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만 이 기능은 더 이상 개선 사항을 받지 않으며 향후 OpenShift Container Platform 릴리스에서 제거됩니다.
새 Operator 프로젝트를 생성하는 데 Red Hat 지원 버전의 Operator SDK는 권장되지 않습니다. 기존 Operator 프로젝트가 있는 Operator 작성자는 OpenShift Container Platform 4.17과 함께 릴리스된 Operator SDK CLI 툴 버전을 사용하여 프로젝트를 유지 관리하고 최신 버전의 OpenShift Container Platform을 대상으로 하는 Operator 릴리스를 생성할 수 있습니다.
Operator 프로젝트의 다음과 같은 관련 기본 이미지는 더 이상 사용되지 않습니다. 이러한 기본 이미지의 런타임 기능 및 구성 API는 버그 수정 및 CVE 문제를 해결하는 데 계속 지원됩니다.
- Ansible 기반 Operator 프로젝트의 기본 이미지
- Helm 기반 Operator 프로젝트의 기본 이미지
OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.
지원되지 않는 커뮤니티 유지 관리 버전에 대한 자세한 내용은 Operator SDK(Operator Framework) 를 참조하십시오.
5.11.1. 스코어 카드 툴 정보
Operator SDK bundle validate
하위 명령은 콘텐츠 및 구조에 대한 로컬 번들 디렉터리 및 원격 번들 이미지를 검증할 수 있지만 scorecard
명령을 사용하면 구성 파일 및 테스트 이미지를 기반으로 Operator에서 테스트를 실행할 수 있습니다. 이러한 테스트는 스코어 카드에 의해 실행되도록 구성된 테스트 이미지 내에서 구현됩니다.
스코어 카드는 OpenShift Container Platform과 같이 구성된 Kubernetes 클러스터에 대한 액세스 권한을 사용하여 실행된다고 가정합니다. 스코어 카드는 각 테스트를 Pod 내에서 실행하며 해당 Pod에서 로그가 집계되고 테스트 결과가 콘솔로 전송됩니다. 스코어 카드에는 기본 테스트 및 OLM(Operator Lifecycle Manager) 테스트가 내장되어 있으며 사용자 정의 테스트 정의를 실행하는 방법도 제공합니다.
스코어 카드 워크플로
- 관련 CR(사용자 정의 리소스) 및 Operator에 필요한 모든 리소스를 생성합니다.
- Operator 배포에 프록시 컨테이너를 생성하여 API 서버에 대한 호출을 기록하고 테스트를 실행합니다.
- CR의 매개변수 검사
스코어 카드 테스트에서는 테스트 중인 Operator의 상태를 가정하지 않습니다. Operator에 대한 Operator 및 CR 생성은 스코어 카드 자체의 범위를 벗어납니다. 그러나 테스트가 리소스 생성을 위해 설계된 경우 필요한 모든 리소스를 생성할 수 있습니다.
scorecard
명령 구문
$ operator-sdk scorecard <bundle_dir_or_image> [flags]
스코어 카드에는 Operator 번들에 대한 디스크상의 경로 또는 번들 이미지 이름에 대한 위치 인수가 필요합니다.
플래그에 대한 자세한 내용을 보려면 다음을 실행합니다.
$ operator-sdk scorecard -h
5.11.2. 스코어 카드 구성
스코어 카드 툴에서는 내부 플러그인과 여러 글로벌 구성 옵션을 구성할 수 있는 구성을 사용합니다. 테스트는 bundle/
디렉터리에 있는 make bundle
명령으로 생성되는 config.yaml
구성 파일로 구동됩니다.
./bundle ... └── tests └── scorecard └── config.yaml
스코어 카드 구성 파일 예제
kind: Configuration apiversion: scorecard.operatorframework.io/v1alpha3 metadata: name: config stages: - parallel: true tests: - image: quay.io/operator-framework/scorecard-test:v1.36.1 entrypoint: - scorecard-test - basic-check-spec labels: suite: basic test: basic-check-spec-test - image: quay.io/operator-framework/scorecard-test:v1.36.1 entrypoint: - scorecard-test - olm-bundle-validation labels: suite: olm test: olm-bundle-validation-test
구성 파일은 스코어 카드로 실행할 수 있는 각 테스트를 정의합니다. 스코어 카드 구성 파일의 다음 필드는 다음과 같이 테스트를 정의합니다.
구성 필드 | Description |
---|---|
| 테스트를 구현하는 컨테이너 이미지 이름 테스트 |
| 테스트를 실행하기 위해 테스트 이미지에서 호출되는 명령 및 인수 |
| 실행할 테스트를 선택하는 스코어 카드 정의 또는 사용자 정의 라벨 |
5.11.3. 기본 제공 스코어 카드 테스트
스코어 카드는 도구 모음(기본 테스트 도구 모음 및 OLM(Operator Lifecycle Manager) 도구 모음)으로 준비된 사전 정의 테스트와 함께 제공됩니다.
테스트 | Description | 짧은 이름 |
---|---|---|
Spec Block Exists |
이 테스트에서는 클러스터에서 생성된 모든 CR(사용자 정의 리소스)에 |
|
테스트 | Description | 짧은 이름 |
---|---|---|
Bundle Validation | 이 테스트에서는 스코어 카드로 전달되는 번들에 있는 번들 매니페스트를 검증합니다. 번들 콘텐츠에 오류가 포함된 경우 테스트 결과 출력에 검증기 로그 및 검증 라이브러리의 오류 메시지가 포함됩니다. |
|
Provided APIs Have Validation |
이 테스트에서는 제공된 CR의 CRD(사용자 정의 리소스 정의)에 검증 섹션이 포함되어 있고 CR에서 탐지된 각 |
|
Owned CRDs Have Resources Listed |
이 테스트는 |
|
Spec Fields With Descriptors |
이 테스트에서는 CR |
|
Status Fields With Descriptors |
이 테스트에서는 CR |
|
5.11.4. 스코어 카드 툴 실행
기본 Kuryrstomize 파일 세트는 init
명령을 실행한 후 Operator SDK에서 생성합니다. 생성된 기본 bundle/tests/scorecard/config.yaml
파일은 즉시 사용하여 Operator에 대해 스코어 카드 툴을 실행하거나 이 파일을 테스트 사양으로 수정할 수 있습니다.
사전 요구 사항
- Operator SDK를 사용하여 Operator 프로젝트 생성
프로세스
Operator에 대한 번들 매니페스트 및 메타데이터를 생성하거나 다시 생성합니다.
$ make bundle
이 명령을 수행하면 테스트를 실행하는 데
scorecard
명령에서 사용하는 번들 메타데이터에 스코어 카드 주석이 자동으로 추가됩니다.Operator 번들에 대한 디스크상의 경로 또는 번들 이미지 이름에 대한 스코어 카드를 실행합니다.
$ operator-sdk scorecard <bundle_dir_or_image>
5.11.5. 스코어 카드 출력
scorecard
명령의 --output
플래그는 스코어 카드 결과 출력 형식을 text
또는 json
중 하나로 지정합니다.
예 5.31. JSON 출력 조각의 예
{ "apiVersion": "scorecard.operatorframework.io/v1alpha3", "kind": "TestList", "items": [ { "kind": "Test", "apiVersion": "scorecard.operatorframework.io/v1alpha3", "spec": { "image": "quay.io/operator-framework/scorecard-test:v1.36.1", "entrypoint": [ "scorecard-test", "olm-bundle-validation" ], "labels": { "suite": "olm", "test": "olm-bundle-validation-test" } }, "status": { "results": [ { "name": "olm-bundle-validation", "log": "time=\"2020-06-10T19:02:49Z\" level=debug msg=\"Found manifests directory\" name=bundle-test\ntime=\"2020-06-10T19:02:49Z\" level=debug msg=\"Found metadata directory\" name=bundle-test\ntime=\"2020-06-10T19:02:49Z\" level=debug msg=\"Getting mediaType info from manifests directory\" name=bundle-test\ntime=\"2020-06-10T19:02:49Z\" level=info msg=\"Found annotations file\" name=bundle-test\ntime=\"2020-06-10T19:02:49Z\" level=info msg=\"Could not find optional dependencies file\" name=bundle-test\n", "state": "pass" } ] } } ] }
예 5.32. 텍스트 출력 조각의 예
-------------------------------------------------------------------------------- Image: quay.io/operator-framework/scorecard-test:v1.36.1 Entrypoint: [scorecard-test olm-bundle-validation] Labels: "suite":"olm" "test":"olm-bundle-validation-test" Results: Name: olm-bundle-validation State: pass Log: time="2020-07-15T03:19:02Z" level=debug msg="Found manifests directory" name=bundle-test time="2020-07-15T03:19:02Z" level=debug msg="Found metadata directory" name=bundle-test time="2020-07-15T03:19:02Z" level=debug msg="Getting mediaType info from manifests directory" name=bundle-test time="2020-07-15T03:19:02Z" level=info msg="Found annotations file" name=bundle-test time="2020-07-15T03:19:02Z" level=info msg="Could not find optional dependencies file" name=bundle-test
출력 형식의 사양은 Test
유형 레이아웃과 일치합니다.
5.11.6. 테스트 선택
스코어 카드 테스트는 --selector
CLI 플래그를 일련의 라벨 문자열로 설정하여 선택합니다. 선택기 플래그를 지정하지 않으면 스코어 카드 구성 파일 내의 모든 테스트가 실행됩니다.
테스트는 순차적으로 실행되고 테스트 결과는 스코어 카드에 의해 집계되어 표준 출력 또는 stdout에 기록됩니다.
프로세스
단일 테스트(예:
basic-check-spec-test
)를 선택하려면--selector
플래그를 사용하여 테스트를 지정합니다.$ operator-sdk scorecard <bundle_dir_or_image> \ -o text \ --selector=test=basic-check-spec-test
테스트 도구 모음(예:
olm
)을 선택하려면 모든 OLM 테스트에서 사용하는 라벨을 지정합니다.$ operator-sdk scorecard <bundle_dir_or_image> \ -o text \ --selector=suite=olm
여러 개의 테스트를 선택하려면 다음 구문을 사용하여
selector
플래그로 테스트 이름을 지정합니다.$ operator-sdk scorecard <bundle_dir_or_image> \ -o text \ --selector='test in (basic-check-spec-test,olm-bundle-validation-test)'
5.11.7. 병렬 테스트 활성화
Operator 작성자는 스코어 카드 구성 파일을 사용하여 테스트에 별도의 단계를 정의할 수 있습니다. 단계는 구성 파일에 정의된 순서에 따라 순차적으로 실행됩니다. 단계에는 테스트 목록과 구성 가능한 parallel
설정이 포함되어 있습니다.
기본적으로 또는 특정 단계에서 명시적으로 parallel
을 false
로 설정한 경우 단계의 테스트는 구성 파일에 정의된 순서에 따라 순차적으로 실행됩니다. 테스트를 한 번에 하나씩 실행하면 두 테스트가 서로 상호 작용하며 충돌하지 않도록 하는 데 유용합니다.
그러나 테스트를 완전히 격리하도록 설계하면 병렬화할 수 있습니다.
프로세스
격리된 테스트 세트를 병렬로 실행하려면 동일한 단계에 테스트 세트를 포함하고
parallel
을true
로 설정합니다.apiVersion: scorecard.operatorframework.io/v1alpha3 kind: Configuration metadata: name: config stages: - parallel: true 1 tests: - entrypoint: - scorecard-test - basic-check-spec image: quay.io/operator-framework/scorecard-test:v1.36.1 labels: suite: basic test: basic-check-spec-test - entrypoint: - scorecard-test - olm-bundle-validation image: quay.io/operator-framework/scorecard-test:v1.36.1 labels: suite: olm test: olm-bundle-validation-test
- 1
- 병렬 테스트 사용
병렬 단계의 테스트는 모두 동시에 실행되고 스코어 카드는 테스트가 모두 완료될 때까지 기다린 후 다음 단계를 진행합니다. 이 경우 테스트가 훨씬 빨라질 수 있습니다.
5.11.8. 사용자 정의 스코어 카드 테스트
스코어 카드 툴에서는 다음과 같은 필수 규칙을 따르는 사용자 정의 테스트를 실행할 수 있습니다.
- 테스트를 컨테이너 이미지 내에서 구현함
- 테스트에서 명령 및 인수를 포함하는 진입점 허용
-
테스트에서 테스트 출력과 관련 없는 로그를 기록하지 않고 JSON 형식으로
v1alpha3
스코어 카드 출력 생성 -
테스트에서
/bundle
의 공유 마운트 옵션에 있는 번들 콘텐츠를 가져올 수 있음 - 테스트에서 클러스터 내 클라이언트 연결을 사용하여 Kubernetes API에 액세스할 수 있음
테스트 이미지가 위 지침을 따르는 경우 다른 프로그래밍 언어로 사용자 정의 테스트를 작성할 수 있습니다.
다음 예제는 Go에서 작성한 사용자 정의 테스트 이미지입니다.
예 5.33. 사용자 정의 스코어 카드 테스트 예제
// Copyright 2020 The Operator-SDK Authors // // Licensed under the Apache License, Version 2.0 (the "License"); // you may not use this file except in compliance with the License. // You may obtain a copy of the License at // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in writing, software // distributed under the License is distributed on an "AS IS" BASIS, // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. // See the License for the specific language governing permissions and // limitations under the License. package main import ( "encoding/json" "fmt" "log" "os" scapiv1alpha3 "github.com/operator-framework/api/pkg/apis/scorecard/v1alpha3" apimanifests "github.com/operator-framework/api/pkg/manifests" ) // This is the custom scorecard test example binary // As with the Redhat scorecard test image, the bundle that is under // test is expected to be mounted so that tests can inspect the // bundle contents as part of their test implementations. // The actual test is to be run is named and that name is passed // as an argument to this binary. This argument mechanism allows // this binary to run various tests all from within a single // test image. const PodBundleRoot = "/bundle" func main() { entrypoint := os.Args[1:] if len(entrypoint) == 0 { log.Fatal("Test name argument is required") } // Read the pod's untar'd bundle from a well-known path. cfg, err := apimanifests.GetBundleFromDir(PodBundleRoot) if err != nil { log.Fatal(err.Error()) } var result scapiv1alpha3.TestStatus // Names of the custom tests which would be passed in the // `operator-sdk` command. switch entrypoint[0] { case CustomTest1Name: result = CustomTest1(cfg) case CustomTest2Name: result = CustomTest2(cfg) default: result = printValidTests() } // Convert scapiv1alpha3.TestResult to json. prettyJSON, err := json.MarshalIndent(result, "", " ") if err != nil { log.Fatal("Failed to generate json", err) } fmt.Printf("%s\n", string(prettyJSON)) } // printValidTests will print out full list of test names to give a hint to the end user on what the valid tests are. func printValidTests() scapiv1alpha3.TestStatus { result := scapiv1alpha3.TestResult{} result.State = scapiv1alpha3.FailState result.Errors = make([]string, 0) result.Suggestions = make([]string, 0) str := fmt.Sprintf("Valid tests for this image include: %s %s", CustomTest1Name, CustomTest2Name) result.Errors = append(result.Errors, str) return scapiv1alpha3.TestStatus{ Results: []scapiv1alpha3.TestResult{result}, } } const ( CustomTest1Name = "customtest1" CustomTest2Name = "customtest2" ) // Define any operator specific custom tests here. // CustomTest1 and CustomTest2 are example test functions. Relevant operator specific // test logic is to be implemented in similarly. func CustomTest1(bundle *apimanifests.Bundle) scapiv1alpha3.TestStatus { r := scapiv1alpha3.TestResult{} r.Name = CustomTest1Name r.State = scapiv1alpha3.PassState r.Errors = make([]string, 0) r.Suggestions = make([]string, 0) almExamples := bundle.CSV.GetAnnotations()["alm-examples"] if almExamples == "" { fmt.Println("no alm-examples in the bundle CSV") } return wrapResult(r) } func CustomTest2(bundle *apimanifests.Bundle) scapiv1alpha3.TestStatus { r := scapiv1alpha3.TestResult{} r.Name = CustomTest2Name r.State = scapiv1alpha3.PassState r.Errors = make([]string, 0) r.Suggestions = make([]string, 0) almExamples := bundle.CSV.GetAnnotations()["alm-examples"] if almExamples == "" { fmt.Println("no alm-examples in the bundle CSV") } return wrapResult(r) } func wrapResult(r scapiv1alpha3.TestResult) scapiv1alpha3.TestStatus { return scapiv1alpha3.TestStatus{ Results: []scapiv1alpha3.TestResult{r}, } }