my current usecase is to walk around multiple MySQL DB hosts and remove user from them. Sounds like a nice usecase for mysql_user module. Bit of complication: all hosts have different root credentials. I do not want to either hardcode credentials into the playbook/CLI invocation nor do I feel comfortable sticking it on every box under ${HOME}/.my.cnf . What are current recommendations for this kind of scenario. I’ve seen vars_prompt, however since I’ll need it per-host: how do I do that? Another thing - since we’re talking “action” vs “configuration” I felt it’s a task for “ansible CLI” vs “ansible-playbook”, am I understanding things correctly? What shall I do with multiple hosts and their login credentials?
The typical way to keep secret data is to load them via “vars_files” from a directory outside of your main playbooks repository.
It is perfectly fine to set up playbooks for doing common tasks if you want to, I actually don’t use /usr/bin/ansible hardly ever, except maybe to reboot some nodes, or to check something simple like uptime.
Though if you want to use the ansible program instead, that is fine too.
But playbooks are for all kinds of processes, not just configuration.
Rolling updates of applications are a particulary common non-OS-config task.
The typical way to keep secret data is to load them via “vars_files” from a directory outside of your main playbooks repository.
I thought of that - but can’t find a way to do it “dictionary style” with mapping hostname → login:password for multiple machines. Am I looking at creating _login and _pass variables? Any better solutions that I can recycle inside a single “mysql_user” command?
It is perfectly fine to set up playbooks for doing common tasks if you want to, I actually don’t use /usr/bin/ansible hardly ever, except maybe to reboot some nodes, or to check something simple like uptime.
Though if you want to use the ansible program instead, that is fine too.
But playbooks are for all kinds of processes, not just configuration.
Rolling updates of applications are a particulary common non-OS-config task.
ok, good to know. I just got a feeling that ansible is “more natural” in setting things up, as running tasks becomes a bit more cumbersome with all the output suppressed etc. “ansible” in those cases is pleasantly verbose
ok, good to know. I just got a feeling that ansible is “more natural” in setting things up, as running tasks becomes a bit more cumbersome with all the output suppressed etc. “ansible” in those cases is pleasantly verbose
that should’ve read as:
ok, good to know. I just got a feeling that ansible-playbook is “more natural” in setting things up, as running tasks becomes a bit more cumbersome with all the output suppressed etc. “ansible” in those cases is pleasantly verbose
you’ll have to agree that it is not nearly as useful as output of “absible” when it comes to post-processing. and yes - I do use “ansible-playbook -vv” a lot.
now that we’ve dealt with ansible vs ansible-playbook, what about the above. I did see vars_files Michael mentioned but how do I do it per-host? Am I missing something obvious?
yes, I was looking at those. Still unconvinced I’d like to store those passwords clear-text (esp. when I push it into central repo). Probably I should just integrate gpg invocation to pull cred info into the vars. Sounds hacky but at least stores things securely. Now what’s the best way to marry ansible and gpg prompt? gpg-agent? Is it a completely whacked idea?
and yes - I do use “ansible-playbook -vv” a lot.