Le 2015-08-19 13:59, Rémy Sanchez a écrit :
On Wed, Aug 19, 2015 at 12:08 PM Wallace <wallace@morkitu.org> wrote:
En fait y a les deux extrêmes, d'un côté on voit les docs qui
disent faut factoriser à fond pour pouvoir réutiliser au maximum
en changeant juste quelques variables et d'un autre la doc
officielle qui montre en exemple un simple listing d'actions à
faire sans prendre en compte différentes versions de Debian ou les
adaptations nécessaires vis à vis d'Ubuntu.
Les exemples de la doc sont effectivement simple et permettent de
rapidement mettre en place des actions mais est ce le bon exemple,
je n'en suis pas convaincu quand je vois le travail de debops qui
là à mon goût est peu flexible si je veux changer une façon de
faire sans forker leur git.
Pour moi la stratégie est la suivante : faire le script pour la/les
machines cibles, et quand de nouvelles machines avec des
distros/versions différentes apparaissent, je rajoute des conditions
pour faire des actions appropriées en fonction de.
En fait je vais un poil plus loin encore...
Mes premières lignes d'un rôle testent la distribution et si personne n'a encore testé ce rôle sur cette distribution dans la version précisée je sors en failed avec un message du genre vas modifier le rôle pour autoriser cette version et du coup jeter un oeil s'il n'y aurait pas de lignes spécifiques à la version du genre un apt ou un yum avec un repository spécifique à une version.
Si vous avez d'autres bonnes pratiques à partager n'hésitez pas, pour ma part, en voici deux :
- je préfixe toutes les variables d'un rôle par le nom du rôle pour éviter les surcharges par un autre rôle...
- une variable ne comprend pas de tiret ni de point, et donc par rapport à la règle juste au-dessus les rôles n'ont donc pas non plus de tiret et de point dans leur nom (Le tiret et le point ont des significations spécifiques en python et donc en ninja2 & ansible... cette connerie m'a fait perdre une bonne demi-journée)
Cdlt,
JYL