Les Dev. et les Ops. ont des considérations opposées. Les premiers souhaitent être libres de déployer leur code ou d’implémenter les dernières technos hypes. Les seconds bichonnent leur plates-formes (et leur tranquillité) en contraignant toute forme de nouveautés (entendons ici des changements …). Le DevOps est né de cette impérieuse nécessité de réduite ce profond clivage. Ok !, une fois que l’on a plaqué cette tarte à la crème, il reste quoi ?
Pas mal de choses à vrai dire et ce post n’évoquera qu’un tout petit bout : la convergence d’outils, de méthode et donc de “mindset” débuté par l’Infra-as-a-code et qui s’accélère avec le concept de GitOps. En effet, les applications Cloud Natives combinent une “tonne” de composants : open source, développements propriétaires, API tierces (SaaS) et autres infra-programmatiques (services Cloud) afin de construire le produit livré aux utilisateurs.
Ainsi, presque par accident, Git est devenu l’outil principal pour gérer presque tous les composants et le code qui les assemble. Construire l’application, la déployer et gérer les dépendances notamment l’infrastructure se retrouve rassemblées autour du même pivot : Git.
Ainsi, Git devient graduellement le sanctuaire de l’entreprise pour ce qui concerne son code, ses configurations et son infra. Ce faisant Git devient le centre de contrôle pour l’IT Cloud-native, que l’on soit Dev ou Ops !
GitOps* naît de ce constat, tout est «code-centric»
*GitOps a créé le buzz lors de la KubeCon + CloudNativeCon EU en Mai dernier. “GitOps is all about “pushing code, not containers” said Alexis Richardson, Weaveworks CEO and chair of the Cloud Native Computing Foundation‘s Technical Oversight Committee, in his KubeCon keynote. The idea is to “make git the center of control,” of cloud-native operations, for both the developer and the system administrator, Richardson said (La prochaine cession ici )
Alors quelle définition pour GitOps ?
https://twitter.com/vitorsilva/status/999978906903080961
On le voit, il s’agit d’une démarche unique pour appliquer à toutes les opérations relatives au Système les principes « Git workflow » (1) largement éprouvée dans le développement, et l’open source particulièrement ;
(1) On parlera ici de tous les avantages de Git par la gestion collaborative du code et notamment :
- L’usage de Pull Request pour demander une modification (et l’autoriser)
- La stratégie de Branches pour définir une stratégie d’évolutions et les cloisonner
- Le suivi temporel des modifications par la comparaison aisée des écarts
- Le revert (rollback) pour revenir à un état précédent
- L’intégration aisée à une CI/CD
- La gestion des permissions
- Etc.
Concrètement, quelle forme cela prend ?
1. Décrire l’état cible de l’ensemble du système de façon déclarative et ce pour chaque environnement.
Le dépôt Git est donc la seule source de vérité pour établir ce qu’est l’état désiré de l’environnement. Tous changements passent par un Git commit (exécution du code taggé comme éligible dans l’environnement ciblé). De fait, toutes les caractéristiques décrites dans Git sont strictement observables sur le Système (infra et appli.).
2. S’il existe un écart (diverged state)
Un mécanisme de synchronisation vérifie donc constamment un éventuel écart entre l’environnement et sa description dans Git. Un écart est alors immédiatement identifié par un "change committed alert” et une alerte “diff” peut être envoyée.
3. Par conséquent les Git commit (activation du code sur l’environnement) entraîne un état vérifiable et idempotent (2) de l’environnement. (2) signifie qu’une opération a le même effet qu’on l’applique une ou plusieurs fois. Le mécanisme de convergence rétablit l’équilibre entre l’état observé et celui qui est souhaité dans le repos Git par une synchronisation automatisée.
4. Le retour arrière est engagé par le commit d’une version précédente du code. Démarche particulière facile grâce à l’utilisation des outils Git et le taggage (propre) des versions. Dit autrement “Rollback is: convergence to an earlier desired state ».
Et ce n’est pas fini, GitOps accélère !
Ce n’est pas le fruit du hasard mais la suite logique d’une brique technologique révolutionnaire et qui s’est maintenant généralisée : kubernetes. Les µservices et les containers associés sont ainsi très largement orchestrés par “Kube”, ce faisant les déploiements applicatifs poussés par les Dev. impliquent des mises à jours de fichiers de configuration propre à l’infrastructure (les fameux .yaml…). On voit alors aisément l’intérêt (nécessité ??!) d’une approche GitOps.
Pour conclure, GitOps repose sur 4 fondamentaux :
- La convergence qui garantie l’alignement d’une description et d’un état
- L’idempotence qui garantie qu’une opération a le même effet qu’on l’applique une ou plusieurs fois
- Le déterminisme qui conduit à définir explicitement (et de façon lisible) ce que l’on veut (statement)
- L’automatisation qui garantie une vérification perpétuelle et une démarche de mise à jour programmatique
GitOps est la vision moderne et actuelle pour faire converger Dev et Ops (donc une brique élémentaire du DevOps…) autour d’outils et de process techniques communs.
Imaginez les gains !
Au delà de la convergence d’un modèle opératoire commun (DevOps) c’est la réduction d’erreurs source d’incident, les retours arrières rapides et efficaces, ou encore un effort marginal à fournir au fur et à mesure que l’environnement grossi.
Si ce n’est pas encore adopté, pensez-y…
Merci pour votre lecture. Si cet article vous a plu, merci de le partager sur vos réseaux 😉
Jean-Pierre Chamarande - Mar 08, 2019
VOUS AVEZ UN PROJET ?
Audit, migration, infogérance ?
Skale-5 vous écoute : contact@skale-5.com
Nous suivre :
