Bonjour, habrozhiteli!Avec le développement des microservices et des conteneurs, les approches de la conception, de la création et du lancement de logiciels ont changé. Explorez les nouveaux modèles et principes de conception requis pour implémenter les applications cloud Kubernetes.Ce livre est destiné aux développeurs qui souhaitent concevoir et développer des applications basées sur le cloud pour la plate-forme Kubernetes. Le plus grand avantage en sera les lecteurs qui sont au moins un peu familiers avec les conteneurs et qui souhaitent atteindre un nouveau niveau. Chaque modèle de conception est une description du problème réel, et la solution est prise en charge et illustrée par des exemples de code spécifiques.Extrait. Motif Sidecar
Le modèle Sidecar (Trailer) consiste à définir un conteneur qui étend les capacités d'un conteneur existant sans le modifier. C'est l'un des modèles de conteneurs fondamentaux qui vous permet de créer des conteneurs hautement spécialisés qui fonctionnent en étroite collaboration. Dans ce chapitre, vous apprendrez tout ce qui concerne l'idée du modèle Sidecar (bande-annonce). Et dans les chapitres 16 et 17, vous vous familiariserez avec des variantes spécialisées de ce modèle - les modèles Adapter et Ambassador, respectivement.Tâche
Containers est une technologie d'emballage populaire qui permet aux développeurs et aux administrateurs système de créer, de livrer et d'exécuter des applications de manière unifiée. Un conteneur représente la frontière naturelle d'une unité fonctionnelle avec son exécution, son cycle de publication, son API et l'équipe de développement à laquelle il appartient. Un conteneur typique agit comme un processus sous Linux - résout un problème et le fait bien - et est créé en supposant la possibilité de remplacement et de réutilisation. Ce dernier est particulièrement important car il vous permet de créer rapidement des applications à l'aide de conteneurs spécialisés existants.Actuellement, pour envoyer une requête HTTP, vous n'avez pas besoin d'écrire une bibliothèque cliente, utilisez simplement celle existante. De même, pour maintenir le site Web, vous n'avez pas besoin de créer un conteneur avec un serveur Web, utilisez simplement celui existant. Cette approche permet aux développeurs de ne pas réinventer la roue et de créer un écosystème avec moins de conteneurs de meilleure qualité pour la maintenance. Cependant, afin de pouvoir utiliser des conteneurs réutilisables hautement spécialisés, des moyens d'étendre leurs capacités et des moyens d'organiser les interactions entre eux sont nécessaires. Le modèle Sidecar (bande-annonce) décrit une telle façon d'organiser les interactions lorsqu'un conteneur étend les capacités d'un autre conteneur existant.Décision
Dans le chapitre 1, nous avons vu comment les pods vous permettent de combiner plusieurs conteneurs en un seul bloc. Dans les coulisses, au moment de l'exécution, under est également un conteneur, mais il démarre comme un processus suspendu (en utilisant littéralement la commande pause) devant tous les autres conteneurs dans l'âtre. Il ne fait que stocker tous les espaces de noms Linux que les conteneurs d'applications utilisent pour interagir tout au long du cycle de vie du pod. En plus de ce détail de mise en œuvre, toutes les caractéristiques que fournit l'abstraction du foyer présentent également un intérêt.Under est une primitive tellement fondamentale qu'elle est présente dans de nombreuses plates-formes cloud, bien que sous des noms différents, mais toujours avec des capacités similaires. Under, en tant qu'unité de déploiement, impose certaines restrictions d'exécution à ses conteneurs. Par exemple, tous les conteneurs sont déployés sur un nœud et ont un cycle de vie commun. De plus, under permet à ses conteneurs d'utiliser des volumes partagés et d'échanger des données via un réseau local ou en utilisant des outils de communication interprocessus hôte. C'est pourquoi les utilisateurs combinent des conteneurs en modules. Le modèle Sidecar (Trailer), parfois également appelé Sidekick (Companion), décrit le scénario de l'ajout d'un conteneur au dessous pour étendre les capacités d'un autre conteneur.Un exemple typique illustrant ce modèle est le serveur HTTP et le mécanisme de synchronisation avec le référentiel Git. Le conteneur de serveur HTTP résout les problèmes associés à la maintenance des fichiers via HTTP et ne sait pas comment et d'où proviennent ces fichiers. De même, le seul but d'un conteneur qui se synchronise avec Git est de synchroniser les données du système de fichiers local avec les données du serveur Git. Il ne se soucie pas de ce qui arrive aux fichiers après la synchronisation, sa seule tâche est de synchroniser le contenu du dossier local avec le contenu du serveur Git distant. Le listing 15.1 fournit une définition de pod avec ces deux conteneurs configurés pour utiliser le volume pour le partage de fichiers.Listing 15.1. Implémentation du modèle Sidecar (bande-annonce)apiVersion: v1
kind: Pod
metadata:
name: web-app
spec:
containers:
- name: app
image: docker.io/centos/httpd ❶
ports:
- containerPort: 80
volumeMounts:
- mountPath: /var/www/html ❸
name: git
- name: poll
image: axeclbr/git ❷
volumeMounts:
- mountPath: /var/lib/data ❸
name: git
env:
- name: GIT_REPO
value: https://github.com/mdn/beginner-html-site-scripted
command:
- "sh"
- "-c"
- "git clone $(GIT_REPO) . && watch -n 600 git pull"
workingDir: /var/lib/data
volumes:
- emptyDir: {}
name: git
(1) Le conteneur d'application principal servant les fichiers via HTTP.(2) Conteneur auxiliaire (Remorque) agissant en parallèle et recevant des données du serveur Git.(3) Un dossier partagé pour l'échange de données entre les conteneurs principal et secondaire.Cet exemple montre comment un conteneur de synchronisation avec Git ajoute du contenu à servir par un serveur HTTP et le maintient à jour. Vous pouvez également dire que les deux conteneurs fonctionnent en étroite coopération et sont tout aussi importants, mais le modèle Sidecar (Trailer) suppose la présence d'un conteneur principal (principal) et auxiliaire qui élargit le comportement collectif. Habituellement, le principal est répertorié en premier dans la liste des conteneurs et représente le conteneur par défaut (qui est lancé par la commande kubectl exec, par exemple).Ce modèle simple, illustré à la fig. 15.1 assure une coopération étroite des conteneurs lors de l'exécution et permet en même temps de partager des tâches qui peuvent appartenir à des équipes distinctes de développeurs utilisant différents langages de programmation, avec différents cycles de publication de nouvelles versions, etc. Il favorise également l'interchangeabilité et la réutilisation des conteneurs - en ce sens que le serveur HTTP et le mécanisme de synchronisation Git peuvent être réutilisés dans d'autres applications et avec d'autres paramètres, à la fois indépendamment et conjointement avec d'autres conteneurs.Explication
Il a déjà été dit ci-dessus que les images de conteneurs sont similaires aux classes, et les conteneurs sont comme des objets dans la programmation orientée objet (POO). Poursuivant cette analogie, nous pouvons comparer l'expansion des capacités des conteneurs avec l'héritage dans OOP, et le travail conjoint de plusieurs conteneurs dans le foyer avec la réception d'une composition dans OOP. Ces deux approches permettent la réutilisation du code, mais l'héritage définit une relation plus étroite et représente la relation «est» entre les conteneurs.La composition dans le foyer représente la relation «a» - elle est plus flexible car elle ne nécessite pas la combinaison de récipients lors de l'assemblage, ce qui permet de changer les récipients plus tard dans la définition du foyer. Mais la composition implique également la présence de plusieurs conteneurs (processus) fonctionnant simultanément, dont l'opérabilité doit être vérifiée et redémarrée et qui consomment des ressources, ainsi que le conteneur d'application principal. Le modèle Sidecar (Trailer) implique la création de petits conteneurs auxiliaires qui consomment un minimum de ressources, mais vous décidez de démarrer un processus distinct ou de mieux combiner toutes les tâches dans un conteneur principal.D'un autre point de vue, la composition des conteneurs est similaire à la programmation orientée aspect, lorsque, à l'aide de conteneurs supplémentaires, des capacités orthogonales (indépendantes) qui ne sont pas liées au conteneur principal sont ajoutées au sous-programme. Ces derniers mois, le modèle Sidecar (Trailer) gagne en popularité, en particulier pour résoudre les tâches de gestion de réseau, les services de surveillance, où chaque service se présente également sous la forme de conteneurs auxiliaires.»Vous trouverez plus d'informations sur le livre sur le site Web de l'éditeur» Sommaire» Extraitpour Khabrozhiteley 25% de réduction sur les coupons - KubernetesLors du paiement de la version papier du livre, un livre électronique est envoyé par e-mail.