# How to "publish" playbooks

**URL:** <https://forum.ansible.com/t/how-to-publish-playbooks/11340>\
**Category:** Ansible Project\
**Tags:** fedora\
**Created:** [March 13, 2012, 1:27am UTC](https://forum.ansible.com/t/how-to-publish-playbooks/11340 "2012-03-13T01:27:07Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![Stephen\_John\_Smoogen](https://avatars.discourse-cdn.com/v4/letter/s/ad7895/32.png) [@Stephen\_John\_Smoogen](https://forum.ansible.com/u/Stephen_John_Smoogen)\
**Post date:** [March 13, 2012, 1:27am UTC](https://forum.ansible.com/t/how-to-publish-playbooks/11340/1 "2012-03-13T01:27:07Z")

</div>

So if I wanted to work out a list of playbooks that I could publish  
for other people to use.. what would be the best way to make sure I  
could do so without slipping out private data (passwords, secret keys,  
Cupcake recipes and such.) Currently for Fedora, we use two git repos  
(one for people in other sysadmin groups can edit) and private for  
those with special access. Any ideas on "best" practices to do this  
with ansible items starting off?

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [March 13, 2012, 1:33am UTC](https://forum.ansible.com/t/how-to-publish-playbooks/11340/2 "2012-03-13T01:33:01Z")

</div>

This is a great question.

How about if we had this in the following optional syntax. if a “vars\_files” is set, we read the paths  
given as a dictionary (aka hash) of attributes, and merge it with the variables that are set already:

vars:  
x: 2  
y: 3  
vars\_files:

- /path/to/datafile.yml
- /path/to/datafile2.yml

I figure this is about a 15 minute patch, so if there’s no better syntax suggestion I will get on that!

You could then keep the datafile.yml out of public hands, while sharing the other file.

(By default you would not need to specify this.)

Sound good?

–Michael

---

<div class="post-metadata">

**Author:** ![Stephen\_John\_Smoogen](https://avatars.discourse-cdn.com/v4/letter/s/ad7895/32.png) [@Stephen\_John\_Smoogen](https://forum.ansible.com/u/Stephen_John_Smoogen)\
**Post date:** [March 13, 2012, 1:50am UTC](https://forum.ansible.com/t/how-to-publish-playbooks/11340/3 "2012-03-13T01:50:56Z")

</div>

It sounds good. I think my best way to a) understand playbooks, and b)  
break playbooks is to convert various sets of tasks that various  
people want done with puppet and/or  
cfengine. I figure in that way it can be "coded" early on on getting  
something done even if it does it completely different from how the  
other tool does things.

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [March 13, 2012, 1:55am UTC](https://forum.ansible.com/t/how-to-publish-playbooks/11340/4 "2012-03-13T01:55:14Z")

</div>

–Michael

> > This is a great question.
> > 
> > How about if we had this in the following optional syntax. if a  
> > “vars\_files” is set, we read the paths  
> > given as a dictionary (aka hash) of attributes, and merge it with the  
> > variables that are set already:
> > 
> > vars:  
> > x: 2  
> > y: 3  
> > vars\_files:
> > 
> > - /path/to/datafile.yml
> > - /path/to/datafile2.yml
> > 
> > I figure this is about a 15 minute patch, so if there’s no better syntax  
> > suggestion I will get on that!
> > 
> > You could then keep the datafile.yml out of public hands, while sharing the  
> > other file.
> > 
> > (By default you would not need to specify this.)
> > 
> > Sound good?
> > 
> > –Michael
> 
> It sounds good. I think my best way to a) understand playbooks, and b)  
> break playbooks is to convert various sets of tasks that various  
> people want done with puppet and/or  
> cfengine. I figure in that way it can be “coded” early on on getting  
> something done even if it does it completely different from how the  
> other tool does things.

Yeah, I think so.

For now, keep in mind that we don’t have some important resources quite just yet:

files (well, we can copy and template, but not set mode/ownership/context)  
users  
groups

We do have things like yum (thanks Seth), services, copy, template, command, etc.

These missing major ones are high up on my priority list to implement soon, though if someone wants to the service  
module as a guide and start going at it that’s welcome too.

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [March 13, 2012, 1:56am UTC](https://forum.ansible.com/t/how-to-publish-playbooks/11340/5 "2012-03-13T01:56:14Z")

</div>

Actually I should add … a side by side of "this is puppet (probably showing a full module tree) vs this is a playbook would be great documentation to have.

We could put that in a contrib repo on github and update it as it gets smarter.

–Michael

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [March 13, 2012, 2:03am UTC](https://forum.ansible.com/t/how-to-publish-playbooks/11340/6 "2012-03-13T02:03:33Z")

</div>

Docs updates pending, but I added this, and here's how it looks:

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [March 13, 2012, 3:14am UTC](https://forum.ansible.com/t/how-to-publish-playbooks/11340/7 "2012-03-13T03:14:10Z")

</div>

Docs updated with lots of edits to the playbook section.

[http://ansible.github.com/playbooks.html](http://ansible.github.com/playbooks.html)

Review would be great.

–Michael

---

<div class="post-metadata">

**Author:** ![Gerhardus\_Geldenhuis](https://avatars.discourse-cdn.com/v4/letter/g/db5fbb/32.png) [@Gerhardus\_Geldenhuis](https://forum.ansible.com/u/Gerhardus_Geldenhuis)\
**Post date:** [March 13, 2012, 2:56pm UTC](https://forum.ansible.com/t/how-to-publish-playbooks/11340/8 "2012-03-13T14:56:20Z")

</div>

Hi  
The following post by a colleague solves a similar problem…  
[http://www.craigdunn.org/2011/10/secret-variables-in-puppet-with-hiera-and-gpg/](http://www.craigdunn.org/2011/10/secret-variables-in-puppet-with-hiera-and-gpg/)

The idea might be adoptable.

Regards

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [March 13, 2012, 3:04pm UTC](https://forum.ansible.com/t/how-to-publish-playbooks/11340/9 "2012-03-13T15:04:48Z")

</div>

That seems way too complicated.

Does this (last night’s feature) solve your problem or no?

[http://ansible.github.com/playbooks.html#external-variables-and-sensitive-data](http://ansible.github.com/playbooks.html#external-variables-and-sensitive-data)

It’s more or less a distillation of the same concept.

Let me know if I’m missing some important capability and what the use case might be.

---

<div class="post-metadata">

**Author:** ![Gerhardus\_Geldenhuis](https://avatars.discourse-cdn.com/v4/letter/g/db5fbb/32.png) [@Gerhardus\_Geldenhuis](https://forum.ansible.com/u/Gerhardus_Geldenhuis)\
**Post date:** [March 13, 2012, 3:16pm UTC](https://forum.ansible.com/t/how-to-publish-playbooks/11340/10 "2012-03-13T15:16:05Z")

</div>

I think the above would mostly solve our problem but you would still need to store that file with variable data somewhere centrally… within your organization. We don’t want to expose passwords to everyone that has svn/git access in the organization ( our svn is a bit open… ) and being able to encrypt them is rather useful.

With with regards to sharing playbooks on the internet, having a central file that you can sanitize would be better/easier but such a file would still need to be distributed along with the example code to get someone else quickly going that wants to use your playbook example.

Regards

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [March 13, 2012, 3:25pm UTC](https://forum.ansible.com/t/how-to-publish-playbooks/11340/11 "2012-03-13T15:25:20Z")

</div>

> > That seems way too complicated.
> > 
> > Does this (last night’s feature) solve your problem or no?
> > 
> > [http://ansible.github.com/playbooks.html#external-variables-and-sensitive-data](http://ansible.github.com/playbooks.html#external-variables-and-sensitive-data)
> > 
> > It’s more or less a distillation of the same concept.
> > 
> > Let me know if I’m missing some important capability and what the use case might be.
> 
> I think the above would mostly solve our problem but you would still need to store that file with variable data somewhere centrally… within your organization. We don’t want to expose passwords to everyone that has svn/git access in the organization ( our svn is a bit open… ) and being able to encrypt them is rather useful.

You could have a bit more locked down git, with SSH only access, for password info. I know some people that do that.

You could also require folks to decrypt from that git to local storage and even have a Makefile or something do it.

I think is pretty good for a minimally viable product, anyway.

Upgrade suggestions that don’t require a config file are welcome though.

> With with regards to sharing playbooks on the internet, having a central file that you can sanitize would be better/easier but such a file would still need to be distributed along with the example code to get someone else quickly going that wants to use your playbook example.

Yes, I think likely you could ship a copy of the file with the passwords scrubbed out. Or just document all the variables in the “vars” section with defaults  
that get overridden by the the files in “vars\_files”.
