Note de traduction.: Dans la communauté Kubernetes, une tendance appelée GitOps gagne en popularité, comme nous l’avons personnellement constaté, KubeCon Europe 2019. Ce terme a été inventé relativement récemment (en réalité, cela a formellement eu lieu en août 2017 — note de la traduction.)
L'année dernière un nouvel abord de déploiement d’applications dans Kubernetes est apparu. Celui-ci est appelé GitOps, et il repose sur le principe fondamental selon lequel le suivi des versions des déploiements est effectué dans un environnement sécurisé d’un dépôt Git. Les principaux avantages de cette approche sont les suivants :
Versionnement des déploiements et historique des modifications:
- . L’état de l’ensemble du cluster est stocké dans le dépôt Git, et les déploiements ne peuvent être mis à jour que par des commits. De plus, toutes les modifications peuvent être suivies grâce à l’historique des commits.Rollbacks utilisant les commandes Git habituelles
- . La simplegit reset
permet de rétablir les modifications dans les déploiements ; les états précédents sont toujours accessibles.Contrôle d’accès déjà en place - . En général, un système Git contient de nombreuses données sensibles, c’est pourquoi la plupart des entreprises accordent une attention particulière à sa protection. Cette protection s’étend donc également aux opérations sur les déploiements.Politiques pour les déploiements
- . La plupart des systèmes Git prennent en charge dès le départ des politiques pour différentes branches — par exemple, seules les pull requests peuvent mettre à jour la master, et les modifications doivent être examinées et acceptées par un autre membre de l’équipe. Comme pour le contrôle d’accès, les mêmes politiques s’appliquent aux mises à jour des déploiements.Comme vous pouvez le voir, la méthode GitOps présente de nombreux avantages. Au cours de la dernière année, deux approches ont particulièrement gagné en popularité. L’une est basée sur le push, l’autre sur le pull. Avant d’examiner ces approches, jetons d’abord un œil à la manière dont se présentent les déploiements typiques de Kubernetes.
Méthodes de déploiement
Au cours des dernières années, différentes méthodes et outils de déploiement se sont établis dans Kubernetes :
Basé sur des modèles natifs de Kubernetes/Kustomize.
- Basé sur des modèles natifs Kubernetes/KustomizeC'est la manière la plus simple de déployer des applications dans Kubernetes. Le développeur crée des fichiers YAML de base et les applique. Pour éviter de réécrire constamment les mêmes modèles, Kustomize a été développé (il transforme les modèles Kubernetes en modules). Note de traduction.: Kustomize a été intégré dans kubectl avec .
- Les Charts Helm. Les Charts Helm permettent de créer des ensembles de modèles, des conteneurs init, des sidecars, etc., qui sont appliqués pour le déploiement d'applications avec des possibilités de configuration plus flexibles que dans l'approche basée sur des modèles. Au cœur de cette méthode se trouvent des fichiers YAML modélisés. Helm les remplit avec divers paramètres puis les envoie à Tiller — un composant de cluster qui les déploie dans le cluster et permet d'effectuer des mises à jour et des retours en arrière. Il est important de noter que, fondamentalement, Helm insère simplement les valeurs nécessaires dans les modèles et les applique ensuite de la même manière que cela se fait dans l'approche traditionnelle. (pour en savoir plus sur le fonctionnement de tout cela et comment l'utiliser, lisez notre — n.d.t.). Il existe une grande variété de Charts Helm prêts à l'emploi, couvrant un large éventail de tâches.
- Outils alternatifs. Il existe de nombreux outils alternatifs. Tous ont en commun qu'ils transforment certains fichiers-modèles en fichiers YAML Kubernetes compréhensibles et les appliquent ensuite.
Dans notre travail, nous utilisons constamment des Charts Helm pour des outils importants (puisqu'ils contiennent beaucoup de choses prêtes, ce qui facilite considérablement la vie) et des fichiers YAML Kubernetes « purs » pour déployer nos propres applications.
Pull & Push
Dans l'un de mes récents articles de blog, j'ai présenté un outil , qui permet de commettre des modèles dans un dépôt Git et de mettre à jour le déploiement après chaque engagement ou push de conteneur. Mon expérience montre que cet outil est l'un des principaux en matière de promotion de l'approche pull, il y a donc de fortes chances que je m'y réfère souvent. Si vous souhaitez en savoir plus sur son utilisation, voici .
NB! Tous les avantages de l'utilisation de GitOps restent valables pour les deux approches.
Approche basée sur Pull
La démarche pull repose sur le fait que toutes les modifications sont appliquées depuis l'intérieur du cluster. À l'intérieur du cluster, un opérateur vérifie régulièrement les dépôts Git et le registre Docker associés. Si des modifications y surviennent, l'état du cluster est mis à jour de l'intérieur. On considère généralement que ce processus est assez sûr, car aucun client externe n'a accès aux droits d'administrateur du cluster.
Avantages :
- Aucun client externe n'a de droits pour apporter des modifications au cluster, toutes les mises à jour sont effectuées de l'intérieur.
- Certaines outils permettent également de synchroniser les mises à jour des charts Helm et de les lier au cluster.
- Le registre Docker peut être scanné pour détecter de nouvelles versions. Si une nouvelle image apparaît, le dépôt Git et le déploiement sont mis à jour vers la nouvelle version.
- Les outils pull peuvent être répartis dans différents espaces de noms avec différents dépôts Git et droits d'accès. Cela permet d'appliquer un modèle multi-tenant. Par exemple, l'équipe A peut utiliser l'espace de nom A, l'équipe B l'espace de nom B, et l'équipe en charge de l'infrastructure peut utiliser un espace de nom global.
- En général, les outils sont assez légers.
- En combinaison avec des outils tels que l'opérateur , les secrets peuvent être stockés sous forme chiffrée dans le dépôt Git et extraits à l'intérieur du cluster.
- Il n'y a pas de lien avec les pipelines CD, car les déploiements se font à l'intérieur du cluster.
Inconvénients:
- Gérer les secrets des déploiements à partir des charts Helm est plus complexe que ceux ordinaires, car ils doivent d'abord être générés sous forme de sealed secrets, puis déchiffrés par l'opérateur interne, et ce n'est qu'après cela qu'ils deviennent accessibles pour l'outil pull. Ensuite, il est possible de lancer une release dans Helm avec les valeurs des secrets déjà déployés. Le moyen le plus simple est de créer un secret avec toutes les valeurs Helm utilisées pour le déploiement, de le déchiffrer et de le committer dans Git.
- En appliquant une approche pull, vous vous retrouvez lié à des outils fonctionnant avec des pulls. Cela limite la capacité à personnaliser le processus de déploiement des déploiements dans le cluster. Par exemple, travailler avec Kustomize est compliqué car il doit être exécuté avant que les modèles finaux n'arrivent dans Git. Je ne dis pas qu'il est impossible d'utiliser des outils séparés, mais leur intégration dans le processus de déploiement est plus difficile.
Approche basée sur le push
Dans l'approche push, un système externe (principalement des pipelines CD) déclenche des déploiements dans le cluster après un commit dans le dépôt Git ou en cas d'exécution réussie du pipeline CI précédent. Dans cette approche, le système a accès au cluster.
Avantages:
- La sécurité est déterminée par le dépôt Git et le pipeline de build.
- Déployer des charts Helm est plus facile, avec un support pour les plugins Helm.
- Gérer les secrets est plus simple, car les secrets peuvent être utilisés dans les pipelines et peuvent également être stockés dans Git de manière chiffrée (selon les préférences de l'utilisateur).
- Absence de dépendance à un outil spécifique, car on peut utiliser n'importe quel type d'outil.
- Les mises à jour des versions des conteneurs peuvent être initiées par le pipeline de build.
Inconvénients:
- Les données d'accès au cluster se trouvent à l'intérieur du système de build.
- La mise à jour des conteneurs de déploiement est toujours plus simple avec un processus pull.
- Forte dépendance au système CD, car les pipelines nécessaires sont peut-être initialement écrits pour Gitlab Runners, et ensuite l'équipe décidera de passer à Azure DevOps ou Jenkins… et il faudra effectuer la migration d'un grand nombre de pipelines de build.
Conclusion : Push ou Pull ?
Comme d'habitude, chaque approche a ses avantages et ses inconvénients. Certaines tâches sont plus faciles à réaliser avec l'une et plus difficiles avec l'autre. Au début, je déployais manuellement, mais après avoir trouvé quelques articles sur Weave Flux, j'ai décidé d'implémenter des processus GitOps pour tous les projets. Pour les modèles de base, cela s'est avéré facile, mais j'ai ensuite commencé à rencontrer des difficultés avec les charts Helm. À l'époque, Weave Flux n'offrait qu'une version embryonnaire de Helm Chart Operator, mais même maintenant, certaines tâches sont plus compliquées en raison de la nécessité de créer manuellement des secrets et de les appliquer. On peut dire que l'approche pull est beaucoup plus sécurisée, car les informations d'identification du cluster ne sont pas accessibles de l'extérieur, ce qui améliore tellement la sécurité qu'il en vaut la peine de faire des efforts supplémentaires.
Après avoir réfléchi un peu, j'en suis arrivé à une conclusion inattendue : ce n'est pas le cas. En ce qui concerne les composants nécessitant une protection maximale, on peut citer les systèmes de stockage de secrets, les systèmes CI/CD, et les dépôts Git. Les informations qu'ils contiennent sont très vulnérables et nécessitent une protection maximale. De plus, si quelqu'un réussit à pénétrer dans votre dépôt Git et peut y push du code, il pourra déployer tout ce qu'il souhaite (qu'il utilise une approche pull ou push), et s'infiltrer dans les systèmes du cluster. Ainsi, les composants les plus critiques nécessitant une protection sont le dépôt Git et les systèmes CI/CD, et non les identifiants du cluster. Si vous avez bien configuré les politiques et les mesures de sécurité pour des systèmes de ce type, et que les informations d'identification du cluster ne sont extraites dans les pipelines qu'en tant que secrets, la sécurité supplémentaire de l'approche pull pourrait ne pas être aussi précieuse que prévu à l'origine.
Donc, si l'approche pull est plus laborieuse et n'apporte aucun avantage en termes de sécurité, n'est-il pas logique d'utiliser uniquement l'approche push ? Mais quelqu'un pourrait dire qu'avec l'approche push, vous dépendez trop du système CD et qu'il serait peut-être mieux de ne pas le faire pour faciliter les futures migrations.
À mon avis (comme toujours), il convient d'utiliser ce qui convient le mieux à chaque situation ou de combiner les deux. Personnellement, j'utilise les deux approches : Weave Flux pour les déploiements basés sur le pull, qui incluent principalement nos propres services, et l'approche push avec Helm et ses plugins, facilitant l'application des charts Helm au cluster et permettant de créer des secrets sans problème. Je pense qu'il n'y aura jamais de solution unique convenant à tous les cas, car il y a toujours beaucoup de nuances qui dépendent de l'application spécifique. Dans ce sens, je recommande vivement GitOps — il facilite énormément la vie et augmente la sécurité.
J'espère que mon expérience sur ce sujet vous aidera à déterminer quelle méthode convient le mieux à votre type de déploiements, et je serais ravi d'entendre votre avis.
P.S. Note du traducteur
Dans les inconvénients du modèle pull, il y a le point selon lequel il est difficile de mettre dans Git des manifestes rendus, mais il n'y a pas d'inconvénient, car le pipeline CD dans le modèle pull vit séparément de la mise en production et devient en quelque sorte un pipeline de la catégorie Continuous Apply. Ainsi, il faudra encore plus d'efforts pour rassembler l'état de tous les déploiements et donner un accès à leur journal/statut, de préférence lié à un système CD.
Dans ce sens, le modèle push permet de donner au moins quelques garanties de mise en production, car la durée de vie du pipeline peut être égale à celle de la mise en production.
Nous avons essayé les deux modèles et en sommes arrivés aux mêmes conclusions que l'auteur de l'article :
- Le modèle pull convient pour organiser la mise à jour des composants système dans un grand nombre de clusters (voir ).
- Le modèle push basé sur GitLab CI convient bien pour le déploiement d'applications à l'aide de charts Helm. De plus, le déploiement des déploiements dans le cadre des pipelines est suivi à l'aide de l'outil . À ce propos, dans le cadre de ce projet, nous avons entendu en permanence "GitOps" lorsque nous discutions des problèmes urgents des ingénieurs DevOps à notre stand à KubeCon Europe 19.
P.P.S. du traducteur
Lisez aussi dans notre blog :
- «»;
- «»;
- «»;
- «».
Seuls les utilisateurs enregistrés peuvent participer au sondage. , s'il vous plaît.
Utilisez-vous GitOps ?
Oui, approche pull
Oui, push
Oui, pull + push
Oui, quelque chose d'autre
Non
30 utilisateurs ont voté. 10 utilisateurs ont abstenu.
Source : habr.com
