L’année dernière, une nouvelle approche a été ajoutée aux options de déploiement possibles pour Kubernetes. Cette approche s’appelle GitOps et est fondée sur le concept de base, à savoir que chaque déploiement est versionné sécurisé dans un référentiel git.
Les principaux avantages de cette approche sont:
- Déploiements versionnés et historique des modifications
Tout l’état de votre cluster se trouve dans un référentiel git, et ce n’est qu’en validant que les utilisateurs peuvent mettre à jour les déploiements. De plus, chaque changement peut être surveillé via l’historique des commit git.
- Annulations à l’aide de primitives git
Une simple réinitialisation git peut annuler les modifications des déploiements et l’ancien état est toujours disponible.
- Contrôle d’accès
prêt à l’emploi Un système git est souvent un endroit contenant beaucoup de données sensibles, il est donc correctement sécurisé dans la plupart des entreprises. Le même niveau de sécurité affecte désormais également les opérations de déploiement.
- Politiques de déploiement
Dès le départ, la plupart des systèmes git prennent en charge les politiques sur les branches, par exemple, que seules les demandes d’extraction peuvent mettre à jour la branche principale et qu’un autre membre de l’équipe doit examiner et accepter le déploiement. Comme pour le contrôle d’accès, les mêmes stratégies s’appliquent à vos mises à jour de déploiement.
Comme vous pouvez le constater, de nombreux avantages vous attendent sur le site GitOps. Au cours de la dernière année, deux approches se sont développées, la première est celle basée sur le push et la seconde est celle basée sur l’attraction. Avant de les analyser tous les deux, nous allons d’abord examiner à quoi ressemblent les déploiements Kubernetes typiques.
Moyens de déploiement
Dans Kubernetes, différentes méthodes et outils de déploiement se sont installés au cours des dernières années.
- Déploiements de modèles bruts Kubernetes / Kustomize
C’est le moyen le plus basique de déployer des applications sur kubernetes. Le développeur crée des fichiers yaml de base et les applique au cluster. Pour réduire la réécriture des mêmes modèles encore et encore, Kustomize est né, qui permet de modulariser les modèles Kubernetes.
- Helm Charts
Les Helm Charts sont une option permettant de créer un ensemble de modèles, de conteneurs d’initiation, de side-cars, etc., qui sont utilisés pour déployer une application avec plus de personnalisation que l’approche modèle. Dans le noyau, il existe des fichiers yaml fortement basés sur des modèles, qui sont remplis avec des valeurs par l’outil Helm, puis envoyés à un composant de cluster appelé tiller qui les déploie sur le cluster et permet la mise à niveau et les annulations. Il est important de noter que, sous le capot, Helm ne remplit que les valeurs du modèle, puis applique les modèles comme dans l’approche traditionnelle. Il existe une variété de graphiques de barre disponibles, couvrant une large gamme d’applications populaires.
- Outils alternatifs
Il existe des tonnes d’outils alternatifs disponibles, tous ont en commun, qu’ils traitent des types de fichiers modèles en fichiers yaml compréhensibles par Kubernetes, puis les soumettent.
Chez mes clients, nous utilisons régulièrement des graphiques Helm pour les outils dont nous dépendons (car ils sont très solides et réduisent beaucoup le travail) et des fichiers yaml bruts de Kubernetes pour déployer nos propres applications.
Pull & Push
Tous les avantages de l’utilisation d’un processus GitOps sont valables pour les deux approches.
Pull approach
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 analyse régulièrement les référentiels git et les registres docker associés et si un changement se produit, l’état du cluster sera mis à jour de l’intérieur. Ce processus est généralement considéré comme très sécurisé, en raison du fait qu’aucun client externe ne dispose d’informations d’identification avec un accès administrateur au cluster.
Avantages:
- Aucun client externe n’a le droit de publier sur le cluster, toutes les mises à jour proviennent de l’intérieur.
- Certains outils permettent également de synchroniser les mises à jour des graphiques de barre et peuvent les synchroniser avec le cluster.
- Les registres Docker peuvent être analysés à la recherche de nouvelles versions et si une nouvelle image est envoyée, le dépôt git et le déploiement sont mis à jour avec la nouvelle version.
- Les outils basés sur l’extraction peuvent être distribués dans différents espaces de noms, avec différents référentiels git et droits d’accès et, grâce à cela, un modèle multi-tenant peut être appliqué. L’équipe A peut utiliser l’espace de noms A, l’équipe B peut utiliser l’espace de noms B et l’équipe Infrastructure peut en avoir un global.
- Les outils sont régulièrement très légers.
- Combinés à un outil tel que l’opérateur Bitnami Sealed Secrets, les secrets peuvent être placés chiffrés dans le référentiel git et extraits à l’intérieur du cluster.
- Pas de couplage sur les pipelines de CD, car les déploiements sont effectués en cluster en interne.
Les inconvénients:
- La gestion des secrets des déploiements Helm Chart est plus difficile que la normale, car les valeurs secrètes doivent d’abord être créées, par exemple des secrets scellés, puis être déchiffrées par un opérateur interne, puis mises à la disposition de l’outil d’extraction. Une fois que cela s’est produit, une version de helm peut être exécutée avec les valeurs des secrets déjà déployés. Le moyen le plus simple serait de créer un secret de toutes les valeurs de helm utilisées pour le déploiement, de le déchiffrer puis de le valider dans git.
- Grâce à l’approche pull, vous êtes lié aux outils exécutant le pull. Cela réduit la possibilité de personnaliser le processus d’application des déploiements au cluster. Par exemple, l’utilisation de Kustomize est plus difficile, car elle doit être exécutée avant que les modèles de résultats ne soient poussés vers git. Je ne dis pas que des outils séparés ne peuvent pas être utilisés, mais il est plus difficile de les implémenter dans le flux de déploiement.
Push approach
Dans l’approche push, un système externe (principalement des pipelines de CD) déclenche des déploiements sur le cluster, après qu’un référentiel git a été validé ou qu’un pipeline CI précédent a été exécuté avec succès. Dans cette approche, le système de pipeline a accès au cluster.
Avantages:
- La sécurité est déterminée par le référentiel git et le pipeline de construction.
- Le déploiement de Helm Charts peut être fait plus facilement et avec le support des plugins Helm.
- La gestion des secrets est plus facile car les secrets peuvent être appliqués aux pipelines et également stockés cryptés dans git, comme le préfère l’utilisateur.
- Non lié à l’outil spécifique, car tous les types d’outils peuvent être utilisés.
- Les mises à jour de la version du conteneur peuvent être injectées par le pipeline de build.
Les inconvénients:
- Les informations d’identification du cluster se trouvent dans le système de génération
- La mise à jour des conteneurs de déploiements est toujours plus facile avec un processus basé sur l’extraction
- Fortement couplé au système de CD, car des pipelines doivent être créés qui sont peut-être dans le langage de Gitlab Runners, puis plus tard, l’équipe décide de migrer vers Azure DevOps ou Jenkins et de nombreux pipelines de construction doivent être migrés.
Résumé – Push ou Pull
Je pense que c’est comme toujours, les deux approches ont leurs avantages et leurs inconvénients et certaines tâches sont faciles avec l’une et plus difficiles avec l’autre. Au début, j’ai fait des déploiements manuellement à la main, mais après être tombé sur certains articles de blog de WeaveFlux, cela m’a convaincu d’implémenter des processus GitOps pour tous les projets. L’implémenter pour tous les modèles de base était un processus facile, mais j’ai ensuite commencé à trébucher sur des problèmes avec mes graphiques de barre. À cette époque, Weave Flux ne fournissait qu’une toute première version de Helm Chart Operator et même maintenant, certaines tâches sont plus difficiles, en raison de la pré-création manuelle des secrets et de leur application. Vous pouvez maintenant affirmer que l’approche pull est beaucoup plus sécurisée car les informations d’identification du cluster ne sont pas disponibles en dehors du cluster et cela augmenterait tellement la sécurité que l’effort supplémentaire en vaut la peine.
J’ai été surpris, qu’après avoir un peu changé cette pensée, je suis arrivé à la conclusion que ce n’est pas vrai. Si vous pensez aux composants qui devraient être les plus sécurisés dans votre organisation, cette liste comprendra les magasins secrets et les systèmes CICD / git dépôts. Les informations qu’ils contiennent sont très sensibles et doivent être très bien protégées. De plus, si quelqu’un parvient à pénétrer dans votre référentiel git et est capable d’y pousser des choses, il peut déployer ce qu’il veut (quel que soit le push / pull) et infiltrer vos systèmes de cluster. Ainsi, le composant le plus critique à protéger est votre référentiel git / systèmes CICD et non vos informations d’identification de cluster ici. Si vous avez de bonnes politiques et mesures de sécurité sur ce type de systèmes et que les informations d’identification du cluster ne sont extraites que sous forme de secrets dans les pipelines,
De plus, si quelqu’un parvient à pénétrer dans votre référentiel git et est capable d’y pousser des choses, il peut déployer ce qu’il veut (indépendamment du push / pull) et infiltrer vos systèmes de cluster
Donc, si l’effort de mise en œuvre est plus élevé et que la sécurité n’est pas augmentée, ne serait-il pas préférable d’utiliser une approche basée sur la poussée? D’un autre côté, quelqu’un pourrait dire que vous vous associez très fortement au système de CD et qu’il vaut peut-être mieux ne pas le faire, pour permettre des migrations plus faciles plus tard.
À mon avis, c’est comme toujours, utilisez ce qui est plus facile pour votre cas d’utilisation ou combinez tout. Personnellement, j’utilise les deux approches, WeaveFlux pour les déploiements basés sur pull, qui comprend principalement nos services auto-écrits, et une approche basée sur push avec Helm et plugins, ce qui facilite l’application des graphiques Helm au cluster sans trébucher sur les problèmes tout en créant des secrets. Je suppose qu’il n’y aura jamais de solution adaptée à tous, car ces sujets sont toujours très complexes et dépendent des cas d’utilisation. Ce que je peux recommander vivement, c’est l’utilisation de GitOps, car cela rend les opérations plus faciles et beaucoup plus sûres.
J’espère que mon opinion personnelle sur ce sujet vous permettra de décider plus facilement quelle approche convient à votre type de déploiement et je serais heureux d’entendre vos opinions.
