5.2. Construction de source à image


La source à l’image (S2I) est un outil pour construire des images de conteneurs reproductibles. Il produit des images prêtes à l’emploi en injectant une source d’application dans une image de conteneur et en assemblant une nouvelle image. La nouvelle image intègre l’image de base, le constructeur et la source construite et est prête à être utilisée avec la commande buildah run. Le S2I prend en charge les constructions incrémentielles, qui réutilisent des dépendances précédemment téléchargées, des artefacts précédemment construits, et ainsi de suite.

La source à l’image (S2I) peut effectuer des constructions incrémentielles, ce qui signifie qu’elle réutilise des artefacts à partir d’images précédemment construites.

Procédure

  • Afin de créer une construction incrémentale, créez un avec la modification suivante de la définition de stratégie:

    strategy:
      sourceStrategy:
        from:
          kind: "ImageStreamTag"
          name: "incremental-image:latest" 
    1
    
        incremental: true 
    2
    Copy to Clipboard Toggle word wrap
    1
    Indiquez une image qui prend en charge les constructions incrémentielles. Consultez la documentation de l’image du constructeur pour déterminer si elle prend en charge ce comportement.
    2
    Ce drapeau contrôle si une construction incrémentale est tentée. Lorsque l’image du constructeur ne prend pas en charge les constructions incrémentielles, la construction réussira toujours, mais vous obtiendrez un message journal indiquant que la construction incrémentale n’a pas été couronnée de succès en raison d’un script manquant d’artéfacts de sauvegarde.

5.2.2. Créer des scripts d’image source-à-image

Il est possible de remplacer les scripts d’assemblage, d’exécution et de sauvegarde des artefacts source-à-image (S2I) fournis par l’image du constructeur.

Procédure

  • Afin de remplacer les scripts S2I d’assemblage, d’exécution et de sauvegarde fournis par l’image du constructeur, complétez l’une des actions suivantes:

    • Fournissez un script assembler, exécuter ou enregistrer des artefacts dans le répertoire .s2i/bin de votre référentiel source d’applications.
    • Fournir une URL d’un répertoire contenant les scripts dans le cadre de la définition de stratégie dans l’objet BuildConfig. À titre d’exemple:

      strategy:
        sourceStrategy:
          from:
            kind: "ImageStreamTag"
            name: "builder-image:latest"
          scripts: "http://somehost.com/scripts_directory" 
      1
      Copy to Clipboard Toggle word wrap
      1
      Le processus de construction append l’exécution, l’assemblage et les sauvegardes-artefacts sur le chemin. En cas d’existence d’un ou de tous les scripts avec ces noms, le processus de construction utilise ces scripts à la place des scripts portant le même nom que celui fourni dans l’image.
      Note

      Les fichiers situés à l’URL des scripts ont préséance sur les fichiers situés dans .s2i/bin du référentiel source.

5.2.3. Les variables d’environnement source à image

Il existe deux façons de rendre les variables d’environnement disponibles pour le processus de création de source et l’image résultante: les fichiers d’environnement et les valeurs d’environnement BuildConfig. Les variables que vous fournissez en utilisant l’une ou l’autre méthode seront présentes pendant le processus de construction et dans l’image de sortie.

La 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/environnement dans le référentiel source. Les variables d’environnement spécifiées dans ce fichier sont présentes pendant le processus de construction et dans l’image de sortie.

Lorsque vous fournissez un fichier .s2i/environnement dans votre référentiel source, source-à-image (S2I) lit ce fichier pendant la construction. Cela permet la personnalisation du comportement de construction car le script assemble peut utiliser ces variables.

Procédure

À titre d’exemple, désactiver la compilation d’actifs pour votre application Rails pendant la construction:

  • Ajouter DISABLE_ASSET_COMPILATION=true dans le fichier .s2i/environnement.

En plus des builds, les variables d’environnement spécifiées sont également disponibles dans l’application en cours d’exécution elle-même. À titre d’exemple, faire démarrer l’application Rails en mode développement au lieu de la production:

  • Ajouter RAILS_ENV=développement au fichier .s2i/environnement.

La liste complète des variables d’environnement prises en charge est disponible dans la section d’utilisation des images pour chaque image.

Il est possible d’ajouter des variables d’environnement à la définition sourceStrategy de la configuration de construction. Les variables d’environnement définies là sont visibles lors de l’exécution du script d’assemblage et seront définies dans l’image de sortie, les rendant également disponibles pour le script d’exécution et le code d’application.

Procédure

  • À titre d’exemple, désactiver la compilation d’actifs pour votre application Rails:

    sourceStrategy:
    ...
      env:
        - name: "DISABLE_ASSET_COMPILATION"
          value: "true"
    Copy to Clipboard Toggle word wrap

5.2.4. Ignorer les fichiers source source source-à-image

La source à image (S2I) prend en charge un fichier .s2iignore, qui contient une liste de modèles de fichiers qui doivent être ignorés. Les fichiers dans le répertoire de travail de construction, tels que 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 assembler.

La source à image (S2I) est un framework qui facilite l’écriture d’images qui prennent le code source de l’application comme 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 construire des images de conteneurs reproductibles est la facilité d’utilisation pour les développeurs. En tant qu’auteur d’images de constructeur, vous devez comprendre deux concepts de base afin que vos images fournissent 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 dans une image finale du conteneur:

  • Les sources
  • Scripts source à image (S2I)
  • Image du constructeur

Le S2I génère un Dockerfile avec l’image du constructeur comme première instruction FROM. Le Dockerfile généré par S2I est ensuite transmis à Buildah.

5.2.5.2. Comment écrire des scripts source à image

Il est possible d’écrire des scripts source à image (S2I) dans n’importe quel langage de programmation, tant que les scripts sont exécutables à l’intérieur de l’image du constructeur. Le S2I prend en charge plusieurs options fournissant des scripts assemble/run/save-artefacts. L’ensemble de ces emplacements sont vérifiés sur chaque construction dans l’ordre suivant:

  1. Le script spécifié dans la configuration de build.
  2. Le script trouvé dans le répertoire source de l’application .s2i/bin.
  3. 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 build peuvent prendre l’une des formes suivantes:

  • image:///path_to_scripts_dir: chemin absolu à l’intérieur de l’image vers un répertoire où se trouvent les scripts S2I.
  • file:///path_to_scripts_dir: chemin relatif ou absolu vers un répertoire sur l’hôte où se trouvent les scripts S2I.
  • HTTP(s)://path_to_scripts_dir: URL vers un répertoire où se trouvent les scripts S2I.
Expand
Tableau 5.1. Scripts S2I
Le scriptDescription

assembler

Le script assemble les artefacts de l’application à partir d’une source et les place dans des répertoires appropriés à l’intérieur de l’image. Ce script est requis. Le flux de travail de ce script est:

  1. Facultatif: Restaurer des artefacts de construction. Lorsque vous souhaitez prendre en charge les constructions incrémentielles, assurez-vous de définir également des objets de sauvegarde.
  2. Placez la source de l’application à l’emplacement souhaité.
  3. Construisez les artefacts de l’application.
  4. Installez les artefacts dans des endroits appropriés pour qu’ils puissent fonctionner.

courir

Le script d’exécution exécute votre application. Ce script est requis.

des objets de sauvegarde

Le script sauvegarde-artefacts rassemble toutes les dépendances qui peuvent accélérer les processus de construction qui suivent. Ce script est facultatif. À titre d’exemple:

  • Avec Ruby, gemmes installées par Bundler.
  • Le contenu de Java, .m2.

Ces dépendances sont rassemblées dans un fichier goudron et diffusées vers la sortie standard.

l’utilisation

Le script d’utilisation vous permet d’informer l’utilisateur comment utiliser correctement votre image. Ce script est facultatif.

essai / course

Le script test/exécution vous permet de créer un processus pour vérifier si l’image fonctionne correctement. Ce script est facultatif. Le déroulement proposé de ce processus est:

  1. Construisez l’image.
  2. Exécutez l’image pour vérifier le script d’utilisation.
  3. Exécutez s2i build pour vérifier le script assembler.
  4. Facultatif: Exécuter s2i à nouveau pour vérifier les sauvegardes-artefacts et assembler les scripts sauvegarder et restaurer la fonctionnalité des artefacts.
  5. Exécutez l’image pour vérifier que l’application de test fonctionne.
Note

L’emplacement suggéré pour mettre l’application de test construite par votre script test/exécution est le répertoire test/test-app dans votre référentiel d’images.

Exemples de scripts S2I

Les exemples de scripts S2I suivants sont écrits en Bash. Chaque exemple suppose que son contenu de goudron est déballé dans le répertoire /tmp/s2i.

assembler le script:

#!/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

exécutez le script:

#!/bin/bash

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

script de sauvegarde-artefacts:

#!/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

script d’utilisation:

#!/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

5.2.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 sourceStrategy de l’objet BuildConfig, ajoutez n’importe quel volume de build au tableau des volumes. À titre d’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
    Copy to Clipboard Toggle word wrap
    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