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?
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.
–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.
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
Docs updates pending, but I added this, and here's how it looks:
Docs updated with lots of edits to the playbook section.
http://ansible.github.com/playbooks.html
Review would be great.
–Michael
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/
The idea might be adoptable.
Regards
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
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.
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
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
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”.