4.9. Gestion des catalogues personnalisés

Procédure

1. Initialiser un catalogue pour un catalogue basé sur des fichiers :

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

      $ mkdir <nom_de_l'opérateur>-index

   2. Créer un fichier Docker qui peut construire une image de catalogue :

      Exemple <operator_name>-index.Dockerfile

      # The base image is expected to contain
      # /bin/opm (with a serve subcommand) and /bin/grpc_health_probe
      FROM registry.redhat.io/openshift4/ose-operator-registry:v4.9
      
      # Configure the entrypoint and command
      ENTRYPOINT ["/bin/opm"]
      CMD ["serve", "/configs"]
      
      # Copy declarative config root into image at /configs
      ADD <operator_name>-index /configs
      
      # Set DC-specific label for the location of the DC root directory
      # in the image
      LABEL operators.operatorframework.io.index.configs.v1=/configs

      Le fichier Docker doit se trouver dans le même répertoire parent que le répertoire du catalogue que vous avez créé à l'étape précédente :

      Exemple de structure de répertoire

      .
      ├── <operator_name>-index
      └── <operator_name>-index.Dockerfile

   3. Remplissez le catalogue avec la définition de votre paquet :

      $ opm init <operator_name> \ 1
          --default-channel=preview \ 2
          --description=./README.md \ 3
          --icon=./operator-icon.svg \ 4
          --output yaml \ 5
          > <operator_name>-index/index.yaml 6

      1

      Nom de l'opérateur ou du paquet.

      2

      Canal que l'abonnement utilisera par défaut s'il n'est pas spécifié.

      3

      Chemin d'accès au site de l'opérateur README.md ou à d'autres documents.

      4

      Chemin d'accès à l'icône de l'opérateur.

      5

      Format de sortie : JSON ou YAML.

      6

      Chemin d'accès pour la création du fichier de configuration du catalogue.

      Cette commande génère un blob de configuration déclarative olm.package dans le fichier de configuration du catalogue spécifié.

2. Ajouter une liasse au catalogue :

   $ opm render <registry>/<namespace>/<bundle_image_name>:<tag> \ 1
       --output=yaml \
       >> <operator_name>-index/index.yaml 2

   1

   Spécification de tirage pour l'image de la liasse.

   2

   Chemin d'accès au fichier de configuration du catalogue.

   La commande opm render génère un blob de configuration déclaratif à partir des images de catalogue et de bundle fournies.

   Note

   Les chaînes doivent contenir au moins une liasse.

3. Ajoutez une entrée de canal pour l'offre groupée. Par exemple, modifiez l'exemple suivant selon vos spécifications et ajoutez-le à votre fichier <operator_name>-index/index.yaml:

   Exemple d'entrée de canal

   ---
   schema: olm.channel
   package: <operator_name>
   name: preview
   entries:
     - name: <operator_name>.v0.1.0 1

   1

   Veillez à inclure le point (.) après <operator_name> mais avant v dans la version. Sinon, l'entrée ne passera pas la commande opm validate.

4. Valider le catalogue basé sur les fichiers :

   1. Exécutez la commande opm validate dans le répertoire du catalogue :

      $ opm validate <nom_de_l'opérateur>-index

   2. Vérifiez que le code d'erreur est bien 0:

      $ echo $?

      Exemple de sortie

      0

5. Construire l'image du catalogue :

   $ podman build . \
       -f <operator_name>-index.Dockerfile \
       -t <registry>/<namespace>/<catalog_image_name>:<tag>

6. Pousser l'image du catalogue vers un registre :

   1. Si nécessaire, authentifiez-vous auprès de votre registre cible :

      $ podman login <registry>

   2. Pousser l'image du catalogue :

      $ podman push <registry>/<namespace>/<catalog_image_name>:<tag>

Procédure

1. Commencer un nouvel index :

   $ opm index add \
       --bundles <registry>/<namespace>/<bundle_image_name>:<tag> \1
       --tag <registry>/<namespace>/<index_image_name>:<tag> \2
       [--binary-image <registry_base_image>] 3

   1

   Liste séparée par des virgules des images de la liasse à ajouter à l'index.

   2

   La balise d'image que vous voulez que l'image d'index ait.

   3

   Facultatif : Une autre image de base du registre à utiliser pour servir le catalogue.

2. Pousser l'image de l'index vers un registre.

   1. Si nécessaire, authentifiez-vous auprès de votre registre cible :

      $ podman login <registry>

   2. Appuyez sur l'image d'index :

      $ podman push <registry>/<namespace>/<index_image_name>:<tag>

Procédure

1. Mettre à jour l'index existant en ajoutant des images de liasses :

   $ opm index add \
       --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \1
       --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \2
       --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \3
       --pull-tool podman 4

   1

   L'option --bundles spécifie une liste séparée par des virgules d'images supplémentaires à ajouter à l'index.

   2

   Le drapeau --from-index spécifie l'index précédemment poussé.

   3

   L'option --tag spécifie la balise d'image à appliquer à l'image d'index mise à jour.

   4

   L'option --pull-tool spécifie l'outil utilisé pour extraire les images des conteneurs.

   où :

   <registry>

   Spécifie le nom d'hôte du registre, par exemple quay.io ou mirror.example.com.

   <namespace>

   Spécifie l'espace de noms du registre, par exemple ocs-dev ou abc.

   <new_bundle_image>

   Spécifie la nouvelle image de paquet à ajouter au registre, par exemple ocs-operator.

   <digest>

   Spécifie l'ID de l'image SHA, ou condensé, de l'image de la liasse, par exemple c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41.

   <existing_index_image>

   Spécifie l'image précédemment poussée, telle que abc-redhat-operator-index.

   <existing_tag>

   Spécifie une balise d'image précédemment poussée, telle que 4.12.

   <updated_tag>

   Spécifie la balise d'image à appliquer à l'image d'index mise à jour, par exemple 4.12.1.

   Example command

   $ opm index add \
       --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \
       --from-index mirror.example.com/abc/abc-redhat-operator-index:4.12 \
       --tag mirror.example.com/abc/abc-redhat-operator-index:4.12.1 \
       --pull-tool podman

2. Pousser l'image d'index mise à jour :

   $ podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>

3. Une fois que Operator Lifecycle Manager (OLM) a interrogé automatiquement l'image d'index référencée dans la source du catalogue à intervalles réguliers, vérifiez que les nouveaux paquets ont été ajoutés avec succès :

   $ oc get packagemanifests -n openshift-marketplace

Procédure

1. S'authentifier avec le registre cible :

   $ podman login <target_registry>

2. Déterminez la liste des paquets que vous souhaitez inclure dans votre index élagué.

   1. Exécutez l'image de l'index source que vous souhaitez élaguer dans un conteneur. Par exemple :

      $ podman run -p50051:50051 \
          -it registry.redhat.io/redhat/redhat-operator-index:v4.12

      Exemple de sortie

      Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.12...
      Getting image source signatures
      Copying blob ae8a0c23f5b1 done
      ...
      INFO[0000] serving registry                              database=/database/index.db port=50051

   2. Dans une autre session de terminal, utilisez la commande grpcurl pour obtenir une liste des paquets fournis par l'index :

      grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out

   3. Inspectez le fichier packages.out et identifiez les noms de paquets de cette liste que vous souhaitez conserver dans votre index élagué. Par exemple :

      Exemples de listes de paquets

      ...
      {
        "name": "advanced-cluster-management"
      }
      ...
      {
        "name": "jaeger-product"
      }
      ...
      {
      {
        "name": "quay-operator"
      }
      ...

   4. Dans la session de terminal où vous avez exécuté la commande podman run, appuyez sur Ctrl et C pour arrêter le processus de conteneur.

3. Exécutez la commande suivante pour élaguer l'index source de tous les paquets, à l'exception des paquets spécifiés :

   $ opm index prune \
       -f registry.redhat.io/redhat/redhat-operator-index:v4.12 \1
       -p advanced-cluster-management,jaeger-product,quay-operator \2
       [-i registry.redhat.io/openshift4/ose-operator-registry:v4.9] \3
       -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.12 4

   1

   Index pour la taille.

   2

   Liste de paquets à conserver, séparés par des virgules.

   3

   Requis uniquement pour les images IBM Power et IBM zSystems : L'image de base Operator Registry avec le tag qui correspond à la version majeure et mineure du cluster OpenShift Container Platform cible.

   4

   Balise personnalisée pour la nouvelle image d'index en cours de construction.

4. Exécutez la commande suivante pour transférer la nouvelle image d'index dans votre registre cible :

   $ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.12

   où <namespace> est un espace de noms existant dans le registre.

Procédure

1. Migrez le catalogue de votre base de données SQLite vers un catalogue basé sur des fichiers en exécutant la commande suivante :

   $ opm migrate <registry_image> <fbc_directory>

2. Générez un fichier Docker pour votre catalogue basé sur les fichiers en exécutant la commande suivante :

   $ opm generate dockerfile <fbc_directory> \
     --binary-image \
     registry.redhat.io/openshift4/ose-operator-registry:v4.12

Procédure

1. Modifiez la définition de CatalogSource en remplaçant l'étiquette spec.grpcPodConfig.securityContextConfig par legacy, comme le montre l'exemple suivant :

   Exemple CatalogSource définition

   apiVersion: operators.coreos.com/v1alpha1
   kind: CatalogSource
   metadata:
     name: my-catsrc
     namespace: my-ns
   spec:
     sourceType: grpc
     grpcPodConfig:
       securityContextConfig: legacy
     image: my-image:latest

   Astuce

   Dans OpenShift Container Platform 4.12, le champ spec.grpcPodConfig.securityContextConfig est défini par défaut sur legacy. Dans une prochaine version d'OpenShift Container Platform, il est prévu que le paramètre par défaut devienne restricted. Si votre catalogue ne peut pas s'exécuter sous une application restreinte, il est recommandé de définir manuellement ce champ à legacy.

2. Modifiez votre fichier <namespace>.yaml pour ajouter les normes d'admission à la sécurité des pods élevés à l'espace de noms de la source de votre catalogue, comme le montre l'exemple suivant :

   Exemple de fichier <namespace>.yaml

   apiVersion: v1
   kind: Namespace
   metadata:
   ...
     labels:
       security.openshift.io/scc.podSecurityLabelSync: "false" 1
       openshift.io/cluster-monitoring: "true"
       pod-security.kubernetes.io/enforce: baseline 2
     name: "<namespace_name>"

   1

   Désactivez la synchronisation des étiquettes de sécurité des pods en ajoutant l'étiquette security.openshift.io/scc.podSecurityLabelSync=false à l'espace de noms.

   2

   Appliquez l'étiquette d'admission à la sécurité du pod pod-security.kubernetes.io/enforce. Définissez l'étiquette sur baseline ou privileged. Utilisez le profil de sécurité du pod baseline à moins que d'autres charges de travail dans l'espace de noms ne nécessitent un profil privileged.