Le 26/08/2015 15:26, Damien MICHAUDET a écrit : > Bonjour à tous, > > Effectivement la discussion part dans toutes les directions qui > devraient converger mais qui ne le font pas. > > Reprenons dans l'ordre. Pour commencer à connaître l'état de machines > il faut connaître les machines. Je n'ai pas encore trouvé d'outil > simple d'inventaire dynamique qui me permette de connaître les > machines et de pondre un inventory ansible en fonction de mes besoins. > Collins semble faire le job mais c'est un outil Java qui consomme 800M > de Ram à vide, ce qui est inacceptable pour un outil d'inventaire qui > ne devrait pas, pour 1000 machines, gérer plus de 2 ou 3M de données > texte. >
Bonjour, De notre côté on a décidé que la supervision serait l'élément qui référence les serveurs. Du coup tout est branché dessus y compris le fait de se connecter en ssh. Si le serveur n'est pas supervisé alors on ne peut rien faire dessus, rien déployer. Ca évite d'un coup l'oubli de supervision d'une machine. Bon c'est old school comme technique de nos jours quand le déploiement auto pourrait ajouter le serveur à la supervision mais comme je fais cette technique depuis 15 ans quand le déploiement auto n'existait pas ... Bref du coup on a fait des scripts qui sortent le listing des hosts de la supervision avec le type de machine (serveur, sw, ...), l'OS, le fqdn, ... Et tout cela peut être soit passé en dynamique à Ansible (on s'y met tranquillement), soit on cron la récupération et la mise en forme d'un fichier static pour Ansible (on va privilégier cette partie là au cas où la supervision ne soit pas joignable en cas de gros crash). J'ai vu des exemples où Ansible peut se brancher sur un vcenter ESXI pour récupérer les hosts présents. Donc on peut lui faire manger à peu près n'importe quelle source pour le fichier host. ++
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
