Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Chapitre 5. En utilisant des stratégies de construction

Les sections suivantes définissent les stratégies de construction principales prises en charge et comment les utiliser.

5.1. Construction de Docker

Le service OpenShift Red Hat sur AWS utilise Buildah pour construire une image conteneur à partir d’un Dockerfile. Consultez la documentation de référence Dockerfile pour plus d’informations sur les images de conteneurs de construction avec Dockerfile.

Astuce

Lorsque vous définissez les arguments de construction Docker à l’aide du tableau buildArgs, voir Comprendre comment ARG et FROM interagissent dans la documentation de référence Dockerfile.

5.1.1. Le remplacement de l’image Dockerfile FROM

Il est possible de remplacer l’instruction FROM du Dockerfile par les paramètres de l’objet BuildConfig. Lorsque le Dockerfile utilise des builds multi-étapes, l’image de la dernière instruction FROM sera remplacée.

Procédure

  • Afin de remplacer l’instruction FROM du Dockerfile par les paramètres de l’objet BuildConfig, ajoutez les paramètres suivants à l’objet BuildConfig: 

    strategy:
  dockerStrategy:
    from:
      kind: "ImageStreamTag"
      name: "debian:latest"
    Copy to Clipboard

5.1.2. En utilisant le chemin Dockerfile

Docker builds utilise un Dockerfile situé à la racine du contexte spécifié dans le champ BuildConfig.spec.source.contextDir.

Le champ dockerfilePath permet à la construction 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, tel que MyDockerfile, ou d’un chemin vers un Dockerfile dans un sous-répertoire, tel que dockerfiles/app1/Dockerfile.

Procédure

  • Définissez le champ dockerfilePath pour que la construction utilise un chemin différent pour localiser votre Dockerfile: 

    strategy:
  dockerStrategy:
    dockerfilePath: dockerfiles/app1/Dockerfile
    Copy to Clipboard

5.1.3. En utilisant des variables d’environnement docker

Afin de rendre les variables d’environnement disponibles pour le processus de construction docker et l’image résultante, vous pouvez ajouter des variables d’environnement à la définition de dockerStrategy de la configuration de construction.

Les variables d’environnement définies là sont insérées comme une seule instruction ENV Dockerfile juste après l’instruction FROM, de sorte qu’elle puisse être référencée plus tard dans le Dockerfile.

Les variables sont définies pendant la construction et restent dans l’image de sortie, elles seront donc présentes dans n’importe quel conteneur qui exécute cette image aussi bien.

À titre d’exemple, définir un proxy HTTP personnalisé à utiliser pendant la construction et l’exécution: 

dockerStrategy:
...
  env:
    - name: "HTTP_PROXY"
      value: "http://myproxy.net:5187/"
Copy to Clipboard

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.1.4. Ajout d’arguments de construction Docker

Il est possible de définir les arguments Docker build à l’aide du tableau buildArgs. Les arguments de construction sont transmis à Docker lorsqu’une build est lancée.

Astuce

Découvrez comment ARG et FROM interagissent dans la documentation de référence Dockerfile.

Procédure

  • Afin de définir les arguments de construction Docker, ajoutez des entrées au tableau buildArgs, qui se trouve dans la définition dockerStrategy de l’objet BuildConfig. À titre d’exemple: 

    dockerStrategy:
...
  buildArgs:
    - name: "version"
      value: "latest"
    Copy to Clipboard
    Note

    Les champs nom et valeur sont pris en charge. Les paramètres sur le champ valueFrom sont ignorés.

5.1.5. Couches d’écaillement avec docker builds

Docker crée normalement un calque représentant chaque instruction dans un Dockerfile. Définir l’imageOptimizationPolicy sur SkipLayers fusionne toutes les instructions en un seul calque au-dessus de l’image de base.

Procédure

  • Définir l’imageOptimizationPolicy sur SkipLayers: 

    strategy:
  dockerStrategy:
    imageOptimizationPolicy: SkipLayers
    Copy to Clipboard

5.1.6. En utilisant des volumes de construction

Les volumes de build peuvent être montés pour donner aux builds en cours l’accès à des informations que vous ne voulez pas persister dans l’image du conteneur de sortie.

Les volumes de construction fournissent des informations sensibles, telles que des informations d’identification de 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 build, dont les données peuvent persister dans l’image du conteneur de sortie.

Les points de montage des volumes de construction, à partir desquels le build en cours d’exécution lit les données, sont fonctionnellement similaires aux montures de volume pod.

Conditions préalables

  • Il a ajouté un secret d’entrée, une carte de configuration ou les deux à un objet BuildConfig.

Procédure

  • Dans la définition dockerStrategy de l’objet BuildConfig, ajoutez n’importe quel volume de build au tableau des volumes. À titre d’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
    Copy to Clipboard
    1 5
    C’est nécessaire. C’est un nom unique.
    2 6
    C’est nécessaire. Le chemin absolu du point de montage. Il ne doit pas contenir .. ou : et n’entre pas en collision avec le chemin de destination généré par le constructeur. Le /opt/app-root/src est le répertoire d’accueil par défaut pour de nombreuses images compatibles Red Hat S2I.
    3 7
    C’est nécessaire. Le type de source, ConfigMap, Secret ou CSI.
    4 8
    C’est nécessaire. Le nom de la source.
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