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

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.

Astuce

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

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"
Copy to Clipboard Toggle word wrap

2.5.1.2. Utilisation du chemin d'accès au fichier Docker

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
Copy to Clipboard Toggle word wrap

2.5.1.3. Utiliser les variables d'environnement de Docker

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/"
Copy to Clipboard Toggle word wrap

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

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.

Astuce

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"
Copy to Clipboard Toggle word wrap
Note

Seuls les champs name et value sont pris en charge. Les paramètres du champ valueFrom sont ignorés.

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 sur SkipLayers:

    strategy:
      dockerStrategy:
        imageOptimizationPolicy: SkipLayers
    Copy to Clipboard Toggle word wrap

2.5.1.6. Utilisation des volumes de construction

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.

Procédure

  • Dans la définition dockerStrategy de l'objet BuildConfig, ajoutez tous les volumes de construction au tableau volumes. Par exemple :

    spec:
      dockerStrategy:
        volumes:
          - name: secret-mvn 
    1
    
            mounts:
            - destinationPath: /opt/app-root/src/.ssh 
    2
    
            source:
              type: Secret 
    3
    
              secret:
                secretName: my-secret 
    4
    
          - name: settings-mvn 
    5
    
            mounts:
            - destinationPath: /opt/app-root/src/.m2  
    6
    
            source:
              type: ConfigMap 
    7
    
              configMap:
                name: my-config 
    8
    
          - name: my-csi-volume 
    9
    
            mounts:
            - destinationPath: /opt/app-root/src/some_path  
    10
    
            source:
              type: CSI 
    11
    
              csi:
                driver: csi.sharedresource.openshift.io 
    12
    
                readOnly: true 
    13
    
                volumeAttributes: 
    14
    
                  attribute: value
    Copy to Clipboard Toggle word wrap
    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, ou CSI.
    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.
Note

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

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.

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 :

    strategy:
      sourceStrategy:
        from:
          kind: "ImageStreamTag"
          name: "incremental-image:latest" 
    1
    
        incremental: true 
    2
    Copy to Clipboard Toggle word wrap
    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.

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 ou save-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 :

    strategy:
      sourceStrategy:
        from:
          kind: "ImageStreamTag"
          name: "builder-image:latest"
        scripts: "http://somehost.com/scripts_directory" 
    1
    Copy to Clipboard Toggle word wrap
    1
    Ce chemin sera complété par run, assemble, et save-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.
Note

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

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.

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.

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"
    Copy to Clipboard Toggle word wrap

2.5.2.4. Ignorer les fichiers source à image

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.

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.

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 ?

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 :

  1. Un script spécifié dans la configuration de la construction.
  2. Un script trouvé dans le répertoire source de l'application .s2i/bin.
  3. 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_dirchemin absolu à l'intérieur de l'image vers un répertoire où se trouvent les scripts S2I.
  • file:///path_to_scripts_dirchemin 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.
Expand
Tableau 2.1. Scénarios S2I
Le scénarioDescription

assemble

Le script assemble construit les artefacts de l'application à partir d'une source et les place dans les répertoires appropriés à l'intérieur de l'image. Ce script est obligatoire. Le flux de travail pour ce script est le suivant :

  1. Optionnel : Restaurer les artefacts de construction. Si vous souhaitez prendre en charge les constructions incrémentielles, veillez à définir également save-artifacts.
  2. Placez la source d'application à l'endroit souhaité.
  3. Construire les artefacts de l'application.
  4. Installer les artefacts dans des endroits appropriés pour qu'ils fonctionnent.

run

Le script run exécute votre application. Ce script est nécessaire.

save-artifacts

Le script save-artifacts rassemble toutes les dépendances qui peuvent accélérer les processus de construction qui suivent. Ce script est facultatif. Par exemple :

  • Pour Ruby, gems installé par Bundler.
  • Pour Java, .m2 contents.

Ces dépendances sont rassemblées dans un fichier tar et transmises à la sortie standard.

usage

Le script usage vous permet d'informer l'utilisateur sur la manière d'utiliser correctement votre image. Ce script est facultatif.

test/run

Le script test/run vous permet de créer un processus pour vérifier si l'image fonctionne correctement. Ce script est facultatif. Le flux proposé pour ce processus est le suivant

  1. Construire l'image.
  2. Exécutez l'image pour vérifier le script usage.
  3. Exécutez s2i build pour vérifier le script assemble.
  4. Facultatif : Exécutez à nouveau s2i build pour vérifier que les scripts save-artifacts et assemble sauvegardent et restaurent les artefacts.
  5. Exécutez l'image pour vérifier que l'application de test fonctionne.
Note

L'emplacement suggéré pour placer l'application de test construite par votre script test/run est le répertoire test/test-app de votre référentiel d'images.

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 :

#!/bin/bash

# restore build artifacts
if [ "$(ls /tmp/s2i/artifacts/ 2>/dev/null)" ]; then
    mv /tmp/s2i/artifacts/* $HOME/.
fi

# move the application source
mv /tmp/s2i/src $HOME/src

# build application artifacts
pushd ${HOME}
make all

# install the artifacts
make install
popd
Copy to Clipboard Toggle word wrap

run le scénario :

#!/bin/bash

# run the application
/opt/application/run.sh
Copy to Clipboard Toggle word wrap

save-artifacts le scénario :

#!/bin/bash

pushd ${HOME}
if [ -d deps ]; then
    # all deps contents to tar stream
    tar cf - deps
fi
popd
Copy to Clipboard Toggle word wrap

usage le scénario :

#!/bin/bash

# inform the user how to use the image
cat <<EOF
This is a S2I sample builder image, to use it, install
https://github.com/openshift/source-to-image
EOF
Copy to Clipboard Toggle word wrap

2.5.2.6. Utilisation des volumes de construction

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.

Procédure

  • Dans la définition sourceStrategy de l'objet BuildConfig, ajoutez tous les volumes de construction au tableau volumes. Par exemple :

    spec:
      sourceStrategy:
        volumes:
          - name: secret-mvn 
    1
    
            mounts:
            - destinationPath: /opt/app-root/src/.ssh 
    2
    
            source:
              type: Secret 
    3
    
              secret:
                secretName: my-secret 
    4
    
          - name: settings-mvn 
    5
    
            mounts:
            - destinationPath: /opt/app-root/src/.m2 
    6
    
            source:
              type: ConfigMap 
    7
    
              configMap:
                name: my-config 
    8
    
          - name: my-csi-volume 
    9
    
            mounts:
            - destinationPath: /opt/app-root/src/some_path  
    10
    
            source:
              type: CSI 
    11
    
              csi:
                driver: csi.sharedresource.openshift.io 
    12
    
                readOnly: true 
    13
    
                volumeAttributes: 
    14
    
                  attribute: value
    Copy to Clipboard Toggle word wrap
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, ou CSI.
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.
Note

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

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.

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"
    Copy to Clipboard Toggle word wrap

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 et mountPath du fichier YAML strategy:

    strategy:
      customStrategy:
        secrets:
          - secretSource: 
    1
    
              name: "secret1"
            mountPath: "/tmp/secret1" 
    2
    
          - secretSource:
              name: "secret2"
            mountPath: "/tmp/secret2"
    Copy to Clipboard Toggle word wrap
    1
    secretSource est une référence à un secret dans le même espace de noms que la construction.
    2
    mountPath est le chemin d'accès à l'intérieur du constructeur personnalisé où le secret doit être monté.

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

  1. Définir un proxy HTTP personnalisé à utiliser lors de la construction :

    customStrategy:
    ...
      env:
        - name: "HTTP_PROXY"
          value: "http://myproxy.net:5187/"
    Copy to Clipboard Toggle word wrap
  2. 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>
    Copy to Clipboard Toggle word wrap

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

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 :

Expand
Tableau 2.2. Variables d'environnement du Custom Builder
Nom de la variableDescription

BUILD

L'intégralité du JSON sérialisé de la définition de l'objet Build. Si vous devez utiliser une version spécifique de l'API pour la sérialisation, vous pouvez définir le paramètre buildAPIVersion dans la spécification de la stratégie personnalisée de la configuration de construction.

SOURCE_REPOSITORY

L'URL d'un dépôt Git contenant les sources à construire.

SOURCE_URI

Utilise la même valeur que SOURCE_REPOSITORY. L'un ou l'autre peut être utilisé.

SOURCE_CONTEXT_DIR

Spécifie le sous-répertoire du dépôt Git à utiliser lors de la construction. Uniquement présent s'il est défini.

SOURCE_REF

La référence Git à construire.

ORIGIN_VERSION

La version du master OpenShift Container Platform qui a créé cet objet de construction.

OUTPUT_REGISTRY

Le registre de l'image du conteneur dans lequel l'image doit être transférée.

OUTPUT_IMAGE

Le nom de l'étiquette de l'image du conteneur pour l'image en cours de construction.

PUSH_DOCKERCFG_PATH

Chemin d'accès aux informations d'identification du registre des conteneurs pour l'exécution d'une opération podman push.

2.5.3.4.2. Flux de travail des constructeurs personnalisés

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 :

  1. La définition de l'objet Build contient toutes les informations nécessaires sur les paramètres d'entrée de la construction.
  2. Exécuter le processus de construction.
  3. 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

Important

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.

Important

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 de jenkinsfile à utiliser par rapport à la source contextDir.
Note

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.

Important

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 source contextDir de votre référentiel.
  • Un nom de fichier spécifié via le champ jenkinsfilePath de la section JenkinsPipelineStrategy de votre BuildConfig, qui est relatif à la source contextDir 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

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

Référence au dépôt Git

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 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.
Important

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"
    Copy to Clipboard Toggle word wrap

Vous pouvez également gérer les variables d'environnement définies dans la configuration de construction à l'aide de la commande oc set env.

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.
Note

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

Important

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

  1. Créer le master Jenkins :

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

    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 
    1
    Copy to Clipboard Toggle word wrap

    Si vous souhaitez utiliser un stockage persistant, utilisez plutôt jenkins-persistent.

  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 du 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 à l'aide d'un objet jenkinsPipelineStrategy, vous indiquez au pipeline ce qu'il doit faire à l'aide d'un objet inline jenkinsfile:

    Note

    Cet 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'objet BuildConfig en utilisant le style littéral YAML, bien que l'inclusion d'un jenkinsfile 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
    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.
    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 Container Platform :

    $ oc create -f nodejs-sample-pipeline.yaml
    Copy to Clipboard Toggle word wrap
    1. 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
      Copy to Clipboard Toggle word wrap
  5. Démarrer le pipeline :

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

    Vous 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 comme nodejs-mongodb-example:stage.
    • Le pod de l'agent est supprimé, s'il était nécessaire pour le pipeline.

      Note

      La 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

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 :

  1. Créez un nouveau projet OpenShift Container Platform.
  2. Créez un secret contenant les informations d'identification permettant d'accéder à un dépôt de code source privé.
  3. Créer une configuration de construction.
  4. 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.
  5. Cliquez sur Save.

2.5.6. Permettre de tirer et de pousser

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.
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