Spinnaker est une plateforme complète de “continuous delivery” multicloud développée par Netflix qui part à l’abordage des problématiques de stabilité, de multicloud, de vélocité, d’immutabilité, de rollback, de stratégie de déploiement et de multiparadigme. En bref, une consolidation d’un certain nombre de bonnes pratiques, de l’intégration continue (CI) jusqu’au déploiement continu (CD). En bonus, Spinnaker élimine le “configuration drift” afin d’éviter que la configuration ne parte à la dérive.
Pour la petite anecdote, le terme Spinnaker est associé à une voilure hissée à l’avant d’un voilier, optimisée pour l'exploitation de la force du vent venant de l'arrière (allures portantes), autant dire que Spinnaker est une promesse d’accélération des déploiements applicatifs dans le cloud.
“At an abstract level, a deployment pipeline is an automated manifestation of your process for getting software from version control into the hands of your users.” ― Jez Humble, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.
C’est bien connu, la société Netflix à l'origine du site web éponyme de streaming vidéo héberge la quasi totalité de sa plateforme sur le cloud AWS. Pour ses besoins de déploiement, elle a développé “Asgard”, outil répondant mieux (dixit Netflix) à leur modèle qu’ AWS Web Console, du moins à l'époque de sa création.
Publié en open source en 2012, Asgard a pour ainsi dire rempli sa mission et servi son objectif premier : le provisioning d'instances EC2 via le déploiement d’AMI Amazon. Les limites de l’outil ont été atteintes assez rapidement, avec l’augmentation de la cadence d’innovation des équipes Netflix. Cela s’explique aussi par l’explosion des audiences sur le service de streaming vidéo Netflix au niveau mondial et la montée en flèche du nombre de (micro)services en backend, nécessaires pour accompagner leur stratégie de croissance.
Pour maintenir leur avantage compétitif en terme d’innovation (cf. la constellation des projets Netflix OSS https://netflix.github.io) une réflexion interne est menée afin d’initier un projet permettant d’assurer de manière standard et globale le continuous delivery de bout en bout dans un contexte Cloud. Le royaume d’Asgard voit naître en 2014 Spinnaker, successeur ambitieux, qui vient non seulement combler les manques du prédécesseur mais aussi couvrir de nouveaux besoins. Comme nous le verrons, le triptyque “Pipeline”, “Deployment Strategy”, “Multi-cloud” résonne déjà comme un mantra, favorisant des déploiements applicatifs répétables avec vélocité et assurance. A noter que le développement de Spinnaker s’est fait en étroite collaboration avec Google (GCP Cloud) , Pivotal (CloudFoundry) , Microsoft (Azure) qui sont tous contributeurs au projet Open Source Spinnaker.
Publié en open source en 2015, Spinnaker est une plateforme de continuous delivery orientée cloud, qui permet de faire du processus de déploiement un "non événement”, tout en supportant le passage à l’échelle.
Dans la galaxie des écosystèmes DevOps, chacun a son outil de delivery de prédilection. Avec l’avènement de l'infrastructure as code, il a été possible d’automatiser les changements et certaines actions de manière répétable mais il vrai que l’offre est pléthorique. Ci-dessous un tableau comparatif.
Au-delà des considérations sur le choix même de ces outils, il existe un léger chevauchement entre ceux-ci et Spinnaker. En effet, ils n’ont pas été conçu à l’origine pour des déploiements cloud centric (même si certains ont évolué très vite dans cette direction), multi-tenant, personnalisable, hautement disponible et multicloud. Par ailleurs, la première partie de tout processus dit robuste (ou fiable) de “software release”, est sa capacité à effectuer un rollback, afin de revenir à l’état nominal. Nous verrons que c’est justement un des aspects où Spinnaker excelle et rend le processus totalement maîtrisé.
Jenkins est sans conteste l’outil de CI le plus populaire avec la multitude d’actions qu’il sait mener, accompagné de sa galaxie de plugins. Lorsqu’il est question de pipeline de delivery, on peut résumer de la manière suivante : Checkout, Test, Build, Release, Deploy .
Dans ce scénario, Spinnaker et Jenkins sont complémentaires. Les phases de gestion du SCM (checkout), de testing et de build de packages sont effectués par Jenkins tandis que Spinnaker effectuera le “Deploy” en gérant les appels vers l’API du cloud provider choisi, ainsi qu’une éventuelle phase de “release” préalable selon le type d’artifact ou le contexte. Les pipelines Spinnaker peuvent à cet effet être déclenchés par des jobs Jenkins via des triggers, et/ou contenir des « stages » (ou étapes) faisant appel à un job Jenkins comme nous le verrons dans la mise en pratique de la 2e partie de cet article.
Dans un contexte d'infrastructure "bare-metal" où les serveurs physiques cibles sont modifiables et altérables dans le temps, les outils de configuration management sont pertinents. Aujourd'hui avec les machines virtuelles et les containers, il y a mieux à faire en terme de gestion des déploiements. Ci-dessous un tableau comparatif Spinnaker vs outils de configuration management.
Conférence AWS Re-Invent | 3 Décembre 2016 | Andy Glover, Manager Delivery Engineering Netflix
Le positionnement de Spinnaker est relativement clair, il fait une chose et il le fait bien. Le déploiement sous forme de pipeline configurable est géré par un moteur d’orchestration. Il est capable de cibler plusieurs clouds en parallèle, pilotés par un cloud-driver specific (AWS, GCP, Openstack, CloudFoundry, Microsoft Azure, OracleCloud, AppEngines etc…).
La stabilité de l’ensemble est rendue possible, notamment par les opinions fortes et les choix de design de départ, tel que l’immutabilité. À ce propos, je vous propose de lire ou de relire l’article publié sur le sujet par Aurelien Maury.
L'expérience et l’ensemble des best practices CI/CD ont été mises à contribution. C’est exactement ce qui est palpable, avec Spinnaker, le continuous delivery devient un pattern.
Le tout est mis en cohérence pour l’accélération de vos pipelines de déploiements, ce qui n’est pas comme on pourrait le penser, un facteur de risque mais bien au contraire, elle le réduit.
Les chiffres parlent d’eux même. En effet, depuis l’introduction de Spinnaker et son utilisation par les équipes Netflix sur la plateforme Cloud AWS, 4000 déploiements sont réalisés par jour.
L’interface web Spinnaker fournit nativement tous les éléments pour réaliser un déploiement zero-downtime vers tous les big players du Cloud, selon des stratégies nativement supportés :
L’un des piliers de la chaîne d’outillage Devops est l’Infrastructure as Code et Spinnaker n’échappe pas à ce principe puisqu’il est possible de versionner dans un dépôt Git , les différents pipeline de déploiement des plateformes applicatives. C’est ici qu’entre en scène le Declarative Continuous Delivery (DCD). La spécification DCD définit un formalisme de déclaration de pipeline cloud agnostic sous forme de fichier YML enrichie par le langage de template Jinja2 (les aficionados d’Ansible/SaltStack se sentiront comme à la maison).
Ci-dessous un extrait de pipeline définit par fichier YML.
Les pipelines Spinnaker sont composés de plusieurs étapes, Stage > Steps > Tasks > Opération, tel que décrites ci-dessous :
Au niveau macro, la cinématique d’ensemble d’un pipeline peut être illustrée par le schéma ci-dessous :
Spinnaker a été conçu en respectant un certain nombre de principes comme mentionné précédemment, l’immutabilité en est un. Cela permet notamment d’éviter de voir la configuration de vos environnements partir à la dérive. Quelle que soit la stratégie de déploiement choisie (Highlander, Blue/Green, Rolling Push), Spinnaker n’effectuera pas une mise à jour d’un service existant, il le remplacera entièrement par une nouvelle version sur de nouvelles machines virtuelles ou en déployant de nouveaux containers dans le cas d’un environnement Cluster Kubernetes.
Pour ce faire Spinnaker intègre l’excellent outil d’Hashicorp Packer, outil de build de image de virtual machine. Le stage “Bake” (que nous verrons de manière approfondie en deuxième partie d’article) peut faire appel à Packer et à Ansible . Cette étape du pipeline peut par exemple vous permettre de rendre vos images AMI ou images Docker compatibles avec une de vos politiques internes; avec Ansible vous pourrez réaliser les traitements de mise en conformité.
Les stratégies de déploiement suivantes sont supportées nativement par Spinnaker :
HighLander : Parce qu’il ne doit t’en rester qu’un ! Il ne peut y avoir à chaque instant, qu’une seule version de la prod. Pour faire simple, dès que le nouvel environnement prod est Up et répond on bascule la totalité du trafic sur le nouvel environnement et on détruit l’ancien. ll n’y a pas de période d’observation, nous remplaçons tout de suite un Auto Scaling Group par un autre puis on fait le switch au niveau ELB.
Rolling Push : Dans cette stratégie de déploiement, les instances EC2 de la version existante sont détruites et remplacées par des instances EC2 de la nouvelle version, une seule instance à la fois, jusqu'à ce que toutes les instances appartenant à un même Auto Scaling Group aient été remplacées.
Le modèle manipulé par Spinnaker est fortement cloud centric; on y parle de déploiement multi-cloud, de Cluster, de Server Group, de Load Balancing, de Security Group et d’Application; pas besoin de traduction dans ce cas, on est vraiment dans une application Cloud Native. Dans le cas kubernetes il est nécessaire de faire une correspondance entre les objets du modèle Spinnaker et ceux de Kubernetes. A quoi correspond une région spinnaker dans le monde kubernetes ? Je vous propose le tableau ci-dessous qui est un récapitulatif des correspondances entre modèle Spinnaker et Kubernetes pour y voir plus clair.
À l’avenir, l’ingress controller kubernetes sera inclus à la notion de loadbalancer Spinnaker, et le Security Group Spinnaker correspondra au network policies (Calico par exemple).
Spinnaker interagit avec les différents cloud providers, par l’intermédiaire d’un cloud-driver spécifique à chaque provider. Il y a donc autant de cloud-drivers que de providers supportés par Spinnaker. Au moment de l’écriture de ce billet, voici la liste complète des cloud-drivers supportés.
Il est intéressant de noter qu’avec la sortie du cloud-driver Kubernetes, les applications "on premise" (dans vos datacenters) peuvent désormais aussi bénéficier des avantages offerts par Spinnaker. Grâce à l'implémentation du cloud-driver Kubernetes, Spinnaker ne cible plus exclusivement des Cloud Provider publics. Il suffit de le pointer vers vos clusters Kubernetes privés pour hisser la grand voile.
Pour des environnements Container orchestrés par Kubernetes, le choix Spinnaker pour la centralisation des déploiements, la visibilité et la gouvernance, est une option intéressante pour les entreprises désireuses de promouvoir les bonnes pratiques de déploiement.
Spinnaker rationalise le processus de continuous delivery, et l’arrivée du CloudDriver Kubernetes contribue à changer la donne pour vos pipelines de déploiement “In-House”. En terme d'implémentation au sein de l'entreprise, l'idée d'un Spinnaker basé sur un modèle en self-service est tout à fait pertinente. Les équipes orientées features produits peuvent ainsi construire leur propre workflow et être responsables de leur propre pipeline. Cela dit, ce n'est pas comme si tout le monde pouvait “scripter” son chemin vers la prod, bien au contraire, Spinnaker offre en quelque sorte un environnement “contrôlé”, avec la flexibilité et la sécurité des rollbacks.
Rendez-vous dans le prochain billet, Spinnaker : Cloud Native Continuous Delivery part II, où nous passerons à la mise en œuvre sous forme de tutoriel, en traitant de l'architecture, de l’installation, de la configuration de pipeline et du déploiement d’une application microservice avec Spinnaker.