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 :
-
.koles fichiers doivent être situés à l'adresse/opt/lib/modules/${KERNEL_VERSION}. -
modprobeetsleepdoivent ê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.
Vous devez avoir un abonnement Red Hat pour télécharger le paquetage kernel-devel.
Procédure
-
Pour générer les fichiers
modules.depet.mappour une version spécifique du noyau, exécutezdepmod -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
buildd'un mappage de noyau. -
Copiez l'adresse
Dockerfilede votre image de conteneur dans une ressourceConfigMap, sous la clédockerfile. -
Assurez-vous que le site
ConfigMapse trouve dans le même espace de noms que le siteModule.
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 DockerfileFROMen 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 DockerfileFROMà 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.
- Construire les modules du noyau.
-
Copiez les fichiers
.kodans une image plus petite destinée à l'utilisateur final, telle queubi-minimal. 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 ressourceBuild. 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