Donc au lieu d'un seul script, j'aurais plus de 50 petits fichiers...
C'est quoi cet intérêt pour n'avoir qu'un seul fichier ? Il n'y a aucune raison de n'avoir qu'un seul fichier. Je ne dis pas que ce n'est pas grave d'avoir plusieurs fichiers, je dis que c'est bénéfiques. Il n'y a pas l'ombre d'un problème à utiliser une arborescence de fichiers.
Je peux alors lancer ./postinstall.sh vim pour exécuter ces 7 actions. Je ne connais pas de manière, avec Ansible, pour appeler 7 plays en une seule commande aussi simple, sauf à faire un playbook pour chaque programme, puis utiliser les rôles, etc etc.
Ça n'est pas comme ça que fonctionne ansible (et les logiciels du genre). Dans ansible tu défini des rôles qui peuvent avoir des fichiers, des templates, un playbook, des variables,... et tu va agréger et paramétrer ces rôles pour chaque cible ou groupe de machines. Donc tu aura un rôle vim que tu applique à ta machine. Comme tout est idempotent, tu ne devrais pas lancer ansible par rôle mais par machine, si tu fais une modification tu ré-applique tout. Les tags peuvent servir, mais je ne les utilise pas pour ça.
Tu utilises le pluriel, là c'est déjà mal parti pour qu'on se comprenne.
On à tous pleins de machines. Celle(s) de chez toi, celle du travail,...
Ensuite je le lance occasionnellement (et partiellement, comme dans l'exemple de vim ci-dessus) pour rétablir des conf que j'ai un peu trop tripatouillées à la main.
C'est là où l'idempotence d'ansible prend tout son sens. Tu ne te pose pas la question tu peux tout relancer continuellement.
Et vu que je ne me rappellerais jamais de cette commande en entier, utilisée une fois tous les 6 mois sur une machine vierge, il faudrait la mettre dans un script :)
C'est de la mauvaise fois... Tu ne peux pas te coller un README.md à la racine de ton dépôt git ?
Comme tu le dis, chacun fait comme il veut. Pour ma part et pour cet usage, je ne vois pas d'intérêt à utiliser Ansible : un script shell est bien plus flexible et facile à utiliser in fine pour cet usage à mon sens.
Je sais parfaitement écrire des scripts shells/bash/zsh, mais justement parce que je sais ce qu'il en retourne la piètre qualité des scripts généralement (mauvaise gestion des inputs par exemple) et, même en zsh, la quantité de code que ça prends de faire les choses bien, je préférerais toujours partir sur une solution, qui ne me fais pas réinventer là roue (fabric par exemple peut faire l'affaire pour ça, mais il n'est pas idempotent).
Regarde tes confs fichiers tout statiques : Les écrire en jinja (c'est le moteur de templates d'ansible) te permet de les rendre plus courts.
L'utilisation d'outils de plus haut niveau te retire le plaisir d'utiliser ce que tu connais parfaitement et te sors de ta zone de confort, mais :
te permet d'avoir une configuration descriptive de ta machine
te permet d'appliquer ta configuration sur toutes les machines auxquels tu as accès
te donne accès à des action de plus haut niveau
te donne de l'idempotence en standard
te pousse aux bonnes pratiques
Le tout pour un coût faible ;) (ne me dis pas que cloner un dépôt, trouver une commande ou le wrapper dans un script, etc sont hors de ta portée)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Devops
Posté par barmic . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 3.
C'est quoi cet intérêt pour n'avoir qu'un seul fichier ? Il n'y a aucune raison de n'avoir qu'un seul fichier. Je ne dis pas que ce n'est pas grave d'avoir plusieurs fichiers, je dis que c'est bénéfiques. Il n'y a pas l'ombre d'un problème à utiliser une arborescence de fichiers.
Ça n'est pas comme ça que fonctionne ansible (et les logiciels du genre). Dans ansible tu défini des rôles qui peuvent avoir des fichiers, des templates, un playbook, des variables,... et tu va agréger et paramétrer ces rôles pour chaque cible ou groupe de machines. Donc tu aura un rôle vim que tu applique à ta machine. Comme tout est idempotent, tu ne devrais pas lancer ansible par rôle mais par machine, si tu fais une modification tu ré-applique tout. Les tags peuvent servir, mais je ne les utilise pas pour ça.
On à tous pleins de machines. Celle(s) de chez toi, celle du travail,...
C'est là où l'idempotence d'ansible prend tout son sens. Tu ne te pose pas la question tu peux tout relancer continuellement.
C'est de la mauvaise fois... Tu ne peux pas te coller un README.md à la racine de ton dépôt git ?
Je sais parfaitement écrire des scripts shells/bash/zsh, mais justement parce que je sais ce qu'il en retourne la piètre qualité des scripts généralement (mauvaise gestion des inputs par exemple) et, même en zsh, la quantité de code que ça prends de faire les choses bien, je préférerais toujours partir sur une solution, qui ne me fais pas réinventer là roue (fabric par exemple peut faire l'affaire pour ça, mais il n'est pas idempotent).
Regarde tes confs fichiers tout statiques : Les écrire en jinja (c'est le moteur de templates d'ansible) te permet de les rendre plus courts.
L'utilisation d'outils de plus haut niveau te retire le plaisir d'utiliser ce que tu connais parfaitement et te sors de ta zone de confort, mais :
Le tout pour un coût faible ;) (ne me dis pas que cloner un dépôt, trouver une commande ou le wrapper dans un script, etc sont hors de ta portée)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)