Pourquoi nous avons besoin de déploiements automatisés
Au cours de la dernière décennie, il y a eu un changement de paradigme dans la façon dont les applications sont écrites, déployées et gérées. Les entreprises ont adopté le cloud natif comme stratégie pour gérer les applications. En conséquence, les applications sont passées à une architecture de microservices. Les plateformes de déploiement sont désormais gérées par des clouds ou Kubernetes.
Lorsque les applications sont écrites de manière microservices, une seule application est divisée en plusieurs petites applications. Chacune de ces petites applications est entièrement indépendante. Ils peuvent avoir leur propre base de données, serveur de cache, files d’attente de messagerie et toute infrastructure d’entreprise de ce type.
Avec de tels changements, la charge d’un ingénieur d’exploitation augmente considérablement. Les applications peuvent être granulaires, mais il doit en déployer et en gérer plusieurs plutôt qu’une seule. Automatiser la tâche est la technique la plus efficace pour la rendre plus facile. Si vous décidez de déployer vos applications à l’aide de Kubernetes, il y aura plus de justifications pour le faire. Pour chaque application à déployer dans Kubernetes, vous devez écrire de nombreux fichiers manifestes. Encore une fois, chaque application contient de nombreux composants déployables, tels qu’une base de données, une API, un frontal, une couche d’accès à la base de données et bien d’autres. Pour chaque composant, il y aurait un ou plusieurs fichiers manifestes. Ainsi, pour une suite de microservices, on peut finir par déployer des centaines de fichiers manifestes Kubernetes. Chacun de ces fichiers doit être déployé dans un ordre particulier sans faute. Sinon, le déploiement risque d’être corrompu ou d’échouer.
Donc, ce qu’il faut, c’est un outil qui pourrait faire ce qui suit :
- Comprendre les microservices et les fichiers manifestes.
- Comprenez l’ordre d’envoi des fichiers vers Kubernetes.
- Considérez la suite complète de microservices comme une seule application.
- Restauration et mise à niveau de l’application comme une seule unité avec presque facilité.
- Faites-le de manière sécurisée.
Il existe plusieurs outils disponibles pour y parvenir. Le plus populaire d’entre eux est Helm.
Qu’est-ce que Helm ?
Helm est un logiciel open source qui aide à installer, mettre à niveau, restaurer et désinstaller les charges de travail Kubernetes dans un cluster Kubernetes. Helm le fait presque sans effort. Il est également appelé gestionnaire de packages pour Kubernetes. Avec Helm, les déploiements complexes de Kubernetes peuvent être installés en toute simplicité. Une très grande suite de microservices peut être installée, désinstallée et gérée avec une seule commande. Helm prend également en charge l’exécution de tests de fumée avant ou après l’installation.
Notez simplement que le terme « installation » est utilisé à la place de « déploiement ». En effet, Helm considère les déploiements comme des applications installées sur une plate-forme, tout comme n’importe quel autre gestionnaire de packages installe des packages sur une plate-forme. Par exemple, yum et apt sont des gestionnaires de packages populaires pour les distributions Linux, et ils installent des packages.
Pour utiliser Helm, nous devons stocker nos fichiers manifestes Kubernetes dans une structure de dossiers spécifique. Cette structure de dossiers est traitée comme un seul package. Les packages Helm sont appelés graphiques. Les graphiques peuvent être imbriqués pour faciliter l’installation de plusieurs applications à l’aide d’une structure de dossiers unique. Pour faciliter la gestion du graphique ainsi que de plusieurs versions du même graphique, les dossiers peuvent également être archivés et stockés dans un référentiel.
La plupart des entreprises publient désormais leurs artefacts Kubernetes sous forme de graphiques et les téléchargent dans des référentiels d’artefacts publics de la CNCF. Les cartes peuvent être stockées localement dans un dossier de fichiers, dans un référentiel de cartes privé local ou dans un référentiel de cartes public. Helm est capable de lire les cartes stockées sur l’un des trois et est capable de les extraire et de les installer.
Comment fonctionne Helm
Nous devrions avoir une idée du fonctionnement de la barre. Avant cela, nous en saurons un peu plus sur l’architecture et les composants de la barre. Ensuite, il sera plus facile de savoir comment fonctionne la barre.
Architecture
Helm contient trois concepts clés avec lesquels nous devons nous familiariser.
Graphique
Comme nous le savons, un graphique est un package qui contient tous les artefacts Kubernetes nécessaires et quelques fichiers spécifiques à Helm dans une certaine structure de dossiers. Tous ces fichiers sont nécessaires pour installer une application Kubernetes.
Configuration
La configuration se compose d’un ou plusieurs fichiers yaml et contient les informations de configuration nécessaires au déploiement d’une application Kubernetes. Ces configurations sont fusionnées dans le tableau pendant les opérations de barre.
Sortie
Une version est appelée l’instance en cours d’exécution d’un graphique. Le graphique est fusionné avec la configuration, et cela installe avec succès une application en tant que version. Un graphique peut avoir plusieurs versions.
Composants
Helm, jusqu’à la version deux, travaillait avec un modèle client-serveur. Cependant, avec la version la plus récente, Helm 3, Helm fonctionne avec un modèle client + bibliothèque. Helm est écrit en langage GO. Lorsque nous installons Helm, nous installons à la fois la bibliothèque Helm et le client.
Client barre
Le client Helm est l’interface de ligne de commande pour travailler avec le cluster Kubernetes. Il lit les informations de Rathercluster à partir du fichier ~/.kube/.config et pointe toujours vers le cluster actuel. Toute opération que l’utilisateur doit invoquer doit être poussée via le client Helm.
Le client Helm est responsable du développement des graphiques locaux, de la gestion des référentiels de graphiques, de la gestion des versions, de l’interaction avec la bibliothèque Helm et de l’installation, de la mise à niveau, de la restauration et de la désinstallation des applications.
Bibliothèque Helm
La bibliothèque Helm est le véritable moteur Helm. Il stocke la logique de toutes les opérations Helm appelées via le client Helm. Comme indiqué précédemment, la logique est écrite en GO. Il interagit avec le serveur d’API Kubernetes pour appeler les opérations Helm. Il utilise REST+JSON pour ses interactions avec le serveur d’API Kubernetes. Il n’utilise pas sa propre base de données. Au lieu de cela, il stocke toutes les informations de configuration dans Kubernetes ETCD.
Lorsque Helm Client émet une commande, la bibliothèque intègre les artefacts Kubernetes et les informations de configuration et génère les fichiers manifestes finaux à envoyer sous forme de message POST au serveur d’API KUBE.
Commandes de barre populaires
Ici, nous énumérerons les commandes Helm les plus utilisées et les plus puissantes. Ces commandes sont utilisées quotidiennement par un opérateur Helm.
Toutes les commandes ci-dessus sont extraites de la documentation Helm. Pour en savoir plus sur les commandes et autres paramètres, veuillez cliquer sur les commandes, et le lien hypertexte vous amènera sur les pages spécifiques vous informant davantage sur les commandes.
Tutoriels de base de Helm
Dans cette section, nous examinerons le cas d’utilisation du déploiement d’une application Kubernetes dans un cluster Kubernetes. Il montrera comment récupérer un graphique à partir d’un référentiel et le déployer sur votre cluster. Nous allons également désinstaller l’application.
Conditions préalables
Pour ce didacticiel, nous supposons que l’utilisateur possède des connaissances de base sur les commandes Kubernetes et Linux. Nous supposons également que vous avez accès à un cluster Kubernetes. Sinon, créez-en un en utilisant Minikube ou utilisez Katakoda. Pour le tutoriel, j’utilise Katakoda.
Pas
Installer Helm
La barre a pu être installée très facilement. Toutes les étapes sont mentionnées sur la page de documentation de Helm. Il existe des sections distinctes pour différents systèmes d’exploitation. Choisissez la section en fonction du système d’exploitation que vous utilisez. Une fois Helm installé avec succès, testez la version et continuez.
Créer un graphique local Helm
Nous allons créer un graphique Helm de base à l’aide de la commande « helm create ». Cette commande créera une charte Helm entièrement fonctionnelle avec tous les fichiers nécessaires et une structure de dossiers appropriée. Vous aurez une représentation visuelle d’un graphique Helm. Ce graphique tentera de déployer une application nginx sur le cluster avec tous les objets d’API Kubernetes requis, tels qu’un déploiement, un service, une carte de configuration, etc. Nous n’installerons pas puis ne supprimerons pas le graphique.
Utilisez les deux commandes suivantes :
1. barre créer nginx-app
2. arbre nginx-app
Vous pourrez voir un nouveau dossier appelé « nginx-app » créé avec quelques fichiers et sous-dossiers. Ouvrez et lisez les fichiers tels que Chart.yaml, values.yaml ou deployment.yaml. La description de chaque fichier dépasse le cadre de cet article. Enfin, supprimez le graphique en exécutant la commande suivante.
rm -rf nginx-app
Déployer un graphique Helm à partir d’un référentiel distant
Dans cette section, nous allons connecter notre client de ligne de commande Helm à un référentiel de graphiques distant et extraire un graphique du référentiel pour l’installer sur notre cluster. J’utiliserai Bitnami comme référentiel de cartes à distance. À partir du référentiel Bitnami, je vais rechercher et installer MySQL. Utilisez les commandes suivantes :
helm repo ajouter bitnami
liste de dépôt de barre
Maintenant que le référentiel a été ajouté, nous allons utiliser les commandes suivantes pour rechercher MySQL et installer le graphique.
helm recherche repo bitnami/mysql
barre installer mysql bitnami/mysql
Copiez la sortie de la dernière commande dans un fichier contenant des instructions sur la façon de se connecter au conteneur MySQL, comme indiqué dans l’image ci-dessous.
Vérifiez que la version est réussie à l’aide des commandes ci-dessous.
liste de barre
kubectl obtient tout
La commande kubectl vous donnera la liste des objets API que la version a créés.
Désinstaller le graphique
Désinstallez maintenant la version en utilisant la commande « helm désinstaller mysql.” Cela supprimera la version, n’en laissant aucune trace. Utilisation « kubectl obtient tout” pour vérifier si un autre élément a été oublié par la version.
Conclusion
Il s’agissait donc d’un court didacticiel dans lequel nous avons appris ce qu’est Helm et comment nous pouvons installer, créer et désinstaller des graphiques Helm. Plus précisément, Helm est le gestionnaire de packages Kubernetes, qui construit des packages appelés graphiques et installe, met à jour et annule et les désinstalle à l’aide de la ligne de commande Helm. Vous pouvez essayer plus en utilisant la documentation Helm.