Je pense surtout que la demande de base est complétement infondée (j’ai le mot idiot en tête). Après, si on te paye pour faire le taff, tant mieux pour toi
Pourquoi je trouve ça infondé ? On te demande de remplacer dans une recette de cuisine, une carotte par un chou. Spoiler : t’auras pas le même gout
Puppet fait de la conformation : tu lui décris CE QUE TU VEUX sur le serveur.
Ansible fait de l’orchestration : tu lui donnes des opérations à effectuer.
Typiquement, puppet va te conformer le fichier A. Quelqu’un te modifie (erreur ou intention, légtitiment ou pas) le fichier A… ll va perdre sa modification au prochain run de l’agent. Question : tu vas vraiment lancé toutes les 30 minutes les playbooks ansible sur l’ensemble de ton parc ? Perso, je l’ai jamais vu. Résultat : Fichier A sera modifié et jamais remis à son état initial.
Vala pour ma remarque
( et je redis : aucune critique sur toi, si le client paye… tant pis pour son choix, tant mieux pour ton compte bancaire)
Globalement je suis d’accord avec toi, même si c’est faisable.
D’ailleurs je l’ai vu chez un client, ils faisaient du ansible en mode pull, leurs vms étaient poussées directement avec ansible d’installés, et toute les heures elles allaient chercher leurs propres configuration.
Chez mon employeur actuel, on vient de faire l’inverse : Adieu Ansible et Go puppet. Pour la partie orchestration, puppet + choria fonctionne très bien
Ça arrive dans un contexte de rachat, les différentes équipes peuvent avoir à uniformiser les outils utilisés.
Par contre, c’est pas de chance quand ça tombe sur un cas comme ça, avec deux outils dont le but est différent, et c’est celui qui n’est pas adapté au besoin qui est choisi pour rester ^^
Chez nous, Puppet et Ansible sont utilisés tous les deux, mais pour des tâches différentes : Puppet gère la conf persistante (OS, packages, etc.), tandis qu’Ansible est dédié aux tâches “oneshot” (déploiement applicatif, déclaration dans l’AD, etc.).
Je pense surtout que la demande de base est complétement infondée (j’ai le mot idiot en tête). Après, si on te paye pour faire le taff, tant mieux pour toi Pourquoi je trouve ça infondé ? On te demande de remplacer dans une recette de cuisine, une carotte par un chou. Spoiler : t’auras pas le même gout
Typiquement, puppet va te conformer le fichier A. Quelqu’un te modifie (erreur ou intention, légtitiment ou pas) le fichier A… ll va perdre sa modification au prochain run de l’agent. Question : tu vas vraiment lancé toutes les 30 minutes les playbooks ansible sur l’ensemble de ton parc ? Perso, je l’ai jamais vu. Résultat : Fichier A sera modifié et jamais remis à son état initial.
Vala pour ma remarque ( et je redis : aucune critique sur toi, si le client paye… tant pis pour son choix, tant mieux pour ton compte bancaire)
Globalement je suis d’accord avec toi, même si c’est faisable. D’ailleurs je l’ai vu chez un client, ils faisaient du ansible en mode pull, leurs vms étaient poussées directement avec ansible d’installés, et toute les heures elles allaient chercher leurs propres configuration.
En terme de perf, ça tenait ?
Oui tant mieux sinon de quoi vivrions nous. Sinon ta remarque est pertinente mais voilà Puppet disparaît petit à petit…
Chez mon employeur actuel, on vient de faire l’inverse : Adieu Ansible et Go puppet. Pour la partie orchestration, puppet + choria fonctionne très bien
Il en fait pour tous les goûts. Bonne chance
une raison particulière à l’abandon de Ansible ?
Ça arrive dans un contexte de rachat, les différentes équipes peuvent avoir à uniformiser les outils utilisés.
Par contre, c’est pas de chance quand ça tombe sur un cas comme ça, avec deux outils dont le but est différent, et c’est celui qui n’est pas adapté au besoin qui est choisi pour rester ^^
Chez nous, Puppet et Ansible sont utilisés tous les deux, mais pour des tâches différentes : Puppet gère la conf persistante (OS, packages, etc.), tandis qu’Ansible est dédié aux tâches “oneshot” (déploiement applicatif, déclaration dans l’AD, etc.).