Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

2.9. Effectuer des constructions avancées

Les sections suivantes fournissent des instructions pour les opérations de construction avancées, notamment la définition des ressources de construction et de la durée maximale, l'affectation des constructions aux nœuds, l'enchaînement des constructions, l'élagage des constructions et les stratégies d'exécution des constructions.

2.9.1. Définition des ressources de construction
Copier lien

Par défaut, les constructions sont réalisées par des pods utilisant des ressources non liées, telles que la mémoire et le processeur. Ces ressources peuvent être limitées.

Procédure

Vous pouvez limiter l'utilisation des ressources de deux manières :

  • Limiter l'utilisation des ressources en spécifiant des limites de ressources dans les limites du conteneur par défaut d'un projet.

  • Limit resource use by specifying resource limits as part of the build configuration. ** In the following example, each of the resources, cpu, and memory parameters are optional: 

    apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  resources:
    limits:
      cpu: "100m"
    1 
    
      memory: "256Mi"
    2
    Copy to Clipboard Toggle word wrap
    1
    cpu is in CPU units: 100m represents 0.1 CPU units (100 * 1e-3).
    2
    memory is in bytes: 256Mi represents 268435456 bytes (256 * 2 ^ 20).

    Toutefois, si un quota a été défini pour votre projet, l'un des deux éléments suivants est nécessaire :

    • Un ensemble de sections resources avec un requests explicite : 

      resources:
  requests:
      1 
      
    cpu: "100m"
    memory: "256Mi"
      Copy to Clipboard Toggle word wrap
      1
      L'objet requests contient la liste des ressources correspondant à la liste des ressources du quota.

    • Une plage de limites définie dans votre projet, où les valeurs par défaut de l'objet LimitRange s'appliquent aux pods créés pendant le processus de construction.

      Dans le cas contraire, la création d'un build pod échouera, car le quota n'aura pas été atteint.

2.9.2. Définition de la durée maximale
Copier lien

Lors de la définition d'un objet BuildConfig, vous pouvez définir sa durée maximale en définissant le champ completionDeadlineSeconds. Ce champ est spécifié en secondes et n'est pas défini par défaut. S'il n'est pas défini, aucune durée maximale n'est imposée.

La durée maximale est calculée à partir du moment où un pod de construction est planifié dans le système, et définit la durée pendant laquelle il peut être actif, y compris le temps nécessaire à l'extraction de l'image du constructeur. Après avoir atteint le délai spécifié, la construction est interrompue par OpenShift Container Platform.

Procédure

  • Pour définir la durée maximale, spécifiez completionDeadlineSeconds dans votre BuildConfig. L'exemple suivant montre la partie d'un BuildConfig spécifiant le champ completionDeadlineSeconds pour 30 minutes : 

    spec:
  completionDeadlineSeconds: 1800
    Copy to Clipboard Toggle word wrap
Note

Ce paramètre n'est pas pris en charge par l'option Stratégie de pipeline.

2.9.3. Assigner des constructions à des nœuds spécifiques
Copier lien

Les builds peuvent être ciblés pour s'exécuter sur des nœuds spécifiques en spécifiant des étiquettes dans le champ nodeSelector d'une configuration de build. La valeur nodeSelector est un ensemble de paires clé-valeur qui sont associées aux étiquettes Node lors de la planification du module de construction.

La valeur nodeSelector peut également être contrôlée par des valeurs par défaut et des valeurs de remplacement à l'échelle du cluster. Les valeurs par défaut ne seront appliquées que si la configuration de construction ne définit aucune paire clé-valeur pour nodeSelector et ne définit pas non plus une valeur de carte explicitement vide pour nodeSelector:{}. Les valeurs de remplacement remplaceront les valeurs dans la configuration de construction sur une base clé par clé.

Note

Si l'adresse NodeSelector spécifiée ne peut être associée à un nœud portant ces étiquettes, la construction reste indéfiniment dans l'état Pending.

Procédure

  • Attribuez des builds à exécuter sur des nœuds spécifiques en attribuant des étiquettes dans le champ nodeSelector de l'adresse BuildConfig, par exemple : 

    apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  nodeSelector:
    1 
    
    key1: value1
    key2: value2
    Copy to Clipboard Toggle word wrap
    1
    Les constructions associées à cette configuration de construction ne s'exécuteront que sur les nœuds portant les étiquettes key1=value2 et key2=value2.

2.9.4. Constructions en chaîne
Copier lien

Pour les langages compilés tels que Go, C, C et Java, l'inclusion des dépendances nécessaires à la compilation dans l'image de l'application peut augmenter la taille de l'image ou introduire des vulnérabilités qui peuvent être exploitées.

Pour éviter ces problèmes, il est possible d'enchaîner deux compilations. Une compilation qui produit l'artefact compilé, et une seconde qui place cet artefact dans une image séparée qui exécute l'artefact.

Dans l'exemple suivant, une compilation source-image (S2I) est combinée avec une compilation docker pour compiler un artefact qui est ensuite placé dans une image d'exécution séparée.

Note

Bien que cet exemple enchaîne une construction S2I et une construction docker, la première construction peut utiliser n'importe quelle stratégie qui produit une image contenant les artefacts souhaités, et la seconde construction peut utiliser n'importe quelle stratégie qui peut consommer du contenu d'entrée à partir d'une image.

La première compilation prend la source de l'application et produit une image contenant un fichier WAR. L'image est poussée vers le flux d'images artifact-image. Le chemin de l'artefact de sortie dépend du script assemble du constructeur S2I utilisé. Dans le cas présent, l'artefact est envoyé à /wildfly/standalone/deployments/ROOT.war. 

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: artifact-build
spec:
  output:
    to:
      kind: ImageStreamTag
      name: artifact-image:latest
  source:
    git:
      uri: https://github.com/openshift/openshift-jee-sample.git
      ref: "master"
  strategy:
    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: wildfly:10.1
        namespace: openshift
Copy to Clipboard Toggle word wrap

La deuxième version utilise l'image source avec un chemin vers le fichier WAR à l'intérieur de l'image de sortie de la première version. Une page dockerfile copie le fichier WAR dans une image d'exécution. 

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: image-build
spec:
  output:
    to:
      kind: ImageStreamTag
      name: image-build:latest
  source:
    dockerfile: |-
      FROM jee-runtime:latest
      COPY ROOT.war /deployments/ROOT.war
    images:
    - from:
1 

        kind: ImageStreamTag
        name: artifact-image:latest
      paths:
2 

      - sourcePath: /wildfly/standalone/deployments/ROOT.war
        destinationDir: "."
  strategy:
    dockerStrategy:
      from:
3 

        kind: ImageStreamTag
        name: jee-runtime:latest
  triggers:
  - imageChange: {}
    type: ImageChange
Copy to Clipboard Toggle word wrap
1
from spécifie que la construction de docker doit inclure la sortie de l'image du flux d'images artifact-image, qui était la cible de la construction précédente.
2
paths spécifie les chemins de l'image cible à inclure dans la construction actuelle de Docker.
3
L'image d'exécution est utilisée comme image source pour la construction de docker.

Le résultat de cette configuration est que l'image de sortie de la deuxième compilation n'a pas besoin de contenir les outils de compilation nécessaires pour créer le fichier WAR. De plus, comme la deuxième compilation contient un déclencheur de changement d'image, chaque fois que la première compilation est exécutée et produit une nouvelle image avec l'artefact binaire, la deuxième compilation est automatiquement déclenchée pour produire une image d'exécution qui contient cet artefact. Par conséquent, les deux compilations se comportent comme une seule compilation avec deux étapes.

2.9.5. Taille des constructions
Copier lien

Par défaut, les versions qui ont terminé leur cycle de vie sont conservées indéfiniment. Vous pouvez limiter le nombre de versions antérieures conservées.

Procédure

  1. Limitez le nombre de constructions précédentes qui sont conservées en fournissant une valeur entière positive pour successfulBuildsHistoryLimit ou failedBuildsHistoryLimit dans votre BuildConfig, par exemple : 

    apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  successfulBuildsHistoryLimit: 2
    1 
    
  failedBuildsHistoryLimit: 2
    2
    Copy to Clipboard Toggle word wrap
    1
    successfulBuildsHistoryLimit conservera jusqu'à deux constructions avec un statut de completed.
    2
    failedBuildsHistoryLimit retiendra jusqu'à deux constructions avec un statut de failed, canceled, ou error.

  2. Déclencher l'élagage de la construction par l'une des actions suivantes :

    • Mise à jour d'une configuration de construction.
    • Attente de la fin du cycle de vie d'une construction.

Les constructions sont triées en fonction de leur date de création, les plus anciennes étant élaguées en premier.

Note

Les administrateurs peuvent élaguer manuellement les constructions à l'aide de la commande d'élagage d'objets 'oc adm'.

2.9.6. Politique d'exécution de la construction
Copier lien

La politique d'exécution de la construction décrit l'ordre dans lequel les constructions créées à partir de la configuration de la construction doivent être exécutées. Pour ce faire, il suffit de modifier la valeur du champ runPolicy dans la section spec de la spécification Build.

Il est également possible de modifier la valeur de runPolicy pour les configurations de construction existantes :

  • Si l'on remplace Parallel par Serial ou SerialLatestOnly et que l'on déclenche une nouvelle construction à partir de cette configuration, la nouvelle construction attendra que toutes les constructions parallèles soient terminées, car la construction en série ne peut s'exécuter que seule.
  • Changer Serial en SerialLatestOnly et déclencher un nouveau build provoque l'annulation de tous les builds existants dans la file d'attente, à l'exception du build en cours d'exécution et du build créé le plus récemment. La version la plus récente s'exécute ensuite.
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