Comment définir le gitops ? Pourquoi est-il autant adopté ? Mais est-il vraiment novateur ?
De nos jours le terme OPS est utilisé et abusé parfois. On connait bien sûr le devops, le devsecops ou encore le noops, le dataops, le netops, le finops… Alors le gitops rejoint-il cette tendance ?
OPS pour opérateurs en français. Très bien cette définition est assez vaste, ramenons cela un peu à l’IT et ce qui fait émerger ce thème à savoir le devops. On parle donc d’un côté d’une approche et d’un univers les développeurs où le besoin et de développer de nouvelles choses (features…). Et de l’autre finalement le monde de la production qui doit répondre à des problématiques différentes à savoir rendre un service avec un certain niveau d’exigences (le développement à lui aussi ces exigences et parfois celles-ci sont aussi conjointes).
Et l’un ne va pas s’en l’autre il faut le rappeler.
Le devops a donc émergé par l’opposition durant des années entre ces deux mondes avec parfois une vraie rupture ou plutôt un fort clivage. Rendant parfois le quotidien délicat au sein des entreprises. Le devops, parfois sous forme de philosophie ou encore sous forme de poste spécifique, a su faire évoluer les mentalités et faire bouger les lignes. Actuellement on peut considérer les blocages sont plus rares. Dorénavant le devops repose surtout plus une stack technologique permettant d’aider à déployer les services (ou microservices) avec facilité jusqu’en production.
Et le gitops dans tout ça ???
Git la source de vérité dans le travail du quotidien
Dans le monde du développement, cela fait des années que git est la référence. Les process de plus en plus élaborés permettent d’assurer un travail coordonné en équipe (gitflow etc…). Git permet donc :
- de versionner
- de commenter
- de travailler à plusieurs
- de valider
Bref l’outil est sans contester le meilleur outil de versionning du marché lancé par Linus Torvalds. Ensuite sont venus des interfaces graphiques qui ont décuplées les fonctions de cet outil et autour de cet outil (github, gitlab…).
Et depuis quelques années, les ops (sysadmin, ingénieurs réseau…) l’utilisent de plus en plus au quotidien. En effet, l’infrastructure as code prend le pas sur les infrastructures mise en place un peu plus à la main sans éléments descriptifs.
Dans le gitops, on retiendra une chose essentielle, le dépôt git doit être la source de vérité… et on doit faire en sorte que ça le soit et forcer à ce que ça le reste (dans les pratiques mais aussi dans le développement du code).
Et le gitops est arrivé…
Clairement, cela fait bientôt 10 ans (voir plus) que les ops utilisent Git pour concevoir leurs infrastructures. Peut être avec une place un peu plus minime qu’avant et avec des process moins élaborés comme l’a connu le monde du développement.
Du coup, depuis plus de 10 ans et l’arrivée des outil d’infra as code (eh oui ça date pas d’aujourd’hui non plus), petit à petit ces ops ce sont mis à versionner et élaborer de manières de plus en plus profondes leurs infrastructures avec git.
Deux tendances s’en dégagent :
- le mode push : dans ce cas on utilise une machine pour pousser les configurations d’infrastructures à distance
- le mode pull : là il s’agit de tirer les informations du dépôt git avec “des agents” présents directement dans l’infrastructure en question. Et ce point c’est accentué avec l’émergence de kubernetes.
Donc on synchronise notre infrastructure avec le dépôt git à l’aide d’outils d’infra as code :
- puppet
- saltstack
- chef
- capistrano
- ansible
- flux
- argocd…
L’effet mode de gitops ?
Le terme gitops émerge ces dernières années alors que la pratique date de bien avant cela. Donc oui on peut considérer que l’on surfe une fois de plus sur cette mode de mettre une fois de plus ce suffixe tellement buzzword.
Néanmoins, ce terme vient mettre un mot sur une pratique… qui ne disposait pas tout à fait de mot… Si ce n’est de l’infra as code qui finalement reflète assez bien ce qui est fait. Le gitops spécifie l’outil de versionning utilisé finalement.
Les gros avantages du gitops
S’il devait être un objectif ultime en matière de gitops, ce serait de faire en sorte q’un ops n’aille plus sur les machines. Voir plus, que les clefs ssh d’utilisateurs ne soient plus à déployer. Un doux rêve mais qui donne l’orientation de la marche à se donner.
Ainsi, après avoir mis au point l’outil d’infra as code adapté, l’ops ne devrait avoir à modifier que le code et le pousser sur la branche git adaptée.
Donc peu importe le terme ce qui compte c’est cette pratique qui est très intéressante et à développer pour aller de plus en plus en profondeur l’infra as code.
Vous aimez ces thématiques ? venez nombreux et abonnez-vous à la chaine xavki !!