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 lienLien copié sur presse-papiers!
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
, andmemory
parameters are optional:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 unrequests
explicite :resources: requests: cpu: "100m" memory: "256Mi"
resources: requests:
1 cpu: "100m" memory: "256Mi"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 lienLien copié sur presse-papiers!
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 votreBuildConfig
. L'exemple suivant montre la partie d'unBuildConfig
spécifiant le champcompletionDeadlineSeconds
pour 30 minutes :spec: completionDeadlineSeconds: 1800
spec: completionDeadlineSeconds: 1800
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 lienLien copié sur presse-papiers!
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é.
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'adresseBuildConfig
, par exemple :Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Les constructions associées à cette configuration de construction ne s'exécuteront que sur les nœuds portant les étiquettes
key1=value2
etkey2=value2
.
2.9.4. Constructions en chaîne Copier lienLien copié sur presse-papiers!
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.
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
.
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.
- 1
from
spécifie que la construction de docker doit inclure la sortie de l'image du flux d'imagesartifact-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 lienLien copié sur presse-papiers!
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
Limitez le nombre de constructions précédentes qui sont conservées en fournissant une valeur entière positive pour
successfulBuildsHistoryLimit
oufailedBuildsHistoryLimit
dans votreBuildConfig
, par exemple :Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.
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 lienLien copié sur presse-papiers!
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
parSerial
ouSerialLatestOnly
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
enSerialLatestOnly
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.