Red Hat SummitChapitre 2. Constructions
2.1. Comprendre les constructions d'images
2.1.1. Constructions
Une compilation est le processus de transformation des paramètres d'entrée en un objet résultant. Le plus souvent, le processus est utilisé pour transformer les paramètres d'entrée ou le code source en une image exécutable. Un objet BuildConfig est la définition de l'ensemble du processus de construction.
OpenShift Container Platform utilise Kubernetes en créant des conteneurs à partir d'images de construction et en les poussant vers un registre d'images de conteneurs.
Les objets de construction partagent des caractéristiques communes, notamment les entrées pour une construction, la nécessité d'achever un processus de construction, l'enregistrement du processus de construction, la publication des ressources des constructions réussies et la publication de l'état final de la construction. Les constructions tirent parti des restrictions de ressources, en spécifiant des limites sur les ressources telles que l'utilisation de l'unité centrale, l'utilisation de la mémoire et le temps d'exécution de la construction ou du pod.
Le système de construction d'OpenShift Container Platform fournit un support extensible pour les stratégies de construction qui sont basées sur des types sélectionnables spécifiés dans l'API de construction. Il existe trois stratégies de construction principales :
- Construction Docker
- Construction de la source à l'image (S2I)
- Construction sur mesure
Par défaut, les constructions docker et les constructions S2I sont prises en charge.
L'objet résultant d'une compilation dépend du constructeur utilisé pour la créer. Pour les constructions docker et S2I, les objets résultants sont des images exécutables. Pour les constructions personnalisées, les objets résultants sont ce que l'auteur de l'image du constructeur a spécifié.
En outre, la stratégie de construction de pipeline peut être utilisée pour mettre en œuvre des flux de travail sophistiqués :
- Intégration continue
- Déploiement continu
2.1.1.1. Construction Docker
OpenShift Container Platform utilise Buildah pour construire une image de conteneur à partir d'un fichier Docker. Pour plus d'informations sur la construction d'images de conteneurs avec des Dockerfiles, voir la documentation de référence Dockerfile.
Si vous définissez les arguments de construction de Docker en utilisant le tableau buildArgs, voir Comprendre comment ARG et FROM interagissent dans la documentation de référence de Dockerfile.
2.1.1.2. Construction de la source à l'image
Source-to-image (S2I) est un outil permettant de créer des images de conteneurs reproductibles. Il produit des images prêtes à l'emploi en injectant la source d'une application dans une image de conteneur et en assemblant une nouvelle image. La nouvelle image incorpore l'image de base, le constructeur et la source construite et est prête à être utilisée avec la commande buildah run. S2I prend en charge les constructions incrémentielles, qui réutilisent les dépendances téléchargées précédemment, les artefacts construits précédemment, etc.
2.1.1.3. Construction sur mesure
La stratégie de construction personnalisée permet aux développeurs de définir une image de constructeur spécifique responsable de l'ensemble du processus de construction. L'utilisation de votre propre image de constructeur vous permet de personnaliser votre processus de construction.
Une image de construction personnalisée est une image conteneur simple incorporant la logique du processus de construction, par exemple pour construire des RPM ou des images de base.
Les builds personnalisés sont exécutés avec un niveau de privilège élevé et ne sont pas accessibles aux utilisateurs par défaut. Seuls les utilisateurs à qui l'on peut faire confiance en leur accordant des autorisations d'administration de cluster doivent avoir accès à l'exécution des builds personnalisés.
2.1.1.4. Construction d'un pipeline
La stratégie de construction Pipeline est obsolète dans OpenShift Container Platform 4. Des fonctionnalités équivalentes et améliorées sont présentes dans les Pipelines d'OpenShift Container Platform basés sur Tekton.
Les images Jenkins sur OpenShift Container Platform sont entièrement prises en charge et les utilisateurs doivent suivre la documentation utilisateur de Jenkins pour définir leur jenkinsfile dans un travail ou le stocker dans un système de gestion du contrôle de la source.
La stratégie de construction Pipeline permet aux développeurs de définir un pipeline Jenkins qui sera utilisé par le plugin Jenkins pipeline. Le build peut être démarré, surveillé et géré par OpenShift Container Platform de la même manière que n'importe quel autre type de build.
Les flux de travail du pipeline sont définis dans un site jenkinsfile, soit directement intégré dans la configuration de construction, soit fourni dans un dépôt Git et référencé par la configuration de construction.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}