4.4. Utilisation d'une image ModuleLoader

La gestion des modules du noyau (KMM) fonctionne avec des images de chargeurs de modules spécifiques. Il s'agit d'images OCI standard qui doivent satisfaire aux exigences suivantes :

  • .ko les fichiers doivent être situés à l'adresse /opt/lib/modules/${KERNEL_VERSION}.
  • modprobe et sleep doivent être définis dans la variable $PATH.

4.4.1. Exécution de depmod

Si votre image de chargeur de modules contient plusieurs modules du noyau et si l'un des modules dépend d'un autre module, il est préférable d'exécuter depmod à la fin du processus de construction pour générer les dépendances et les fichiers de mappage.

Note

Vous devez avoir un abonnement Red Hat pour télécharger le paquetage kernel-devel.

Procédure

  1. Pour générer les fichiers modules.dep et .map pour une version spécifique du noyau, exécutez depmod -b /opt ${KERNEL_VERSION}.

4.4.1.1. Example Dockerfile

Si vous construisez votre image sur OpenShift Container Platform, pensez à utiliser le Driver Tool Kit (DTK).

Pour plus d'informations, voir l'utilisation d'un build intitulé.

apiVersion: v1
kind: ConfigMap
metadata:
  name: kmm-ci-dockerfile
data:
  dockerfile: |
    ARG DTK_AUTO
    FROM ${DTK_AUTO} as builder
    ARG KERNEL_VERSION
    WORKDIR /usr/src
    RUN ["git", "clone", "https://github.com/rh-ecosystem-edge/kernel-module-management.git"]
    WORKDIR /usr/src/kernel-module-management/ci/kmm-kmod
    RUN KERNEL_SRC_DIR=/lib/modules/${KERNEL_VERSION}/build make all
    FROM registry.redhat.io/ubi8/ubi-minimal
    ARG KERNEL_VERSION
    RUN microdnf install kmod
    COPY --from=builder /usr/src/kernel-module-management/ci/kmm-kmod/kmm_ci_a.ko /opt/lib/modules/${KERNEL_VERSION}/
    COPY --from=builder /usr/src/kernel-module-management/ci/kmm-kmod/kmm_ci_b.ko /opt/lib/modules/${KERNEL_VERSION}/
    RUN depmod -b /opt ${KERNEL_VERSION}

Ressources supplémentaires

4.4.2. Construire dans le cluster

KMM peut construire des images de chargeurs de modules dans le cluster. Suivez les instructions suivantes :

  • Fournir des instructions de compilation en utilisant la section build d'un mappage de noyau.
  • Copiez l'adresse Dockerfile de votre image de conteneur dans une ressource ConfigMap, sous la clé dockerfile.
  • Assurez-vous que le site ConfigMap se trouve dans le même espace de noms que le site Module.

KMM vérifie si le nom de l'image spécifié dans le champ containerImage existe. Si c'est le cas, la construction est ignorée.

Sinon, KMM crée une ressource Build pour construire votre image. Une fois l'image construite, KMM procède au rapprochement avec Module. Voir l'exemple suivant.

# ...
- regexp: '^.+$'
  containerImage: "some.registry/org/<my_kmod>:${KERNEL_FULL_VERSION}"
  build:
    buildArgs:  1
      - name: ARG_NAME
        value: <some_value>
    secrets: 2
      - name: <some_kubernetes_secret> 3
    baseImageRegistryTLS:
      insecure: false 4
      insecureSkipTLSVerify: false 5
    dockerfileConfigMap:  6
      name: <my_kmod_dockerfile>
  registryTLS:
    insecure: false 7
    insecureSkipTLSVerify: false 8
1
En option.
2
En option.
3
Il sera monté dans le module de construction comme /run/secrets/some-kubernetes-secret.
4
Facultatif : Évitez d'utiliser ce paramètre. Si ce paramètre vaut true, la compilation sera autorisée à extraire l'image dans l'instruction Dockerfile FROM en utilisant le protocole HTTP.
5
Facultatif : Évitez d'utiliser ce paramètre. S'il vaut true, la compilation ignorera toute validation de certificat de serveur TLS lors de l'extraction de l'image dans l'instruction Dockerfile FROM à l'aide d'un simple HTTP.
6
Required.
7
Facultatif : Évitez d'utiliser ce paramètre. S'il vaut true, KMM sera autorisé à vérifier si l'image du conteneur existe déjà en utilisant le protocole HTTP ordinaire.
8
Facultatif : Évitez d'utiliser ce paramètre. S'il est défini sur true, KMM ignorera toute validation de certificat de serveur TLS lors de la vérification de l'existence de l'image du conteneur.

Ressources supplémentaires

4.4.3. Utilisation du Driver Toolkit

Le Driver Toolkit (DTK) est une image de base pratique pour construire des images de chargeur de module de construction. Il contient des outils et des bibliothèques pour la version d'OpenShift en cours d'exécution dans le cluster.

Procédure

Utiliser le DTK comme première étape d'un processus en plusieurs étapes Dockerfile.

  1. Construire les modules du noyau.
  2. Copiez les fichiers .ko dans une image plus petite destinée à l'utilisateur final, telle que ubi-minimal.
  3. Pour tirer parti de DTK dans votre compilation en grappe, utilisez l'argument de compilation DTK_AUTO. La valeur est automatiquement définie par KMM lors de la création de la ressource Build. Voir l'exemple suivant.

    ARG DTK_AUTO
    FROM ${DTK_AUTO} as builder
    ARG KERNEL_VERSION
    WORKDIR /usr/src
    RUN ["git", "clone", "https://github.com/rh-ecosystem-edge/kernel-module-management.git"]
    WORKDIR /usr/src/kernel-module-management/ci/kmm-kmod
    RUN KERNEL_SRC_DIR=/lib/modules/${KERNEL_VERSION}/build make all
    FROM registry.redhat.io/ubi8/ubi-minimal
    ARG KERNEL_VERSION
    RUN microdnf install kmod
    COPY --from=builder /usr/src/kernel-module-management/ci/kmm-kmod/kmm_ci_a.ko /opt/lib/modules/${KERNEL_VERSION}/
    COPY --from=builder /usr/src/kernel-module-management/ci/kmm-kmod/kmm_ci_b.ko /opt/lib/modules/${KERNEL_VERSION}/
    RUN depmod -b /opt ${KERNEL_VERSION}

Ressources supplémentaires