Hi,
I am looking into Ansible to define our infrastructure in, and one charming idea I got from other provisioning systems is to map Git branches to environments. For example, I could try out a change in the infrastructure in a development branch and merge back into master to apply this change to the production servers. Puppet can do this with r10k [1], and Salt has this baked in with its GitFS backend [2].
Is anyone doing something like this with Ansible?
[1] https://github.com/adrienthebo/r10k
[2] http://docs.saltstack.com/topics/tutorials/gitfs.html
Regards,
Joost
Both of these tend to make my eyes bleed.
Generally, I don’t think there’s no reason for Ansible to need to because you could just execute an ansible-playbook command for each environment.
You could just check out your branch in different directories and you are good to go.
(However, this is pretty easy to do in AWX as you would just set up seperate project checkouts)
Both of these tend to make my eyes bleed.
Generally, I don’t think there’s no reason for Ansible to need to because you could just execute an ansible-playbook command for each environment.
But would not developing that playbook be easier in a separate branch than copied from one directory to another?
You could just check out your branch in different directories and you are good to go.
(However, this is pretty easy to do in AWX as you would just set up seperate project checkouts)
Sure, I can set up some Git hooks myself too. That was my plan B. 
Regards,
Joost
Yeah I’m suggesting you would still be using a seperate branch, you’d just have it checked out in a few different places. Same repo, branched, mergeable, still…
Just not having to “git branch” from the checkout location to get to see the one you want when you have to work on it, but rather making it accessible via the current filesystem – thus Ansible need not know about it
Yeah I’m suggesting you would still be using a seperate branch, you’d just have it checked out in a few different places. Same repo, branched, mergeable, still…
Ah, check!
Just not having to “git branch” from the checkout location to get to see the one you want when you have to work on it, but rather making it accessible via the current filesystem – thus Ansible need not know about it
Okay, I can see why you would want to keep this out of Ansible proper. If I would take the directory layout from the Best Practices docs [1], what would be the best place to integrate other branches?
[1] http://www.ansibleworks.com/docs/bestpractices.html#directory-layout
Regards,
Joost
You’d actually branch the entire project, so it wouldn’t affect the hierarchy.
You could just check out the repo at two filesystem different points at different branches.
While I like the concept of ansible getting its info via git, I think
in general its linking something unnecessary into ansible. I'd rather
have an HTTP accessible method where (for example) ansible retrieves
playbooks etc, and writes facts back into e.g. into CouchDB. I can
replicate securely between datacentres, and share inventory across
separate secure infrastructures. I'm not sure if an HTTP arrangement
like GET /ansible/playbooks … PUT /ansible/configs/:server would be
acceptable for core ansible?
Anyway.
In git-contrib there's a module called git-new-workdir which allows
sharing the same git index across multiple working dirs. It should
come in a default install of any recent git in the last couple years.
On my OSX is set as a shell alias:
gnw='/usr/local/Cellar/git/*/share/git-core/contrib/workdir/git-new-workdir'
usage: gnw <repository> <new_workdir> [<branch>]
if your project is stored in /projects/runcible then you can have a
separate checkout like so:
gnw /projects/runcible projects/pea-green-boat leafy-branch
Inside /projects/pea-green-boat it behaves just like a normal git
clone, except that the index is shared from /projects/runcible.
A+
Dave
“I’d rather
have an HTTP accessible method where (for example) ansible retrieves
playbooks etc, and writes facts back into e.g. into CouchDB.”
No, Ansible pushes playbooks.
I don’t see any need for an http layer with it’s own security system here.
As for recording facts, you could definitely write your own callback system, though there is no reason for this to require another network connection.
I’m looking at building a system that keeps facts in a lookaside cache sometime in 1.3 or early 1.4.