5.4. Opérateurs basés sur Ansible


Les développeurs d’opérateurs peuvent profiter du support Ansible dans le SDK de l’opérateur pour créer un exemple d’opérateur Ansible pour Memcached, un magasin à valeur clé distribué, et gérer son cycle de vie. Ce tutoriel passe par le processus suivant:

  • Créer un déploiement Memcached
  • Assurez-vous que la taille de déploiement est la même que celle spécifiée par la spécification Memcached Custom Resource (CR)
  • Actualisez le statut de Memcached CR en utilisant l’auteur de statut avec les noms des pods memcached
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 Opérateur, est dépréciée et devrait être supprimée dans une future version de Red Hat OpenShift Service sur AWS. 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 du futur service Red Hat OpenShift sur les versions AWS.

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 Red Hat OpenShift Service sur AWS 4 pour maintenir leurs projets et créer des versions d’opérateur ciblant de nouvelles versions de Red Hat OpenShift Service sur AWS.

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).

Ce processus est réalisé en utilisant deux pièces maîtresses du Cadre opérateur:

Le SDK de l’opérateur
L’outil operator-sdk CLI et l’API de bibliothèque de contrôleurs
Gestionnaire du cycle de vie de l’opérateur (OLM)
Installation, mise à niveau et contrôle d’accès basé sur les rôles (RBAC) des opérateurs sur un cluster
Note

Ce tutoriel va plus en détail que commencer avec Operator SDK pour les opérateurs basés sur Ansible dans la documentation OpenShift Container Platform.

5.4.1.1. Conditions préalables

  • L’opérateur SDK CLI installé
  • Installation d’OpenShift CLI (oc) 4+
  • Ansible 2.15.0
  • Ansible Runner 2.3.3+
  • Ansible Runner HTTP Event Emitter plugin 1.0.0+
  • 3,9 + Python
  • Client Python Kubernetes
  • Connexion à un service Red Hat OpenShift sur AWS cluster avec un compte doté d’autorisations d’administration dédiées
  • Afin de permettre au cluster de tirer l’image, le référentiel où vous poussez votre image doit être défini comme public, ou vous devez configurer une image pull secret

5.4.1.2. Créer un projet

Faites appel à l’opérateur SDK CLI pour créer un projet appelé memcached-operator.

Procédure

  1. Créer un répertoire pour le projet:

    $ mkdir -p $HOME/projects/memcached-operator
    Copy to Clipboard Toggle word wrap
  2. Changement dans le répertoire:

    $ cd $HOME/projects/memcached-operator
    Copy to Clipboard Toggle word wrap
  3. Exécutez la commande operator-sdk init avec le plugin ansible pour initialiser le projet:

    $ operator-sdk init \
        --plugins=ansible \
        --domain=example.com
    Copy to Clipboard Toggle word wrap
5.4.1.2.1. Fichier PROJET

Il y a parmi les fichiers générés par la commande operator-sdk init un fichier Kubebuilder PROJECT. Les commandes ultérieures de l’opérateur-sdk, ainsi que la sortie d’aide, qui sont exécutées à partir de la racine du projet lisent ce fichier et sont conscientes que le type de projet est Ansible. À titre d’exemple:

domain: example.com
layout:
- ansible.sdk.operatorframework.io/v1
plugins:
  manifests.sdk.operatorframework.io/v2: {}
  scorecard.sdk.operatorframework.io/v2: {}
  sdk.x-openshift.io/v1: {}
projectName: memcached-operator
version: "3"
Copy to Clipboard Toggle word wrap

5.4.1.3. Création d’une API

Faites appel à l’opérateur SDK CLI pour créer une API Memcached.

Procédure

  • Exécutez la commande suivante pour créer une API avec le cache de groupe, version, v1, et sortez Memcached:

    $ operator-sdk create api \
        --group cache \
        --version v1 \
        --kind Memcached \
        --generate-role 
    1
    Copy to Clipboard Toggle word wrap
    1
    Génère un rôle Ansible pour l’API.

Après avoir créé l’API, votre projet Opérateur se met à jour avec la structure suivante:

À propos de Memcached CRD
Inclut un échantillon de ressource Memcached
Gestionnaire

Le programme qui réconcilie l’état du cluster avec l’état souhaité en utilisant:

  • Conciliateur, soit un rôle Ansible ou un playbook
  • Fichier watch.yaml, qui connecte la ressource Memcached au rôle memcached Ansible

5.4.1.4. La modification du gestionnaire

Actualisez votre projet Opérateur pour fournir la logique de rapprochement, sous la forme d’un rôle Ansible, qui s’exécute chaque fois qu’une ressource Memcached est créée, mise à jour ou supprimée.

Procédure

  1. Actualisez le fichier role/memcached/tasks/main.yml avec la structure suivante:

    ---
    - name: start memcached
      k8s:
        definition:
          kind: Deployment
          apiVersion: apps/v1
          metadata:
            name: '{{ ansible_operator_meta.name }}-memcached'
            namespace: '{{ ansible_operator_meta.namespace }}'
          spec:
            replicas: "{{size}}"
            selector:
              matchLabels:
                app: memcached
            template:
              metadata:
                labels:
                  app: memcached
              spec:
                containers:
                - name: memcached
                  command:
                  - memcached
                  - -m=64
                  - -o
                  - modern
                  - -v
                  image: "docker.io/memcached:1.4.36-alpine"
                  ports:
                    - containerPort: 11211
    Copy to Clipboard Toggle word wrap

    Ce rôle memcached assure l’existence d’un déploiement mémcached et définit la taille du déploiement.

  2. Définissez les valeurs par défaut pour les variables utilisées dans votre rôle Ansible en éditant le fichier role/memcached/defaults/main.yml:

    ---
    # defaults file for Memcached
    size: 1
    Copy to Clipboard Toggle word wrap
  3. Actualisez la ressource de l’échantillon Memcached dans le fichier config/samples/cache_v1_memcached.yaml avec la structure suivante:

    apiVersion: cache.example.com/v1
    kind: Memcached
    metadata:
      labels:
        app.kubernetes.io/name: memcached
        app.kubernetes.io/instance: memcached-sample
        app.kubernetes.io/part-of: memcached-operator
        app.kubernetes.io/managed-by: kustomize
        app.kubernetes.io/created-by: memcached-operator
      name: memcached-sample
    spec:
      size: 3
    Copy to Clipboard Toggle word wrap

    Les paires clé-valeur dans la spécification de ressource personnalisée (CR) sont transmises à Ansible sous forme de variables supplémentaires.

Note

Les noms de toutes les variables dans le champ spec sont convertis en cas de serpent, c’est-à-dire minuscules avec un accent, par l’opérateur avant d’exécuter Ansible. À titre d’exemple, serviceAccount dans la spécification devient service_account dans Ansible.

Dans votre fichier watch.yaml, vous pouvez désactiver cette conversion en paramétrant l’optionnakCaseParameters. Il est recommandé d’effectuer une validation de type dans Ansible sur les variables pour vous assurer que votre application reçoit les entrées attendues.

5.4.1.5. Activer le support proxy

Les auteurs d’opérateurs peuvent développer des opérateurs qui prennent en charge les proxys réseau. Les administrateurs dotés du rôle d’administrateur dédié configurent la prise en charge du proxy pour les variables d’environnement qui sont gérées par Operator Lifecycle Manager (OLM). Afin de prendre en charge les clusters proxiés, votre opérateur doit inspecter l’environnement pour les variables proxy standard suivantes et transmettre les valeurs à Operands:

  • HTTP_PROXY
  • HTTPS_PROXY
  • AUCUN_PROXY
Note

Ce tutoriel utilise HTTP_PROXY comme exemple de variable d’environnement.

Conditions préalables

  • C’est un cluster doté d’un proxy de sortie à l’échelle du cluster activé.

Procédure

  1. Ajoutez les variables d’environnement au déploiement en mettant à jour le fichier role/memcached/tasks/main.yml avec ce qui suit:

    ...
    env:
       - name: HTTP_PROXY
         value: '{{ lookup("env", "HTTP_PROXY") | default("", True) }}'
       - name: http_proxy
         value: '{{ lookup("env", "HTTP_PROXY") | default("", True) }}'
    ...
    Copy to Clipboard Toggle word wrap
  2. Définissez la variable d’environnement sur le déploiement de l’opérateur en ajoutant ce qui suit au fichier config/manager/manager.yaml:

    containers:
     - args:
       - --leader-elect
       - --leader-election-id=ansible-proxy-demo
       image: controller:latest
       name: manager
       env:
         - name: "HTTP_PROXY"
           value: "http_proxy_test"
    Copy to Clipboard Toggle word wrap

5.4.1.6. Exécution de l’opérateur

Afin de construire et d’exécuter votre opérateur, utilisez l’opérateur SDK CLI pour regrouper votre opérateur, puis utilisez le gestionnaire de cycle de vie de l’opérateur (OLM) pour le déploiement sur le cluster.

Note

Lorsque vous souhaitez déployer votre opérateur sur un cluster OpenShift Container Platform au lieu d’un service Red Hat OpenShift sur AWS, deux options de déploiement supplémentaires sont disponibles:

  • Exécutez localement en dehors du cluster en tant que programme Go.
  • Exécutez comme un déploiement sur le cluster.
5.4.1.6.1.1. Groupement d’un opérateur

Le format de paquet Opérateur est la méthode d’emballage par défaut pour Operator SDK et Operator Lifecycle Manager (OLM). En utilisant le SDK de l’opérateur, vous pouvez préparer votre opérateur à une utilisation sur OLM pour construire et pousser votre projet Opérateur en tant qu’image groupée.

Conditions préalables

  • L’opérateur SDK CLI installé sur un poste de travail de développement
  • Installation d’OpenShift CLI (oc) v4+
  • Le projet d’opérateur initialisé à l’aide du SDK de l’opérateur

Procédure

  1. Exécutez les commandes suivantes dans votre répertoire de projet Opérateur pour construire et pousser l’image de votre opérateur. Modifiez l’argument IMG dans les étapes suivantes pour faire référence à un référentiel auquel vous avez accès. Il est possible d’obtenir un compte de stockage des conteneurs sur des sites de dépôt tels que Quay.io.

    1. Construire l’image:

      $ make docker-build IMG=<registry>/<user>/<operator_image_name>:<tag>
      Copy to Clipboard Toggle word wrap
      Note

      Le Dockerfile généré par le SDK pour l’opérateur renvoie explicitement GOARCH=amd64 pour la construction de go. Cela peut être modifié à GOARCH=$TARGETARCH pour les architectures non-AMD64. Docker définira automatiquement la variable d’environnement à la valeur spécifiée par -platform. Avec Buildah, le -build-arg devra être utilisé à cet effet. En savoir plus, consultez Multiple Architectures.

    2. Appuyez sur l’image vers un référentiel:

      $ make docker-push IMG=<registry>/<user>/<operator_image_name>:<tag>
      Copy to Clipboard Toggle word wrap
  2. Créez votre paquet Opérateur manifeste en exécutant la commande make bundle, qui invoque plusieurs commandes, y compris l’opérateur SDK génère des paquets et des sous-commandes validant:

    $ make bundle IMG=<registry>/<user>/<operator_image_name>:<tag>
    Copy to Clipboard Toggle word wrap

    Les manifestes de paquets pour un opérateur décrivent comment afficher, créer et gérer une application. La commande make bundle crée les fichiers et répertoires suivants dans votre projet Opérateur:

    • Le bundle manifeste un répertoire nommé bundle/manifests qui contient un objet ClusterServiceVersion
    • Annuaire de métadonnées groupé nommé bundle/metadata
    • L’ensemble des définitions de ressources personnalisées (CRD) dans un répertoire config/crd
    • Dockerfile bundle.Dockerfile

    Ces fichiers sont ensuite automatiquement validés en utilisant le bundle opérateur-sdk valide pour s’assurer que la représentation des faisceaux sur disque est correcte.

  3. Créez et poussez votre image de paquet en exécutant les commandes suivantes. L’OLM consomme des faisceaux d’opérateurs à l’aide d’une image d’index, qui référence à une ou plusieurs images groupées.

    1. Construisez l’image du bundle. Définissez BUNDLE_IMG avec les détails du registre, de l’espace de noms d’utilisateur et de la balise d’image où vous avez l’intention de pousser l’image:

      $ make bundle-build BUNDLE_IMG=<registry>/<user>/<bundle_image_name>:<tag>
      Copy to Clipboard Toggle word wrap
    2. Appuyez sur l’image du paquet:

      $ docker push <registry>/<user>/<bundle_image_name>:<tag>
      Copy to Clipboard Toggle word wrap

Le gestionnaire de cycle de vie de l’opérateur (OLM) vous aide à installer, mettre à jour et gérer le cycle de vie des Opérateurs et de leurs services associés sur un cluster Kubernetes. Le système OLM est installé par défaut sur Red Hat OpenShift Service sur AWS et s’exécute sous forme d’extension Kubernetes afin que vous puissiez utiliser la console Web et OpenShift CLI (oc) pour toutes les fonctions de gestion du cycle de vie de l’opérateur sans outils supplémentaires.

Le format de paquet opérateur est la méthode d’emballage par défaut pour l’opérateur SDK et OLM. Le SDK de l’opérateur permet d’exécuter rapidement une image groupée sur OLM afin de s’assurer qu’elle fonctionne correctement.

Conditions préalables

  • L’opérateur SDK CLI installé sur un poste de travail de développement
  • Ensemble d’image de l’opérateur construit et poussé à un registre
  • Installation OLM sur un cluster basé sur Kubernetes (v1.16.0 ou version ultérieure si vous utilisez apiextensions.k8s.io/v1 CRDs, par exemple Red Hat OpenShift Service sur AWS 4)
  • Connexion au cluster avec oc à l’aide d’un compte avec des autorisations d’administration dédiées

Procédure

  • Entrez la commande suivante pour exécuter l’opérateur sur le cluster:

    $ operator-sdk run bundle \
    1
    
        -n <namespace> \
    2
    
        <registry>/<user>/<bundle_image_name>:<tag> 
    3
    Copy to Clipboard Toggle word wrap
    1
    La commande run bundle crée un catalogue basé sur des fichiers valide et installe le paquet Opérateur sur votre cluster en utilisant OLM.
    2
    Facultatif: Par défaut, la commande installe l’opérateur dans le projet actuellement actif dans votre fichier ~/.kube/config. Il est possible d’ajouter le drapeau -n pour définir un espace de noms différent pour l’installation.
    3
    Dans le cas où vous ne spécifiez pas une image, la commande utilise quay.io/operator-framework/opm:latest comme image d’index par défaut. Lorsque vous spécifiez une image, la commande utilise l’image du faisceau lui-même comme image d’index.
    Important

    À partir de Red Hat OpenShift Service sur AWS 4.11, la commande run bundle prend en charge le format de catalogue basé sur des fichiers pour les catalogues d’opérateurs par défaut. Le format de base de données SQLite obsolète pour les catalogues d’opérateurs continue d’être pris en charge; cependant, il sera supprimé dans une version ultérieure. Il est recommandé aux auteurs de l’opérateur de migrer leurs flux de travail vers le format de catalogue basé sur les fichiers.

    Cette commande effectue les actions suivantes:

    • Créez une image d’index faisant référence à votre image de paquet. L’image de l’index est opaque et éphémère, mais reflète avec précision comment un paquet serait ajouté à un catalogue en production.
    • Créez une source de catalogue qui pointe vers votre nouvelle image d’index, ce qui permet à OperatorHub de découvrir votre opérateur.
    • Déployez votre opérateur dans votre cluster en créant un groupe d’opérateurs, un abonnement, un plan d’installation et toutes les autres ressources requises, y compris RBAC.

5.4.1.7. Créer une ressource personnalisée

Après l’installation de votre opérateur, vous pouvez le tester en créant une ressource personnalisée (CR) qui est maintenant fournie sur le cluster par l’opérateur.

Conditions préalables

  • Exemple Memcached Operator, qui fournit le Memcached CR, installé sur un cluster

Procédure

  1. Changer l’espace de noms où votre opérateur est installé. À titre d’exemple, si vous avez déployé l’opérateur à l’aide de la commande make deployment:

    $ oc project memcached-operator-system
    Copy to Clipboard Toggle word wrap
  2. Éditer l’échantillon Memcached CR manifeste à config/samples/cache_v1_memcached.yaml pour contenir les spécifications suivantes:

    apiVersion: cache.example.com/v1
    kind: Memcached
    metadata:
      name: memcached-sample
    ...
    spec:
    ...
      size: 3
    Copy to Clipboard Toggle word wrap
  3. Créer le CR:

    $ oc apply -f config/samples/cache_v1_memcached.yaml
    Copy to Clipboard Toggle word wrap
  4. Assurez-vous que l’opérateur Memcached crée le déploiement de l’échantillon CR avec la bonne taille:

    $ oc get deployments
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
    memcached-operator-controller-manager   1/1     1            1           8m
    memcached-sample                        3/3     3            3           1m
    Copy to Clipboard Toggle word wrap

  5. Consultez le statut des pods et CR pour confirmer que le statut est mis à jour avec les noms de pod de Memcached.

    1. Consultez les gousses:

      $ oc get pods
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      NAME                                  READY     STATUS    RESTARTS   AGE
      memcached-sample-6fd7c98d8-7dqdr      1/1       Running   0          1m
      memcached-sample-6fd7c98d8-g5k7v      1/1       Running   0          1m
      memcached-sample-6fd7c98d8-m7vn7      1/1       Running   0          1m
      Copy to Clipboard Toggle word wrap

    2. Consultez l’état CR:

      $ oc get memcached/memcached-sample -o yaml
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      apiVersion: cache.example.com/v1
      kind: Memcached
      metadata:
      ...
        name: memcached-sample
      ...
      spec:
        size: 3
      status:
        nodes:
        - memcached-sample-6fd7c98d8-7dqdr
        - memcached-sample-6fd7c98d8-g5k7v
        - memcached-sample-6fd7c98d8-m7vn7
      Copy to Clipboard Toggle word wrap

  6. Actualisez la taille du déploiement.

    1. Actualisez le fichier config/samples/cache_v1_memcached.yaml pour modifier le champ spec.size dans le CR Memcached de 3 à 5:

      $ oc patch memcached memcached-sample \
          -p '{"spec":{"size": 5}}' \
          --type=merge
      Copy to Clipboard Toggle word wrap
    2. Confirmez que l’opérateur modifie la taille du déploiement:

      $ oc get deployments
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
      memcached-operator-controller-manager   1/1     1            1           10m
      memcached-sample                        5/5     5            5           3m
      Copy to Clipboard Toggle word wrap

  7. Supprimez le CR en exécutant la commande suivante:

    $ oc delete -f config/samples/cache_v1_memcached.yaml
    Copy to Clipboard Toggle word wrap
  8. Nettoyez les ressources qui ont été créées dans le cadre de ce tutoriel.

    • Lorsque vous avez utilisé la commande make deployment pour tester l’opérateur, exécutez la commande suivante:

      $ make undeploy
      Copy to Clipboard Toggle word wrap
    • Lorsque vous avez utilisé la commande operator-sdk run bundle pour tester l’opérateur, exécutez la commande suivante:

      $ operator-sdk cleanup <project_name>
      Copy to Clipboard Toggle word wrap

L’opérateur-sdk CLI peut générer, ou échafauder, un certain nombre de paquets et de fichiers pour chaque projet d’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 Opérateur, est dépréciée et devrait être supprimée dans une future version de Red Hat OpenShift Service sur AWS. 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 du futur service Red Hat OpenShift sur les versions AWS.

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 Red Hat OpenShift Service sur AWS 4 pour maintenir leurs projets et créer des versions d’opérateur ciblant de nouvelles versions de Red Hat OpenShift Service sur AWS.

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.4.2.1. Disposition de projet basée sur Ansible

Les projets d’opérateur basés sur Ansible générés à l’aide de la commande operator-sdk init --plugins ansible contiennent les répertoires et fichiers suivants:

Expand
Fichier ou répertoireBut

Dockerfile

Dockerfile pour la construction de l’image du conteneur pour l’opérateur.

À propos de Makefile

Cibles pour la construction, la publication, le déploiement de l’image du conteneur qui enveloppe le binaire Opérateur, et les cibles pour l’installation et la désinstallation de la définition de ressources personnalisées (CRD).

LE PROJET

Fichier YAML contenant des informations de métadonnées pour l’opérateur.

configuration/crd

Les fichiers CRD de base et les paramètres de fichier kustomization.yaml.

configuration/défaut

Collecte tous les manifestes de l’opérateur pour le déploiement. À utiliser par la commande make deployment.

configuration/gestionnaire

Déploiement du gestionnaire de contrôleur.

configuration/prométhée

La ressource ServiceMonitor pour la surveillance de l’opérateur.

config/rbac

Lien de rôle et de rôle pour le proxy d’élection et d’authentification du leader.

configuration/échantillons

Échantillons de ressources créées pour les CRD.

configuration/test

Configurations d’échantillons pour les tests.

livres de lecture/

C’est un sous-répertoire pour que les playbooks s’exécutent.

les rôles/

Le sous-répertoire de l’arborescence des rôles s’exécute.

les montres.yaml

Groupe/version/type (GVK) des ressources à surveiller, et la méthode d’invocation Ansible. De nouvelles entrées sont ajoutées à l’aide de la commande create api.

exigences.yml

Fichier YAML contenant les collections Ansibles et les dépendances de rôles à installer lors d’une construction.

la molécule/

Des scénarios de molécules pour tester de bout en bout votre rôle et votre opérateur.

Le service OpenShift Red Hat sur AWS 4 prend en charge le SDK 1.38.0 de l’opérateur. Lorsque vous disposez déjà du 1.36.1 CLI installé sur votre poste de travail, vous pouvez mettre à jour le CLI à 1.38.0 en installant la dernière version.

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 Opérateur, est dépréciée et devrait être supprimée dans une future version de Red Hat OpenShift Service sur AWS. 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 du futur service Red Hat OpenShift sur les versions AWS.

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 Red Hat OpenShift Service sur AWS 4 pour maintenir leurs projets et créer des versions d’opérateur ciblant de nouvelles versions de Red Hat OpenShift Service sur AWS.

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).

Cependant, pour s’assurer que vos projets d’opérateur existants maintiennent la compatibilité avec le SDK 1.38.0 de l’opérateur, des étapes de mise à jour sont nécessaires pour les modifications de rupture associées introduites depuis 1.36.1. Les étapes de mise à jour doivent être exécutées manuellement dans l’un de vos projets Opérateurs qui ont été précédemment créés ou maintenus avec 1.36.1.

La procédure suivante met à jour un projet existant d’opérateur basé sur Ansible pour la compatibilité avec 1.38.0.

Conditions préalables

  • L’opérateur SDK 1.38.0 installé
  • Création ou maintenance d’un projet opérateur avec l’opérateur SDK 1.36.1

Procédure

  1. Éditez le Makefile de votre projet Opérateur pour mettre à jour la version SDK de l’opérateur vers 1.38.0, comme indiqué dans l’exemple suivant:

    Exemple de Makefile

    # Set the Operator SDK version to use. By default, what is installed on the system is used.
    # This is useful for CI or a project to utilize a specific version of the operator-sdk toolkit.
    OPERATOR_SDK_VERSION ?= v1.38.0 
    1
    Copy to Clipboard Toggle word wrap

    1
    Changer la version de 1.36.1 à 1.38.0.
  2. Éditez le Dockerfile de votre projet Opérateur pour mettre à jour la balise image ose-ansible-operator à 4, comme indiqué dans l’exemple suivant:

    Exemple Dockerfile

    FROM registry.redhat.io/openshift4/ose-ansible-operator:v4
    Copy to Clipboard Toggle word wrap

  3. Il faut mettre à niveau les versions Kubernetes de votre projet Opérateur pour utiliser 1.30 et Kubebuilder v4.

    Astuce

    Cette mise à jour comprend des changements complexes d’échafaudage en raison de l’élimination du kube-rbac-proxy. Lorsque ces migrations deviennent difficiles à suivre, échafauder un nouveau projet d’échantillon à des fins de comparaison.

    1. Actualisez la version Kustomize dans votre Makefile en apportant les modifications suivantes:

      - curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v5.3.0/kustomize_v5.3.0_$(OS)_$(ARCH).tar.gz | \
      + curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v5.4.2/kustomize_v5.4.2_$(OS)_$(ARCH).tar.gz | \
      Copy to Clipboard Toggle word wrap
    2. Actualisez votre fichier config/default/kustomization.yaml avec les modifications suivantes:

        # [PROMETHEUS] To enable prometheus monitor, uncomment all sections with 'PROMETHEUS'.
        #- ../prometheus
      + # [METRICS] Expose the controller manager metrics service.
      + - metrics_service.yaml
      
      + # Uncomment the patches line if you enable Metrics, and/or are using webhooks and cert-manager
        patches:
      - # Protect the /metrics endpoint by putting it behind auth.
      - # If you want your controller-manager to expose the /metrics
      - # endpoint w/o any authn/z, please comment the following line.
      - - path: manager_auth_proxy_patch.yaml
      + # [METRICS] The following patch will enable the metrics endpoint using HTTPS and the port :8443.
      + # More info: https://book.kubebuilder.io/reference/metrics
      + - path: manager_metrics_patch.yaml
      +   target:
      +     kind: Deployment
      Copy to Clipboard Toggle word wrap
    3. Enlevez les fichiers config/default/manager_auth_proxy_patch.yaml et config/default/manager_config_patch.yaml.
    4. Créez un fichier config/default/manager_metrics_patch.yaml avec le contenu suivant:

      # This patch adds the args to allow exposing the metrics endpoint using HTTPS
      - op: add
        path: /spec/template/spec/containers/0/args/0
        value: --metrics-bind-address=:8443
      # This patch adds the args to allow securing the metrics endpoint
      - op: add
        path: /spec/template/spec/containers/0/args/0
        value: --metrics-secure
      # This patch adds the args to allow RBAC-based authn/authz the metrics endpoint
      - op: add
        path: /spec/template/spec/containers/0/args/0
        value: --metrics-require-rbac
      Copy to Clipboard Toggle word wrap
    5. Créez un fichier config/default/metrics_service.yaml avec le contenu suivant:

      apiVersion: v1
      kind: Service
      metadata:
        labels:
          control-plane: controller-manager
          app.kubernetes.io/name: <operator-name>
          app.kubernetes.io/managed-by: kustomize
        name: controller-manager-metrics-service
        namespace: system
      spec:
        ports:
          - name: https
            port: 8443
            protocol: TCP
            targetPort: 8443
        selector:
          control-plane: controller-manager
      Copy to Clipboard Toggle word wrap
    6. Actualisez votre fichier config/manager/manager.yaml avec les modifications suivantes:

        - --leader-elect
      + - --health-probe-bind-address=:6789
      Copy to Clipboard Toggle word wrap
    7. Actualisez votre fichier config/prometheus/monitor.yaml avec les modifications suivantes:

           - path: /metrics
      -      port: https
      +      port: https # Ensure this is the name of the port that exposes HTTPS metrics
             tlsConfig:
      +        # TODO(user): The option insecureSkipVerify: true is not recommended for production since it disables
      +        # certificate verification. This poses a significant security risk by making the system vulnerable to
      +        # man-in-the-middle attacks, where an attacker could intercept and manipulate the communication between
      +        # Prometheus and the monitored services. This could lead to unauthorized access to sensitive metrics data,
      +        # compromising the integrity and confidentiality of the information.
      +        # Please use the following options for secure configurations:
      +        # caFile: /etc/metrics-certs/ca.crt
      +        # certFile: /etc/metrics-certs/tls.crt
      +        # keyFile: /etc/metrics-certs/tls.key
               insecureSkipVerify: true
      Copy to Clipboard Toggle word wrap
    8. Supprimez les fichiers suivants du répertoire config/rbac/:

      • auth_proxy_client_clusterrole.yaml
      • auth_proxy_role.yaml
      • auth_proxy_role_binding.yaml
      • auth_proxy_service.yaml
    9. Actualisez votre fichier config/rbac/kustomization.yaml avec les modifications suivantes:

        - leader_election_role_binding.yaml
      - # Comment the following 4 lines if you want to disable
      - # the auth proxy (https://github.com/brancz/kube-rbac-proxy)
      - # which protects your /metrics endpoint.
      - - auth_proxy_service.yaml
      - - auth_proxy_role.yaml
      - - auth_proxy_role_binding.yaml
      - - auth_proxy_client_clusterrole.yaml
      + # The following RBAC configurations are used to protect
      + # the metrics endpoint with authn/authz. These configurations
      + # ensure that only authorized users and service accounts
      + # can access the metrics endpoint. Comment the following
      + # permissions if you want to disable this protection.
      + # More info: https://book.kubebuilder.io/reference/metrics.html
      + - metrics_auth_role.yaml
      + - metrics_auth_role_binding.yaml
      + - metrics_reader_role.yaml
      Copy to Clipboard Toggle word wrap
    10. Créez un fichier config/rbac/metrics_auth_role_binding.yaml avec le contenu suivant:

      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRoleBinding
      metadata:
        name: metrics-auth-rolebinding
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: metrics-auth-role
      subjects:
        - kind: ServiceAccount
          name: controller-manager
          namespace: system
      Copy to Clipboard Toggle word wrap
    11. Créez un fichier config/rbac/metrics_reader_role.yaml avec le contenu suivant:

      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRole
      metadata:
        name: metrics-reader
      rules:
      - nonResourceURLs:
        - "/metrics"
        verbs:
        - get
      Copy to Clipboard Toggle word wrap

5.4.4. Assistance Ansible dans le SDK de l’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 Opérateur, est dépréciée et devrait être supprimée dans une future version de Red Hat OpenShift Service sur AWS. 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 du futur service Red Hat OpenShift sur les versions AWS.

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 Red Hat OpenShift Service sur AWS 4 pour maintenir leurs projets et créer des versions d’opérateur ciblant de nouvelles versions de Red Hat OpenShift Service sur AWS.

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.4.4.1. Fichiers de ressources personnalisés

Les opérateurs utilisent le mécanisme d’extension Kubernetes, les définitions de ressources personnalisées (CRD), de sorte que votre ressource personnalisée (CR) ressemble et agit comme les objets Kubernetes natifs intégrés.

Le format de fichier CR est un fichier de ressource Kubernetes. L’objet a des champs obligatoires et facultatifs:

Expand
Tableau 5.1. Champs de ressources personnalisés
Le champDescription

apiVersion

La version du CR à créer.

kind

C’est une sorte de CR à créer.

les métadonnées

Des métadonnées spécifiques à Kubernetes à créer.

caractéristiques (facultatif)

Liste de valeurs clés des variables qui sont transmises à Ansible. Ce champ est vide par défaut.

status

Il résume l’état actuel de l’objet. Dans le cas des opérateurs basés sur Ansible, la sous-ressource d’état est activée pour les CRD et gérée par l’opérateur_sdk.util.k8s_status module Ansible par défaut, qui inclut des informations de condition au statut CR.

annotations

Les annotations spécifiques à Kubernetes doivent être ajoutées au CR.

La liste suivante des annotations CR modifie le comportement de l’Opérateur:

Expand
Tableau 5.2. Annotations d’opérateur basées sur Ansible
AnnotationDescription

Ansible.operator-sdk/réconcile-période

Indique l’intervalle de rapprochement pour le CR. Cette valeur est analysée en utilisant le temps standard du paquet Golang. En particulier, ParseDuration est utilisé qui applique le suffixe par défaut de s, donnant la valeur en quelques secondes.

Exemple Ansible-basé sur l’annotation de l’opérateur

apiVersion: "test1.example.com/v1alpha1"
kind: "Test1"
metadata:
  name: "example"
annotations:
  ansible.operator-sdk/reconcile-period: "30s"
Copy to Clipboard Toggle word wrap

5.4.4.2. fichier Watch.yaml

Groupe/version/type (GVK) est un identifiant unique pour une API Kubernetes. Le fichier watch.yaml contient une liste de cartographies à partir de ressources personnalisées (CRs), identifiées par son GVK, à un rôle ou un playbook Ansible. L’opérateur s’attend à ce fichier mappage dans un emplacement prédéfini à /opt/ansible/watches.yaml.

Expand
Tableau 5.3. cartographie des fichiers Watch.yaml
Le champDescription

groupe de travail

Groupe de CR à regarder.

la version

La version de CR à regarder.

kind

Genre de CR à regarder

le rôle (par défaut)

Chemin vers le rôle Ansible ajouté au conteneur. À titre d’exemple, si votre répertoire de rôles est à /opt/ansible/roles/ et que votre rôle est nommé busybox, cette valeur serait /opt/ansible/roles/busybox. Ce champ s’exclut mutuellement avec le champ de playbook.

livre de lecture

Chemin vers le livre de lecture Ansible ajouté au conteneur. Ce livre de lecture devrait être un moyen d’appeler des rôles. Ce champ s’exclut mutuellement avec le domaine des rôles.

concilier la Période (facultatif)

L’intervalle de réconciliation, la fréquence à laquelle le rôle ou le playbook est exécuté, pour un CR donné.

GérerStatus (facultatif)

Lorsqu’il est défini sur true (par défaut), l’opérateur gère le statut du CR génériquement. Lorsqu’il est défini sur false, le statut du CR est géré ailleurs, par le rôle ou le playbook spécifié ou dans un contrôleur séparé.

Exemple watch.yaml fichier

- version: v1alpha1 
1

  group: test1.example.com
  kind: Test1
  role: /opt/ansible/roles/Test1

- version: v1alpha1 
2

  group: test2.example.com
  kind: Test2
  playbook: /opt/ansible/playbook.yml

- version: v1alpha1 
3

  group: test3.example.com
  kind: Test3
  playbook: /opt/ansible/test3.yml
  reconcilePeriod: 0
  manageStatus: false
Copy to Clipboard Toggle word wrap

1
Exemple simple de cartographie Test1 au rôle test1.
2
Exemple simple de mappage Test2 vers un playbook.
3
Exemple plus complexe pour le type Test3. Désactive la re-requête et la gestion du statut CR dans le livre de lecture.
5.4.4.2.1. Des options avancées

Les fonctionnalités avancées peuvent être activées en les ajoutant à votre fichier watch.yaml par GVK. Ils peuvent aller sous le groupe, la version, le genre et le playbook ou les champs de rôle.

Certaines fonctionnalités peuvent être remplacées par ressource à l’aide d’une annotation sur ce CR. Les options qui peuvent être remplacées ont l’annotation spécifiée ci-dessous.

Expand
Tableau 5.4. Advanced watch.yaml options de fichier
CaractéristiqueClé YAMLDescriptionAnnotation pour la surchargeLa valeur par défaut

Concilier la période

concilier la période

Le temps entre réconcilier court pour un CR particulier.

Ansible.operator-sdk/réconcile-période

1M

Gérer le statut

gérer le statut

Il permet à l’opérateur de gérer la section conditions de chaque section d’état CR.

 

C’est vrai

Surveiller les ressources dépendantes

les ressources de WatchDependentResources

Il permet à l’opérateur de surveiller dynamiquement les ressources créées par Ansible.

 

C’est vrai

Examiner les ressources en grappes

accueil &gt; WatchClusterScopedResources

Il permet à l’opérateur de regarder les ressources en grappes créées par Ansible.

 

faux

Artéfacts Max runner

à propos de maxRunnerArtifacts

Gère le nombre de répertoires d’artefacts qu’Ansible Runner conserve dans le conteneur de l’opérateur pour chaque ressource individuelle.

Ansible.operator-sdk/max-runner-artefacts

20

Exemple de fichier watch.yml avec des options avancées

- version: v1alpha1
  group: app.example.com
  kind: AppService
  playbook: /opt/ansible/playbook.yml
  maxRunnerArtifacts: 30
  reconcilePeriod: 5s
  manageStatus: False
  watchDependentResources: False
Copy to Clipboard Toggle word wrap

5.4.4.3. Des variables supplémentaires envoyées à Ansible

Des variables supplémentaires peuvent être envoyées à Ansible, qui sont ensuite gérées par l’opérateur. La section Spécification de la ressource personnalisée (CR) passe le long des paires clé-valeur en tant que variables supplémentaires. Cela équivaut à des variables supplémentaires passées à la commande ansible-playbook.

L’opérateur passe également le long de variables supplémentaires sous le champ méta pour le nom du CR et l’espace de noms du CR.

C) pour l’exemple suivant:

apiVersion: "app.example.com/v1alpha1"
kind: "Database"
metadata:
  name: "example"
spec:
  message: "Hello world 2"
  newParameter: "newParam"
Copy to Clipboard Toggle word wrap

La structure passée à Ansible en tant que variables supplémentaires est:

{ "meta": {
        "name": "<cr_name>",
        "namespace": "<cr_namespace>",
  },
  "message": "Hello world 2",
  "new_parameter": "newParam",
  "_app_example_com_database": {
     <full_crd>
   },
}
Copy to Clipboard Toggle word wrap

Le message et les champs newParamètre sont définis dans le niveau supérieur en tant que variables supplémentaires, et méta fournit les métadonnées pertinentes pour le CR telles que définies dans l’opérateur. Les champs méta peuvent être consultés à l’aide de la notation par point dans Ansible, par exemple:

---
- debug:
    msg: "name: {{ ansible_operator_meta.name }}, {{ ansible_operator_meta.namespace }}"
Copy to Clipboard Toggle word wrap

5.4.4.4. Ansible Runner Ansible Ansible

Ansible Runner conserve des informations sur les courses Ansible dans le conteneur. Ceci est situé à /tmp/ansible-operator/runner/<group>/&lt;version&gt;/&lt;kind&gt;/&lt;namespace&gt;/&lt;name&gt;.

5.4.5. Collection Kubernetes pour Ansible

Afin de gérer le cycle de vie de votre application sur Kubernetes à l’aide d’Ansible, vous pouvez utiliser la collection Kubernetes pour Ansible. Cette collection de modules Ansible permet à un développeur de tirer parti de ses fichiers de ressources Kubernetes existants écrits dans YAML ou d’exprimer la gestion du cycle de vie dans Ansible natif.

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 Opérateur, est dépréciée et devrait être supprimée dans une future version de Red Hat OpenShift Service sur AWS. 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 du futur service Red Hat OpenShift sur les versions AWS.

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 Red Hat OpenShift Service sur AWS 4 pour maintenir leurs projets et créer des versions d’opérateur ciblant de nouvelles versions de Red Hat OpenShift Service sur AWS.

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).

L’un des plus grands avantages de l’utilisation d’Ansible en conjonction avec les fichiers de ressources Kubernetes existants est la possibilité d’utiliser Jinja tentant afin que vous puissiez personnaliser les ressources avec la simplicité de quelques variables dans Ansible.

Cette section détaille l’utilisation de la collection Kubernetes. Installez la collection sur votre poste de travail local et testez-la à l’aide d’un livre de lecture avant de l’utiliser au sein d’un opérateur.

5.4.5.1. Installation de la collection Kubernetes pour Ansible

Il est possible d’installer la collection Kubernetes pour Ansible sur votre poste de travail local.

Procédure

  1. Installer Ansible 2.15+:

    $ sudo dnf install ansible
    Copy to Clipboard Toggle word wrap
  2. Installez le package client Python Kubernetes:

    $ pip install kubernetes
    Copy to Clipboard Toggle word wrap
  3. Installez la collection Kubernetes en utilisant l’une des méthodes suivantes:

    • La collection peut être installée directement à partir d’Ansible Galaxy:

      $ ansible-galaxy collection install community.kubernetes
      Copy to Clipboard Toggle word wrap
    • Lorsque vous avez déjà initialisé votre opérateur, vous pourriez avoir un fichier requirements.yml au niveau supérieur de votre projet. Ce fichier spécifie les dépendances anonymes qui doivent être installées pour que votre opérateur fonctionne. Ce fichier installe par défaut la collection community.kubernetes ainsi que la collection operator_sdk.util, qui fournit des modules et des plugins pour les fonctions spécifiques à l’opérateur.

      Installer les modules dépendants à partir du fichier requirements.yml:

      $ ansible-galaxy collection install -r requirements.yml
      Copy to Clipboard Toggle word wrap

5.4.5.2. Tester la collection Kubernetes localement

Les développeurs d’opérateurs peuvent exécuter le code Ansible à partir de leur machine locale plutôt que d’exécuter et de reconstruire l’opérateur à chaque fois.

Conditions préalables

  • Initialiser un projet d’opérateur basé sur Ansible et créer une API qui a un rôle Ansible généré en utilisant le SDK de l’opérateur
  • Installer la collection Kubernetes pour Ansible

Procédure

  1. Dans votre répertoire de projet Opérateur Ansible, modifiez le fichier role/&lt;kind&gt;/tasks/main.yml avec la logique Ansible que vous souhaitez. Le répertoire role/&lt;kind&gt;/ est créé lorsque vous utilisez le drapeau --generate-role lors de la création d’une API. Le &lt;kind&gt; remplaçable correspond au type que vous avez spécifié pour l’API.

    L’exemple suivant crée et supprime une carte de configuration basée sur la valeur d’une variable nommée état:

    ---
    - name: set ConfigMap example-config to {{ state }}
      community.kubernetes.k8s:
        api_version: v1
        kind: ConfigMap
        name: example-config
        namespace: <operator_namespace> 
    1
    
        state: "{{ state }}"
      ignore_errors: true 
    2
    Copy to Clipboard Toggle word wrap
    1
    Indiquez l’espace de noms où vous souhaitez créer la carte de configuration.
    2
    La configuration d’ignorer_erreurs: true s’assure que la suppression d’une carte de configuration inexistante ne échoue pas.
  2. Changer le fichier role/&lt;kind&gt;/defaults/main.yml pour définir l’état à présenter par défaut:

    ---
    state: present
    Copy to Clipboard Toggle word wrap
  3. Créez un playbook Ansible en créant un fichier playbook.yml dans le niveau supérieur de votre répertoire de projet, et incluez votre rôle &lt;kind&gt;:

    ---
    - hosts: localhost
      roles:
        - <kind>
    Copy to Clipboard Toggle word wrap
  4. Exécutez le livre de lecture:

    $ ansible-playbook playbook.yml
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'
    
    PLAY [localhost] ********************************************************************************
    
    TASK [Gathering Facts] ********************************************************************************
    ok: [localhost]
    
    TASK [memcached : set ConfigMap example-config to present] ********************************************************************************
    changed: [localhost]
    
    PLAY RECAP ********************************************************************************
    localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
    Copy to Clipboard Toggle word wrap

  5. Assurez-vous que la carte de configuration a été créée:

    $ oc get configmaps
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME               DATA   AGE
    example-config     0      2m1s
    Copy to Clipboard Toggle word wrap

  6. Exécutez à nouveau l’état de réglage du livre de lecture à l’absence:

    $ ansible-playbook playbook.yml --extra-vars state=absent
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'
    
    PLAY [localhost] ********************************************************************************
    
    TASK [Gathering Facts] ********************************************************************************
    ok: [localhost]
    
    TASK [memcached : set ConfigMap example-config to absent] ********************************************************************************
    changed: [localhost]
    
    PLAY RECAP ********************************************************************************
    localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
    Copy to Clipboard Toggle word wrap

  7. Assurez-vous que la carte de configuration a été supprimée:

    $ oc get configmaps
    Copy to Clipboard Toggle word wrap

5.4.5.3. Les prochaines étapes

  • Consultez Utiliser Ansible à l’intérieur d’un opérateur pour plus de détails sur le déclenchement de votre logique personnalisée Ansible à l’intérieur d’un opérateur lorsqu’une ressource personnalisée (CR) change.

Après avoir connu l’utilisation locale de la collection Kubernetes pour Ansible, vous pouvez déclencher la même logique Ansible à l’intérieur d’un opérateur lorsqu’une ressource personnalisée (CR) change. Cet exemple cartographie un rôle Ansible à une ressource spécifique de Kubernetes que l’opérateur regarde. Ce mappage se fait dans le fichier watch.yaml.

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 Opérateur, est dépréciée et devrait être supprimée dans une future version de Red Hat OpenShift Service sur AWS. 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 du futur service Red Hat OpenShift sur les versions AWS.

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 Red Hat OpenShift Service sur AWS 4 pour maintenir leurs projets et créer des versions d’opérateur ciblant de nouvelles versions de Red Hat OpenShift Service sur AWS.

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.4.6.1. Fichiers de ressources personnalisés

Les opérateurs utilisent le mécanisme d’extension Kubernetes, les définitions de ressources personnalisées (CRD), de sorte que votre ressource personnalisée (CR) ressemble et agit comme les objets Kubernetes natifs intégrés.

Le format de fichier CR est un fichier de ressource Kubernetes. L’objet a des champs obligatoires et facultatifs:

Expand
Tableau 5.5. Champs de ressources personnalisés
Le champDescription

apiVersion

La version du CR à créer.

kind

C’est une sorte de CR à créer.

les métadonnées

Des métadonnées spécifiques à Kubernetes à créer.

caractéristiques (facultatif)

Liste de valeurs clés des variables qui sont transmises à Ansible. Ce champ est vide par défaut.

status

Il résume l’état actuel de l’objet. Dans le cas des opérateurs basés sur Ansible, la sous-ressource d’état est activée pour les CRD et gérée par l’opérateur_sdk.util.k8s_status module Ansible par défaut, qui inclut des informations de condition au statut CR.

annotations

Les annotations spécifiques à Kubernetes doivent être ajoutées au CR.

La liste suivante des annotations CR modifie le comportement de l’Opérateur:

Expand
Tableau 5.6. Annotations d’opérateur basées sur Ansible
AnnotationDescription

Ansible.operator-sdk/réconcile-période

Indique l’intervalle de rapprochement pour le CR. Cette valeur est analysée en utilisant le temps standard du paquet Golang. En particulier, ParseDuration est utilisé qui applique le suffixe par défaut de s, donnant la valeur en quelques secondes.

Exemple Ansible-basé sur l’annotation de l’opérateur

apiVersion: "test1.example.com/v1alpha1"
kind: "Test1"
metadata:
  name: "example"
annotations:
  ansible.operator-sdk/reconcile-period: "30s"
Copy to Clipboard Toggle word wrap

5.4.6.2. Tester un opérateur basé sur Ansible localement

Il est possible de tester la logique à l’intérieur d’un opérateur basé sur Ansible qui s’exécute localement en utilisant la commande make run à partir du répertoire de haut niveau de votre projet Opérateur. La cible Makefile exécute localement le binaire ansible-operator, qui lit à partir du fichier watch.yaml et utilise votre fichier ~/.kube/config pour communiquer avec un cluster Kubernetes tout comme le font les modules k8s.

Note

Il est possible de personnaliser le chemin des rôles en définissant la variable d’environnement ANSIBLE_ROLES_PATH ou en utilisant le drapeau ansible-roles-path. Dans le cas où le rôle n’est pas trouvé dans la valeur ANSIBLE_ROLES_PATH, l’opérateur le recherche dans {{annuaire de courant}}/roles.

Conditions préalables

  • Ansible Runner v2.3.3+
  • Ansible Runner HTTP Event Emitter plugin v1.0.0+
  • A effectué les étapes précédentes pour tester la collection Kubernetes localement

Procédure

  1. Installez votre définition de ressources personnalisées (CRD) et les définitions appropriées du contrôle d’accès basé sur les rôles (RBAC) pour votre ressource personnalisée (CR):

    $ make install
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    /usr/bin/kustomize build config/crd | kubectl apply -f -
    customresourcedefinition.apiextensions.k8s.io/memcacheds.cache.example.com created
    Copy to Clipboard Toggle word wrap

  2. Exécutez la commande make run:

    $ make run
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    /home/user/memcached-operator/bin/ansible-operator run
    {"level":"info","ts":1612739145.2871568,"logger":"cmd","msg":"Version","Go Version":"go1.15.5","GOOS":"linux","GOARCH":"amd64","ansible-operator":"v1.10.1","commit":"1abf57985b43bf6a59dcd18147b3c574fa57d3f6"}
    ...
    {"level":"info","ts":1612739148.347306,"logger":"controller-runtime.metrics","msg":"metrics server is starting to listen","addr":":8080"}
    {"level":"info","ts":1612739148.3488882,"logger":"watches","msg":"Environment variable not set; using default value","envVar":"ANSIBLE_VERBOSITY_MEMCACHED_CACHE_EXAMPLE_COM","default":2}
    {"level":"info","ts":1612739148.3490262,"logger":"cmd","msg":"Environment variable not set; using default value","Namespace":"","envVar":"ANSIBLE_DEBUG_LOGS","ANSIBLE_DEBUG_LOGS":false}
    {"level":"info","ts":1612739148.3490646,"logger":"ansible-controller","msg":"Watching resource","Options.Group":"cache.example.com","Options.Version":"v1","Options.Kind":"Memcached"}
    {"level":"info","ts":1612739148.350217,"logger":"proxy","msg":"Starting to serve","Address":"127.0.0.1:8888"}
    {"level":"info","ts":1612739148.3506632,"logger":"controller-runtime.manager","msg":"starting metrics server","path":"/metrics"}
    {"level":"info","ts":1612739148.350784,"logger":"controller-runtime.manager.controller.memcached-controller","msg":"Starting EventSource","source":"kind source: cache.example.com/v1, Kind=Memcached"}
    {"level":"info","ts":1612739148.5511978,"logger":"controller-runtime.manager.controller.memcached-controller","msg":"Starting Controller"}
    {"level":"info","ts":1612739148.5512562,"logger":"controller-runtime.manager.controller.memcached-controller","msg":"Starting workers","worker count":8}
    Copy to Clipboard Toggle word wrap

    Avec l’opérateur qui surveille maintenant votre CR pour les événements, la création d’un CR déclenchera votre rôle Ansible à exécuter.

    Note

    Considérez un exemple de config/samples/<gvk>.yaml CR manifeste:

    apiVersion: <group>.example.com/v1alpha1
    kind: <kind>
    metadata:
      name: "<kind>-sample"
    Copy to Clipboard Toggle word wrap

    Comme le champ spec n’est pas défini, Ansible est invoqué sans variables supplémentaires. Le passage de variables supplémentaires d’un CR à Ansible est couvert dans une autre section. Il est important de fixer des défauts raisonnables pour l’opérateur.

  3. Créez une instance de votre CR avec l’état variable par défaut défini pour présenter:

    $ oc apply -f config/samples/<gvk>.yaml
    Copy to Clipboard Toggle word wrap
  4. Assurez-vous que la carte de configuration example-config a été créée:

    $ oc get configmaps
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                    STATUS    AGE
    example-config          Active    3s
    Copy to Clipboard Toggle word wrap

  5. Modifiez votre fichier config/samples/<gvk>.yaml pour définir le champ d’état à absent. À titre d’exemple:

    apiVersion: cache.example.com/v1
    kind: Memcached
    metadata:
      name: memcached-sample
    spec:
      state: absent
    Copy to Clipboard Toggle word wrap
  6. Appliquer les modifications:

    $ oc apply -f config/samples/<gvk>.yaml
    Copy to Clipboard Toggle word wrap
  7. Confirmez que la carte de configuration est supprimée:

    $ oc get configmap
    Copy to Clipboard Toggle word wrap

5.4.6.3. Essai d’un opérateur Ansible sur le cluster

Après avoir testé votre logique Ansible personnalisée localement à l’intérieur d’un opérateur, vous pouvez tester l’opérateur à l’intérieur d’un pod sur un Red Hat OpenShift Service sur le cluster AWS, qui est préféré pour une utilisation de production.

En tant que déploiement sur votre cluster, vous pouvez exécuter votre projet Opérateur.

Procédure

  1. Exécutez les commandes suivantes pour construire et pousser l’image de l’opérateur. Modifiez l’argument IMG dans les étapes suivantes pour faire référence à un référentiel auquel vous avez accès. Il est possible d’obtenir un compte de stockage des conteneurs sur des sites de dépôt tels que Quay.io.

    1. Construire l’image:

      $ make docker-build IMG=<registry>/<user>/<image_name>:<tag>
      Copy to Clipboard Toggle word wrap
      Note

      Le Dockerfile généré par le SDK pour l’opérateur renvoie explicitement GOARCH=amd64 pour la construction de go. Cela peut être modifié à GOARCH=$TARGETARCH pour les architectures non-AMD64. Docker définira automatiquement la variable d’environnement à la valeur spécifiée par -platform. Avec Buildah, le -build-arg devra être utilisé à cet effet. En savoir plus, consultez Multiple Architectures.

    2. Appuyez sur l’image vers un référentiel:

      $ make docker-push IMG=<registry>/<user>/<image_name>:<tag>
      Copy to Clipboard Toggle word wrap
      Note

      Le nom et la balise de l’image, par exemple IMG=&lt;registry&gt;/&lt;user&gt;/&lt;image_name&gt;:&lt;tag&gt;, dans les deux commandes peuvent également être définis dans votre Makefile. Changez la valeur IMG ?= Controller:dernière valeur pour définir votre nom d’image par défaut.

  2. Exécutez la commande suivante pour déployer l’opérateur:

    $ make deploy IMG=<registry>/<user>/<image_name>:<tag>
    Copy to Clipboard Toggle word wrap

    Cette commande crée un espace de noms avec le nom de votre projet Opérateur dans le formulaire &lt;project_name&gt;-system et est utilisée pour le déploiement. Cette commande installe également les manifestes RBAC à partir de config/rbac.

  3. Exécutez la commande suivante pour vérifier que l’opérateur est en cours d’exécution:

    $ oc get deployment -n <project_name>-system
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
    <project_name>-controller-manager       1/1     1            1           8m
    Copy to Clipboard Toggle word wrap

5.4.6.4. Journaux Ansibles

Les opérateurs basés sur Ansible fournissent des journaux sur l’exécution Ansible, ce qui peut être utile pour déboger vos tâches Ansible. Les journaux peuvent également contenir des informations détaillées sur les internes de l’opérateur et ses interactions avec Kubernetes.

5.4.6.4.1. Affichage des journaux Ansibles

Conditions préalables

  • Opérateur basé sur Ansible s’exécutant comme déploiement sur un cluster

Procédure

  • Afin d’afficher les journaux d’un opérateur basé sur Ansible, exécutez la commande suivante:

    $ oc logs deployment/<project_name>-controller-manager \
        -c manager \
    1
    
        -n <namespace> 
    2
    Copy to Clipboard Toggle word wrap
    1
    Afficher les journaux du conteneur gestionnaire.
    2
    Lorsque vous avez utilisé la commande make deployment pour exécuter l’opérateur en tant que déploiement, utilisez l’espace de noms &lt;project_name&gt;-system.

    Exemple de sortie

    {"level":"info","ts":1612732105.0579333,"logger":"cmd","msg":"Version","Go Version":"go1.15.5","GOOS":"linux","GOARCH":"amd64","ansible-operator":"v1.10.1","commit":"1abf57985b43bf6a59dcd18147b3c574fa57d3f6"}
    {"level":"info","ts":1612732105.0587437,"logger":"cmd","msg":"WATCH_NAMESPACE environment variable not set. Watching all namespaces.","Namespace":""}
    I0207 21:08:26.110949       7 request.go:645] Throttling request took 1.035521578s, request: GET:https://172.30.0.1:443/apis/flowcontrol.apiserver.k8s.io/v1alpha1?timeout=32s
    {"level":"info","ts":1612732107.768025,"logger":"controller-runtime.metrics","msg":"metrics server is starting to listen","addr":"127.0.0.1:8080"}
    {"level":"info","ts":1612732107.768796,"logger":"watches","msg":"Environment variable not set; using default value","envVar":"ANSIBLE_VERBOSITY_MEMCACHED_CACHE_EXAMPLE_COM","default":2}
    {"level":"info","ts":1612732107.7688773,"logger":"cmd","msg":"Environment variable not set; using default value","Namespace":"","envVar":"ANSIBLE_DEBUG_LOGS","ANSIBLE_DEBUG_LOGS":false}
    {"level":"info","ts":1612732107.7688901,"logger":"ansible-controller","msg":"Watching resource","Options.Group":"cache.example.com","Options.Version":"v1","Options.Kind":"Memcached"}
    {"level":"info","ts":1612732107.770032,"logger":"proxy","msg":"Starting to serve","Address":"127.0.0.1:8888"}
    I0207 21:08:27.770185       7 leaderelection.go:243] attempting to acquire leader lease  memcached-operator-system/memcached-operator...
    {"level":"info","ts":1612732107.770202,"logger":"controller-runtime.manager","msg":"starting metrics server","path":"/metrics"}
    I0207 21:08:27.784854       7 leaderelection.go:253] successfully acquired lease memcached-operator-system/memcached-operator
    {"level":"info","ts":1612732107.7850506,"logger":"controller-runtime.manager.controller.memcached-controller","msg":"Starting EventSource","source":"kind source: cache.example.com/v1, Kind=Memcached"}
    {"level":"info","ts":1612732107.8853772,"logger":"controller-runtime.manager.controller.memcached-controller","msg":"Starting Controller"}
    {"level":"info","ts":1612732107.8854098,"logger":"controller-runtime.manager.controller.memcached-controller","msg":"Starting workers","worker count":4}
    Copy to Clipboard Toggle word wrap

La variable d’environnement ANSIBLE_DEBUG_LOGS sur True permet de vérifier le résultat complet Ansible dans les journaux, ce qui peut être utile lors du débogage.

Procédure

  • Éditer les fichiers config/manager/manager.yaml et config/default/manager_metrics_patch.yaml pour inclure la configuration suivante:

          containers:
          - name: manager
            env:
            - name: ANSIBLE_DEBUG_LOGS
              value: "True"
    Copy to Clipboard Toggle word wrap
5.4.6.4.3. Activer le débogage verbeux dans les journaux

Lors du développement d’un opérateur basé sur Ansible, il peut être utile d’activer un débogage supplémentaire dans les journaux.

Procédure

  • Ajoutez l’annotation ansible.sdk.operatorframework.io/verbosity à votre ressource personnalisée pour activer le niveau de verbosité que vous souhaitez. À titre d’exemple:

    apiVersion: "cache.example.com/v1alpha1"
    kind: "Memcached"
    metadata:
      name: "example-memcached"
      annotations:
        "ansible.sdk.operatorframework.io/verbosity": "4"
    spec:
      size: 4
    Copy to Clipboard Toggle word wrap

5.4.7. Gestion de l’état des ressources personnalisées

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 Opérateur, est dépréciée et devrait être supprimée dans une future version de Red Hat OpenShift Service sur AWS. 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 du futur service Red Hat OpenShift sur les versions AWS.

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 Red Hat OpenShift Service sur AWS 4 pour maintenir leurs projets et créer des versions d’opérateur ciblant de nouvelles versions de Red Hat OpenShift Service sur AWS.

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).

Les opérateurs basés sur Ansible mettent automatiquement à jour les sous-ressources d’état des ressources personnalisées (CR) avec des informations génériques sur l’exécution Ansible précédente. Cela inclut le nombre de tâches réussies et échouées et les messages d’erreur pertinents comme indiqué:

status:
  conditions:
  - ansibleResult:
      changed: 3
      completion: 2018-12-03T13:45:57.13329
      failures: 1
      ok: 6
      skipped: 0
    lastTransitionTime: 2018-12-03T13:45:57Z
    message: 'Status code was -1 and not [200]: Request failed: <urlopen error [Errno
      113] No route to host>'
    reason: Failed
    status: "True"
    type: Failure
  - lastTransitionTime: 2018-12-03T13:46:13Z
    message: Running reconciliation
    reason: Running
    status: "True"
    type: Running
Copy to Clipboard Toggle word wrap

Les opérateurs basés sur Ansible permettent également aux auteurs de l’opérateur de fournir des valeurs d’état personnalisées avec le module k8s_status Ansible, qui est inclus dans la collection operator_sdk.util. Cela permet à l’auteur de mettre à jour l’état à partir de l’intérieur d’Ansible avec n’importe quelle paire clé-valeur comme souhaité.

Les opérateurs basés sur Ansible incluent toujours la sortie générique d’exécution Ansible comme indiqué ci-dessus. Lorsque vous préférez que votre application n’ait pas mis à jour l’état avec la sortie Ansible, vous pouvez suivre l’état manuellement à partir de votre application.

La collection operator_sdk.util permet de modifier votre opérateur Ansible afin de suivre manuellement l’état de la ressource personnalisée (CR) depuis votre application.

Conditions préalables

  • Le projet d’opérateur basé sur Ansible créé à l’aide du SDK de l’opérateur

Procédure

  1. Actualisez le fichier watch.yaml avec un champ ManagStatus défini à false:

    - version: v1
      group: api.example.com
      kind: <kind>
      role: <role>
      manageStatus: false
    Copy to Clipboard Toggle word wrap
  2. Utilisez le module operator_sdk.util.k8s_status Ansible pour mettre à jour la sous-ressource. À titre d’exemple, pour mettre à jour avec les données clés de test et de valeur, operator_sdk.util peut être utilisé comme indiqué:

    - operator_sdk.util.k8s_status:
        api_version: app.example.com/v1
        kind: <kind>
        name: "{{ ansible_operator_meta.name }}"
        namespace: "{{ ansible_operator_meta.namespace }}"
        status:
          test: data
    Copy to Clipboard Toggle word wrap
  3. Il est possible de déclarer les collections dans le fichier meta/main.yml pour le rôle, qui est inclus pour les opérateurs échafaudés basés sur Ansible:

    collections:
      - operator_sdk.util
    Copy to Clipboard Toggle word wrap
  4. Après avoir déclaré les collections dans la méta de rôle, vous pouvez invoquer le module k8s_status directement:

    k8s_status:
      ...
      status:
        key1: value1
    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