Red Hat Summit17.3. Didacticiel: Concepts OpenShift
17.3.1. La source à l’image (S2I)
La source à image (S2I) est une boîte à outils et un flux de travail pour créer des images de conteneurs reproductibles à partir du code source. Le S2I produit des images prêtes à l’emploi en insérant du code source dans une image de conteneur et en laissant le conteneur préparer le code source. En créant des images de constructeur auto-assemblant, vous pouvez versionner et contrôler vos environnements de construction exactement comme vous utilisez des images conteneur pour la version de vos environnements d’exécution.
17.3.1.1. Comment ça marche
Dans un langage dynamique tel que Ruby, les environnements de temps de construction et de temps d’exécution sont généralement les mêmes. En supposant que Ruby, Bundler, Rake, Apache, GCC et tous les autres paquets nécessaires pour configurer et exécuter une application Ruby sont déjà installés, une image de constructeur effectue les étapes suivantes:
- L’image du constructeur démarre un conteneur avec la source de l’application injectée dans un répertoire connu.
- Le processus de conteneur transforme ce code source en configuration exécutable appropriée. Il installe par exemple des dépendances avec Bundler et déplace le code source dans un répertoire où Apache a été préconfiguré pour rechercher le fichier de configuration Ruby.
- Il engage ensuite le nouveau conteneur et définit le point d’entrée de l’image pour être un script qui va démarrer Apache pour héberger l’application Ruby.
Dans le cas des langages compilés tels que C, C++, Go ou Java, les dépendances nécessaires à la compilation peuvent être supérieures à la taille des artefacts d’exécution. Afin de garder les images d’exécution petites, S2I active un processus de construction en plusieurs étapes, où un artefact binaire tel qu’un fichier exécutable est créé dans la première image du constructeur, extrait et injecté dans une deuxième image d’exécution qui place simplement le programme exécutable à l’emplacement correct.
À titre d’exemple, créer un pipeline de construction reproductible pour Tomcat et Maven:
- Créez une image constructeur contenant OpenJDK et Tomcat qui s’attend à ce qu’un fichier WAR soit injecté.
- Créez une deuxième image qui couche au-dessus de la première image Maven et toute autre dépendance standard, et s’attend à ce qu’un projet Maven soit injecté.
- Démarrez S2I à l’aide de la source de l’application Java et de l’image Maven pour créer la WAR de l’application souhaitée.
- Démarrez S2I une deuxième fois en utilisant le fichier WAR de l’étape précédente et l’image Tomcat initiale pour créer l’image d’exécution.
En plaçant la logique de construction à l’intérieur des images et en combinant les images en plusieurs étapes, l’environnement d’exécution est proche de l’environnement de construction sans nécessiter le déploiement d’outils de construction à la production.
17.3.1.2. Avantages S2I
- La reproductibilité
- Permettre aux environnements de construction d’être rigoureusement versionnés en les encapsulant dans une image conteneur et en définissant une interface simple de code source injecté pour les appelants. Les constructions reproductibles sont une exigence clé pour permettre des mises à jour de sécurité et une intégration continue dans l’infrastructure conteneurisée, et les images du constructeur aident à assurer la répétabilité et la possibilité d’échanger des temps d’exécution.
- Flexibilité
- Chaque système de construction existant qui peut fonctionner sur Linux peut fonctionner à l’intérieur d’un conteneur, et chaque constructeur individuel peut également faire partie d’un pipeline plus grand. Les scripts qui traitent le code source de l’application peuvent être injectés dans l’image du constructeur, permettant aux auteurs d’adapter les images existantes pour permettre la gestion de la source.
- La vitesse
- Au lieu de construire plusieurs couches dans un seul Dockerfile, S2I encourage les auteurs à représenter une application dans une seule couche d’image. Cela permet d’économiser du temps pendant la création et le déploiement et permet un meilleur contrôle sur la sortie de l’image finale.
- La sécurité
- Dockerfiles sont exécutés sans la plupart des contrôles opérationnels normaux des conteneurs. Ils s’exécutent généralement comme racine et ont accès au réseau de conteneurs. Le S2I peut contrôler les autorisations et privilèges disponibles pour l’image du constructeur depuis le lancement de la construction dans un seul conteneur. De concert avec des plateformes comme OpenShift, S2I permet aux administrateurs de contrôler les privilèges dont disposent les développeurs au moment de la construction.
17.3.2. Itinéraires
L’itinéraire OpenShift expose un service à un nom d’hôte afin que les clients externes puissent l’atteindre par leur nom. Lorsqu’un objet Route est créé sur OpenShift, il est récupéré par l’équilibreur de charge HAProxy intégré pour exposer le service demandé et le rendre disponible en externe avec la configuration donnée.
À l’instar de l’objet de Kubernetes Ingress, Red Hat a créé le concept de route pour combler un besoin et a ensuite contribué aux principes de conception derrière elle à la communauté, ce qui a fortement influencé le design de l’Ingress. L’itinéraire comporte des caractéristiques supplémentaires, comme on peut le voir dans le tableau suivant:
| Caractéristique | Entrée sur OpenShift | Itinéraire sur OpenShift |
|---|---|---|
| Kubernetes objet standard | A) X | |
| Accès externe aux services | A) X | A) X |
| Des sessions persistantes (collantes) | A) X | A) X |
| Les stratégies d’équilibrage de la charge (par exemple, le vol à rondes) | A) X | A) X |
| Limite de vitesse et d’étroitesse | A) X | A) X |
| Liste blanche IP | A) X | A) X |
| Terminaison de bord TLS pour une sécurité améliorée | A) X | A) X |
| Le recryptage TLS pour une sécurité améliorée | A) X | |
| Le passhtrough TLS pour une sécurité améliorée | A) X | |
| Backends pondérés multiples (trafic partagé) | A) X | |
| Des noms d’hôte basés sur des modèles générés | A) X | |
| Domaines wildcard | A) X |
La résolution DNS pour un nom d’hôte est gérée séparément du routage. Il se peut que votre administrateur ait configuré un domaine cloud qui se résoudra toujours correctement sur le routeur ou modifie indépendamment vos enregistrements DNS nom d’hôte indépendants pour le résoudre au routeur.
L’itinéraire individuel peut remplacer certaines valeurs par défaut en fournissant des configurations spécifiques dans ses annotations.
17.3.3. Flux d’images
Le flux d’images stocke une cartographie des balises en images, des métadonnées qui sont appliquées lorsque les images sont étiquetées dans un flux, et une référence facultative à un référentiel d’images Docker sur un registre.
17.3.3.1. Avantages du flux d’images
En utilisant un flux d’images, il est plus facile de modifier une balise pour une image de conteneur. Dans le cas contraire, pour changer manuellement une balise, vous devez télécharger l’image, la modifier localement, puis tout repousser. La promotion des applications en modifiant manuellement une balise, puis la mise à jour de l’objet de déploiement implique de nombreuses étapes.
Avec les flux d’images, vous téléchargez une fois une image conteneur, puis vous gérez ses balises virtuelles en interne dans OpenShift. Dans un projet, vous pouvez utiliser la balise de développement et ne changer qu’une référence à elle en interne, tandis que dans la production, vous pouvez utiliser une balise de production et la gérer en interne. Il n’est pas nécessaire de traiter le registre.
Il est également possible d’utiliser des flux d’images en conjonction avec les configurations de déploiement pour définir un déclencheur qui démarrera un déploiement dès qu’une nouvelle image apparaît ou qu’une balise change de référence.
17.3.4. Constructions
La construction 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. L’objet BuildConfig est la définition de l’ensemble du processus de construction.
La plate-forme de conteneurs OpenShift exploite Kubernetes en créant des conteneurs au format Docker à partir de la création d’images et en les poussant vers un registre d’images de conteneur.
Construire des objets partagent des caractéristiques communes:
- Entrées pour une construction
- Exigences pour compléter un processus de construction
- Journalisation du processus de construction
- La publication de ressources issues de constructions réussies
- La publication du statut final de la construction
Les builds profitent des restrictions de ressources, spécifiant des limites sur les ressources telles que l’utilisation du CPU, l’utilisation de la mémoire et le temps d’exécution de la construction ou du pod.
Ressources supplémentaires
'%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}