Qu'est-ce que le GitOps, et en quoi diffère-t-il d'un déploiement en push ?

Le GitOps garde l'état souhaité du système dans git et fait tourner un agent dans l'environnement cible qui tire cet état en continu et réconcilie la réalité avec lui. Un déploiement en push fait détenir à la CI des identifiants sur le cluster et applique les changements depuis l'extérieur. Le modèle en pull veut dire que la CI n'a jamais besoin d'identifiants de production, que la dérive est corrigée automatiquement, et que l'historique git est un journal d'audit fidèle de ce qui est déployé.

Ce qui définit le GitOps, ce n'est pas que les manifestes vivent dans git, c'est qu'un agent à l'intérieur du cluster surveille le dépôt et réconcilie en continu l'état qui tourne pour qu'il corresponde. Le push, ça veut dire que mon job de CI détient un kubeconfig avec accès en écriture et applique depuis l'extérieur, donc ces identifiants existent dans le système de CI, et une fois qu'il a appliqué il s'en désintéresse. Avec le modèle en pull, la CI n'écrit jamais que dans un dépôt. Rien à l'extérieur n'a besoin d'identifiants sur le cluster, ce qui réduit beaucoup la surface d'attaque. Et comme la réconciliation est une boucle et pas un événement, si quelqu'un modifie un déploiement à la main à deux heures du matin, c'est annulé et je vois la dérive. Les parties délicates sont réelles cela dit. La promotion entre environnements devient une pull request qui change un tag d'image dans un overlay, ce qui paraît plus lent jusqu'à ce que vous réalisiez que c'est aussi la trace d'audit. Les secrets ont besoin d'être chiffrés avec un service de gestion de clés, puisque le dépôt lui-même n'est pas un endroit sûr. Et il vous faut un chemin de secours documenté pour quand la réconciliation est justement ce qui vous empêche de régler une panne.