5.3. Construction de pipelines


Important

La stratégie de construction du pipeline est dépréciée dans OpenShift Dedicated 4. Des fonctionnalités équivalentes et améliorées sont présentes dans les pipelines dédiés OpenShift basés sur Tekton.

Les images Jenkins sur OpenShift Dedicated sont entièrement prises en charge et les utilisateurs doivent suivre la documentation utilisateur de Jenkins pour définir leur fichier jenkins dans un travail ou le stocker dans un système de gestion de contrôle de source.

La stratégie de construction Pipeline permet aux développeurs de définir un pipeline Jenkins pour une utilisation par le plugin pipeline Jenkins. La construction peut être démarrée, surveillée et gérée par OpenShift Dedicated de la même manière que n’importe quel autre type de construction.

Les flux de travail de pipeline sont définis dans un fichier jenkins, soit intégrés directement dans la configuration de construction, soit fournis dans un référentiel Git et référencés par la configuration de construction.

5.3.1. Comprendre les pipelines dédiés à OpenShift

Important

La stratégie de construction du pipeline est dépréciée dans OpenShift Dedicated 4. Des fonctionnalités équivalentes et améliorées sont présentes dans les pipelines dédiés OpenShift basés sur Tekton.

Les images Jenkins sur OpenShift Dedicated sont entièrement prises en charge et les utilisateurs doivent suivre la documentation utilisateur de Jenkins pour définir leur fichier jenkins dans un travail ou le stocker dans un système de gestion de contrôle de source.

Les pipelines vous donnent le contrôle de la construction, du déploiement et de la promotion de vos applications sur OpenShift Dedicated. En utilisant une combinaison de la stratégie de construction de Jenkins Pipeline, des jenkinsfiles et du langage spécifique de domaine dédié OpenShift (DSL) fourni par le plugin client Jenkins, vous pouvez créer une construction avancée, tester, déployer et promouvoir des pipelines pour n’importe quel scénario.

Jenkins Sync Plugin dédié à OpenShift

Le plugin de synchronisation Jenkins dédié OpenShift maintient la configuration de construction et construit des objets en synchronisation avec les tâches et les builds Jenkins, et fournit les éléments suivants:

  • Création dynamique d’emplois et de gestion à Jenkins.
  • Création dynamique de modèles de pod d’agent à partir de flux d’images, de balises de flux d’images ou de configuration de cartes.
  • Injection de variables d’environnement.
  • La visualisation de pipeline dans la console Web dédiée OpenShift.
  • Intégration avec le plugin Jenkins Git, qui passe des informations de commit depuis OpenShift Dedicated builds au plugin Jenkins Git.
  • La synchronisation des secrets dans les entrées d’identification Jenkins.

Jenkins Client Plugin dédié à OpenShift

Le plugin client Jenkins dédié OpenShift est un plugin Jenkins qui vise à fournir une syntaxe de pipeline Jenkins lisible, concise, complète et fluide pour des interactions riches avec un serveur API dédié OpenShift. Le plugin utilise l’outil de ligne de commande OpenShift Dedicated, oc, qui doit être disponible sur les nœuds exécutant le script.

Le plugin client Jenkins doit être installé sur votre master Jenkins afin que le DSL dédié OpenShift soit disponible à utiliser dans le fichier jenkins pour votre application. Ce plugin est installé et activé par défaut lors de l’utilisation de l’image OpenShift Dedicated Jenkins.

Dans le cas des pipelines dédiés à OpenShift dans votre projet, vous devrez utiliser la stratégie de construction de pipelines Jenkins. Cette stratégie par défaut à l’utilisation d’un jenkinsfile à la racine de votre référentiel source, mais fournit également les options de configuration suivantes:

  • Le champ jenkinsfile en ligne dans votre configuration de construction.
  • Champ jenkinsfilePath dans votre configuration de construction qui fait référence à l’emplacement du jenkinsfile à utiliser par rapport au contexte sourceDir.
Note

Le champ jenkinsfilePath optionnel spécifie le nom du fichier à utiliser, par rapport au contexte sourceDir. En cas d’omission de contextDir, il par défaut à la racine du référentiel. En cas d’omission de jenkinsfilePath, il devient jenkinsfile par défaut.

Important

La stratégie de construction du pipeline est dépréciée dans OpenShift Dedicated 4. Des fonctionnalités équivalentes et améliorées sont présentes dans les pipelines dédiés OpenShift basés sur Tekton.

Les images Jenkins sur OpenShift Dedicated sont entièrement prises en charge et les utilisateurs doivent suivre la documentation utilisateur de Jenkins pour définir leur fichier jenkins dans un travail ou le stocker dans un système de gestion de contrôle de source.

Le jenkinsfile utilise la syntaxe standard du langage groovy pour permettre un contrôle fin de la configuration, de la construction et du déploiement de votre application.

Il est possible de fournir le jenkinsfile de l’une des façons suivantes:

  • Fichier situé dans votre référentiel de code source.
  • Intégré dans le cadre de votre configuration de build en utilisant le champ jenkinsfile.

Lors de l’utilisation de la première option, le jenkinsfile doit être inclus dans le référentiel de code source de vos applications à l’un des endroits suivants:

  • Fichier nommé jenkinsfile à la racine de votre référentiel.
  • Fichier nommé jenkinsfile à la racine du contexte sourceDir de votre référentiel.
  • Le nom de fichier spécifié via le champ jenkinsfilePath de la section JenkinsPipelineStrategy de votre BuildConfig, qui est relatif au contexte sourceDir si fourni, sinon il par défaut à la racine du référentiel.

Le fichier jenkinsfile est exécuté sur le pod d’agent Jenkins, qui doit avoir les binaires du client OpenShift Dedicated si vous avez l’intention d’utiliser le DSL dédié OpenShift.

Procédure

Afin de fournir le fichier Jenkins, vous pouvez soit:

  • Intégrez le fichier Jenkins dans la configuration de construction.
  • Inclure dans la configuration de construction une référence au référentiel Git qui contient le fichier Jenkins.

Définition intégrée

kind: "BuildConfig"
apiVersion: "v1"
metadata:
  name: "sample-pipeline"
spec:
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfile: |-
        node('agent') {
          stage 'build'
          openshiftBuild(buildConfig: 'ruby-sample-build', showBuildLogs: 'true')
          stage 'deploy'
          openshiftDeploy(deploymentConfig: 'frontend')
        }
Copy to Clipboard Toggle word wrap

La référence à Git Repository

kind: "BuildConfig"
apiVersion: "v1"
metadata:
  name: "sample-pipeline"
spec:
  source:
    git:
      uri: "https://github.com/openshift/ruby-hello-world"
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfilePath: some/repo/dir/filename 
1
Copy to Clipboard Toggle word wrap

1
Le champ jenkinsfilePath optionnel spécifie le nom du fichier à utiliser, par rapport au contexte sourceDir. En cas d’omission de contextDir, il par défaut à la racine du référentiel. En cas d’omission de jenkinsfilePath, il devient jenkinsfile par défaut.
Important

La stratégie de construction du pipeline est dépréciée dans OpenShift Dedicated 4. Des fonctionnalités équivalentes et améliorées sont présentes dans les pipelines dédiés OpenShift basés sur Tekton.

Les images Jenkins sur OpenShift Dedicated sont entièrement prises en charge et les utilisateurs doivent suivre la documentation utilisateur de Jenkins pour définir leur fichier jenkins dans un travail ou le stocker dans un système de gestion de contrôle de source.

Afin de rendre les variables d’environnement disponibles pour le processus de construction de pipelines, vous pouvez ajouter des variables d’environnement à la définition jenkinsPipelineStrategy de la configuration de construction.

Les variables d’environnement seront définies comme paramètres pour n’importe quel travail Jenkins associé à la configuration de construction.

Procédure

  • Afin de définir les variables d’environnement à utiliser pendant la construction, modifiez le fichier YAML:

    jenkinsPipelineStrategy:
    ...
      env:
        - name: "FOO"
          value: "BAR"
    Copy to Clipboard Toggle word wrap

Il est également possible de gérer les variables d’environnement définies dans la configuration de build avec la commande oc set env.

Lorsqu’un travail Jenkins est créé ou mis à jour en fonction des modifications apportées à une configuration de construction de stratégie de pipeline, toutes les variables d’environnement de la configuration de construction sont cartographiées aux définitions des paramètres de travail Jenkins, où les valeurs par défaut pour les définitions des paramètres de travail Jenkins sont les valeurs actuelles des variables d’environnement associées.

Après la création initiale de l’emploi Jenkins, vous pouvez toujours ajouter des paramètres supplémentaires à la tâche à partir de la console Jenkins. Les noms des paramètres diffèrent des noms des variables d’environnement dans la configuration de construction. Les paramètres sont honorés lorsque les constructions sont lancées pour ces emplois Jenkins.

La façon dont vous démarrez des builds pour le travail Jenkins dicte comment les paramètres sont définis.

  • Lorsque vous démarrez avec oc start-build, les valeurs des variables d’environnement dans la configuration de build sont les paramètres définis pour l’instance de travail correspondante. Les modifications que vous apportez aux valeurs par défaut des paramètres de la console Jenkins sont ignorées. Les valeurs de configuration de build ont préséance.
  • Lorsque vous démarrez avec oc start-build -e, les valeurs pour les variables d’environnement spécifiées dans l’option -e ont préséance.

    • Lorsque vous spécifiez une variable d’environnement non listée dans la configuration de construction, elles seront ajoutées sous forme de définitions de paramètres de travail Jenkins.
    • Les modifications que vous apportez de la console Jenkins aux paramètres correspondant aux variables d’environnement sont ignorées. La configuration de la construction et ce que vous spécifiez avec oc start-build -e ont préséance.
  • Lorsque vous démarrez le travail Jenkins avec la console Jenkins, vous pouvez contrôler le réglage des paramètres avec la console Jenkins dans le cadre du démarrage d’une construction pour le travail.
Note

Il est recommandé de spécifier dans la configuration de construction toutes les variables d’environnement possibles à associer aux paramètres de travail. Cela réduit les E/S sur disque et améliore les performances pendant le traitement de Jenkins.

5.3.4. Didacticiel de construction de pipeline

Important

La stratégie de construction du pipeline est dépréciée dans OpenShift Dedicated 4. Des fonctionnalités équivalentes et améliorées sont présentes dans les pipelines dédiés OpenShift basés sur Tekton.

Les images Jenkins sur OpenShift Dedicated sont entièrement prises en charge et les utilisateurs doivent suivre la documentation utilisateur de Jenkins pour définir leur fichier jenkins dans un travail ou le stocker dans un système de gestion de contrôle de source.

Cet exemple montre comment créer un pipeline dédié OpenShift qui va construire, déployer et vérifier une application Node.js/MongoDB en utilisant le modèle nodejs-mongodb.json.

Procédure

  1. Créer le maître Jenkins:

      $ oc project <project_name>
    Copy to Clipboard Toggle word wrap

    Choisissez le projet que vous souhaitez utiliser ou créez un nouveau projet avec oc new-project &lt;project_name&gt;.

      $ oc new-app jenkins-ephemeral 
    1
    Copy to Clipboard Toggle word wrap

    À la place, si vous souhaitez utiliser un stockage persistant, utilisez des jenkins-persistents.

  2. Créez un fichier nommé nodejs-sample-pipeline.yaml avec le contenu suivant:

    Note

    Cela crée un objet BuildConfig qui utilise la stratégie de pipeline Jenkins pour construire, déployer et mettre à l’échelle l’application d’exemple Node.js/MongoDB.

    kind: "BuildConfig"
    apiVersion: "v1"
    metadata:
      name: "nodejs-sample-pipeline"
    spec:
      strategy:
        jenkinsPipelineStrategy:
          jenkinsfile: <pipeline content from below>
        type: JenkinsPipeline
    Copy to Clipboard Toggle word wrap
  3. Après avoir créé un objet BuildConfig avec un jenkinsPipelineStrategy, dites au pipeline quoi faire en utilisant un jenkinsfile en ligne:

    Note

    Cet exemple ne met pas en place un référentiel Git pour l’application.

    Le contenu jenkinsfile suivant est écrit dans Groovy en utilisant OpenShift Dedicated DSL. Dans cet exemple, incluez du contenu en ligne dans l’objet BuildConfig en utilisant le style YAML Literal, bien que l’inclusion d’un fichier jenkins dans votre référentiel source soit la méthode préférée.

    def templatePath = 'https://raw.githubusercontent.com/openshift/nodejs-ex/master/openshift/templates/nodejs-mongodb.json' 
    1
    
    def templateName = 'nodejs-mongodb-example' 
    2
    
    pipeline {
      agent {
        node {
          label 'nodejs' 
    3
    
        }
      }
      options {
        timeout(time: 20, unit: 'MINUTES') 
    4
    
      }
      stages {
        stage('preamble') {
            steps {
                script {
                    openshift.withCluster() {
                        openshift.withProject() {
                            echo "Using project: ${openshift.project()}"
                        }
                    }
                }
            }
        }
        stage('cleanup') {
          steps {
            script {
                openshift.withCluster() {
                    openshift.withProject() {
                      openshift.selector("all", [ template : templateName ]).delete() 
    5
    
                      if (openshift.selector("secrets", templateName).exists()) { 
    6
    
                        openshift.selector("secrets", templateName).delete()
                      }
                    }
                }
            }
          }
        }
        stage('create') {
          steps {
            script {
                openshift.withCluster() {
                    openshift.withProject() {
                      openshift.newApp(templatePath) 
    7
    
                    }
                }
            }
          }
        }
        stage('build') {
          steps {
            script {
                openshift.withCluster() {
                    openshift.withProject() {
                      def builds = openshift.selector("bc", templateName).related('builds')
                      timeout(5) { 
    8
    
                        builds.untilEach(1) {
                          return (it.object().status.phase == "Complete")
                        }
                      }
                    }
                }
            }
          }
        }
        stage('deploy') {
          steps {
            script {
                openshift.withCluster() {
                    openshift.withProject() {
                      def rm = openshift.selector("dc", templateName).rollout()
                      timeout(5) { 
    9
    
                        openshift.selector("dc", templateName).related('pods').untilEach(1) {
                          return (it.object().status.phase == "Running")
                        }
                      }
                    }
                }
            }
          }
        }
        stage('tag') {
          steps {
            script {
                openshift.withCluster() {
                    openshift.withProject() {
                      openshift.tag("${templateName}:latest", "${templateName}-staging:latest") 
    10
    
                    }
                }
            }
          }
        }
      }
    }
    Copy to Clipboard Toggle word wrap
    1
    Chemin du modèle à utiliser.
    1 2
    Le nom du modèle qui sera créé.
    3
    Lancez un pod d’agent node.js sur lequel exécuter cette construction.
    4
    Fixez un délai de 20 minutes pour ce pipeline.
    5
    Effacer tout avec cette étiquette de modèle.
    6
    Effacer tous les secrets avec cette étiquette de modèle.
    7
    Créez une nouvelle application à partir du templatePath.
    8
    Attendez jusqu’à cinq minutes pour que la construction soit terminée.
    9
    Attendez jusqu’à cinq minutes pour que le déploiement se termine.
    10
    Lorsque tout le reste réussit, marquez $ {templateName}:dernière image comme $ {templateName}-staging:lastest. La configuration de construction de pipeline pour l’environnement de mise en scène peut regarder pour $ {templateName}-staging:dernière image à changer, puis la déployer dans l’environnement de mise en scène.
    Note

    L’exemple précédent a été écrit en utilisant le style de pipeline déclaratif, mais l’ancien style de pipeline scripté est également pris en charge.

  4. Créez le Pipeline BuildConfig dans votre cluster OpenShift dédié:

    $ oc create -f nodejs-sample-pipeline.yaml
    Copy to Clipboard Toggle word wrap
    1. Dans le cas où vous ne souhaitez pas créer votre propre fichier, vous pouvez utiliser l’échantillon du référentiel Origin en exécutant:

      $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/jenkins/pipeline/nodejs-sample-pipeline.yaml
      Copy to Clipboard Toggle word wrap
  5. Démarrez le pipeline:

    $ oc start-build nodejs-sample-pipeline
    Copy to Clipboard Toggle word wrap
    Note

    Alternativement, vous pouvez démarrer votre pipeline avec la console Web dédiée OpenShift en naviguant vers la section Builds Pipeline et en cliquant sur Démarrer le pipeline, ou en visitant la console Jenkins, en naviguant vers le pipeline que vous avez créé, et en cliquant sur Construire maintenant.

    Lorsque le pipeline est lancé, vous devriez voir les actions suivantes effectuées dans le cadre de votre projet:

    • L’instance d’emploi est créée sur le serveur Jenkins.
    • La gousse d’agent est lancée, si votre pipeline en a besoin.
    • Le pipeline coule sur la gousse d’agent, ou le capitaine si aucun agent n’est requis.

      • Les ressources précédemment créées avec l’étiquette template=nodejs-mongodb-example seront supprimées.
      • Le modèle nodejs-mongodb-exemple de nodejs-mongodb-exemple créera une nouvelle application et toutes ses ressources associées.
      • La construction sera lancée à l’aide de l’exemple nodejs-mongodb BuildConfig.

        • Le pipeline attendra jusqu’à ce que la construction soit terminée pour déclencher la prochaine étape.
      • Le déploiement sera lancé à l’aide de la configuration de déploiement nodejs-mongodb-exemple.

        • Le pipeline attendra jusqu’à ce que le déploiement soit terminé pour déclencher la prochaine étape.
      • En cas de succès de la construction et du déploiement, l’image nodejs-mongodb-example:dernière image sera marquée comme nodejs-mongodb-example:stage.
    • La gousse d’agent est supprimée, si l’on en avait besoin pour le pipeline.

      Note

      La meilleure façon de visualiser l’exécution du pipeline est de l’afficher dans la console Web dédiée OpenShift. Consultez vos pipelines en vous connectant à la console Web et en naviguant vers Builds Pipelines.

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