5.9. La validation des opérateurs à l’aide de l’outil de carte de pointage


En tant qu’auteur de l’opérateur, vous pouvez utiliser l’outil de carte de pointage dans le SDK de l’opérateur pour effectuer les tâches suivantes:

  • Validez que votre projet Opérateur est exempt d’erreurs de syntaxe et emballé correctement
  • Évaluez les suggestions sur les façons d’améliorer votre opérateur
Important

La version prise en charge par Red Hat de l’outil Operator SDK CLI, y compris les outils d’échafaudage et de test connexes pour les projets d’opérateur, est dépréciée et devrait être supprimée dans une version ultérieure d’OpenShift Dedicated. Le Red Hat fournira des corrections de bogues et une prise en charge de cette fonctionnalité pendant le cycle de vie de la version actuelle, mais cette fonctionnalité ne recevra plus d’améliorations et sera supprimée des futures versions d’OpenShift Dedicated.

La version prise en charge par Red Hat du SDK de l’opérateur n’est pas recommandée pour la création de nouveaux projets d’opérateur. Les auteurs d’opérateurs avec des projets d’opérateur existants peuvent utiliser la version de l’outil Operator SDK CLI publié avec OpenShift Dedicated 4 pour maintenir leurs projets et créer des versions d’opérateur ciblant des versions plus récentes d’OpenShift Dedicated.

Les images de base suivantes pour les projets d’opérateur ne sont pas dépréciées. Les fonctionnalités d’exécution et les API de configuration de ces images de base sont toujours prises en charge pour les corrections de bogues et pour l’adressage des CVE.

  • L’image de base pour les projets d’opérateurs basés sur Ansible
  • L’image de base pour les projets d’opérateur basé sur Helm

Afin d’obtenir de l’information sur la version non prise en charge et gérée par la communauté du SDK de l’opérateur, voir Operator SDK (Operator Framework).

5.9.1. À propos de l’outil de tableau de bord

Alors que la sous-commande de validation du paquet SDK de l’opérateur peut valider des répertoires de faisceaux locaux et des images de faisceau à distance pour le contenu et la structure, vous pouvez utiliser la commande de carte de pointage pour exécuter des tests sur votre opérateur en fonction d’un fichier de configuration et d’images de test. Ces tests sont implémentés dans des images de test qui sont configurées et construites pour être exécutées par le tableau de bord.

Le tableau de bord suppose qu’il est exécuté avec l’accès à un cluster Kubernetes configuré, tel qu’OpenShift Dedicated. Le tableau de bord exécute chaque test dans un pod, à partir duquel les logs de pod sont agrégés et les résultats des tests sont envoyés à la console. Le tableau de bord a intégré les tests de base et de gestion du cycle de vie de l’opérateur (OLM) et fournit également un moyen d’exécuter des définitions de test personnalisées.

Flux de travail de carte de pointage

  1. Créer toutes les ressources requises par toutes les ressources personnalisées (CR) et l’opérateur connexes
  2. Créer un conteneur proxy dans le déploiement de l’opérateur pour enregistrer les appels au serveur API et exécuter des tests
  3. Examiner les paramètres dans les CR

Les tests de tableau de bord ne font pas d’hypothèses quant à l’état de l’opérateur testé. La création d’opérateurs et de CR pour un opérateur dépasse la portée du tableau de bord lui-même. Les tests de tableau de bord peuvent cependant créer les ressources dont ils ont besoin si les tests sont conçus pour la création de ressources.

la syntaxe de commande de carte de pointage

$ operator-sdk scorecard <bundle_dir_or_image> [flags]
Copy to Clipboard Toggle word wrap

La carte de pointage nécessite un argument positionnel pour le chemin d’accès sur le disque vers votre paquet Opérateur ou le nom d’une image de paquet.

Afin d’obtenir de plus amples informations sur les drapeaux, courez:

$ operator-sdk scorecard -h
Copy to Clipboard Toggle word wrap

5.9.2. Configuration de la carte de pointage

L’outil de carte de pointage utilise une configuration qui vous permet de configurer des plugins internes, ainsi que plusieurs options de configuration globales. Les tests sont pilotés par un fichier de configuration nommé config.yaml, qui est généré par la commande make bundle, situé dans votre bundle/annuaire:

./bundle
...
└── tests
    └── scorecard
        └── config.yaml
Copy to Clipboard Toggle word wrap

Exemple de fichier de configuration de carte de pointage

kind: Configuration
apiversion: scorecard.operatorframework.io/v1alpha3
metadata:
  name: config
stages:
- parallel: true
  tests:
  - image: quay.io/operator-framework/scorecard-test:v1.38.0
    entrypoint:
    - scorecard-test
    - basic-check-spec
    labels:
      suite: basic
      test: basic-check-spec-test
  - image: quay.io/operator-framework/scorecard-test:v1.38.0
    entrypoint:
    - scorecard-test
    - olm-bundle-validation
    labels:
      suite: olm
      test: olm-bundle-validation-test
Copy to Clipboard Toggle word wrap

Le fichier de configuration définit chaque test que la carte de pointage peut exécuter. Les champs suivants du fichier de configuration de la carte de pointage définissent le test comme suit:

Expand
Champ de configurationDescription

image

Le nom de l’image du conteneur de test qui implémente un test

le point d’entrée

Commande et arguments invoqués dans l’image de test pour exécuter un test

étiquettes

Étiquettes définies par la carte de bord ou personnalisées qui sélectionnent les tests à exécuter

5.9.3. Des tests de carte de pointage intégrés

Le tableau de bord est livré avec des tests prédéfinis qui sont disposés en suites: la suite de test de base et la suite Operator Lifecycle Manager (OLM).

Expand
Tableau 5.20. La suite de test de base
EssaiDescriptionCourt nom

Le bloc spec existe

Ce test vérifie la ressource personnalisée (CR) créée dans le cluster pour s’assurer que tous les CR ont un bloc spec.

Basic-check-spec-test

Expand
Tableau 5.21. La suite de test OLM
EssaiDescriptionCourt nom

La validation des paquets

Ce test valide les manifestes de paquets trouvés dans le paquet qui est transmis dans la carte de pointage. Lorsque le contenu du paquet contient des erreurs, le résultat du test inclut le journal du validateur ainsi que les messages d’erreur de la bibliothèque de validation.

essai OLM-bundle-validation-test

Les API fournies ont une validation

Ce test vérifie que les définitions de ressources personnalisées (CRD) pour les CR fournis contiennent une section de validation et qu’il y a validation pour chaque champ de spécification et d’état détecté dans le CR.

les OLM-crds-ont-validation-test

Les CRD possédés ont des ressources répertoriées

Ce test permet de s’assurer que les CRD pour chaque CR fournis par l’option du manifeste cr disposent d’une sous-section des ressources de la section CRD de la ClusterServiceVersion (CSV). Lorsque le test détecte les ressources utilisées qui ne sont pas listées dans la section Ressources, il les énumère dans les suggestions à la fin du test. Les utilisateurs sont tenus de remplir la section ressources après la génération de code initiale pour que ce test passe.

les OLM-crds-ont-ressources-test

Champs spec avec descripteurs

Ce test vérifie que chaque champ dans les sections spec CRs a un descripteur correspondant listé dans le CSV.

le test OLM-spec-descriptors-test

Champs d’état avec descripteurs

Ce test vérifie que chaque champ dans les sections de statut CRs a un descripteur correspondant listé dans le CSV.

le test OLM-status-descriptors-test

5.9.4. Exécution de l’outil de tableau de bord

Après l’exécution de la commande init, un ensemble par défaut de fichiers Kustomize est généré par le SDK de l’opérateur. Le fichier bundle/tests/scorecard/config.yaml par défaut qui est généré peut être immédiatement utilisé pour exécuter l’outil de carte de pointage contre votre opérateur, ou vous pouvez modifier ce fichier à vos spécifications de test.

Conditions préalables

  • Le projet d’opérateur généré à l’aide du SDK de l’opérateur

Procédure

  1. Générer ou régénérer vos manifestes et métadonnées de paquets pour votre opérateur:

    $ make bundle
    Copy to Clipboard Toggle word wrap

    Cette commande ajoute automatiquement des annotations de carte de pointage à vos métadonnées de paquet, qui est utilisée par la commande de carte de pointage pour exécuter des tests.

  2. Exécutez la carte de pointage par rapport au chemin d’accès sur le disque vers votre paquet Opérateur ou le nom d’une image de paquet:

    $ operator-sdk scorecard <bundle_dir_or_image>
    Copy to Clipboard Toggle word wrap

5.9.5. Sortie du tableau de bord

L’indicateur --output pour la commande de la carte de pointage spécifie le format de sortie des résultats du tableau de bord: texte ou json.

Exemple 5.7. Exemple d’extrait de sortie 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.38.0",
        "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"
          }
        ]
      }
    }
  ]
}
Copy to Clipboard Toggle word wrap

Exemple 5.8. Exemple de sortie de texte

--------------------------------------------------------------------------------
Image:      quay.io/operator-framework/scorecard-test:v1.38.0
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
Copy to Clipboard Toggle word wrap
Note

La spécification du format de sortie correspond à la disposition du type de test.

5.9.6. La sélection des tests

Les tests de tableau de bord sont sélectionnés en définissant le drapeau CLI --selector sur un ensemble de chaînes d’étiquettes. En l’absence d’un drapeau sélecteur, tous les tests dans le fichier de configuration de la carte de pointage sont exécutés.

Les tests sont exécutés en série, les résultats des tests étant agrégés par la carte de pointage et écrits en sortie standard, ou stdout.

Procédure

  1. Afin de sélectionner un seul test, par exemple Basic-check-spec-test, spécifiez le test en utilisant le drapeau --selector:

    $ operator-sdk scorecard <bundle_dir_or_image> \
        -o text \
        --selector=test=basic-check-spec-test
    Copy to Clipboard Toggle word wrap
  2. Afin de sélectionner une série de tests, par exemple olm, spécifiez une étiquette utilisée par tous les tests OLM:

    $ operator-sdk scorecard <bundle_dir_or_image> \
        -o text \
        --selector=suite=olm
    Copy to Clipboard Toggle word wrap
  3. Afin de sélectionner plusieurs tests, spécifiez les noms de test en utilisant l’indicateur sélecteur en utilisant la syntaxe suivante:

    $ operator-sdk scorecard <bundle_dir_or_image> \
        -o text \
        --selector='test in (basic-check-spec-test,olm-bundle-validation-test)'
    Copy to Clipboard Toggle word wrap

5.9.7. Activer les tests parallèles

En tant qu’auteur de l’opérateur, vous pouvez définir des étapes distinctes pour vos tests à l’aide du fichier de configuration de la carte de pointage. Les étapes s’exécutent de manière séquentielle dans l’ordre où elles sont définies dans le fichier de configuration. L’étape contient une liste de tests et un réglage parallèle configurable.

Par défaut, ou lorsqu’une étape se définit explicitement en parallèle à false, les tests d’une étape sont exécutés de manière séquentielle dans l’ordre où ils sont définis dans le fichier de configuration. L’exécution de tests un à la fois est utile pour garantir qu’aucun test n’interagisse et n’entre en conflit l’un avec l’autre.

Cependant, si les tests sont conçus pour être complètement isolés, ils peuvent être parallélisés.

Procédure

  • Exécuter un ensemble de tests isolés en parallèle, les inclure dans la même étape et définir parallèlement à 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.38.0
        labels:
          suite: basic
          test: basic-check-spec-test
      - entrypoint:
        - scorecard-test
        - olm-bundle-validation
        image: quay.io/operator-framework/scorecard-test:v1.38.0
        labels:
          suite: olm
          test: olm-bundle-validation-test
    Copy to Clipboard Toggle word wrap
    1
    Active les tests parallèles

    L’ensemble des tests dans une phase parallèle sont exécutés simultanément, et le tableau de bord attend que tous les tests soient terminés avant de passer à l’étape suivante. Cela peut rendre vos tests plus rapides.

5.9.8. Des tests personnalisés de carte de pointage

L’outil de tableau de bord peut exécuter des tests personnalisés qui suivent ces conventions prescrites:

  • Les tests sont mis en œuvre dans une image de conteneur
  • Les tests acceptent un point d’entrée qui inclut une commande et des arguments
  • Les tests produisent une sortie de carte de pointage v1alpha3 au format JSON sans enregistrement externe dans la sortie d’essai
  • Les tests peuvent obtenir le contenu du paquet à un point de montage partagé de /bundle
  • Les tests peuvent accéder à l’API Kubernetes à l’aide d’une connexion client intégrée

L’écriture de tests personnalisés dans d’autres langages de programmation est possible si l’image de test suit les directives ci-dessus.

L’exemple suivant montre une image de test personnalisée écrite dans Go:

Exemple 5.9. Exemple de test de carte de pointage personnalisé

// 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},
	}
}
Copy to Clipboard Toggle word wrap
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat