Discussion:
[ansible-project] Log the actual playbook contents?
Mark Felder
2015-04-29 15:56:25 UTC
Permalink
Hello,

I'm working with ansible in some environments rather sensitive to
security/auditing and we have some significant controls designed around
playbooks working their way up to QA/Prod environments, but our test
environment of course needs to have some looser controls while we work
the kinks out of our playbooks.

I'm looking for a way to not only log the playbook run itself, but the
entire contents of the playbook so if an event somehow occurs and
something unsavory works its way into the dev environment we can see
what the playbook contents were at the exact time of the playbook run.

I may also consider settling for good, readable command line output of
exactly what was run; the playbook stdout is simply not sufficient.

Does anyone have any suggestions on how I could achieve this?


Thanks!
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+***@googlegroups.com.
To post to this group, send email to ansible-***@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/1430322985.4059917.260237261.6A7E2F3D%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.
Martin
2015-04-29 16:22:56 UTC
Permalink
Hi,

how about doing something like this:

1. wrap the actual playbook run
2. run only thru wrapper!!
3. tag in version control

You might want to swap steps 2 and 3 depending on your requirements.
Basically it resembles a rather basic CI environment where any build
(regardless of outcome) triggers a tag in your preferred SCM.

regards,
Martin
Post by Mark Felder
Hello,
I'm working with ansible in some environments rather sensitive to
security/auditing and we have some significant controls designed around
playbooks working their way up to QA/Prod environments, but our test
environment of course needs to have some looser controls while we work
the kinks out of our playbooks.
I'm looking for a way to not only log the playbook run itself, but the
entire contents of the playbook so if an event somehow occurs and
something unsavory works its way into the dev environment we can see
what the playbook contents were at the exact time of the playbook run.
I may also consider settling for good, readable command line output of
exactly what was run; the playbook stdout is simply not sufficient.
Does anyone have any suggestions on how I could achieve this?
Thanks!
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/1430322985.4059917.260237261.6A7E2F3D%40webmail.messagingengine.com
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+***@googlegroups.com.
To post to this group, send email to ansible-***@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAK1mKERLhnS6WaQad%3Dqy1FehMTjvxMHJ4TvebDVYkE3Jq%2BUXPg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Mark Felder
2015-04-29 16:38:54 UTC
Permalink
Post by Martin
Hi,
1. wrap the actual playbook run
2. run only thru wrapper!!
3. tag in version control
You might want to swap steps 2 and 3 depending on your requirements.
Basically it resembles a rather basic CI environment where any build
(regardless of outcome) triggers a tag in your preferred SCM.
It gets really hard to draw the line; at some point you have to say "we
trust the person with access to run the playbook is not malicious"
because if you require a wrapper (ours will be Tower) someone with ssh
access could run without Tower to get around it... and if they can do
that, why couldn't they disable the additional logging, modules, etc?
There will always be someone with access to bypass these controls, so
I'd like to not add too much complication to the design. I'm also a
little concerned about the insane amount of noise introduced into the
VCS with automatic commits like that, but it's something I've also been
thinking about.

If I can show that the log indicates the run results and what the
playbook looked like it will pacify those with concerns, so that's the
current goal.

Thanks for the idea, though.
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+***@googlegroups.com.
To post to this group, send email to ansible-***@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/1430325534.4068857.260252389.5EB8938C%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.
Dan Vaida
2015-06-19 10:26:42 UTC
Permalink
Hi Mark,

One of the talks that were at our first Ansible meetups here in Berlin was
about this very topic more or less. The guys were using an Ansible callback
plugin to save the playbook run output in Elasticsearch.
I'm not sure if they managed to opensource their work yet but here's
another plugin doing
that: https://gist.github.com/metmajer/7da2f9599c2d75d80ee5
I wouldn't go for a wrapper. Callback plugins are so much more elegant.

Cheers,
Dan.
Post by Mark Felder
Hello,
I'm working with ansible in some environments rather sensitive to
security/auditing and we have some significant controls designed around
playbooks working their way up to QA/Prod environments, but our test
environment of course needs to have some looser controls while we work
the kinks out of our playbooks.
I'm looking for a way to not only log the playbook run itself, but the
entire contents of the playbook so if an event somehow occurs and
something unsavory works its way into the dev environment we can see
what the playbook contents were at the exact time of the playbook run.
I may also consider settling for good, readable command line output of
exactly what was run; the playbook stdout is simply not sufficient.
Does anyone have any suggestions on how I could achieve this?
Thanks!
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+***@googlegroups.com.
To post to this group, send email to ansible-***@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/f5d458c1-175f-4257-9eb3-8399bdc1fb37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Mark Felder
2015-07-09 18:21:33 UTC
Permalink
Post by Dan Vaida
Hi Mark,
One of the talks that were at our first Ansible meetups here in Berlin was
about this very topic more or less. The guys were using an Ansible callback
plugin to save the playbook run output in Elasticsearch.
I'm not sure if they managed to opensource their work yet but here's
another plugin doing
that: https://gist.github.com/metmajer/7da2f9599c2d75d80ee5
I wouldn't go for a wrapper. Callback plugins are so much more elegant.
I'm not sure this is the same thing. I'm trying to log things that
Ansible does not currently expose at any logging level.

https://github.com/ansible/ansible/pull/11004
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+***@googlegroups.com.
To post to this group, send email to ansible-***@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/1436466093.3468570.319696401.1B7BBB7F%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.
Loading...