Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

1.6. Configuration du plugin Jenkins Kubernetes

L’image OpenShift Jenkins inclut le plugin Kubernetes préinstallé pour Jenkins afin que les agents Jenkins puissent être provisionnés dynamiquement sur plusieurs hôtes de conteneurs à l’aide de Kubernetes et OpenShift Dedicated.

Afin d’utiliser le plugin Kubernetes, OpenShift Dedicated fournit une image OpenShift Agent Base qui convient à l’utilisation comme agent Jenkins.

Important

4.11 déplace les images OpenShift Jenkins et OpenShift Agent Base vers le référentiel ocp-tools-4 sur Registry.redhat.io afin que Red Hat puisse produire et mettre à jour les images en dehors du cycle de vie dédié OpenShift. Auparavant, ces images se trouvaient dans la charge utile d’installation d’OpenShift Dedicated et dans le référentiel openshift4 sur Registry.redhat.io.

Les images OpenShift Jenkins Maven et NodeJS Agent ont été retirées de la charge utile OpenShift Dedicated 4.11. Le Red Hat ne produit plus ces images, et ils ne sont pas disponibles dans le référentiel ocp-tools-4 sur register.redhat.io. Le Red Hat maintient les versions 4.10 et précédentes de ces images pour tous les correctifs de bogues importants ou les CVE de sécurité, conformément à la politique de cycle de vie dédié OpenShift.

Consultez le lien « Modifications importantes des images OpenShift Jenkins » dans la section suivante « Ressources supplémentaires ».

Les images d’agent Maven et Node.js sont automatiquement configurées comme des images de modèles de pod Kubernetes dans la configuration d’image Jenkins dédiée OpenShift pour le plugin Kubernetes. Cette configuration comprend des étiquettes pour chaque image que vous pouvez appliquer à l’un de vos travaux Jenkins dans le cadre de leur restriction où ce projet peut être exécuté. Dans le cas où l’étiquette est appliquée, les tâches s’exécutent sous un Pod OpenShift Dédicated exécutant l’image de l’agent respectif.

Important

Dans OpenShift Dedicated 4.10 et ultérieur, le modèle recommandé pour exécuter les agents Jenkins à l’aide du plugin Kubernetes est d’utiliser des modèles de pod avec des conteneurs jnlp et sidecar. Le conteneur jnlp utilise l’image de l’agent OpenShift Dedicated Jenkins Base pour faciliter le lancement d’un pod séparé pour votre construction. L’image du conteneur sidecar a les outils nécessaires pour construire dans un langage particulier dans le pod séparé qui a été lancé. De nombreuses images de conteneur du catalogue de conteneurs Red Hat sont référencées dans les flux d’images d’échantillon dans l’espace de noms openshift. L’image OpenShift Dedicated Jenkins a un modèle de pod nommé java-build avec des conteneurs sidecar qui démontrent cette approche. Ce modèle de pod utilise la dernière version Java fournie par le flux d’images java dans l’espace de noms openshift.

L’image Jenkins fournit également la découverte automatique et la configuration automatique d’images d’agent supplémentaires pour le plugin Kubernetes.

Avec le plugin OpenShift Dedicated sync, sur le démarrage de Jenkins, les recherches d’image Jenkins dans le projet qu’il est en cours d’exécution, ou les projets listés dans la configuration du plugin, pour les éléments suivants:

  • L’image coule avec l’étiquette de rôle définie sur jenkins-agent.
  • Balises de flux d’images avec l’annotation de rôle définie sur jenkins-agent.
  • Configurez les cartes avec l’étiquette de rôle définie sur jenkins-agent.

Lorsque l’image Jenkins trouve un flux d’image avec l’étiquette appropriée, ou une balise de flux d’image avec l’annotation appropriée, elle génère la configuration correspondante du plugin Kubernetes. De cette façon, vous pouvez assigner vos tâches Jenkins à exécuter dans un pod exécutant l’image conteneur fournie par le flux d’images.

Le nom et les références d’image du flux d’image, ou balise de flux d’images, sont mappés aux champs nom et image du modèle de pod de plugin Kubernetes. Il est possible de contrôler le champ d’étiquette du modèle de pod de plugin Kubernetes en définissant une annotation sur le flux d’image, ou l’objet de balise de flux d’images, avec le label d’agent clé. Dans le cas contraire, le nom est utilisé comme étiquette.

Note

Il ne faut pas se connecter à la console Jenkins et modifier la configuration du modèle de pod. Lorsque le modèle de pod est créé et que le plugin OpenShift Dedicated Sync détecte que l’image associée au flux d’image ou à la balise de flux d’image a changé, il remplace le modèle de pod et écrase ces modifications de configuration. Il est impossible de fusionner une nouvelle configuration avec la configuration existante.

Considérez l’approche config map si vous avez des besoins de configuration plus complexes.

Lorsqu’il trouve une carte de configuration avec l’étiquette appropriée, l’image Jenkins suppose que toutes les valeurs de la charge utile des données clés de la carte de configuration contiennent un langage de balisage extensible (XML) conforme au format de configuration pour Jenkins et les modèles de pod de plugin Kubernetes. L’un des principaux avantages de la configuration des cartes sur les flux d’images et les balises de flux d’images est que vous pouvez contrôler tous les paramètres du modèle de module de plugin Kubernetes.

Exemple de carte de configuration pour jenkins-agent

kind: ConfigMap
apiVersion: v1
metadata:
  name: jenkins-agent
  labels:
    role: jenkins-agent
data:
  template1: |-
    <org.csanchez.jenkins.plugins.kubernetes.PodTemplate>
      <inheritFrom></inheritFrom>
      <name>template1</name>
      <instanceCap>2147483647</instanceCap>
      <idleMinutes>0</idleMinutes>
      <label>template1</label>
      <serviceAccount>jenkins</serviceAccount>
      <nodeSelector></nodeSelector>
      <volumes/>
      <containers>
        <org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
          <name>jnlp</name>
          <image>openshift/jenkins-agent-maven-35-centos7:v3.10</image>
          <privileged>false</privileged>
          <alwaysPullImage>true</alwaysPullImage>
          <workingDir>/tmp</workingDir>
          <command></command>
          <args>${computer.jnlpmac} ${computer.name}</args>
          <ttyEnabled>false</ttyEnabled>
          <resourceRequestCpu></resourceRequestCpu>
          <resourceRequestMemory></resourceRequestMemory>
          <resourceLimitCpu></resourceLimitCpu>
          <resourceLimitMemory></resourceLimitMemory>
          <envVars/>
        </org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
      </containers>
      <envVars/>
      <annotations/>
      <imagePullSecrets/>
      <nodeProperties/>
    </org.csanchez.jenkins.plugins.kubernetes.PodTemplate>
Copy to Clipboard Toggle word wrap

L’exemple suivant montre deux conteneurs qui référencent des flux d’images dans l’espace de noms openshift. Il s’agit d’un conteneur qui gère le contrat JNLP pour le lancement de Pods en tant qu’agents Jenkins. L’autre conteneur utilise une image avec des outils pour le code de construction dans un langage de codage particulier: 

kind: ConfigMap
apiVersion: v1
metadata:
  name: jenkins-agent
  labels:
    role: jenkins-agent
data:
  template2: |-
        <org.csanchez.jenkins.plugins.kubernetes.PodTemplate>
          <inheritFrom></inheritFrom>
          <name>template2</name>
          <instanceCap>2147483647</instanceCap>
          <idleMinutes>0</idleMinutes>
          <label>template2</label>
          <serviceAccount>jenkins</serviceAccount>
          <nodeSelector></nodeSelector>
          <volumes/>
          <containers>
            <org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
              <name>jnlp</name>
              <image>image-registry.openshift-image-registry.svc:5000/openshift/jenkins-agent-base-rhel8:latest</image>
              <privileged>false</privileged>
              <alwaysPullImage>true</alwaysPullImage>
              <workingDir>/home/jenkins/agent</workingDir>
              <command></command>
              <args>\$(JENKINS_SECRET) \$(JENKINS_NAME)</args>
              <ttyEnabled>false</ttyEnabled>
              <resourceRequestCpu></resourceRequestCpu>
              <resourceRequestMemory></resourceRequestMemory>
              <resourceLimitCpu></resourceLimitCpu>
              <resourceLimitMemory></resourceLimitMemory>
              <envVars/>
            </org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
            <org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
              <name>java</name>
              <image>image-registry.openshift-image-registry.svc:5000/openshift/java:latest</image>
              <privileged>false</privileged>
              <alwaysPullImage>true</alwaysPullImage>
              <workingDir>/home/jenkins/agent</workingDir>
              <command>cat</command>
              <args></args>
              <ttyEnabled>true</ttyEnabled>
              <resourceRequestCpu></resourceRequestCpu>
              <resourceRequestMemory></resourceRequestMemory>
              <resourceLimitCpu></resourceLimitCpu>
              <resourceLimitMemory></resourceLimitMemory>
              <envVars/>
            </org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
          </containers>
          <envVars/>
          <annotations/>
          <imagePullSecrets/>
          <nodeProperties/>
        </org.csanchez.jenkins.plugins.kubernetes.PodTemplate>
Copy to Clipboard Toggle word wrap
Note

Il ne faut pas se connecter à la console Jenkins et modifier la configuration du modèle de pod. Lorsque le modèle de pod est créé et que le plugin OpenShift Dedicated Sync détecte que l’image associée au flux d’image ou à la balise de flux d’image a changé, il remplace le modèle de pod et écrase ces modifications de configuration. Il est impossible de fusionner une nouvelle configuration avec la configuration existante.

Considérez l’approche config map si vous avez des besoins de configuration plus complexes.

Après avoir été installé, le plugin OpenShift Dedicated Sync surveille le serveur API d’OpenShift Dedicated pour les mises à jour des flux d’images, les balises de flux d’images et la configuration des cartes et ajuste la configuration du plugin Kubernetes.

Les règles suivantes s’appliquent:

  • La suppression de l’étiquette ou de l’annotation de la carte de configuration, du flux d’images ou de la balise de flux d’images supprime tout PodTemplate existant de la configuration du plugin Kubernetes.
  • Lorsque ces objets sont supprimés, la configuration correspondante est supprimée du plugin Kubernetes.
  • Lorsque vous créez des objets ConfigMap, ImageStream, ImageStream ou ImageStreamTag correctement étiquetés ou annotés, ou si vous ajoutez des étiquettes après leur création initiale, cela se traduit par la création d’un PodTemplate dans la configuration Kubernetes-plugin.
  • Dans le cas du PodTemplate par config map form, les modifications aux données de la carte de configuration pour le PodTemplate sont appliquées aux paramètres PodTemplate dans la configuration du plugin Kubernetes. Les modifications remplacent également les modifications apportées au PodTemplate via l’interface utilisateur de Jenkins entre les modifications apportées à la carte de configuration.

Afin d’utiliser une image conteneur comme agent Jenkins, l’image doit exécuter l’agent comme point d’entrée. Consultez la documentation officielle de Jenkins pour plus de détails.

Ressources supplémentaires

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