Remarque perev. : Dans la communauté Kubernetes, une tendance appelée GitOps gagne en popularité, comme nous l'avons vu personnellement en visitant KubeCon Europe 2019. Ce terme a été inventé relativement récemment par le chef de Weaveworks - Alexis Richardson - et signifie l'utilisation d'outils familiers pour les développeurs (principalement Git, d'où le nom lui-même) pour résoudre les problèmes opérationnels. En particulier, nous parlons d'exploiter Kubernetes en stockant ses configurations dans Git et en déployant automatiquement les modifications du cluster. Matthias Jg parle de deux approches de ce déploiement dans cet article.
L'année dernière
(en fait, cela s'est passé officiellement en août 2017 - environ la traduction) , une nouvelle approche pour le déploiement d'applications dans Kubernetes est apparue. Il s'appelle GitOps, et il est basé sur l'idée de base que le suivi des versions des déploiements se fait dans un environnement de référentiel Git sécurisé.
Les principaux avantages de cette approche sont les suivants :
- Déploiement des versions et historique des modifications . L'état de l'ensemble du cluster est stocké dans le référentiel Git et les déploiements ne sont mis à jour que par des validations. De plus, toutes les modifications peuvent être suivies à l'aide de l'historique des validations.
- Kickbacks utilisant des commandes Git familières . Une simple
git reset vous permet d'annuler les modifications du déploiement; 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 confidentielles, de sorte que la plupart des entreprises accordent une attention particulière à sa protection. Par conséquent, cette protection s'étend aux opérations avec déploiements.
- Stratégies de déploiement . La plupart des systèmes Git prennent initialement en charge les politiques pour différentes branches - par exemple, seules les demandes d'extraction peuvent mettre à jour le maître, et un autre membre de l'équipe doit vérifier et accepter les modifications. Comme pour le contrôle d'accès, les mêmes stratégies s'appliquent aux mises à jour de déploiement.
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 acquis une popularité particulière. L'un est basé sur la poussée, l'autre sur la traction. Avant de les examiner, voyons d'abord à quoi ressemblent les déploiements Kubernetes typiques.
Méthodes de déploiement
Ces dernières années, différentes méthodes et outils de déploiement ont été mis en place chez Kubernetes:
- 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 se débarrasser de la réécriture constante des mêmes modèles, Kustomize a été développé (il transforme les modèles Kubernetes en modules). Remarque perev. : Kustomize a été intégré à kubectl avec la sortie de Kubernetes 1.14 .
- Graphiques Helm . Les graphiques Helm vous permettent de créer des ensembles de modèles, conteneurs d'initialisation, sidecar'ov, etc., qui sont utilisés pour déployer des applications avec des options de configuration plus flexibles que dans l'approche basée sur des modèles. Cette méthode est basée sur des modèles de fichiers YAML. Helm les remplit de divers paramètres puis les envoie à Tiller, le composant de cluster, qui les déploie dans le cluster et permet les mises à jour et les restaurations. L'important est qu'en fait, Helm insère simplement les valeurs nécessaires dans les modèles et les applique ensuite de la même manière que dans l'approche traditionnelle (pour plus de détails sur la façon dont tout cela fonctionne et comment vous pouvez l'utiliser, lisez notre article sur Helm - env. .) . Il existe une grande variété de graphiques Helm prêts à l'emploi couvrant un large éventail de tâches.
- Outils alternatifs . Il existe de nombreux outils alternatifs. Tous sont unis par le fait qu'ils transforment certains fichiers modèles en fichiers YAML compatibles avec Kubernetes, puis les appliquent.
Dans notre travail, nous utilisons constamment des graphiques Helm pour des outils importants (car beaucoup d'entre eux sont déjà prêts, ce qui simplifie considérablement la vie) et des fichiers YAML «propres» de Kubernetes 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
Weave Flux , qui vous permet de valider des modèles dans le référentiel Git et de mettre à jour le déploiement après chaque commit ou push conteneur. Mon expérience montre que cet outil est l'un des principaux dans la promotion de l'approche pull, je vais donc souvent y faire référence. Si vous souhaitez en savoir plus sur son utilisation, voici un
lien vers l'article .
NB! Tous les avantages de l'utilisation de GitOps sont conservés pour les deux approches.Approche basée sur la traction
L'approche pull est basée sur le fait que toutes les modifications sont appliquées à partir du cluster. À l'intérieur du cluster, un opérateur vérifie régulièrement les référentiels de registre Git et Docker associés. Si des modifications s'y produisent, l'état du cluster est mis à jour en interne. Il est généralement considéré qu'un tel processus est très sûr, car aucun client externe n'a accès aux droits d'administrateur de cluster.
Avantages:- Aucun client externe n'a le droit d'apporter des modifications au cluster; toutes les mises à jour sont effectuées de l'intérieur.
- Certains outils vous permettent également de synchroniser les mises à jour des graphiques Helm et de les lier à un cluster.
- Docker Registry peut être analysé pour de nouvelles versions. Si une nouvelle image apparaît, le référentiel Git et le déploiement sont mis à jour vers la nouvelle version.
- Les outils d'extraction peuvent être distribués sur différents espaces de noms avec différents référentiels et autorisations Git. Grâce à cela, il est possible d'utiliser le modèle multi-locataire. Par exemple, l'équipe A peut utiliser l'espace de noms A, l'équipe B peut utiliser l'espace de noms B et une équipe d'infrastructure peut utiliser l'espace global.
- En règle générale, les outils sont très légers.
- Combinés à des outils comme l'instruction Bitnami Sealed Secrets , les secrets peuvent être stockés cryptés dans le référentiel Git et récupérés dans le cluster.
- Il n'y a aucune communication avec les pipelines de CD, car les déploiements se produisent au sein du cluster.
Inconvénients :
- La gestion des secrets de déploiement à partir des graphiques Helm est plus compliquée que d'habitude, car vous devez d'abord les générer dans, disons, des secrets scellés, puis les déchiffrer avec un opérateur interne et seulement après cela, ils deviennent disponibles pour l'outil d'extraction. Ensuite, vous pouvez lancer la version dans Helm avec des valeurs dans des secrets déjà déployés. Le moyen le plus simple consiste à créer un secret avec toutes les valeurs de Helm utilisées pour le déploiement, à le déchiffrer et à le valider dans Git.
- En utilisant l'approche par traction, vous vous retrouvez lié à des outils qui fonctionnent sur des tractions. Cela limite la possibilité de personnaliser le processus de déploiement de déploiement dans le cluster. Par exemple, travailler avec Kustomize est compliqué par le fait qu'il doit être exécuté avant l'arrivée des modèles finaux dans Git. Je ne dis pas que vous ne pouvez pas utiliser des outils individuels, mais ils sont plus difficiles à intégrer dans le processus de déploiement.
Approche basée sur la poussée
Dans l'approche push, un système externe (principalement des pipelines CD) commence à se déployer sur le cluster après la validation dans le référentiel Git ou en cas de réussite de l'exécution 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 référentiel Git et le pipeline de génération.
- Le déploiement des graphiques Helm est plus facile; il existe un support pour les plugins Helm.
- Les secrets sont plus faciles à gérer, car les secrets peuvent être utilisés dans des pipelines, ainsi que stockés dans Git sous une forme chiffrée (selon les préférences de l'utilisateur).
- Manque de liaison à un outil spécifique, car n'importe lequel de leurs types peut être utilisé.
- Les mises à jour de version de conteneur peuvent être déclenchées par le pipeline d'assemblage.
Inconvénients :
- Les données permettant d'accéder au cluster se trouvent à l'intérieur du système de génération.
- La mise à jour des conteneurs de déploiement est encore plus facile à faire avec le processus d'extraction.
- Cela dépend beaucoup du système de CD, car les pipelines dont nous avons besoin sont probablement écrits à l'origine pour Gitlab Runners, puis l'équipe décide de passer à Azure DevOps ou Jenkins ... et vous devez migrer un grand nombre de pipelines de construction.
Conclusion: pousser ou tirer?
Comme d'habitude, 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, j'ai passé les déploiements manuellement, mais après avoir rencontré plusieurs articles sur Weave Flux, j'ai décidé de mettre en œuvre des processus GitOps pour tous les projets. Pour les modèles de base, cela s'est avéré facile, mais j'ai ensuite rencontré des difficultés pour travailler avec les graphiques Helm. À ce moment-là, Weave Flux ne proposait qu'une version rudimentaire de l'Opérateur Chart Helm, 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. Vous pouvez dire que l'approche Pull est beaucoup plus sécurisée, car les informations d'identification du cluster ne sont pas disponibles en dehors de celle-ci, ce qui augmente tellement la sécurité que cela coûte un effort supplémentaire.
Après avoir réfléchi un peu, je suis arrivé à la conclusion inattendue que ce n'est pas le cas. Si nous parlons de composants qui nécessitent une protection maximale, cette liste comprendra le stockage des secrets et des systèmes CI / CD, 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 entre dans votre référentiel Git et peut y pousser le code, il pourra déployer tout ce qu'il veut (quelle que soit l'approche choisie, ce sera tirer ou pousser) et infiltrer les systèmes de cluster. Ainsi, les composants les plus importants nécessitant une protection sont le référentiel Git et les systèmes CI / CD, et non les informations d'identification du cluster. Si vous disposez de stratégies et de mesures de sécurité bien ajustées pour les systèmes de ce type, et que les informations d'identification de cluster sont récupérées dans les canaux uniquement comme des secrets, la sécurité supplémentaire de l'approche d'extraction peut ne pas être aussi utile que prévu à l'origine.
Donc, si l'approche pull prend plus de temps et ne donne pas un gain de sécurité, n'est-il pas logique d'utiliser uniquement l'approche push? Mais quelqu'un peut dire que dans l'approche push, vous êtes trop lié au système CD et, peut-être, il vaut mieux ne pas le faire afin de faciliter les migrations à l'avenir.
À mon avis (comme toujours), vous devez utiliser ce qui convient le mieux à un cas particulier ou combiner. Personnellement, j'utilise les deux approches: Weave Flux pour les déploiements basés sur l'extraction qui incluent principalement nos propres services, et une approche push avec Helm et des plugins qui simplifie l'application des graphiques Helm au cluster et vous permet de créer facilement des secrets. 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. En même temps, je recommande fortement GitOps - il simplifie considérablement la vie et améliore la sécurité.
J'espère que mon expérience sur ce sujet aidera à déterminer quelle méthode est la plus adaptée à votre type de déploiement, et je serai heureux de connaître votre opinion.
PS Note du traducteur
Dans les inconvénients du modèle d'extraction, il y a un point sur le fait qu'il est difficile de mettre des manifestes rendus dans Git, mais il n'y a pas moins que le pipeline CD dans le modèle d'extraction vit séparément du déploiement et, en fait, devient un
pipeline de catégorie d'
application continue . Par conséquent, encore plus d'efforts seront nécessaires pour collecter leur état de tous les déploiements et donner en quelque sorte accès aux journaux / état, et de préférence en référence au système de CD.
En ce sens, le modèle push vous permet de donner au moins une certaine garantie de déploiement, car la durée de vie du pipeline peut être égale à la durée de vie du déploiement.
Nous avons testé 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 système sur un grand nombre de clusters (voir l' article sur l'opérateur d'addon ).
- Le modèle push basé sur GitLab CI est bien adapté pour le déploiement d'applications à l'aide de graphiques Helm. Dans ce déploiement, le déploiement dans les pipelines est contrôlé à l'aide de l'outil werf . Soit dit en passant, dans le contexte de notre projet, nous avons entendu le «GitOps» constant lorsque nous avons discuté des problèmes pressants des ingénieurs DevOps sur notre stand à KubeCon Europe'19.
PPS du traducteur
Lisez aussi dans notre blog: