5.3. Construction de pipelines
La stratégie de construction de pipelines est dépréciée dans Red Hat OpenShift Service sur AWS 4. Des fonctionnalités équivalentes et améliorées sont présentes dans le service OpenShift Red Hat sur AWS Pipelines basé sur Tekton.
Les images Jenkins sur Red Hat OpenShift Service sur AWS 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 Red Hat OpenShift Service sur AWS de la même manière que tout 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 Red Hat OpenShift Service sur les pipelines AWS Copier lienLien copié sur presse-papiers!
La stratégie de construction de pipelines est dépréciée dans Red Hat OpenShift Service sur AWS 4. Des fonctionnalités équivalentes et améliorées sont présentes dans le service OpenShift Red Hat sur AWS Pipelines basé sur Tekton.
Les images Jenkins sur Red Hat OpenShift Service sur AWS 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 Red Hat OpenShift Service sur AWS. En utilisant une combinaison de la stratégie de construction de Jenkins Pipeline, des jenkinsfiles et du service Red Hat OpenShift sur AWS Domain specific Language (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.
Le Red Hat OpenShift Service sur AWS Jenkins Sync Plugin
Le Red Hat OpenShift Service sur AWS Jenkins Sync Plugin maintient la configuration de construction et construit des objets en synchronisation avec les tâches et les builds Jenkins, et fournit ce qui suit:
- 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 le Red Hat OpenShift Service sur la console web AWS.
- Intégration avec le plugin Jenkins Git, qui passe les informations de Red Hat OpenShift Service sur AWS builds au plugin Jenkins Git.
- La synchronisation des secrets dans les entrées d’identification Jenkins.
Le Red Hat OpenShift Service sur AWS Jenkins Client Plugin
Le Red Hat OpenShift Service sur AWS Jenkins Client Plugin est un plugin Jenkins qui vise à fournir une syntaxe de pipeline Jenkins lisible, concise, complète et fluide pour des interactions riches avec un service OpenShift Red Hat sur AWS API Server. Le plugin utilise le service Red Hat OpenShift sur l’outil de ligne de commande AWS, oc, qui doit être disponible sur les nœuds exécutant le script.
Le plugin client Jenkins doit être installé sur votre maître Jenkins de sorte que le service Red Hat OpenShift sur AWS DSL sera disponible à utiliser dans le fichier jenkins pour votre application. Ce plugin est installé et activé par défaut lors de l’utilisation du service OpenShift Red Hat sur l’image AWS Jenkins.
En ce qui concerne Red Hat OpenShift Service sur AWS Pipelines dans votre projet, vous devez 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.
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.
5.3.2. Fournir le fichier Jenkins pour les constructions de pipelines Copier lienLien copié sur presse-papiers!
La stratégie de construction de pipelines est dépréciée dans Red Hat OpenShift Service sur AWS 4. Des fonctionnalités équivalentes et améliorées sont présentes dans le service OpenShift Red Hat sur AWS Pipelines basé sur Tekton.
Les images Jenkins sur Red Hat OpenShift Service sur AWS 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 jenkinsfile est exécuté sur le pod agent Jenkins, qui doit avoir le service OpenShift Red Hat sur les binaires clients AWS si vous avez l’intention d’utiliser le service OpenShift Red Hat sur AWS DSL.
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
La référence à Git Repository
- 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.
5.3.3. En utilisant des variables d’environnement pour les constructions de pipelines Copier lienLien copié sur presse-papiers!
La stratégie de construction de pipelines est dépréciée dans Red Hat OpenShift Service sur AWS 4. Des fonctionnalités équivalentes et améliorées sont présentes dans le service OpenShift Red Hat sur AWS Pipelines basé sur Tekton.
Les images Jenkins sur Red Hat OpenShift Service sur AWS 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"
jenkinsPipelineStrategy: ... env: - name: "FOO" value: "BAR"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Il est également possible de gérer les variables d’environnement définies dans la configuration de build avec la commande oc set env.
5.3.3.1. Cartographie entre les variables d’environnement BuildConfig et les paramètres de travail Jenkins Copier lienLien copié sur presse-papiers!
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.
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 Copier lienLien copié sur presse-papiers!
La stratégie de construction de pipelines est dépréciée dans Red Hat OpenShift Service sur AWS 4. Des fonctionnalités équivalentes et améliorées sont présentes dans le service OpenShift Red Hat sur AWS Pipelines basé sur Tekton.
Les images Jenkins sur Red Hat OpenShift Service sur AWS 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 service Red Hat OpenShift sur AWS Pipeline qui va construire, déployer et vérifier une application Node.js/MongoDB en utilisant le modèle nodejs-mongodb.json.
Procédure
Créer le maître Jenkins:
oc project <project_name>
$ oc project <project_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Choisissez le projet que vous souhaitez utiliser ou créez un nouveau projet avec oc new-project <project_name>.
oc new-app jenkins-ephemeral
$ oc new-app jenkins-ephemeral
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow À la place, si vous souhaitez utiliser un stockage persistant, utilisez des jenkins-persistents.
Créez un fichier nommé nodejs-sample-pipeline.yaml avec le contenu suivant:
NoteCela 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.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Après avoir créé un objet BuildConfig avec un jenkinsPipelineStrategy, dites au pipeline quoi faire en utilisant un jenkinsfile en ligne:
NoteCet exemple ne met pas en place un référentiel Git pour l’application.
Le contenu jenkinsfile suivant est écrit dans Groovy en utilisant le service Red Hat OpenShift sur AWS 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.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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.
NoteL’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.
Créez le Pipeline BuildConfig dans votre Red Hat OpenShift Service sur AWS cluster:
oc create -f nodejs-sample-pipeline.yaml
$ oc create -f nodejs-sample-pipeline.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/jenkins/pipeline/nodejs-sample-pipeline.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Démarrez le pipeline:
oc start-build nodejs-sample-pipeline
$ oc start-build nodejs-sample-pipeline
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteAlternativement, vous pouvez démarrer votre pipeline avec le service Red Hat OpenShift sur la console Web AWS 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.
NoteLa meilleure façon de visualiser l’exécution du pipeline est de l’afficher dans le Red Hat OpenShift Service sur la console web AWS. Consultez vos pipelines en vous connectant à la console Web et en naviguant vers Builds
Pipelines.