Jenkins

Il est possible de gérer l’authentification Jenkins de deux manières:

Le serveur Jenkins peut être configuré avec les variables d’environnement suivantes:

Jenkins Si vous allez exécuter Jenkins ailleurs que votre même projet, vous devez fournir un jeton d’accès à Jenkins pour accéder à votre projet.

L’image Jenkins peut être exécutée avec des volumes montés pour permettre un stockage persistant pour la configuration:

Afin de personnaliser le service officiel Red Hat OpenShift sur l’image AWS Jenkins, vous pouvez utiliser l’image comme constructeur source-à-image (S2I).

Il est possible d’utiliser S2I pour copier vos définitions de tâches Jenkins personnalisées, ajouter des plugins supplémentaires ou remplacer le fichier config.xml fourni par votre propre configuration personnalisée.

Afin d’inclure vos modifications dans l’image Jenkins, vous devez disposer d’un référentiel Git avec la structure de répertoire suivante:

pluginId:pluginVersion

pluginId:pluginVersion

Le contenu du répertoire configuration/ est copié dans le répertoire /var/lib/jenkins/, de sorte que vous pouvez également inclure des fichiers supplémentaires, tels que Credentials.xml, là-bas.

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: custom-jenkins-build
spec:
  source:                       
    git:
      uri: https://github.com/custom/repository
    type: Git
  strategy:                     
    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: jenkins:2
        namespace: openshift
    type: Source
  output:                       
    to:
      kind: ImageStreamTag
      name: custom-jenkins:latest

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: custom-jenkins-build
spec:
  source:                       

    git:
      uri: https://github.com/custom/repository
    type: Git
  strategy:                     

    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: jenkins:2
        namespace: openshift
    type: Source
  output:                       

    to:
      kind: ImageStreamTag
      name: custom-jenkins:latest

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.

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.

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:

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.

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.

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>

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>

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>

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>

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:

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.

Dans la carte de configuration, l’élément <serviceAccount> du modèle de pod XML est le service OpenShift Red Hat sur le compte de service AWS utilisé pour la pod résultante, les identifiants de compte de service sont montés dans le pod. Les autorisations sont associées au compte de service et contrôlent quelles opérations contre le service OpenShift Red Hat sur AWS Master sont autorisées à partir du pod.

Considérez le scénario suivant avec les comptes de service utilisés pour le pod, qui est lancé par le plugin Kubernetes qui fonctionne dans le Red Hat OpenShift Service sur l’image AWS Jenkins.

Lorsque vous utilisez le modèle d’exemple pour Jenkins fourni par Red Hat OpenShift Service sur AWS, le compte de service jenkins est défini avec le rôle d’édition du projet Jenkins s’exécute, et le maître Jenkins pod a ce compte de service monté.

Les deux modèles de pod Maven et NodeJS par défaut qui sont injectés dans la configuration Jenkins sont également configurés pour utiliser le même compte de service que le maître Jenkins.

Les modèles fournissent des champs de paramètres pour définir toutes les variables d’environnement avec des valeurs par défaut prédéfinies. Le service Red Hat OpenShift sur AWS fournit des modèles pour faciliter la création d’un nouveau service Jenkins. Les modèles Jenkins doivent être enregistrés dans le projet openshift par défaut par l’administrateur de votre cluster lors de la configuration initiale du cluster.

Les deux modèles disponibles définissent à la fois la configuration de déploiement et un service. Les modèles diffèrent dans leur stratégie de stockage, ce qui affecte si le contenu de Jenkins persiste à travers le redémarrage du pod.

Afin d’utiliser un magasin PV, l’administrateur du cluster doit définir un pool PV dans le Red Hat OpenShift Service sur le déploiement AWS.

Après avoir sélectionné le modèle que vous voulez, vous devez instancier le modèle pour pouvoir utiliser Jenkins.

Avec les deux modèles, vous pouvez exécuter oc décrire sur eux pour voir tous les paramètres disponibles pour l’écrasement.

À titre d’exemple:

oc describe jenkins-ephemeral

$ oc describe jenkins-ephemeral

Dans l’exemple suivant, l’objet BuildConfig d’openshift-jee-sample provoque la mise à disposition dynamique d’un pod d’agent Jenkins Maven. Le pod clone un certain code source Java, construit un fichier WAR et provoque un second BuildConfig, openshift-jee-sample-docker à exécuter. Le second BuildConfig couche le nouveau fichier WAR dans une image de conteneur.

kind: List
apiVersion: v1
items:
- kind: ImageStream
  apiVersion: image.openshift.io/v1
  metadata:
    name: openshift-jee-sample
- kind: BuildConfig
  apiVersion: build.openshift.io/v1
  metadata:
    name: openshift-jee-sample-docker
  spec:
    strategy:
      type: Docker
    source:
      type: Docker
      dockerfile: |-
        FROM openshift/wildfly-101-centos7:latest
        COPY ROOT.war /wildfly/standalone/deployments/ROOT.war
        CMD $STI_SCRIPTS_PATH/run
      binary:
        asFile: ROOT.war
    output:
      to:
        kind: ImageStreamTag
        name: openshift-jee-sample:latest
- kind: BuildConfig
  apiVersion: build.openshift.io/v1
  metadata:
    name: openshift-jee-sample
  spec:
    strategy:
      type: JenkinsPipeline
      jenkinsPipelineStrategy:
        jenkinsfile: |-
          node("maven") {
            sh "git clone https://github.com/openshift/openshift-jee-sample.git ."
            sh "mvn -B -Popenshift package"
            sh "oc start-build -F openshift-jee-sample-docker --from-file=target/ROOT.war"
          }
    triggers:
    - type: ConfigChange

kind: List
apiVersion: v1
items:
- kind: ImageStream
  apiVersion: image.openshift.io/v1
  metadata:
    name: openshift-jee-sample
- kind: BuildConfig
  apiVersion: build.openshift.io/v1
  metadata:
    name: openshift-jee-sample-docker
  spec:
    strategy:
      type: Docker
    source:
      type: Docker
      dockerfile: |-
        FROM openshift/wildfly-101-centos7:latest
        COPY ROOT.war /wildfly/standalone/deployments/ROOT.war
        CMD $STI_SCRIPTS_PATH/run
      binary:
        asFile: ROOT.war
    output:
      to:
        kind: ImageStreamTag
        name: openshift-jee-sample:latest
- kind: BuildConfig
  apiVersion: build.openshift.io/v1
  metadata:
    name: openshift-jee-sample
  spec:
    strategy:
      type: JenkinsPipeline
      jenkinsPipelineStrategy:
        jenkinsfile: |-
          node("maven") {
            sh "git clone https://github.com/openshift/openshift-jee-sample.git ."
            sh "mvn -B -Popenshift package"
            sh "oc start-build -F openshift-jee-sample-docker --from-file=target/ROOT.war"
          }
    triggers:
    - type: ConfigChange

Il est également possible de remplacer la spécification du pod d’agent Jenkins créé dynamiquement. Ce qui suit est une modification de l’exemple précédent, qui remplace la mémoire du conteneur et spécifie une variable d’environnement.

kind: BuildConfig
apiVersion: build.openshift.io/v1
metadata:
  name: openshift-jee-sample
spec:
  strategy:
    type: JenkinsPipeline
    jenkinsPipelineStrategy:
      jenkinsfile: |-
        podTemplate(label: "mypod", 
                    cloud: "openshift", 
                    inheritFrom: "maven", 
                    containers: [
            containerTemplate(name: "jnlp", 
                              image: "openshift/jenkins-agent-maven-35-centos7:v3.10", 
                              resourceRequestMemory: "512Mi", 
                              resourceLimitMemory: "512Mi", 
                              envVars: [
              envVar(key: "CONTAINER_HEAP_PERCENT", value: "0.25") 
            ])
          ]) {
          node("mypod") { 
            sh "git clone https://github.com/openshift/openshift-jee-sample.git ."
            sh "mvn -B -Popenshift package"
            sh "oc start-build -F openshift-jee-sample-docker --from-file=target/ROOT.war"
          }
        }
  triggers:
  - type: ConfigChange

kind: BuildConfig
apiVersion: build.openshift.io/v1
metadata:
  name: openshift-jee-sample
spec:
  strategy:
    type: JenkinsPipeline
    jenkinsPipelineStrategy:
      jenkinsfile: |-
        podTemplate(label: "mypod", 

                    cloud: "openshift", 

                    inheritFrom: "maven", 

                    containers: [
            containerTemplate(name: "jnlp", 

                              image: "openshift/jenkins-agent-maven-35-centos7:v3.10", 

                              resourceRequestMemory: "512Mi", 

                              resourceLimitMemory: "512Mi", 

                              envVars: [
              envVar(key: "CONTAINER_HEAP_PERCENT", value: "0.25") 

            ])
          ]) {
          node("mypod") { 

            sh "git clone https://github.com/openshift/openshift-jee-sample.git ."
            sh "mvn -B -Popenshift package"
            sh "oc start-build -F openshift-jee-sample-docker --from-file=target/ROOT.war"
          }
        }
  triggers:
  - type: ConfigChange

Le pod est supprimé par défaut lorsque la construction est terminée. Ce comportement peut être modifié avec le plugin ou dans un pipeline Jenkinsfile.

En amont Jenkins a récemment introduit un format déclaratif YAML pour définir un pipeline podTemplate DSL en ligne avec vos pipelines. Exemple de ce format, en utilisant l’échantillon java-builder pod modèle qui est défini dans le Red Hat OpenShift Service sur l’image AWS Jenkins:

def nodeLabel = 'java-buidler'

pipeline {
  agent {
    kubernetes {
      cloud 'openshift'
      label nodeLabel
      yaml """
apiVersion: v1
kind: Pod
metadata:
  labels:
    worker: ${nodeLabel}
spec:
  containers:
  - name: jnlp
    image: image-registry.openshift-image-registry.svc:5000/openshift/jenkins-agent-base-rhel8:latest
    args: ['\$(JENKINS_SECRET)', '\$(JENKINS_NAME)']
  - name: java
    image: image-registry.openshift-image-registry.svc:5000/openshift/java:latest
    command:
    - cat
    tty: true
"""
    }
  }

  options {
    timeout(time: 20, unit: 'MINUTES')
  }

  stages {
    stage('Build App') {
      steps {
        container("java") {
          sh "mvn --version"
        }
     }
    }
  }
}

def nodeLabel = 'java-buidler'

pipeline {
  agent {
    kubernetes {
      cloud 'openshift'
      label nodeLabel
      yaml """
apiVersion: v1
kind: Pod
metadata:
  labels:
    worker: ${nodeLabel}
spec:
  containers:
  - name: jnlp
    image: image-registry.openshift-image-registry.svc:5000/openshift/jenkins-agent-base-rhel8:latest
    args: ['\$(JENKINS_SECRET)', '\$(JENKINS_NAME)']
  - name: java
    image: image-registry.openshift-image-registry.svc:5000/openshift/java:latest
    command:
    - cat
    tty: true
"""
    }
  }

  options {
    timeout(time: 20, unit: 'MINUTES')
  }

  stages {
    stage('Build App') {
      steps {
        container("java") {
          sh "mvn --version"
        }
     }
    }
  }
}

Lorsqu’il est déployé par les modèles Jenkins Ephemeral ou Jenkins Persistent fournis, la limite de mémoire par défaut est de 1 Gi.

Par défaut, tous les autres processus qui s’exécutent dans le conteneur Jenkins ne peuvent pas utiliser plus de 512 MiB de mémoire. En cas de besoin de plus de mémoire, le conteneur s’arrête. Il est donc fortement recommandé que les pipelines exécutent des commandes externes dans un conteneur d’agent dans la mesure du possible.

Et si les quotas du projet le permettent, consultez les recommandations de la documentation Jenkins sur ce qu’un maître Jenkins devrait avoir du point de vue de la mémoire. Ces recommandations proscrivent d’allouer encore plus de mémoire au maître Jenkins.

Il est recommandé de spécifier la requête de mémoire et les valeurs limites sur les conteneurs d’agent créés par le plugin Jenkins Kubernetes. Les utilisateurs admin peuvent définir des valeurs par défaut sur une base d’image par agent via la configuration Jenkins. Les paramètres de requête et de limite de mémoire peuvent également être annulés sur une base par conteneur.

Il est possible d’augmenter la quantité de mémoire disponible pour Jenkins en surmontant le paramètre MEMORY_LIMIT lors de l’instanciation du modèle Jenkins Ephemeral ou Jenkins Persistent.

Les images de l’agent de Red Hat OpenShift sur AWS Jenkins sont disponibles sur Quay.io ou Registry.redhat.io.

Les images de Jenkins sont disponibles via le Registre Red Hat:

docker pull registry.redhat.io/ocp-tools-4/jenkins-rhel8:<image_tag>

$ docker pull registry.redhat.io/ocp-tools-4/jenkins-rhel8:<image_tag>

docker pull registry.redhat.io/ocp-tools-4/jenkins-agent-base-rhel8:<image_tag>

$ docker pull registry.redhat.io/ocp-tools-4/jenkins-agent-base-rhel8:<image_tag>

Afin d’utiliser ces images, vous pouvez y accéder directement à partir de Quay.io ou Register.redhat.io ou les pousser dans votre service Red Hat OpenShift sur le registre des images conteneur AWS.

Chaque conteneur d’agent Jenkins peut être configuré avec les variables d’environnement suivantes.

JVM est utilisé dans tous les agents Jenkins pour héberger l’agent Jenkins JNLP ainsi que pour exécuter toutes les applications Java telles que javac, Maven ou Gradle.

Le Jenkins JNLP agent JVM utilise 50% de la limite de mémoire du conteneur pour son tas. Cette valeur peut être modifiée par la variable d’environnement CONTAINER_HEAP_PERCENT. Il peut également être plafonné à une limite supérieure ou dépassé entièrement.

Par défaut, tous les autres processus exécutés dans le conteneur d’agent Jenkins, tels que les scripts shell ou les commandes oc exécutées à partir de pipelines, ne peuvent pas utiliser plus de la limite de mémoire de 50% restante sans provoquer une destruction OOM.

Chaque autre processus JVM qui s’exécute dans un conteneur d’agent Jenkins utilise jusqu’à 25% de la limite de mémoire du conteneur pour son tas. Il pourrait être nécessaire d’ajuster cette limite pour de nombreuses charges de travail de construction.

Hébergement Gradle construit dans l’agent Jenkins sur Red Hat OpenShift Service sur AWS présente des complications supplémentaires car en plus de l’agent Jenkins JNLP et Gradle JVM, Gradle génère un troisième JVM pour exécuter des tests s’ils sont spécifiés.

Les paramètres suivants sont suggérés comme point de départ pour exécuter Gradle builds dans un agent Jenkins limité à la mémoire sur Red Hat OpenShift Service sur AWS. Ces paramètres peuvent être modifiés au besoin.

Les pods d’agent Jenkins sont supprimés par défaut une fois la construction terminée ou arrêtée. Ce comportement peut être modifié par le paramètre de rétention de la pod du plugin Kubernetes. La rétention de pod peut être définie pour toutes les constructions Jenkins, avec des dépassements pour chaque modèle de pod. Les comportements suivants sont pris en charge:

Il est possible de remplacer la rétention des pods dans le pipeline Jenkinsfile:

podTemplate(label: "mypod",
  cloud: "openshift",
  inheritFrom: "maven",
  podRetention: onFailure(), 
  containers: [
    ...
  ]) {
  node("mypod") {
    ...
  }
}

podTemplate(label: "mypod",
  cloud: "openshift",
  inheritFrom: "maven",
  podRetention: onFailure(), 

  containers: [
    ...
  ]) {
  node("mypod") {
    ...
  }
}

Consultez et comparez les termes équivalents suivants utilisés dans Jenkins et OpenShift Pipelines.

Les exemples équivalents suivants vous permettent de migrer vos pipelines de construction, de tester et de déployer des pipelines de Jenkins vers OpenShift Pipelines.

pipeline {
   agent any
   stages {
       stage('Build') {
           steps {
               sh 'make'
           }
       }
       stage('Test'){
           steps {
               sh 'make check'
               junit 'reports/**/*.xml'
           }
       }
       stage('Deploy') {
           steps {
               sh 'make publish'
           }
       }
   }
}

pipeline {
   agent any
   stages {
       stage('Build') {
           steps {
               sh 'make'
           }
       }
       stage('Test'){
           steps {
               sh 'make check'
               junit 'reports/**/*.xml'
           }
       }
       stage('Deploy') {
           steps {
               sh 'make publish'
           }
       }
   }
}

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: myproject-build
spec:
  workspaces:
  - name: source
  steps:
  - image: my-ci-image
    command: ["make"]
    workingDir: $(workspaces.source.path)

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: myproject-build
spec:
  workspaces:
  - name: source
  steps:
  - image: my-ci-image
    command: ["make"]
    workingDir: $(workspaces.source.path)

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: myproject-test
spec:
  workspaces:
  - name: source
  steps:
  - image: my-ci-image
    command: ["make check"]
    workingDir: $(workspaces.source.path)
  - image: junit-report-image
    script: |
      #!/usr/bin/env bash
      junit-report reports/**/*.xml
    workingDir: $(workspaces.source.path)

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: myproject-test
spec:
  workspaces:
  - name: source
  steps:
  - image: my-ci-image
    command: ["make check"]
    workingDir: $(workspaces.source.path)
  - image: junit-report-image
    script: |
      #!/usr/bin/env bash
      junit-report reports/**/*.xml
    workingDir: $(workspaces.source.path)

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: myprojectd-deploy
spec:
  workspaces:
  - name: source
  steps:
  - image: my-deploy-image
    command: ["make deploy"]
    workingDir: $(workspaces.source.path)

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: myprojectd-deploy
spec:
  workspaces:
  - name: source
  steps:
  - image: my-deploy-image
    command: ["make deploy"]
    workingDir: $(workspaces.source.path)

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: myproject-pipeline
spec:
  workspaces:
  - name: shared-dir
  tasks:
  - name: build
    taskRef:
      name: myproject-build
    workspaces:
    - name: source
      workspace: shared-dir
  - name: test
    taskRef:
      name: myproject-test
    workspaces:
    - name: source
      workspace: shared-dir
  - name: deploy
    taskRef:
      name: myproject-deploy
    workspaces:
    - name: source
      workspace: shared-dir

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: myproject-pipeline
spec:
  workspaces:
  - name: shared-dir
  tasks:
  - name: build
    taskRef:
      name: myproject-build
    workspaces:
    - name: source
      workspace: shared-dir
  - name: test
    taskRef:
      name: myproject-test
    workspaces:
    - name: source
      workspace: shared-dir
  - name: deploy
    taskRef:
      name: myproject-deploy
    workspaces:
    - name: source
      workspace: shared-dir

Il est possible d’étendre la capacité de Jenkins en utilisant des plugins. Afin d’obtenir une extensibilité similaire dans les pipelines OpenShift, utilisez l’une des tâches disponibles sur Tekton Hub.

À titre d’exemple, considérez la tâche git-clone dans Tekton Hub, qui correspond au plugin git pour Jenkins.

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
 name: demo-pipeline
spec:
 params:
   - name: repo_url
   - name: revision
 workspaces:
   - name: source
 tasks:
   - name: fetch-from-git
     taskRef:
       name: git-clone
     params:
       - name: url
         value: $(params.repo_url)
       - name: revision
         value: $(params.revision)
     workspaces:
     - name: output
       workspace: source

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
 name: demo-pipeline
spec:
 params:
   - name: repo_url
   - name: revision
 workspaces:
   - name: source
 tasks:
   - name: fetch-from-git
     taskRef:
       name: git-clone
     params:
       - name: url
         value: $(params.repo_url)
       - name: revision
         value: $(params.revision)
     workspaces:
     - name: output
       workspace: source

Dans OpenShift Pipelines, si vous ne trouvez pas la bonne tâche dans Tekton Hub, ou si vous avez besoin d’un plus grand contrôle sur les tâches, vous pouvez créer des tâches et des scripts personnalisés pour étendre les capacités d’OpenShift Pipelines.

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: maven-test
spec:
  workspaces:
  - name: source
  steps:
  - image: my-maven-image
    command: ["mvn test"]
    workingDir: $(workspaces.source.path)

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: maven-test
spec:
  workspaces:
  - name: source
  steps:
  - image: my-maven-image
    command: ["mvn test"]
    workingDir: $(workspaces.source.path)

...
steps:
  image: ubuntu
  script: |
      #!/usr/bin/env bash
      /workspace/my-script.sh
...

...
steps:
  image: ubuntu
  script: |
      #!/usr/bin/env bash
      /workspace/my-script.sh
...

...
steps:
  image: python
  script: |
      #!/usr/bin/env python3
      print(“hello from python!”)
...

...
steps:
  image: python
  script: |
      #!/usr/bin/env python3
      print(“hello from python!”)
...

Jenkins et OpenShift Pipelines offrent des fonctions similaires, mais sont différentes en architecture et en exécution.

Jenkins et OpenShift Pipelines offrent des capacités pour les cas communs d’utilisation CI/CD, tels que:

#!/usr/bin/groovy
node('maven') {
    stage 'Checkout'
    checkout scm

    stage 'Build'
    sh 'cd helloworld && mvn clean'
    sh 'cd helloworld && mvn compile'

    stage 'Run Unit Tests'
    sh 'cd helloworld && mvn test'

    stage 'Package'
    sh 'cd helloworld && mvn package'

    stage 'Archive artifact'
    sh 'mkdir -p artifacts/deployments && cp helloworld/target/*.war artifacts/deployments'
    archive 'helloworld/target/*.war'

    stage 'Create Image'
    sh 'oc login https://kubernetes.default -u admin -p admin --insecure-skip-tls-verify=true'
    sh 'oc new-project helloworldproject'
    sh 'oc project helloworldproject'
    sh 'oc process -f helloworld/jboss-eap70-binary-build.json | oc create -f -'
    sh 'oc start-build eap-helloworld-app --from-dir=artifacts/'

    stage 'Deploy'
    sh 'oc new-app helloworld/jboss-eap70-deploy.json' }

#!/usr/bin/groovy
node('maven') {
    stage 'Checkout'
    checkout scm

    stage 'Build'
    sh 'cd helloworld && mvn clean'
    sh 'cd helloworld && mvn compile'

    stage 'Run Unit Tests'
    sh 'cd helloworld && mvn test'

    stage 'Package'
    sh 'cd helloworld && mvn package'

    stage 'Archive artifact'
    sh 'mkdir -p artifacts/deployments && cp helloworld/target/*.war artifacts/deployments'
    archive 'helloworld/target/*.war'

    stage 'Create Image'
    sh 'oc login https://kubernetes.default -u admin -p admin --insecure-skip-tls-verify=true'
    sh 'oc new-project helloworldproject'
    sh 'oc project helloworldproject'
    sh 'oc process -f helloworld/jboss-eap70-binary-build.json | oc create -f -'
    sh 'oc start-build eap-helloworld-app --from-dir=artifacts/'

    stage 'Deploy'
    sh 'oc new-app helloworld/jboss-eap70-deploy.json' }

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: maven-pipeline
spec:
  workspaces:
    - name: shared-workspace
    - name: maven-settings
    - name: kubeconfig-dir
      optional: true
  params:
    - name: repo-url
    - name: revision
    - name: context-path
  tasks:
    - name: fetch-repo
      taskRef:
        name: git-clone
      workspaces:
        - name: output
          workspace: shared-workspace
      params:
        - name: url
          value: "$(params.repo-url)"
        - name: subdirectory
          value: ""
        - name: deleteExisting
          value: "true"
        - name: revision
          value: $(params.revision)
    - name: mvn-build
      taskRef:
        name: maven
      runAfter:
        - fetch-repo
      workspaces:
        - name: source
          workspace: shared-workspace
        - name: maven-settings
          workspace: maven-settings
      params:
        - name: CONTEXT_DIR
          value: "$(params.context-path)"
        - name: GOALS
          value: ["-DskipTests", "clean", "compile"]
    - name: mvn-tests
      taskRef:
        name: maven
      runAfter:
        - mvn-build
      workspaces:
        - name: source
          workspace: shared-workspace
        - name: maven-settings
          workspace: maven-settings
      params:
        - name: CONTEXT_DIR
          value: "$(params.context-path)"
        - name: GOALS
          value: ["test"]
    - name: mvn-package
      taskRef:
        name: maven
      runAfter:
        - mvn-tests
      workspaces:
        - name: source
          workspace: shared-workspace
        - name: maven-settings
          workspace: maven-settings
      params:
        - name: CONTEXT_DIR
          value: "$(params.context-path)"
        - name: GOALS
          value: ["package"]
    - name: create-image-and-deploy
      taskRef:
        name: openshift-client
      runAfter:
        - mvn-package
      workspaces:
        - name: manifest-dir
          workspace: shared-workspace
        - name: kubeconfig-dir
          workspace: kubeconfig-dir
      params:
        - name: SCRIPT
          value: |
            cd "$(params.context-path)"
            mkdir -p ./artifacts/deployments && cp ./target/*.war ./artifacts/deployments
            oc new-project helloworldproject
            oc project helloworldproject
            oc process -f jboss-eap70-binary-build.json | oc create -f -
            oc start-build eap-helloworld-app --from-dir=artifacts/
            oc new-app jboss-eap70-deploy.json

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: maven-pipeline
spec:
  workspaces:
    - name: shared-workspace
    - name: maven-settings
    - name: kubeconfig-dir
      optional: true
  params:
    - name: repo-url
    - name: revision
    - name: context-path
  tasks:
    - name: fetch-repo
      taskRef:
        name: git-clone
      workspaces:
        - name: output
          workspace: shared-workspace
      params:
        - name: url
          value: "$(params.repo-url)"
        - name: subdirectory
          value: ""
        - name: deleteExisting
          value: "true"
        - name: revision
          value: $(params.revision)
    - name: mvn-build
      taskRef:
        name: maven
      runAfter:
        - fetch-repo
      workspaces:
        - name: source
          workspace: shared-workspace
        - name: maven-settings
          workspace: maven-settings
      params:
        - name: CONTEXT_DIR
          value: "$(params.context-path)"
        - name: GOALS
          value: ["-DskipTests", "clean", "compile"]
    - name: mvn-tests
      taskRef:
        name: maven
      runAfter:
        - mvn-build
      workspaces:
        - name: source
          workspace: shared-workspace
        - name: maven-settings
          workspace: maven-settings
      params:
        - name: CONTEXT_DIR
          value: "$(params.context-path)"
        - name: GOALS
          value: ["test"]
    - name: mvn-package
      taskRef:
        name: maven
      runAfter:
        - mvn-tests
      workspaces:
        - name: source
          workspace: shared-workspace
        - name: maven-settings
          workspace: maven-settings
      params:
        - name: CONTEXT_DIR
          value: "$(params.context-path)"
        - name: GOALS
          value: ["package"]
    - name: create-image-and-deploy
      taskRef:
        name: openshift-client
      runAfter:
        - mvn-package
      workspaces:
        - name: manifest-dir
          workspace: shared-workspace
        - name: kubeconfig-dir
          workspace: kubeconfig-dir
      params:
        - name: SCRIPT
          value: |
            cd "$(params.context-path)"
            mkdir -p ./artifacts/deployments && cp ./target/*.war ./artifacts/deployments
            oc new-project helloworldproject
            oc project helloworldproject
            oc process -f jboss-eap70-binary-build.json | oc create -f -
            oc start-build eap-helloworld-app --from-dir=artifacts/
            oc new-app jboss-eap70-deploy.json

Le service Red Hat OpenShift sur AWS 4.11 apporte des changements importants à l’emplacement et à la disponibilité d’images spécifiques d’OpenShift Jenkins. De plus, vous pouvez configurer quand et comment mettre à jour ces images.

Auparavant, chaque image de Jenkins ne supportait qu’une seule version de Red Hat OpenShift Service sur AWS et Red Hat pouvait mettre à jour ces images de manière séquentielle au fil du temps.

À propos des nouvelles balises de flux d’images:

Cependant, l’opérateur d’échantillons de cluster ne supprime pas les flux d’images jenkins-agent-maven et jenkins-agent-nodejs créés par des versions antérieures, qui pointent vers les balises du service OpenShift Red Hat respectif sur les images de charge utile AWS sur register.redhat.io. Ainsi, vous pouvez tirer les mises à jour de ces images en exécutant les commandes suivantes:

oc import-image jenkins-agent-nodejs -n openshift

$ oc import-image jenkins-agent-nodejs -n openshift

oc import-image jenkins-agent-maven -n openshift

$ oc import-image jenkins-agent-maven -n openshift

Afin de remplacer le comportement de mise à niveau par défaut et de contrôler la mise à niveau de l’image Jenkins, vous définissez la valeur de balise de flux d’image que vos configurations de déploiement Jenkins utilisent.

Le comportement de mise à niveau par défaut est le comportement qui existait lorsque l’image Jenkins faisait partie de la charge utile d’installation. Les noms de balises de flux d’images, 2 et ocp-upgrade-redeploy, dans le fichier de flux d’images jenkins-rhel.json utilisent des références d’image spécifiques à SHA. Ainsi, lorsque ces balises sont mises à jour avec un nouveau SHA, le Red Hat OpenShift Service sur le contrôleur de changement d’image AWS redéploie automatiquement la configuration de déploiement de Jenkins à partir des modèles associés, tels que jenkins-ephemeral.json ou jenkins-persistent.json.

Dans le cas de nouveaux déploiements, pour remplacer cette valeur par défaut, vous modifiez la valeur du modèle JENKINS_IMAGE_STREAM_TAG dans le modèle jenkins-ephemeral.json Jenkins. À titre d’exemple, remplacer le 2 dans "valeur": "jenkins:2" par l’une des balises de flux d’images suivantes: