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 en utilisant Kubernetes et Red Hat OpenShift Service sur AWS.

Afin d’utiliser le plugin Kubernetes, Red Hat OpenShift Service sur AWS fournit une image OpenShift Agent Base qui convient à l’utilisation comme agent Jenkins.

Important

Le Red Hat OpenShift Service sur AWS 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 service OpenShift Red Hat sur le cycle de vie AWS. Auparavant, ces images figuraient dans le service Red Hat OpenShift sur AWS installer la charge utile et le référentiel openshift4 sur Registry.redhat.io.

Les images OpenShift Jenkins Maven et NodeJS Agent ont été retirées du Red Hat OpenShift Service sur AWS 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 conserve les versions 4.10 et précédentes de ces images pour tout correctif important de bug ou CVE de sécurité, en suivant le Red Hat OpenShift Service sur la stratégie de cycle de vie AWS.

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 le service OpenShift Red Hat sur AWS Jenkins configuration d’image 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é. Lorsque l’étiquette est appliquée, les tâches exécutées sous un service OpenShift Red Hat sur AWS pod exécutant l’image de l’agent respectif.

Important

Dans Red Hat OpenShift Service sur AWS 4.10 et versions ultérieures, 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 le Red Hat OpenShift Service sur l’image de l’agent AWS 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. Le Red Hat OpenShift Service sur AWS Jenkins image 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 Red Hat OpenShift Service sur AWS synchro plugin, 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 vous le faites après la création du modèle de pod, et que le service OpenShift Red Hat sur AWS Sync détecte que l’image associée au flux d’images ou à la balise de flux d’images 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 vous le faites après la création du modèle de pod, et que le service OpenShift Red Hat sur AWS Sync détecte que l’image associée au flux d’images ou à la balise de flux d’images 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 Red Hat OpenShift Service sur AWS Sync surveille le serveur API de Red Hat OpenShift Service sur AWS 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