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
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 Copier lienLien copié sur presse-papiers!
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
- Créer toutes les ressources requises par toutes les ressources personnalisées (CR) et l’opérateur connexes
- 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
- 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]
$ operator-sdk scorecard <bundle_dir_or_image> [flags]
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
$ operator-sdk scorecard -h
5.9.2. Configuration de la carte de pointage Copier lienLien copié sur presse-papiers!
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
./bundle
...
└── tests
└── scorecard
└── config.yaml
Exemple de fichier de configuration de carte de pointage
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:
Champ de configuration | Description |
---|---|
| Le nom de l’image du conteneur de test qui implémente un test |
| Commande et arguments invoqués dans l’image de test pour exécuter un test |
| É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 Copier lienLien copié sur presse-papiers!
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).
Essai | Description | Court 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. |
|
Essai | Description | Court 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. |
|
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 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. |
|
Champs spec avec descripteurs | Ce test vérifie que chaque champ dans les sections spec CRs a un descripteur correspondant listé dans le CSV. |
|
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. |
|
5.9.4. Exécution de l’outil de tableau de bord Copier lienLien copié sur presse-papiers!
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
Générer ou régénérer vos manifestes et métadonnées de paquets pour votre opérateur:
make bundle
$ make bundle
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.
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>
$ operator-sdk scorecard <bundle_dir_or_image>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.9.5. Sortie du tableau de bord Copier lienLien copié sur presse-papiers!
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
Exemple 5.8. Exemple de sortie de texte
La spécification du format de sortie correspond à la disposition du type de test.
5.9.6. La sélection des tests Copier lienLien copié sur presse-papiers!
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
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
$ operator-sdk scorecard <bundle_dir_or_image> \ -o text \ --selector=test=basic-check-spec-test
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
$ operator-sdk scorecard <bundle_dir_or_image> \ -o text \ --selector=suite=olm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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)'
$ operator-sdk scorecard <bundle_dir_or_image> \ -o text \ --selector='test in (basic-check-spec-test,olm-bundle-validation-test)'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.9.7. Activer les tests parallèles Copier lienLien copié sur presse-papiers!
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:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 Copier lienLien copié sur presse-papiers!
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é