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.
5.2.1. Effectuer des constructions incrémentielles source-à-image Copier lienLien copié sur presse-papiers!
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:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 Copier lienLien copié sur presse-papiers!
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:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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.
NoteLes 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 Copier lienLien copié sur presse-papiers!
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.
5.2.3.1. En utilisant des fichiers d’environnement source à image Copier lienLien copié sur presse-papiers!
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.
5.2.3.2. En utilisant l’environnement de configuration source à image Copier lienLien copié sur presse-papiers!
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"
sourceStrategy: ... env: - name: "DISABLE_ASSET_COMPILATION" value: "true"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.4. Ignorer les fichiers source source source-à-image Copier lienLien copié sur presse-papiers!
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.
5.2.5. Création d’images à partir du code source avec source-à-image Copier lienLien copié sur presse-papiers!
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.
5.2.5.1. Comprendre le processus de création de source à image Copier lienLien copié sur presse-papiers!
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 Copier lienLien copié sur presse-papiers!
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:
- Le script spécifié dans la configuration de build.
- Le script trouvé dans le répertoire source de l’application .s2i/bin.
- 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.
Le script | Description |
---|---|
| 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:
|
| Le script d’exécution exécute votre application. Ce script est requis. |
| 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:
Ces dépendances sont rassemblées dans un fichier goudron et diffusées vers la sortie standard. |
| Le script d’utilisation vous permet d’informer l’utilisateur comment utiliser correctement votre image. Ce script est facultatif. |
| 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:
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:
exécutez le script:
run the application
#!/bin/bash
# run the application
/opt/application/run.sh
script de sauvegarde-artefacts:
script d’utilisation:
5.2.6. En utilisant des volumes de construction Copier lienLien copié sur presse-papiers!
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:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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.