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 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 )

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 :

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 :

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…