2.5. Utiliser des stratégies de construction
Les sections suivantes définissent les principales stratégies de construction prises en charge et expliquent comment les utiliser.
2.5.1. Construction Docker Copier lienLien copié sur presse-papiers!
OpenShift Container Platform utilise Buildah pour construire une image de conteneur à partir d'un fichier Docker. Pour plus d'informations sur la construction d'images de conteneurs avec des Dockerfiles, voir la documentation de référence Dockerfile.
Si vous définissez les arguments de construction de Docker en utilisant le tableau buildArgs
, voir Comprendre comment ARG et FROM interagissent dans la documentation de référence de Dockerfile.
2.5.1.1. Remplacer le fichier Dockerfile de l'image Copier lienLien copié sur presse-papiers!
Vous pouvez remplacer l'instruction FROM
du fichier Docker par l'instruction from
de l'objet BuildConfig
. Si le fichier Docker utilise des constructions en plusieurs étapes, l'image de la dernière instruction FROM
sera remplacée.
Procédure
Pour remplacer l'instruction FROM
du fichier Docker par l'instruction from
du fichier BuildConfig
.
strategy: dockerStrategy: from: kind: "ImageStreamTag" name: "debian:latest"
strategy:
dockerStrategy:
from:
kind: "ImageStreamTag"
name: "debian:latest"
2.5.1.2. Utilisation du chemin d'accès au fichier Docker Copier lienLien copié sur presse-papiers!
Par défaut, les constructions Docker utilisent un Dockerfile situé à la racine du contexte spécifié dans le champ BuildConfig.spec.source.contextDir
.
Le champ dockerfilePath
permet au build d'utiliser un chemin différent pour localiser votre Dockerfile, par rapport au champ BuildConfig.spec.source.contextDir
. Il peut s'agir d'un nom de fichier différent du Dockerfile par défaut, comme MyDockerfile
, ou d'un chemin vers un Dockerfile dans un sous-répertoire, comme dockerfiles/app1/Dockerfile
.
Procédure
Pour utiliser le champ dockerfilePath
afin que le build utilise un chemin différent pour localiser votre Dockerfile, définissez :
strategy: dockerStrategy: dockerfilePath: dockerfiles/app1/Dockerfile
strategy:
dockerStrategy:
dockerfilePath: dockerfiles/app1/Dockerfile
2.5.1.3. Utiliser les variables d'environnement de Docker Copier lienLien copié sur presse-papiers!
Pour rendre les variables d'environnement disponibles au processus de construction de docker et à l'image résultante, vous pouvez ajouter des variables d'environnement à la définition dockerStrategy
de la configuration de construction.
Les variables d'environnement qui y sont définies sont insérées sous la forme d'une seule instruction ENV
Dockerfile juste après l'instruction FROM
, de sorte qu'elles puissent être référencées ultérieurement dans le Dockerfile.
Procédure
Les variables sont définies lors de la construction et restent dans l'image de sortie, elles seront donc également présentes dans tout conteneur qui exécute cette image.
Par exemple, la définition d'un proxy HTTP personnalisé à utiliser lors de la construction et de l'exécution :
dockerStrategy: ... env: - name: "HTTP_PROXY" value: "http://myproxy.net:5187/"
dockerStrategy:
...
env:
- name: "HTTP_PROXY"
value: "http://myproxy.net:5187/"
Vous pouvez également gérer les variables d'environnement définies dans la configuration de construction à l'aide de la commande oc set env
.
2.5.1.4. Ajouter des arguments de construction de docker Copier lienLien copié sur presse-papiers!
Vous pouvez définir les arguments de construction de docker en utilisant le tableau buildArgs
. Les arguments de construction sont transmis à docker lorsqu'une construction est lancée.
Voir Comprendre comment ARG et FROM interagissent dans la documentation de référence Dockerfile.
Procédure
Pour définir les arguments de construction de docker, ajoutez des entrées au tableau buildArgs
, qui se trouve dans la définition dockerStrategy
de l'objet BuildConfig
. Par exemple :
dockerStrategy: ... buildArgs: - name: "foo" value: "bar"
dockerStrategy:
...
buildArgs:
- name: "foo"
value: "bar"
Seuls les champs name
et value
sont pris en charge. Les paramètres du champ valueFrom
sont ignorés.
2.5.1.5. La réduction des couches avec les constructions de dockers Copier lienLien copié sur presse-papiers!
Les constructions Docker créent normalement une couche représentant chaque instruction dans un Dockerfile. En définissant imageOptimizationPolicy
sur SkipLayers
, on fusionne toutes les instructions en une seule couche au-dessus de l'image de base.
Procédure
Réglez le site
imageOptimizationPolicy
surSkipLayers
:strategy: dockerStrategy: imageOptimizationPolicy: SkipLayers
strategy: dockerStrategy: imageOptimizationPolicy: SkipLayers
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.1.6. Utilisation des volumes de construction Copier lienLien copié sur presse-papiers!
Vous pouvez monter des volumes de construction pour permettre aux constructions en cours d'accéder aux informations que vous ne souhaitez pas conserver dans l'image du conteneur de sortie.
Les volumes de construction fournissent des informations sensibles, telles que les références du référentiel, dont l'environnement de construction ou la configuration n'a besoin qu'au moment de la construction. Les volumes de construction sont différents des entrées de construction, dont les données peuvent persister dans l'image du conteneur de sortie.
Les points de montage des volumes de construction, à partir desquels la construction en cours lit les données, sont fonctionnellement similaires aux montages des volumes de pods.
Conditions préalables
Procédure
Dans la définition
dockerStrategy
de l'objetBuildConfig
, ajoutez tous les volumes de construction au tableauvolumes
. Par exemple :Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1 5 9
- Obligatoire. Un nom unique.
- 2 6 10
- Obligatoire. Le chemin absolu du point de montage. Il ne doit pas contenir
..
ou:
et ne doit pas entrer en conflit avec le chemin de destination généré par le constructeur./opt/app-root/src
est le répertoire d'accueil par défaut pour de nombreuses images Red Hat S2I. - 3 7 11
- Obligatoire. Le type de source,
ConfigMap
,Secret
, ouCSI
. - 4 8
- Obligatoire. Le nom de la source.
- 12
- Nécessaire. Le pilote qui fournit le volume CSI éphémère.
- 13
- Obligatoire. Cette valeur doit être définie sur
true
. Fournit un volume en lecture seule. - 14
- Facultatif. Les attributs de volume du volume CSI éphémère. Consultez la documentation du pilote CSI pour connaître les clés et les valeurs des attributs pris en charge.
Le pilote CSI pour ressources partagées est pris en charge en tant que fonction d'aperçu technologique.
2.5.2. Construction de la source à l'image Copier lienLien copié sur presse-papiers!
Source-to-image (S2I) est un outil permettant de créer des images de conteneurs reproductibles. Il produit des images prêtes à l'emploi en injectant la source d'une application dans une image de conteneur et en assemblant une nouvelle image. La nouvelle image incorpore l'image de base, le constructeur et la source construite et est prête à être utilisée avec la commande buildah run
. S2I prend en charge les constructions incrémentielles, qui réutilisent les dépendances téléchargées précédemment, les artefacts construits précédemment, etc.
2.5.2.1. Effectuer des constructions incrémentielles de source à image Copier lienLien copié sur presse-papiers!
Source-to-image (S2I) peut effectuer des constructions incrémentielles, ce qui signifie qu'il réutilise les artefacts des images construites précédemment.
Procédure
Pour créer une construction incrémentielle, créez une stratégie avec la modification suivante de la définition de la stratégie :
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Spécifiez une image qui prend en charge les constructions incrémentielles. Consultez la documentation de l'image du constructeur pour savoir si elle prend en charge ce comportement.
- 2
- Cette option permet de contrôler si une construction incrémentale est tentée. Si l'image du constructeur ne prend pas en charge les constructions incrémentielles, la construction réussira quand même, mais vous obtiendrez un message indiquant que la construction incrémentielle n'a pas réussi à cause d'un script
save-artifacts
manquant.
2.5.2.2. Remplacer les scripts d'image du constructeur de sources par des scripts d'image du constructeur d'images Copier lienLien copié sur presse-papiers!
Vous pouvez remplacer les scripts source-image (S2I) assemble
, run
et save-artifacts
fournis par l'image de construction.
Procédure
Pour remplacer les scripts S2I assemble
, run
, et save-artifacts
fournis par l'image du constructeur, il faut soit :
-
Fournissez un script
assemble
,run
ousave-artifacts
dans le répertoire.s2i/bin
du référentiel des sources de votre application. Fournir l'URL d'un répertoire contenant les scripts dans le cadre de la définition de la stratégie. Par exemple :
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ce chemin sera complété par
run
,assemble
, etsave-artifacts
. Si l'un ou tous les scripts sont trouvés, ils seront utilisés à la place des scripts du même nom fournis dans l'image.
Les fichiers situés à l'URL scripts
sont prioritaires sur les fichiers situés à l'URL .s2i/bin
du référentiel source.
2.5.2.3. Variables d'environnement source-image Copier lienLien copié sur presse-papiers!
Il existe deux façons de mettre les variables d'environnement à la disposition du processus de compilation des sources et de l'image qui en résulte. Les fichiers d'environnement et les valeurs d'environnement BuildConfig. Les variables fournies seront présentes lors du processus de construction et dans l'image de sortie.
2.5.2.3.1. Utilisation de fichiers d'environnement source-image Copier lienLien copié sur presse-papiers!
Source build vous permet de définir des valeurs d'environnement, une par ligne, à l'intérieur de votre application, en les spécifiant dans un fichier .s2i/environment
dans le dépôt de sources. Les variables d'environnement spécifiées dans ce fichier sont présentes pendant le processus de construction et dans l'image de sortie.
Si vous fournissez un fichier .s2i/environment
dans votre dépôt de sources, source-to-image (S2I) lit ce fichier pendant la construction. Cela permet de personnaliser le comportement de la compilation, car le script assemble
peut utiliser ces variables.
Procédure
Par exemple, pour désactiver la compilation des actifs pour votre application Rails pendant la construction :
-
Ajouter
DISABLE_ASSET_COMPILATION=true
dans le fichier.s2i/environment
.
En plus des builds, les variables d'environnement spécifiées sont également disponibles dans l'application en cours d'exécution. Par exemple, pour que l'application Rails démarre en mode development
au lieu de production
:
-
Ajouter
RAILS_ENV=development
au fichier.s2i/environment
.
La liste complète des variables d'environnement prises en charge est disponible dans la section "Utilisation des images" pour chaque image.
2.5.2.3.2. Utilisation de l'environnement de configuration de la construction source-image Copier lienLien copié sur presse-papiers!
Vous pouvez ajouter des variables d'environnement à la définition sourceStrategy
de la configuration de construction. Les variables d'environnement définies à cet endroit sont visibles lors de l'exécution du script assemble
et seront définies dans l'image de sortie, ce qui les rend également disponibles pour le script run
et le code de l'application.
Procédure
Par exemple, pour désactiver la compilation des actifs pour votre application Rails :
sourceStrategy: ... env: - name: "DISABLE_ASSET_COMPILATION" value: "true"
sourceStrategy: ... env: - name: "DISABLE_ASSET_COMPILATION" value: "true"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.2.4. Ignorer les fichiers source à image Copier lienLien copié sur presse-papiers!
Source-to-image (S2I) prend en charge un fichier .s2iignore
, qui contient une liste de modèles de fichiers à ignorer. Les fichiers du répertoire de travail de la compilation, tels qu'ils sont fournis par les différentes sources d'entrée, qui correspondent à un modèle trouvé dans le fichier .s2iignore
ne seront pas mis à la disposition du script assemble
.
2.5.2.5. Créer des images à partir du code source avec source-to-image Copier lienLien copié sur presse-papiers!
Source-to-image (S2I) est un cadre qui facilite l'écriture d'images qui prennent le code source d'une application en entrée et produisent une nouvelle image qui exécute l'application assemblée en sortie.
Le principal avantage de l'utilisation de S2I pour la construction d'images de conteneurs reproductibles est la facilité d'utilisation pour les développeurs. En tant qu'auteur d'une image de construction, vous devez comprendre deux concepts de base pour que vos images offrent les meilleures performances S2I : le processus de construction et les scripts S2I.
2.5.2.5.1. Comprendre le processus de construction de la source à l'image Copier lienLien copié sur presse-papiers!
Le processus de construction se compose des trois éléments fondamentaux suivants, qui sont combinés pour former une image finale du conteneur :
- Sources d'information
- Scripts source-image (S2I)
- Image du constructeur
S2I génère un Dockerfile avec l'image du constructeur comme première instruction FROM
. Le fichier Docker généré par S2I est ensuite transmis à Buildah.
2.5.2.5.2. Comment écrire des scripts source-image ? Copier lienLien copié sur presse-papiers!
Vous pouvez écrire des scripts source-image (S2I) dans n'importe quel langage de programmation, à condition que les scripts soient exécutables dans l'image du constructeur. S2I prend en charge plusieurs options fournissant des scripts assemble
/run
/save-artifacts
. Tous ces emplacements sont vérifiés lors de chaque compilation dans l'ordre suivant :
- Un script spécifié dans la configuration de la construction.
-
Un script trouvé dans le répertoire source de l'application
.s2i/bin
. -
Un script trouvé à l'URL de l'image par défaut avec l'étiquette
io.openshift.s2i.scripts-url
.
L'étiquette io.openshift.s2i.scripts-url
spécifiée dans l'image et le script spécifié dans une configuration de compilation peuvent prendre l'une des formes suivantes :
-
image:///path_to_scripts_dir
chemin absolu à l'intérieur de l'image vers un répertoire où se trouvent les scripts S2I. -
file:///path_to_scripts_dir
chemin d'accès : chemin relatif ou absolu vers un répertoire de l'hôte où se trouvent les scripts S2I. -
http(s)://path_to_scripts_dir
: URL d'un répertoire où se trouvent les scripts S2I.
Le scénario | Description |
---|---|
|
Le script
|
|
Le script |
|
Le script
Ces dépendances sont rassemblées dans un fichier |
|
Le script |
|
Le script
Note
L'emplacement suggéré pour placer l'application de test construite par votre script |
Example S2I scripts
Les exemples de scripts S2I suivants sont écrits en Bash. Chaque exemple suppose que le contenu de tar
est décompressé dans le répertoire /tmp/s2i
.
assemble
le scénario :
run
le scénario :
run the application
#!/bin/bash
# run the application
/opt/application/run.sh
save-artifacts
le scénario :
usage
le scénario :
2.5.2.6. Utilisation des volumes de construction Copier lienLien copié sur presse-papiers!
Vous pouvez monter des volumes de construction pour permettre aux constructions en cours d'accéder aux informations que vous ne souhaitez pas conserver dans l'image du conteneur de sortie.
Les volumes de construction fournissent des informations sensibles, telles que les références du référentiel, dont l'environnement de construction ou la configuration n'a besoin qu'au moment de la construction. Les volumes de construction sont différents des entrées de construction, dont les données peuvent persister dans l'image du conteneur de sortie.
Les points de montage des volumes de construction, à partir desquels la construction en cours lit les données, sont fonctionnellement similaires aux montages des volumes de pods.
Conditions préalables
Procédure
Dans la définition
sourceStrategy
de l'objetBuildConfig
, ajoutez tous les volumes de construction au tableauvolumes
. Par exemple :Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 1 5 9
- Obligatoire. Un nom unique.
- 2 6 10
- Obligatoire. Le chemin absolu du point de montage. Il ne doit pas contenir
..
ou:
et ne doit pas entrer en conflit avec le chemin de destination généré par le constructeur./opt/app-root/src
est le répertoire d'accueil par défaut pour de nombreuses images Red Hat S2I. - 3 7 11
- Obligatoire. Le type de source,
ConfigMap
,Secret
, ouCSI
. - 4 8
- Obligatoire. Le nom de la source.
- 12
- Nécessaire. Le pilote qui fournit le volume CSI éphémère.
- 13
- Obligatoire. Cette valeur doit être définie sur
true
. Fournit un volume en lecture seule. - 14
- Facultatif. Les attributs de volume du volume CSI éphémère. Consultez la documentation du pilote CSI pour connaître les clés et les valeurs des attributs pris en charge.
Le pilote CSI pour ressources partagées est pris en charge en tant que fonction d'aperçu technologique.
2.5.3. Construction sur mesure Copier lienLien copié sur presse-papiers!
La stratégie de construction personnalisée permet aux développeurs de définir une image de constructeur spécifique responsable de l'ensemble du processus de construction. L'utilisation de votre propre image de constructeur vous permet de personnaliser votre processus de construction.
Une image de construction personnalisée est une image conteneur simple incorporant la logique du processus de construction, par exemple pour construire des RPM ou des images de base.
Les builds personnalisés sont exécutés avec un niveau de privilège élevé et ne sont pas accessibles aux utilisateurs par défaut. Seuls les utilisateurs à qui l'on peut faire confiance en leur accordant des autorisations d'administration de cluster doivent avoir accès à l'exécution des builds personnalisés.
2.5.3.1. Utilisation de l'image FROM pour des constructions personnalisées Copier lienLien copié sur presse-papiers!
Vous pouvez utiliser la section customStrategy.from
pour indiquer l'image à utiliser pour la construction personnalisée
Procédure
Définir la section
customStrategy.from
:strategy: customStrategy: from: kind: "DockerImage" name: "openshift/sti-image-builder"
strategy: customStrategy: from: kind: "DockerImage" name: "openshift/sti-image-builder"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.3.2. Utilisation des secrets dans les constructions personnalisées Copier lienLien copié sur presse-papiers!
Outre les secrets pour les sources et les images qui peuvent être ajoutés à tous les types de construction, les stratégies personnalisées permettent d'ajouter une liste arbitraire de secrets au module de construction.
Procédure
Pour monter chaque secret à un emplacement spécifique, modifiez les champs
secretSource
etmountPath
du fichier YAMLstrategy
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.3.3. Utilisation de variables d'environnement pour des constructions personnalisées Copier lienLien copié sur presse-papiers!
Pour mettre les variables d'environnement à la disposition du processus de compilation personnalisé, vous pouvez ajouter des variables d'environnement à la définition customStrategy
de la configuration de compilation.
Les variables d'environnement qui y sont définies sont transmises au pod qui exécute la construction personnalisée.
Procédure
Définir un proxy HTTP personnalisé à utiliser lors de la construction :
customStrategy: ... env: - name: "HTTP_PROXY" value: "http://myproxy.net:5187/"
customStrategy: ... env: - name: "HTTP_PROXY" value: "http://myproxy.net:5187/"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pour gérer les variables d'environnement définies dans la configuration de la compilation, entrez la commande suivante :
oc set env <enter_variables> $ oc set env <enter_variables>
oc set env <enter_variables> $ oc set env <enter_variables>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.3.4. Utilisation des images personnalisées du constructeur Copier lienLien copié sur presse-papiers!
La stratégie de construction personnalisée d'OpenShift Container Platform vous permet de définir une image de construction spécifique responsable de l'ensemble du processus de construction. Lorsque vous avez besoin d'un build pour produire des artefacts individuels tels que des packages, des JAR, des WAR, des ZIP installables ou des images de base, utilisez une image de constructeur personnalisée à l'aide de la stratégie de build personnalisée.
Une image de construction personnalisée est une image de conteneur simple incorporant la logique du processus de construction, qui est utilisée pour construire des artefacts tels que des RPM ou des images de conteneur de base.
En outre, le constructeur personnalisé permet de mettre en œuvre n'importe quel processus de construction étendu, tel qu'un flux CI/CD qui exécute des tests unitaires ou d'intégration.
2.5.3.4.1. Image personnalisée du constructeur Copier lienLien copié sur presse-papiers!
Lors de son invocation, une image de constructeur personnalisé reçoit les variables d'environnement suivantes avec les informations nécessaires pour procéder à la construction :
Nom de la variable | Description |
---|---|
|
L'intégralité du JSON sérialisé de la définition de l'objet |
| L'URL d'un dépôt Git contenant les sources à construire. |
|
Utilise la même valeur que |
| Spécifie le sous-répertoire du dépôt Git à utiliser lors de la construction. Uniquement présent s'il est défini. |
| La référence Git à construire. |
| La version du master OpenShift Container Platform qui a créé cet objet de construction. |
| Le registre de l'image du conteneur dans lequel l'image doit être transférée. |
| Le nom de l'étiquette de l'image du conteneur pour l'image en cours de construction. |
|
Chemin d'accès aux informations d'identification du registre des conteneurs pour l'exécution d'une opération |
2.5.3.4.2. Flux de travail des constructeurs personnalisés Copier lienLien copié sur presse-papiers!
Bien que les auteurs d'images de construction personnalisées aient une certaine flexibilité dans la définition du processus de construction, votre image de construction doit respecter les étapes suivantes nécessaires à l'exécution d'une construction au sein d'OpenShift Container Platform :
-
La définition de l'objet
Build
contient toutes les informations nécessaires sur les paramètres d'entrée de la construction. - Exécuter le processus de construction.
- Si votre compilation produit une image, poussez-la dans l'emplacement de sortie de la compilation s'il est défini. D'autres emplacements de sortie peuvent être passés avec des variables d'environnement.
2.5.4. Construction d'un pipeline Copier lienLien copié sur presse-papiers!
La stratégie de construction Pipeline est obsolète dans OpenShift Container Platform 4. Des fonctionnalités équivalentes et améliorées sont présentes dans les Pipelines d'OpenShift Container Platform basés sur Tekton.
Les images Jenkins sur OpenShift Container Platform sont entièrement prises en charge et les utilisateurs doivent suivre la documentation utilisateur de Jenkins pour définir leur jenkinsfile
dans un travail ou le stocker dans un système de gestion du contrôle de la source.
La stratégie de construction Pipeline permet aux développeurs de définir un pipeline Jenkins qui sera utilisé par le plugin Jenkins pipeline. Le build peut être démarré, surveillé et géré par OpenShift Container Platform de la même manière que n'importe quel autre type de build.
Les flux de travail du pipeline sont définis dans un site jenkinsfile
, soit directement intégré dans la configuration de construction, soit fourni dans un dépôt Git et référencé par la configuration de construction.
2.5.4.1. Comprendre les pipelines de la plateforme de conteneurs OpenShift Copier lienLien copié sur presse-papiers!
La stratégie de construction Pipeline est obsolète dans OpenShift Container Platform 4. Des fonctionnalités équivalentes et améliorées sont présentes dans les Pipelines d'OpenShift Container Platform basés sur Tekton.
Les images Jenkins sur OpenShift Container Platform sont entièrement prises en charge et les utilisateurs doivent suivre la documentation utilisateur de Jenkins pour définir leur jenkinsfile
dans un travail ou le stocker dans un système de gestion du contrôle de la source.
Les pipelines vous permettent de contrôler la construction, le déploiement et la promotion de vos applications sur OpenShift Container Platform. En combinant la stratégie de construction Jenkins Pipeline, jenkinsfiles
, et le langage spécifique au domaine OpenShift Container Platform (DSL) fourni par le plugin client Jenkins, vous pouvez créer des pipelines avancés de construction, de test, de déploiement et de promotion pour n'importe quel scénario.
OpenShift Container Platform Jenkins Sync Plugin
Le plugin Jenkins Sync d'OpenShift Container Platform maintient la configuration et les objets de construction synchronisés avec les travaux et les constructions Jenkins, et fournit les éléments suivants :
- Création dynamique de tâches et d'exécutions dans Jenkins.
- Création dynamique de modèles de pods d'agents à partir de flux d'images, de balises de flux d'images ou de cartes de configuration.
- Injection de variables d'environnement.
- Visualisation du pipeline dans la console web de OpenShift Container Platform.
- Intégration avec le plugin Jenkins Git, qui transmet les informations de commit des builds d'OpenShift Container Platform au plugin Jenkins Git.
- Synchronisation des secrets dans les entrées de justificatifs Jenkins.
OpenShift Container Platform Jenkins Client Plugin
Le plugin client Jenkins d'OpenShift Container Platform 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'OpenShift Container Platform. Le plugin utilise l'outil de ligne de commande d'OpenShift Container Platform, oc
, qui doit être disponible sur les nœuds exécutant le script.
Le plugin Jenkins Client doit être installé sur votre master Jenkins afin que le DSL OpenShift Container Platform soit disponible pour être utilisé dans le site jenkinsfile
pour votre application. Ce plugin est installé et activé par défaut lors de l'utilisation de l'image Jenkins d'OpenShift Container Platform.
Pour les Pipelines OpenShift Container Platform dans votre projet, vous devez utiliser la stratégie de construction de Pipeline Jenkins. Cette stratégie utilise par défaut une adresse jenkinsfile
à la racine de votre référentiel source, mais fournit également les options de configuration suivantes :
-
Un champ en ligne
jenkinsfile
dans votre configuration de construction. -
Un champ
jenkinsfilePath
dans votre configuration de construction qui référence l'emplacement dejenkinsfile
à utiliser par rapport à la sourcecontextDir
.
Le champ facultatif jenkinsfilePath
indique le nom du fichier à utiliser, par rapport à la source contextDir
. Si contextDir
est omis, la valeur par défaut est la racine du référentiel. Si jenkinsfilePath
est omis, la valeur par défaut est jenkinsfile
.
2.5.4.2. Fournir le fichier Jenkins pour les constructions de pipelines Copier lienLien copié sur presse-papiers!
La stratégie de construction Pipeline est obsolète dans OpenShift Container Platform 4. Des fonctionnalités équivalentes et améliorées sont présentes dans les Pipelines d'OpenShift Container Platform basés sur Tekton.
Les images Jenkins sur OpenShift Container Platform sont entièrement prises en charge et les utilisateurs doivent suivre la documentation utilisateur de Jenkins pour définir leur jenkinsfile
dans un travail ou le stocker dans un système de gestion du contrôle de la source.
Le site jenkinsfile
utilise la syntaxe standard du langage groovy pour permettre un contrôle précis de la configuration, de la construction et du déploiement de votre application.
Vous pouvez fournir le site jenkinsfile
de l'une des manières suivantes :
- Un fichier situé dans votre dépôt de code source.
-
Intégrée dans votre configuration de construction à l'aide du champ
jenkinsfile
.
Si vous utilisez la première option, le site jenkinsfile
doit être inclus dans le dépôt du code source de vos applications à l'un des endroits suivants :
-
Un fichier nommé
jenkinsfile
à la racine de votre référentiel. -
Un fichier nommé
jenkinsfile
à la racine de la sourcecontextDir
de votre référentiel. -
Un nom de fichier spécifié via le champ
jenkinsfilePath
de la sectionJenkinsPipelineStrategy
de votre BuildConfig, qui est relatif à la sourcecontextDir
si elle est fournie, sinon il prend par défaut la racine du référentiel.
Le site jenkinsfile
est exécuté sur le pod d'agent Jenkins, qui doit disposer des binaires du client OpenShift Container Platform si vous avez l'intention d'utiliser le DSL OpenShift Container Platform.
Procédure
Pour fournir le fichier Jenkins, vous pouvez soit
- Intégrer le fichier Jenkins dans la configuration de construction.
- Inclure dans la configuration de construction une référence au dépôt Git qui contient le fichier Jenkins.
Définition de l'intégration
Référence au dépôt Git
- 1
- Le champ facultatif
jenkinsfilePath
indique le nom du fichier à utiliser, par rapport à la sourcecontextDir
. SicontextDir
est omis, la valeur par défaut est la racine du référentiel. SijenkinsfilePath
est omis, la valeur par défaut estjenkinsfile
.
2.5.4.3. Utilisation de variables d'environnement pour la construction de pipelines Copier lienLien copié sur presse-papiers!
La stratégie de construction Pipeline est obsolète dans OpenShift Container Platform 4. Des fonctionnalités équivalentes et améliorées sont présentes dans les Pipelines d'OpenShift Container Platform basés sur Tekton.
Les images Jenkins sur OpenShift Container Platform sont entièrement prises en charge et les utilisateurs doivent suivre la documentation utilisateur de Jenkins pour définir leur jenkinsfile
dans un travail ou le stocker dans un système de gestion du contrôle de la source.
Pour mettre les variables d'environnement à la disposition du processus de construction de Pipeline, vous pouvez ajouter des variables d'environnement à la définition jenkinsPipelineStrategy
de la configuration de construction.
Une fois définies, les variables d'environnement seront définies comme paramètres pour tout travail Jenkins associé à la configuration de construction.
Procédure
Pour définir les variables d'environnement à utiliser lors de la construction, éditez le fichier YAML :
jenkinsPipelineStrategy: ... env: - name: "FOO" value: "BAR"
jenkinsPipelineStrategy: ... env: - name: "FOO" value: "BAR"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Vous pouvez également gérer les variables d'environnement définies dans la configuration de construction à l'aide de la commande oc set env
.
2.5.4.3.1. Mapping entre les variables d'environnement BuildConfig et les paramètres des jobs Jenkins Copier lienLien copié sur presse-papiers!
Lorsqu'un travail Jenkins est créé ou mis à jour en fonction des modifications apportées à la configuration de construction d'une stratégie Pipeline, toutes les variables d'environnement de la configuration de construction sont mises en correspondance avec les définitions des paramètres du travail Jenkins, les valeurs par défaut des définitions des paramètres du travail Jenkins étant les valeurs actuelles des variables d'environnement associées.
Après la création initiale du job Jenkins, vous pouvez encore ajouter des paramètres supplémentaires au job à partir de la console Jenkins. Les noms des paramètres diffèrent des noms des variables d'environnement dans la configuration de la construction. Les paramètres sont pris en compte lors du lancement des builds pour ces travaux Jenkins.
La façon dont vous démarrez la construction d'une tâche Jenkins détermine la façon dont les paramètres sont définis.
-
Si vous démarrez avec
oc start-build
, les valeurs des variables d'environnement dans la configuration de construction sont les paramètres définis pour l'instance de travail correspondante. Toute modification apportée aux valeurs par défaut des paramètres à partir de la console Jenkins est ignorée. Les valeurs de la configuration de construction sont prioritaires. Si vous commencez par
oc start-build -e
, les valeurs des variables d'environnement spécifiées dans l'option-e
sont prioritaires.- Si vous spécifiez une variable d'environnement qui ne figure pas dans la configuration de la construction, elle sera ajoutée en tant que définition des paramètres du travail de Jenkins.
-
Toute modification apportée aux paramètres correspondant aux variables d'environnement à partir de la console Jenkins est ignorée. La configuration de construction et ce que vous spécifiez avec
oc start-build -e
sont prioritaires.
- Si vous démarrez le travail Jenkins avec la console Jenkins, vous pouvez alors contrôler le réglage des paramètres avec la console Jenkins dans le cadre du lancement d'une compilation pour le travail.
Il est recommandé de spécifier dans la configuration de la construction toutes les variables d'environnement possibles à associer aux paramètres du travail. Cela permet de réduire les entrées/sorties sur disque et d'améliorer les performances lors du traitement par Jenkins.
2.5.4.4. Tutoriel de construction d'un pipeline Copier lienLien copié sur presse-papiers!
La stratégie de construction Pipeline est obsolète dans OpenShift Container Platform 4. Des fonctionnalités équivalentes et améliorées sont présentes dans les Pipelines d'OpenShift Container Platform basés sur Tekton.
Les images Jenkins sur OpenShift Container Platform sont entièrement prises en charge et les utilisateurs doivent suivre la documentation utilisateur de Jenkins pour définir leur jenkinsfile
dans un travail ou le stocker dans un système de gestion du contrôle de la source.
Cet exemple montre comment créer un pipeline OpenShift Container Platform qui construira, déploiera et vérifiera une application Node.js/MongoDB
en utilisant le modèle nodejs-mongodb.json
.
Procédure
Créer le master Jenkins :
oc project <project_name>
$ oc project <project_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Sélectionnez le projet que vous souhaitez utiliser ou créez un nouveau projet à l'aide de
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 Si vous souhaitez utiliser un stockage persistant, utilisez plutôt
jenkins-persistent
.Créez un fichier nommé
nodejs-sample-pipeline.yaml
avec le contenu suivant :NoteCela crée un objet
BuildConfig
qui utilise la stratégie du pipeline Jenkins pour construire, déployer et mettre à l'échelle l'application d'exempleNode.js/MongoDB
.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Après avoir créé un objet
BuildConfig
à l'aide d'un objetjenkinsPipelineStrategy
, vous indiquez au pipeline ce qu'il doit faire à l'aide d'un objet inlinejenkinsfile
:NoteCet exemple ne met pas en place un dépôt Git pour l'application.
Le contenu suivant
jenkinsfile
est écrit en Groovy en utilisant le DSL OpenShift Container Platform. Pour cet exemple, incluez du contenu en ligne dans l'objetBuildConfig
en utilisant le style littéral YAML, bien que l'inclusion d'unjenkinsfile
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
- Nom du modèle qui sera créé.
- 3
- Créer un pod d'agent
node.js
sur lequel exécuter ce build. - 4
- Définir un délai de 20 minutes pour ce pipeline.
- 5
- Supprimer tout ce qui porte l'étiquette de ce modèle.
- 6
- Supprimez tous les secrets portant cette étiquette de modèle.
- 7
- Créez une nouvelle application à partir du site
templatePath
. - 8
- Attendez jusqu'à cinq minutes que la construction soit terminée.
- 9
- Attendez jusqu'à cinq minutes que le déploiement soit terminé.
- 10
- Si tout le reste a réussi, marquez l'image
$ {templateName}:latest
comme$ {templateName}-staging:latest
. Une configuration de construction de pipeline pour l'environnement de mise à l'essai peut surveiller la modification de l'image$ {templateName}-staging:latest
et la déployer ensuite dans l'environnement de mise à l'essai.
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 cluster OpenShift Container Platform :oc create -f nodejs-sample-pipeline.yaml
$ oc create -f nodejs-sample-pipeline.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Si vous ne souhaitez pas créer votre propre fichier, vous pouvez utiliser l'exemple 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émarrer le pipeline :
oc start-build nodejs-sample-pipeline
$ oc start-build nodejs-sample-pipeline
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteVous pouvez également démarrer votre pipeline avec la console web d'OpenShift Container Platform en naviguant vers la section Builds
Pipeline et en cliquant sur Start Pipeline, ou en visitant la console Jenkins, en naviguant vers le pipeline que vous avez créé et en cliquant sur Build Now. Une fois le pipeline lancé, vous devriez voir les actions suivantes se dérouler dans votre projet :
- Une instance de travail est créée sur le serveur Jenkins.
- Un module d'agent est lancé, si votre pipeline en nécessite un.
Le pipeline s'exécute sur le pod agent, ou sur le master si aucun agent n'est requis.
-
Toutes les ressources créées précédemment avec l'étiquette
template=nodejs-mongodb-example
seront supprimées. -
Une nouvelle application et toutes ses ressources associées seront créées à partir du modèle
nodejs-mongodb-example
. Une compilation sera lancée à l'aide de
nodejs-mongodb-example
BuildConfig
.- Le pipeline attendra que la construction soit terminée pour déclencher l'étape suivante.
Un déploiement sera lancé à l'aide de la configuration de déploiement
nodejs-mongodb-example
.- Le pipeline attendra que le déploiement soit terminé pour déclencher l'étape suivante.
-
Si la construction et le déploiement sont réussis, l'image
nodejs-mongodb-example:latest
sera étiquetée commenodejs-mongodb-example:stage
.
-
Toutes les ressources créées précédemment avec l'étiquette
Le pod de l'agent est supprimé, s'il était nécessaire pour le pipeline.
NoteLa meilleure façon de visualiser l'exécution du pipeline est de l'afficher dans la console web d'OpenShift Container Platform. Vous pouvez visualiser vos pipelines en vous connectant à la console web et en naviguant vers Builds
Pipelines.
2.5.5. Ajouter des secrets avec la console web Copier lienLien copié sur presse-papiers!
Vous pouvez ajouter un secret à votre configuration de construction afin qu'elle puisse accéder à un dépôt privé.
Procédure
Pour ajouter un secret à votre configuration de construction afin qu'elle puisse accéder à un dépôt privé à partir de la console web d'OpenShift Container Platform :
- Créez un nouveau projet OpenShift Container Platform.
- Créez un secret contenant les informations d'identification permettant d'accéder à un dépôt de code source privé.
- Créer une configuration de construction.
-
Sur la page de l'éditeur de configuration de la construction ou sur la page
create app from builder image
de la console web, définissez le paramètre Source Secret. - Cliquez sur Save.
2.5.6. Permettre de tirer et de pousser Copier lienLien copié sur presse-papiers!
Vous pouvez activer l'extraction vers un registre privé en définissant le secret d'extraction et la poussée en définissant le secret de poussée dans la configuration de la construction.
Procédure
Pour permettre l'extraction vers un registre privé :
- Définir le secret d'extraction dans la configuration de la construction.
Pour activer la poussée :
- Définir le secret de poussée dans la configuration de la construction.