Introduction au CD
L’adoption de conteneurs est une stratégie courante pour les entreprises afin de déployer rapidement de nouvelles modifications d’applications, de déployer efficacement et d’exécuter des applications en toute sécurité.
Aujourd’hui, pour atteindre ces objectifs, de nombreuses entreprises adoptent désormais la livraison continue (CD) afin de déployer les modifications en production rapidement, fréquemment et en toute sécurité.
De nombreux outils de CD sont utilisés pour fournir des logiciels à la production. Certains des outils les plus courants sur le marché sont :
- Spinnaker
- Argo CD
- CD Tekton
- Laboratoire Git
- Azure DevOps
Spinnaker et Argo CD sont les outils préférés pour transformer les processus de livraison de logiciels, c’est pourquoi on nous demande souvent de décrire les différences entre eux et d’évaluer lequel est le meilleur. La réponse courte est que cela dépend de la situation spécifique et des exigences de chaque client. Mais ce n’est pas une réponse satisfaisante, alors approfondissons quand Spinnaker et Argo CD ont du sens.
Une introduction rapide à Spinnaker et Argo CD
Spinnaker
Spinnaker est une plate-forme de CD open source et multi-cloud pour la publication de modifications logicielles avec une rapidité et une confiance élevées.
Spinnaker propose un système de gestion de pipeline puissant et flexible, utilisé par de nombreuses entreprises du Fortune 500 pour déployer des millions de changements par an.
Reportez-vous à l’interface utilisateur de Spinnaker :
Argo CD
ArgoCD, un outil de CD déclaratif pour les applications Kubernetes, utilise le style GitOps pour gérer les ressources du cluster. Argo CD surveille la configuration de l’application définie dans votre référentiel Git et la compare avec l’état en direct dans le cluster. Lorsqu’un développeur modifie la définition de l’application dans Git, Argo CD détecte et informe les administrateurs de l’état de désynchronisation. Si l’administrateur approuve la modification, ArgoCD crée des ressources dans les clusters Kubernetes avec la configuration nouvellement définie.
Reportez-vous à l’interface utilisateur du CD Argo
Comparaison entre Spinnaker et Argo CD
Nous avons séparé notre évaluation de Spinnaker et Argo CD selon quatre dimensions : installation et mise en œuvre, déploiements, flux de travail complexes et sécurité.
Comparaison tabulaire : Spinnaker vs Argo CD
Installation et mise en œuvre
Installation
L’un des principaux paramètres que toute entreprise visualise est l’opération Day1, qui comprend les prérequis, l’installation, la configuration et l’architecture.
Argo CD est très léger et peut être installé dans minikube à l’aide de manifestes ou de cartes HELM (avec 2 Go de mémoire et 2 processeurs), tandis que Spinnaker est riche en fonctionnalités, ce qui le rend assez lourd.
L’installation de Halyard – un gestionnaire de cycle de vie pour Spinnaker – nécessite au moins 12 Go de mémoire (bien qu’il puisse être exécuté sur 1 Go pour une petite configuration). De plus, Spinnaker nécessite un cluster Kubernetes avec quatre cœurs et 16 Go de RAM.
Du point de vue de l’installation, Spinnaker et Argo CD sont bien documentés et facilement installés avec quelques commandes et en quelques minutes. Les deux outils de CD offrent une architecture hautement disponible et tolérante aux pannes pour minimiser les interruptions de service pendant le déploiement du logiciel.
Courbe d’apprentissage et adoption à l’échelle de l’entreprise
Un autre facteur qui aide certainement les entreprises à adopter une solution CD est la courbe d’apprentissage.
Comme Spinnaker est riche en fonctionnalités et possède de nombreuses fonctionnalités et composants, l’équipe DevOps doit apprendre à configurer des pipelines ou à les déployer dans des environnements multi-cloud, etc. De nombreuses ressources, documentations, vidéos et plugins Spinnaker d’entreprise sont disponibles pour le équipe DevOps pour raccourcir leur courbe d’apprentissage et leur permettre de l’adopter progressivement en production.
En revanche, Argo est une solution CD légère limitée aux déploiements d’applications Kubernetes. Si vous avez besoin d’une solution CD pour Kubernetes, vous pouvez vous installer très rapidement avec Argo CD. Cependant, dans un déploiement de production, Argo CD peut ne pas satisfaire à toutes les exigences de sécurité et de conformité définies par les responsables DevSecOps pour les déploiements de production.
Les organisations qui souhaitent une solution de CD centralisée et prête pour la production pour gérer divers types d’applications et cibles de déploiement doivent rechercher un fournisseur qui fournit des solutions de CD Spinnaker et Argo prêtes pour la production qui sont sécurisées, évolutives, extensibles, renforcées et Fedramp- conforme, selon les exigences de votre organisation.
Déploiements
Argo CD suit le déploiement de style GitOps, c’est-à-dire qu’il traite Git comme une source de vérité et surveille le référentiel pour tout changement dans le fichier manifeste pour le déploiement d’applications dans Kubernetes. Le manifeste peut être spécifié dans un fichier texte ou un fichier JSON, des applications Kustomize, des graphiques HELM, des applications ksonnet ou des fichiers jsonnet.
Le CD Argo est destiné à être utilisé uniquement avec les applications et services Kubernetes. Argo CD suit les mises à jour des branches ou des balises ou est épinglé à une version spécifique des manifestes lors d’un commit Git et déploie les modifications dans Kubernetes. Les manifestes Kubernetes d’un référentiel Git sont appliqués à la configuration de votre cluster, et Argo s’efforcera de garantir que votre référentiel et vos clusters sont toujours synchronisés.
Argo CD peut également renvoyer l’état Git à l’environnement cible s’il y a un changement dans l’environnement cible pour une raison quelconque.
Argo CD fournit une interface utilisateur pour présenter l’état de déploiement d’un changement (et dépend de la synchronisation avec le changement Git). Reportez-vous à l’image ci-dessous :
Spinnaker ne prend pas en charge le style de diffusion GitOps ; cependant, il existe un autre moyen d’y parvenir en utilisant une solution améliorée par le fournisseur. Spinnaker propose des pipelines déclaratifs pour la livraison d’applications. Les ingénieurs DevOps qui déploient sur le cloud public ou Kubernetes choisissent les pipelines Spinnaker. En utilisant des pipelines, Spinnaker peut déployer des applications dans n’importe quelle machine virtuelle (VM) sur site ou centre de données cloud comme AWS, GCP, Azure et Kubernetes. La meilleure partie des pipelines Spinnaker est que vous pouvez configurer des étapes pour un processus de publication séquentiel.
Reportez-vous à la capture d’écran ci-dessous où un pipeline Spinnaker (pour un déploiement AWS) est exécuté :
Les développeurs qui souhaitent utiliser des modèles de livraison de style GitOps avec Spinnaker peuvent utiliser un hack avec les pipelines. Ils doivent configurer des déclencheurs dans Git pour exécuter un pipeline sur n’importe quel commit sur n’importe quel code dans Git. Un tel hack pour atteindre GitOps est appelé livraison gérée.
Les fichiers manifestes peuvent être spécifiés dans un fichier texte ou un fichier JSON, ou des applications Kustomize, des graphiques HELM ou des modèles Spring Spel. Toute modification du fichier manifeste dans Git déclenchera le déploiement des pipelines Spinnaker. Le déploiement de l’application suit les mises à jour des branches ou des balises ou est épinglé à une version spécifique des manifestes lors d’un commit Git. L’API Spinnaker peut être appelée pour créer et gérer l’infrastructure (groupes de sécurité, équilibreurs de charge, pare-feu) et traiter les déploiements.
Reportez-vous à la capture d’écran ci-dessous où un pipeline Spinnaker est appelé en fonction des modifications apportées à Git :
Pour les grandes organisations, Spinnaker est pratique pour construire un flux de travail de livraison de bout en bout en configurant une série d’étapes dans les pipelines Spinnaker. Les webhooks à ces étapes peuvent exécuter automatiquement de nombreuses activités d’un processus de publication, telles que les tâches de construction Jenkins, le déploiement dans des environnements de test, le déclenchement de cas de test automatisés ou le déploiement dans des environnements de mise en scène et de production, etc. Les portes de jugement et de vérification manuelles peuvent également être configurées comme une partie du même pipeline pour assurer un processus de publication automatisé et sans risque. Ci-dessous, la figure A représente l’orchestration d’un processus de livraison de logiciels d’entreprise à l’aide de Spinnaker, et la figure B représente un exemple de pipeline Spinnaker automatisant diverses étapes de livraison – construction, test, déploiement et production :
Figure A :
Figure B :
Pour un déploiement en toute sécurité, Spinnaker et Argo (Argo Rollouts) proposent des stratégies de déploiement intégrées telles que highlander, bleu-vert, mises à jour progressives et canary.
Modifications des applications
Spinnaker et Argo CD prennent en charge Kubernetes sur site et géré. Les deux outils prennent en charge le déploiement d’applications dans Kubernetes géré (EKS/GKE/AKS). Argo CD se déploie directement en fonction du changement de configuration, tandis que Spinnaker utilise un pipeline de livraison pour le déploiement.
Si vous avez quelques applications hébergées sur site ou dans des clusters Kubernetes gérés et que vous êtes encore en cours de transformation dans le cloud, alors Argo CD peut vous convenir. Toutefois, si vous souhaitez créer un flux de travail transparent pour automatiser un processus de livraison qui comprend l’intégration de tests, des portes d’approbation (manuelles ou automatiques), des créations d’images intégrées et une visibilité sur les déploiements dans des environnements hybrides ou multi-cloud, choisissez Spinnaker pour une livraison continue. .
Mise à l’échelle à l’échelle de l’entreprise avec des workflows complexes
Déploiements basés sur des machines virtuelles
Chaque entreprise déploie des applications sur des machines virtuelles, soit dans le cloud via GCP, AWS, ou un autre cloud, soit sur des machines virtuelles de centre de données sur site. Il est courant de créer une spécification pour l’environnement requis pour une application – la version du système d’exploitation, les fichiers binaires, le stockage, la mise en réseau, les bibliothèques, les applications, les fichiers compressés, etc., pour créer une machine virtuelle. Ceci est également appelé boulangerie VM, où l’équipe d’infrastructure crée un instantané de l’environnement global et le conserve dans quelque chose comme un magasin AMI. Et une fois que cette image est prête, la création de plusieurs images – même jusqu’à des dizaines de milliers d’images – peut être créée pour répondre aux exigences de l’application. Le processus est également connu sous le nom d’infrastructure immuable et est pratiqué pour éviter la dérive de configuration.
Spinnaker utilise des graphiques HELM pour créer des fichiers manifestes Kubernetes. De même, il utilise un modèle de packer (sous le capot) pour cuire les images de VM. Une fois qu’un pipeline de livraison est terminé, Spinnaker peut provisionner ces machines virtuelles (ainsi que les équilibreurs de charge, les pare-feu, etc.) dans l’environnement cible (du cloud aux machines virtuelles sur site, aux serveurs bare metal). Cela aide les équipes d’infrastructure à tirer parti de Spinnaker pour orchestrer les déploiements basés sur des machines virtuelles. Cette capacité à déployer des mises à jour des services Kubernetes et des applications basées sur des machines virtuelles est l’une des principales raisons pour lesquelles de nombreuses organisations choisissent de se standardiser sur Spinnaker pour les déploiements de logiciels.
De plus, Spinnaker fournit une fenêtre unique où vous pouvez voir et contrôler vos ressources. Les équipes de développement et d’exploitation n’ont pas besoin de se connecter à une autre interface utilisateur ou à un cloud public pour comprendre l’état des ressources.
Argo CD actuellement…