Noter. trad.: Dans la communauté Kubernetes, une tendance appelée GitOps gagne en popularité, comme nous l'avons personnellement constaté, KubeCon Europe 2019. Ce terme était relativement récent par le patron de Weaveworks - Alexis Richardson - et désigne l'utilisation d'outils familiers aux développeurs (principalement Git, d'où le nom) pour résoudre des problèmes opérationnels. Nous parlons en particulier du fonctionnement de Kubernetes en stockant ses configurations dans Git et en déployant automatiquement les modifications sur le cluster. Matthias Jg parle de deux approches pour ce déploiement dans cet article.
В прошлом году (en fait, cela s'est officiellement produit en août 2017 - traduction approximative.) Il existe une nouvelle approche pour déployer des applications dans Kubernetes. Cela s'appelle GitOps et repose sur l'idée de base selon laquelle les versions de déploiement sont suivies dans l'environnement sécurisé d'un référentiel Git.
Les principaux avantages de cette approche sont les suivants ::
- Versionnement du déploiement et historique des modifications. L'état de l'ensemble du cluster est stocké dans un référentiel Git et les déploiements sont mis à jour uniquement via des validations. De plus, toutes les modifications peuvent être suivies à l'aide de l'historique des validations.
- Annulations à l'aide de commandes Git familières... Plaine
git resetvous permet de réinitialiser les modifications dans les déploiements ; les états passés sont toujours disponibles. - Contrôle d'accès prêt. En règle générale, un système Git contient de nombreuses données sensibles, c'est pourquoi la plupart des entreprises accordent une attention particulière à leur protection. Cette protection s’applique donc également aux opérations avec déploiements.
- Politiques de déploiement. La plupart des systèmes Git prennent en charge de manière native les politiques branche par branche : par exemple, seules les demandes d'extraction peuvent mettre à jour le maître, 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 de déploiement.
Comme vous pouvez le constater, la méthode GitOps présente de nombreux avantages. Au cours de la dernière année, deux approches ont gagné en popularité. L’un est basé sur le push, l’autre est basé sur le pull. Avant de les examiner, voyons d’abord à quoi ressemblent les déploiements Kubernetes typiques.
Méthodes de déploiement
Ces dernières années, Kubernetes a mis en place diverses méthodes et outils de déploiement :
- Basé sur des modèles natifs Kubernetes/Kustomize. C'est le moyen le plus simple de déployer des applications sur Kubernetes. Le développeur crée les 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). Noter. trad.: Kustomize a été intégré à Kubectl avec .
- Cartes de barre. Les graphiques Helm vous permettent de créer des ensembles de modèles, de conteneurs d'initialisation, de side-cars, etc., qui sont utilisés pour déployer des applications avec des options de personnalisation plus flexibles que dans une approche basée sur des modèles. Cette méthode est basée sur 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 sur le cluster et autorise les mises à jour et les restaurations. L'important est que Helm insère essentiellement les valeurs souhaitées dans les modèles, puis les applique de la même manière que dans l'approche traditionnelle. (en savoir plus sur comment tout cela fonctionne et comment vous pouvez l'utiliser dans notre - environ. trad.). Il existe une grande variété de cartes Helm prêtes à l'emploi couvrant un large éventail de tâches.
- Outils alternatifs. Il existe de nombreux outils alternatifs. Ce qu'ils ont tous en commun, c'est qu'ils transforment certains fichiers modèles en fichiers YAML lisibles par Kubernetes, puis les utilisent.
Dans notre travail, nous utilisons constamment des graphiques Helm pour les outils importants (car ils ont déjà beaucoup de choses prêtes, ce qui rend la vie beaucoup plus facile) et des fichiers YAML Kubernetes « purs » pour déployer nos propres applications.
Tirer et pousser
Dans l'un de mes récents articles de blog, j'ai présenté l'outil , qui vous permet de valider des modèles dans le référentiel Git et de mettre à jour le déploiement après chaque validation ou push du conteneur. Mon expérience montre que cet outil est l’un des principaux pour promouvoir l’approche pull, j’y ferai donc souvent référence. Si vous souhaitez en savoir plus sur son utilisation, c'est ici .
NB! Tous les avantages de l'utilisation de GitOps restent les mêmes pour les deux approches.
Approche basée sur le pull
L'approche pull est basée sur le fait que toutes les modifications sont appliquées depuis l'intérieur du cluster. Il y a un opérateur à l'intérieur du cluster qui vérifie régulièrement les référentiels Git et Docker Registry associés. Si des modifications leur sont apportées, l'état du cluster est mis à jour en interne. Ce processus est généralement considéré comme très sécurisé, puisqu'aucun client externe n'a accès aux droits d'administrateur du cluster.
Avantages:
- Aucun client externe n'a le droit d'apporter des modifications au cluster ; toutes les mises à jour sont déployées depuis l'intérieur.
- Certains outils vous permettent également de synchroniser les mises à jour des graphiques Helm et de les lier au cluster.
- Docker Registry peut être analysé à la recherche de nouvelles versions. Si une nouvelle image est disponible, le référentiel et le déploiement Git sont mis à jour vers la nouvelle version.
- Les outils Pull peuvent être distribués sur différents espaces de noms avec différents référentiels et autorisations Git. Grâce à cela, un modèle multi-tenant peut être utilisé. Par exemple, l'équipe A peut utiliser l'espace de noms A, l'équipe B peut utiliser l'espace de noms B et l'équipe d'infrastructure peut utiliser l'espace global.
- En règle générale, les outils sont très légers.
- Combiné avec des outils tels que l'opérateur , les secrets peuvent être stockés chiffrés dans un référentiel Git et récupérés au sein du cluster.
- Il n'existe aucune connexion aux pipelines CD puisque les déploiements ont lieu au sein du cluster.
Moins:
- La gestion des secrets de déploiement à partir des graphiques Helm est plus difficile que les secrets classiques, car ils doivent d'abord être générés sous la forme, par exemple, de secrets scellés, puis déchiffrés par un opérateur interne, et seulement après cela, ils deviennent disponibles pour l'outil d'extraction. Ensuite, vous pouvez exécuter la version dans Helm avec les valeurs des secrets déjà déployés. Le moyen le plus simple consiste à créer un secret avec toutes les valeurs Helm utilisées pour le déploiement, à le déchiffrer et à le valider dans Git.
- Lorsque vous adoptez une approche pull, vous devenez lié aux outils pull. Cela limite la possibilité de personnaliser le processus de déploiement dans un cluster. Par exemple, Kustomize est compliqué par le fait qu'il doit s'exécuter avant que les modèles finaux ne soient validés dans Git. Je ne dis pas que vous ne pouvez pas utiliser d'outils autonomes, mais ils sont plus difficiles à intégrer dans votre processus de déploiement.
Approche basée sur le push
Dans l'approche push, un système externe (principalement des pipelines CD) lance les déploiements sur le cluster après une validation dans le référentiel Git ou si le pipeline CI précédent réussit. Dans cette approche, le système a accès au cluster.
Avantages:
- La sécurité est déterminée par le référentiel Git et le pipeline de build.
- Le déploiement de graphiques Helm est plus simple et prend en charge les plugins Helm.
- Les secrets sont plus faciles à gérer car ils peuvent être utilisés dans des pipelines et peuvent également être stockés cryptés dans Git (selon les préférences de l'utilisateur).
- Il n’y a pas de connexion avec un outil spécifique, puisque n’importe quel type peut être utilisé.
- Les mises à jour de version du conteneur peuvent être initiées par le pipeline de build.
Moins:
- Les données d'accès au cluster se trouvent à l'intérieur du système de construction.
- La mise à jour des conteneurs de déploiement est encore plus facile avec un processus pull.
- Forte dépendance au système CD, puisque les pipelines dont nous avons besoin ont peut-être été écrits à l'origine pour Gitlab Runners, et l'équipe décide alors de passer à Azure DevOps ou Jenkins... et devra migrer un grand nombre de pipelines de build.
Résultats : pousser ou tirer ?
Comme c’est généralement le cas, chaque approche a ses avantages et ses inconvénients. Certaines tâches sont plus faciles à accomplir avec l’une et plus difficiles avec l’autre. Au début, je faisais des déploiements manuellement, mais après être tombé sur 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, c'était facile, mais j'ai ensuite commencé à rencontrer des difficultés avec les graphiques Helm. À l'époque, Weave Flux ne proposait qu'une version rudimentaire de Helm Chart Operator, mais même aujourd'hui, certaines tâches sont plus difficiles en raison de la nécessité de créer manuellement des secrets et de les appliquer. On pourrait affirmer que l'approche pull est beaucoup plus sécurisée car les informations d'identification du cluster ne sont pas accessibles en dehors du cluster, ce qui la rend tellement plus sécurisée que cela en vaut la peine.
Après réflexion, je suis arrivé à la conclusion inattendue que ce n’était pas le cas. Si nous parlons de composants qui nécessitent une protection maximale, cette liste comprendra le stockage secret, les systèmes CI/CD et les référentiels Git. Les informations qu’ils contiennent sont très vulnérables et nécessitent une protection maximale. De plus, si quelqu'un accède à votre référentiel Git et peut y envoyer du code, il peut déployer ce qu'il veut (que ce soit en mode pull ou push) et infiltrer les systèmes du cluster. Ainsi, les composants les plus importants qui doivent être protégés sont le référentiel Git et les systèmes CI/CD, et non les informations d'identification du cluster. Si vous disposez de politiques et de contrôles de sécurité bien configurés pour ces types de systèmes, et que les informations d'identification du cluster ne sont extraites dans les pipelines que sous forme de secrets, la sécurité supplémentaire d'une approche pull n'est peut-être pas aussi précieuse qu'on le pensait initialement.
Ainsi, si l’approche pull demande plus de main d’œuvre et n’apporte aucun avantage en matière de sécurité, n’est-il pas logique d’utiliser uniquement l’approche push ? Mais quelqu'un pourrait faire valoir que dans l'approche push, vous êtes trop lié au système CD et, peut-être, il vaut mieux ne pas le faire afin qu'il soit plus facile d'effectuer des migrations à l'avenir.
À mon avis (comme toujours), vous devez utiliser ce qui convient le mieux à un cas ou à une combinaison particulière. Personnellement, j'utilise les deux approches : Weave Flux pour les déploiements basés sur le pull qui incluent principalement nos propres services, et une approche push avec Helm et les plugins, qui facilite l'application des graphiques Helm au cluster et vous permet de créer des secrets de manière transparente. Je pense qu’il n’y aura jamais de solution unique adaptée à tous les cas, car il y a toujours beaucoup de nuances et elles dépendent de l’application spécifique. Cela étant dit, je recommande fortement GitOps – cela rend la vie beaucoup plus facile et améliore la sécurité.
J'espère que mon expérience sur ce sujet vous aidera à décider quelle méthode est la plus adaptée à votre type de déploiement, et je serais heureux de connaître votre avis.
PS Note du traducteur
L'inconvénient du modèle pull est qu'il est difficile de mettre les manifestes rendus dans Git, mais il n'y a aucun inconvénient à ce que le pipeline CD dans le modèle pull soit séparé du déploiement et devienne essentiellement un pipeline de catégories. Application continue. Par conséquent, encore plus d'efforts seront nécessaires pour collecter leur statut à partir de tous les déploiements et fournir d'une manière ou d'une autre un accès aux journaux/statuts, de préférence en référence au système CD.
En ce sens, le modèle push nous permet de fournir au moins certaines garanties de déploiement, car la durée de vie du pipeline peut être rendue égale à la durée de vie du déploiement.
Nous avons essayé les deux modèles et sommes arrivés aux mêmes conclusions que l'auteur de l'article :
- Le modèle pull nous convient pour organiser les mises à jour des composants du système sur un grand nombre de clusters (voir. ).
- Le modèle push basé sur GitLab CI est bien adapté au déploiement d'applications utilisant des charts Helm. Parallèlement, le déploiement des déploiements au sein des pipelines est suivi à l'aide de l'outil . D'ailleurs, dans le contexte de notre projet, nous avons entendu le « GitOps » constant lorsque nous discutions des problèmes urgents des ingénieurs DevOps sur notre stand à la KubeCon Europe'19.
PPS du traducteur
A lire aussi sur notre blog :
- «";
- «";
- «";
- «».
Seuls les utilisateurs enregistrés peuvent participer à l'enquête. s'il te plait.
Utilisez-vous GitOps ?
-
Oui, approche pull
-
Oui, pousse
-
Oui, tirez + poussez
-
Oui, autre chose
-
Aucun
30 utilisateurs ont voté. 10 utilisateurs se sont abstenus.
Source: habr.com