[Salt-fr] Quelques questions - best practices salt

Damien Wyart damien.wyart at free.fr
Mer 18 Nov 21:38:25 CET 2015


Bonsoir,

* Adnan Aita <adnan.aita at gmail.com> [2015-11-18 16:36]:
> je bute sur un petit soucis d'ordre idéologique.

> J'ai des formules qui me gère proprement mes installs BDD et Apache, etc.

> j'essaie maintenant de m'assurer que les bonnes bases sont déployées au bon
> endroit en fonction des applicatifs et des versions d'environnement sachant
> que :
>  * en dev, j'ai souvent les bases et les httpd sur la même machine
>  * en test, c'est mixed
>  * en prod c'est toujours séparés

> Ce que j'ai fait :
> [...]

> Voici donc mes questions :
> 1/ J'ai essayé de faire en sorte de "déporter" les match grain pour les
> vhosts par exemple dans un apache.sls dans mes pillar, le soucis est que je
> n'arrive pas à inclure correctement quand je mix un 'include' avec un
> (match grain). Si quelqu'un l'a déjà fait, je veux bien un exemple

Je pense qu'il faut plutôt mettre les rôles directement dans les
pillars, et matcher là-dessus (cela centralise l'information). Et cela
évitera de devoir matcher sur les grains dans les pillars.

(dans les versions récentes de Salt, on peut matcher sur les données de
pillar, https://docs.saltstack.com/en/develop/topics/targeting/pillar.html).

Cette discussion peut également donner des pistes :
http://stackoverflow.com/questions/27618718/how-do-i-manage-minion-roles-with-salt-stack-pillars

> 2/ j'ai essayé de passer via jinja pour inclure les env via une boucle

>     {% for env in salt['grains.get']('webenv', {}) %}
>     - apache.{{ env }}
>     {% endfor %}   ## LOOP : Install the Vhosts based on grains

> C'est top, ca marche, mais j'ai le pb suivant :
> * Toutes les applis n'ont pas de base, donc quand je fais pareil avec mes
> bases, il n'est pas content des fichiers .sls non existant pour ces bases
> qui n'existent pas.
> * Si je crée un fichier vide avec par exemple juste (## No database) dans
> le fichier, j'ai le même soucis. Et à supposer que ca soit la solution, ca
> va me faire créer un packet de fichier vide car je compte gérer de la même
> facon le déploiement des crons, etc.

On peut le faire en deux "couches", comme expliqué par exemple ici :

https://thiggy.wordpress.com/2013/09/19/role-based-state-management-with-saltstack/

Cet exemple est ancien donc utilise les grains pour les rôles, mais
actuellement, on utiliserait plutôt des données de pillar.

Un autre exemple intéressant qui montre l'évolution depuis des rôles
dans les grains vers quelque chose de plus souple :
https://github.com/saltstack-formulas/hadoop-formula/issues/10
https://github.com/saltstack-formulas/hadoop-formula/commit/b467b6618647c54bad2a456c1f175a0d6cb2b761

Après quelques recherches complémentaires, j'ai également trouvé ceci
qui me semble pertinent (et on voit bien l'évolution depuis les grains
vers le pillar, même si ici c'est un external pillar (que je ne connais
pas en détail) :

http://devop.ninja/configuration%20management/2014/08/25/the-grains-conundrum/
http://devop.ninja/configuration%20management/2015/03/01/beyond-grains-roles-with-an-external-pillar/


Bonne lecture :)

Cordialement,
-- 
Damien Wyart


Plus d'informations sur la liste de diffusion Salt-fr