Pull vs Push

Info

Pull vs Push Dans l’univers du GitOps, il existe deux modes de fonctionnement distincts : le Push et le Pull. Ces modes désignent l’acteur qui va s’occuper de synchroniser l’infrastructure avec le code ( ce qu’on appelera la boucle de réconciliation).

Par exemple, en mode Push : Jenkins peut déployer l’infrastructure en appelant Terraform comme l’aurait fait un administrateur système.

En mode Pull : c’est l’infrastructure qui va elle-même chercher sa configuration sur le dépôt Git. Un exemple un peu bateau serait un conteneur qui va lui-même télécharger sa configuration sur un dépôt Git (oui, c’est pas courant et peu efficace, mais cela correspond bien à notre définition).

Ces deux modes possèdent des avantages et des inconvénients que nous allons détailler ci-après.

Mode Push Le mode Push est le plus simple à mettre en place et s’interface souvent avec des outils déjà présents dans la stack technique (Terraform, Puppet, Saltstack, Ansible etc.).

En revanche, il demande à ce que les identifiants/secrets nécessaires pour administrer notre environnement technique soient utilisables par le runner CI-CD ou quelque part dans le pipeline de déploiement (qui peut être un point de vulnérabilité).

Ainsi, l’acteur lançant le programme de déploiement devient sensible et il convient de sécuriser au maximum la supply-chain pour ne pas que cette machine dévoile les accès.

Mode Pull En mode Pull, l’acteur déployant l’infrastructure est lui-même présent à l’intérieur de celle-ci. Compte tenu de sa nature, il possède déjà les accès pour réaliser son devoir : comparer le Git avec l’environnement technique et s’assurer que les deux soient en accord.

L’avantage est que le Git est donc totalement propre de toute donnée sensible. Le principal défaut dans ce système est qu’il peut être complexe à mettre en place et que tout environnement n’est pas forcément compatible.