2.9. Effectuer des constructions avancées

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.

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.

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

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.

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

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

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: 
        kind: ImageStreamTag
        name: artifact-image:latest
      paths: 
      - sourcePath: /wildfly/standalone/deployments/ROOT.war
        destinationDir: "."
  strategy:
    dockerStrategy:
      from: 
        kind: ImageStreamTag
        name: jee-runtime:latest
  triggers:
  - imageChange: {}
    type: ImageChange

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: 

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

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

        kind: ImageStreamTag
        name: jee-runtime:latest
  triggers:
  - imageChange: {}
    type: ImageChange

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.

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.

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

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 :