Reprise du message précédent :
ouaip, pas d'erreur mais la commande retourne rien oO alors que sur une machine du LAN no soucy

Tu peux augmenter le timeout pour voir ? (-t <secondes> )
 
Par défaut c'est 5.

J'aimerais faire un module pour mettre en place un dump mysql dès que puppet détecte qu'il y a mysql / mysqld d'installé. le problème c'est que je n'ai jamais fais de module qui doit se lancer sur la condition de quelque-chose, jusqu'ici si tel ou tel module s'appliqué c'était au niveau du provisionning via Foreman. La j'ai vraiment besoin d'un module que j'applique a toute les machines et qui met en place le dump uniquement quand il détecte une base de donnée.
 
Une idée ?

Mais le fait d'installer un serveur mysql, tu le gères via puppet ou ça a été fait à l'arrache en dehors ?

Nop pas par puppet. Justement le but c'est de gérer ce cas, un mysql est installé a l'arrache par un tierce, le module puppet le detecte et met en place le dump.

les utilisateurs de puppet/chef : vous utilisez des feature-flag dans vos manifests/recipes ?

C'est crado
 
En bricolant un fact tu peux t'en sortir, mais j'ai envie de dire : c'est super crado et pas vraiment dans la logique de l'outil

+1
 
tu la pupettises et basta

Y'en a qui utilisent ansible ici?

Oui

 
Tu veux vraiment faire ça automatiquement et pas au cas par cas ?  
Parce que si la base fait plusieurs GB et que tu balances un mysqldump --all-databases en pleine charge, ça va bloquer un petit moment.

 Je me suis recemment mis a puppet - j'ai mon labo aws, un master et un slave, j'ai reussi a faire une install de package -> jusqu'ici, tout va bien.
 
Mais j'essaie d'approfondir le sujet et je trouve la doc officielle... Bah a chier en fait    Un tour sur google me donne des trucs lambda. Vous, vous avez quel site fetiche? Ceux en 1ere page sont un peu hs  
 
Merci!

Tu reproches quoi aux docs officielles ?

Je cherchais un tuto - un bon primer - sur: installer le serveur, installer le client, les faire communiquer, creer un manifest etc...
 
La doc officielle part dans tous les sens et est (au debut, c'est une faiblesse) trop exhaustive (a-la wikipedia). Donc quand on connais le sujet c'est surement cool, mais quand on ne sais meme pas comment extraire une variable d'env., c'est une doc. pour se noyer.

Je sais pas mais https://docs.puppetlabs.com/puppet/ [...] start.html (et le menu sur la gauche) rassemble un peu tout, mais topic par topic.  
 
pour la var d'env ça fait un bail que j'ai plus fait de puppet mais il faut un fact special non ?

 
Tu veux pas essayer un truc mieux (genre plus simple à prendre en main au passage) ? Genre Salt ou Ansible ?

C'est pour le boulot, donc non  

Comment ça ? Tu veux dire que ta déjà du Puppet de partout donc ta pas le choix ? Dommage

Non, je suis consultant et c'est une techno que je dois/ai envie d'apprendre  

tu sors, vite

 
mouhahahaha

Hello,
 
Dites, est-ce aue foreman conviendrait a ce cas d'utilisation ?
 
J'ai un serveur DC avec des RPi deployés (une 30aine). C'est RPi sont cablés sur des cartes industrielles multi purpose et je veux deployer differentes applis (maison) sur ces RPi, les activer/desactiver RPi par RPi depuis une interface "user friendly" et idealement pilotable en REST.
 
On est bon ?

Je ne qualifierai pas forcément foreman de user friendly pour tout ce qui est association de classes/paramètres puppet (si tu comptes l'utiliser avec Chef, je ne sais pas comment ça se passe), mais sinon oui
 
Bien sûr il te faudra quand même faire des recettes Puppet/Chef pour déployer/configurer/lancer tes applis.

 
Heu, moi gros noob, j'utilise juste un peu puppet à la main comme un goret (sans hiera... mais je vais mettre ma ptite nouvelle dessus ). Ca apporte quoi chef ?
 

Salut les gens,

Je cherche des conseils sur un déploiement.

J'vous explique le cas d'utilisation :

- Déploiement massif de machines virtuelles, sur un OS proprio
- La configuration de ces machines peut se faire en API REST, ou en ssh sur les machines en question via le shell constructeur
- La configuration de ces machines n'est pas exactement identique (différences sur la partie networking, et sur certains pools d'IP utilisés par la suite) : cette configuration est aujourd'hui décrite dans un fichier excel (qui contient la liste des objets, quels objets s'applique sur quel device, la valeur des objets, etc).

La méthodologie actuellement utilisée et que dans le fichier excel, pour chaque objet il y a la ligne de conf à entrer en ssh sur la machine, et un script agrège ces commandes et va les jouer sur la machine cible. Ca fonctionne, mais je trouve ça crade, je préférerai mettre en place quelque chose utilisant les APIs. Puis ça me ferait un truc à coder.

Cependant, je ne vois pas trop comment articuler une solution "propre".
Vous allez me dire que tant que c'est basé sur un fichier excel... certes.

Vous aborderiez ça comment ?

ansible + écriture d'un module pour ton bouzin (si t'es à l'aise en Python ça ne devrait pas trop poser de problème), en privilégiant le REST.
 
Tu pourrais par exemple t'inspirer de ce qui est fait pour proxmox :
https://github.com/ansible/ansible- [...] proxmox.py

Bonjour, ( )
 
j'ai un gros problème d'organisation (de workflow) avec saltstack:
 
j'utilise un backend git pour mes states
 

 
et ce repository contient les branches pour les différentes environnement: master (production)/qa/dev
 
problème: quand je veux develloper de nouvelles formules je suis obligé:
- d'écrire/modifier les formules
- commiter sur la branche dev
- pousser
- tester
 
et ce jusqu'à ce que ça marche et que je pousse ces changement vers la branche "qa"
 
c'est très lourd, chiant, lent, inutilisable comme workflow...
 
du coup je cherche une alternative... et j'ai pensé à ça:
 
- je n'utilise git que pour la production et le qa
- pour l'environnement "dev" j'utilise un fileroots local au serveur ( par exmple '/srv/salt/dev/' ) qui est un clone du git.
 
du coup:
- j'écris et je testes mes formules directement
- je commite et pousse directement vers qa à la fin
 
ça me semble plus raisonnable, mais est-ce que je fais les choses bien ?
ou il y est-ce que je passe à côté de quelque chose encore plus simple pour développer et tester ses nouvelles formules ou ses modifications ?

Alors je sais pas ce dont tu as besoin, mais de mon côté, mes formules sont sur le Salt Master, et le dossier des formules est bien entendu dans Git.

Je fais des modifs en local, et quand ça me convient (par ex si j'avais un environnement de dev qui teste les formules), je pousse dans le Git.

Pour l'instant je me contente de cibler une VM pas importante en premier pour être sûr de pas avoir fait de la merde, si OK, push dans git puis salt *.

En tout cas c'est le flow qui m'est venu naturellement. Étant le seul admin, ça me gène pas.

Si je devais bosser avec d'autres admin, je ferai un truc plus chiant (PR des changements de formules, et la PR se hook sur un push des formules sur les hôtes de dev). Si ya du OK partout, la PR est mergeable. Et le merge sur la branche "master" lance l'application des formules partout.

C'est un probleme assez commun. Il y a une bonne part de tooling qui permet de le résoudre, mais surtout il faut penser le workflow correctement à la base.  
 
Si tu es seul, le workflow de plam fonctionne, mais est limité; personnellement je n'aime pas, meme seul : c'est facilement source d'erreurs difficile à retracer, tu risques de mettre une machine en vrac, et tu perds plus ou moins l'historique entre dev et prod
 
ici on utilise chef (et donc les outils associés) mais voici globalement comment on fonctionne, sachant qu'on est en train de changer notre façon de bosser
 

• repo git
• des tests unitaires
• une validation fonctionnelle, via kitchenci (avec un driver docker). il existe aussi un support pour salt apparemment
• des tests automatisés de qualité, via foodcritic
• des tests de cohérence, via des scripts maison

lse 2 derniers sont lancés par jenkins, idéalement on voudrait ajouter les tests fonctionnels (via bats) en plus, mais il faut du temps pour tout ça.
 
On a chacun un env de dev, composé de VMs trashables et recréables à volonté (via vagrant+des scripts). pour le deploy on utilise un outil maison
 
Donc pour résumer : on fait notre tambouille dans une branche, que l'on pousse|uploade en dev. une fois que c'est OK, on commite. ça part en review et ça fait les allers-retours classiques. une fois OK, on merge et on déploie.
 
ça nous permet de bosser à plusieurs, c'est scalable avec la taille de l'équipe et chacun peut suivre ce qu'il se passe.
 
my 0.2c

donc c'est bien d'avoir un environnement en file_roots pour pouvoir développer de nouvelles régles sans avoir à commiter
 
ou sinon lancer en master-less sur la VM trashable:
 

#j'édite le code [...]
# je teste:
rsync -av salt_states/ ma_vm_trashable:~/salt_states/
ssh ma_vm_trashable "sudo salt-call --local --file-root=~/salt_states/"
# si c'est pas bon je recommence...
# ou si c'est bon je commit et ça part en test automatisé (jenkins)

 
c'est ce que tu fais black_lord ? (en fait je cherche à ne pas commiter à chaque fois que je veux changer une coquille dans mon code)

#j'édite le code [...]
# je teste:
rsync -av salt_states/ ma_vm_trashable:~/salt_states/
ssh ma_vm_trashable "sudo salt-call --local --file-root=~/salt_states/"
# si c'est pas bon je recommence...
# ou si c'est bon je commit et ça part en test automatisé (jenkins)

 
plus ou moins oui. la methode est différente (à cause de l'outil), mais l'approche reste la meme.

Merci Plam et black_lord pour vos réponses

De rien Je peux pas trop aider dans des cas d'indus poussée, vu mon usage assez basique

Hello,
 
Savez vous s'il est possible de s'installer un ansible-galaxy "privé" afin de partager différents rôles au sein d'une entreprise ?

Hola,
 
Un outil de provisioning simple pour monter une machine ?
 
C'est pour un serveur@home, les services sont dockerisés mais j'ai quand même un peu de conf sur l'hôte, du style firewall. J'ai déjà joué avec Puppet sans beaucoup de conviction (voir mon histo sur le topac), j'aimerais éviter
Vagrant est cool pour le peu que je souhaite faire mais ne s'applique (à ma connaissance) qu'aux VM.
 
S'il existe un juste milieu entre le script bash et Puppet & Co, je prends.
 
Bonus point si je peux lancer le provisioning d'une machine neuve (fresh install de l'OS) à partir d'un client Windows.
 

Ansible

Mais t'oublie le provisionning, c'est pas son boulot, ni d'aucun autre système de gestion de conf d'ailleurs.

Du coup tu connais un outil dont c'est le boulot ?
(je regarde Ansible au cas où)

maas, foreman, fai...

pareil, on a essayé de faire fonctionner des maj de serveurs et fichiers dans ma boite, avec puppet c'est la merde entre leur gestion des numero de version et la doc mal faite. j'avais l'impression d'utiliser une API en béta alors que eux avaient le culot d' appeler ça une version "3.7" de souvenir

On l'utilise pour gérer tout notre parc.
Pour nous ça marche très bien.