Comparez Spinnaker avec Jenkins 2.0 en tant qu'outil de distribution continue
Comme nous le savons, Jenkins 2.0 a été publié et il va au-delà de l’intégration continue (CI) à la livraison continue (CD). Je voudrais donc demander quels sont les avantages concurrentiels de Spinnaker par rapport à Jenkins 2.0?
Je travaille beaucoup sur l'intégration de Jenkins dans Spinnaker et dans la fonctionnalité Pipelines de Netflix.
Spinnaker n'a jamais été conçu pour être un outil de construction de bout en bout. Jenkins fera mieux en termes de gestion de la GCA, d’exécution de tests, de construction de paquetages, de plugins gazillion, etc., etc., etc.
Ce que Spinnaker essaie de faire est de prendre un logiciel que vous avez publié (un paquet debian, une image de menu fixe ou un fichier JAR déployable) et de l'exécuter au cours d'un cycle de déploiement de logiciel prévisible et hautement personnalisable. En d'autres termes, chaque fonctionnalité de Spinnaker est conçue pour faciliter le déploiement d'artefacts hautement disponibles, multi-comptes et multi-cloud.
Les pipelines Spinnaker prennent une vue centrée sur le nuage. La plupart de nos étapes de pipeline et de nos contrôles API concernent la création de nouveaux groupes de serveurs et la modification des groupes de serveurs existants de manière prévisible et conviviale. En cas de doute, c’est le cas pour lequel nous optimisons.
Nous avons des opinions bien arrêtées sur le déploiement du cloud et nous aurons souvent une interface utilisateur pointer-cliquer pour traiter les tâches de déploiement du cloud dans nos pipelines de CD --- trouver l'image dans le cluster x, désactiver ce cluster, redimensionner un groupe de serveurs , réduisez ce cluster, faites en sorte que ce cluster prenne le trafic, détruisez ce vieux cluster, etc.
La fonctionnalité de pipeline Jenkins ne nous était pas disponible lorsque nous avons commencé à écrire Spinnaker il y a plus de 2 ans. Nous avons donc mis au point la fonctionnalité dont nous avions besoin. Le support Jenkins que nous avons créé a évolué à partir de nos besoins et a aidé d’autres équipes de Netflix à créer des milliers de pipelines de déploiement en interne. Etant donné que Netflix dépend énormément de Jenkins pour la construction et les tests, la transition entre les tâches Jenkins et les étapes Spinnaker est relativement transparente.
Certaines équipes de Netflix n'utilisent pas la fonctionnalité de pipeline Spinnaker mais utilisent plutôt l'API Spinnaker dans leurs travaux Jenkins comme raccourci à déployer sur AWS. Si vous utilisez des pipelines Jenkins ou des outils de CD similaires, Spinnaker rend votre phase de déploiement vraiment flexible.
Nous avons également des équipes qui aiment la façon dont Spinnaker décompose les tâches Jenkins en tâches atomiques et réutilisables autour d’une application. Les équipes qui ne se déploient pas dans le cloud utilisent Spinnaker, car nos pipelines répondent mieux à leurs besoins que ce qu’ils peuvent trouver dans le monde Jenkins.
Les canalisations Jenkins sont plutôt chouettes. Je ne pense pas que Spinnaker remplacera jamais complètement Jenkins et son million de choses. Notre objectif est simplement de simplifier et d’étendre davantage l’étape «déployer dans le cloud». Le choix d'utiliser l'un sur l'autre, ensemble ou pas du tout, est à vous.
Il y a quelques raisons pour lesquelles vous pouvez choisir Spinnaker plutôt que Jenkins (2.0) Pipeline comme outil de CD:
- Spinnaker inclut une interface utilisateur Web qui peut réellement mettre en service des ressources, et ce, dans plusieurs environnements de cloud. Donc, pour créer des ressources de base telles que des machines virtuelles, des équilibreurs de charge, des clusters, etc., vous pouvez le faire à partir de la même interface utilisateur que votre outil de diffusion.
- Si votre architecture est similaire à celle de Netflix, Netflix l'utilise comme plate-forme de gestion en nuage complète. Vous n'avez donc presque pas besoin d'outils étendus pour prendre en charge votre gestion des livraisons et de votre infrastructure.
Par ailleurs, il existe de nombreuses raisons de choisir le pipeline Jenkins au lieu de Spinnaker.
- Spinnaker nécessite toujours un outil de compilation. Vous devrez peut-être quand même maintenir Jenkins. Ainsi, si Jenkins Pipeline devient votre outil de CD, il peut déjà effectuer nativement vos tâches spécifiques à l'exécuteur.
- Spinnaker n’a pas de contrôle d’accès précis (et n’a ajouté qu’une authentification récente), alors que Jenkins propose de nombreux plug-ins et configurations natives dans Pipeline pour offrir un contrôle d’accès au niveau des ressources.
- Tout est piloté par un seul script groovy, c'est donc une vraie configuration en tant que code. Cela permet un flux/une logique/un contrôle simples, impossibles (ou du moins faciles) avec d'autres outils de CD.
- Support de pipeline multi-branches, créer/supprimer/changer facilement des branches
- Prise en charge étendue de plug-ins pour Jenkins déjà. Par exemple, nous utilisons le AWS ECS Plugin pour autoriser les nœuds de docker dynamiques pour nos pipelines.
- Partagez facilement/collaborez sur du code vers des pipelines. Vous aurez certainement des fonctions réutilisables que vous souhaitez utiliser sur plusieurs pipelines. Jenkins facilite cela avec des outils tels que Plugin de chargeur distant
- Grand soutien de la communauté
Nous avons finalement choisi Jenkins 2.0 Pipeline comme outil de CD plutôt que Spinnaker et plusieurs autres.
Nous utilisons Maven pour conditionner toute la base de code avec les configurations, les propriétés (c’est-à-dire tout ce qui est versionné dans GitHub) et en créer un RPM. Avec cette fin de flux, nous déclenchons les pipelines Spinnaker dans AWS ou tout autre cloud pour lancer la partie CD.
Spinnaker est très unique avec cette portée donnée du CD.
Promotion du code: le même RPM que nous allons promouvoir garantit que nous rendons notre code/env sous-jacent immuable.
Nous pouvons contrôler le redimensionnement d'instances à partir de la console Spinnaker
Revenir en arrière, c'est juste un clic.
Tous les concepts de déploiement modernes tels que Bleu-Vert/Rouge-Noir, Canaries, Highlander, etc.
Les journaux de pipeline donnent une vue très perspicace, de haut niveau et de bas niveau
Déploiements multi-régions (DR stratégique)
si quelqu'un a besoin d'aide (aide gratuite!) pour l'installation de Spinnaker dans RHEL, vous pouvez me le faire savoir.
Mais je dois dire que nous utilisons Spinnaker uniquement pour les déploiements centrés sur le cloud.