I am not convinced by the advantages of the web gui for deployment against our good old fabric/buildbot/deploy, does someone has a feedback with that tool ?
Anyway, I am always very happy to see OSS projects like that making a living of paid services (or the opposite, whatever ;) ).
Are you comparing the web gui to the command line, or Ansible to fabric? It feels like you're conflating two different things there.
I can't speak for the UI, but I use Ansible to deploy everything. It's been a joy and a lifesaver. I just used it to provision a new server (from zero to full Django stack) in 30 seconds. Fabric will accomplish the same things, but Ansible is much more elegant and terse (by a lot). I definitely, definitely recommend it.
For the UI, we use either ansible-pull or http://www.getinstabot.com, which is a chat room assistant I'm working on in my spare time. Being able to say "instabot deploy feature/discounts to staging2" and have the code running there in ten seconds is fantastic, and only possible thanks to Ansible.
Disclaimer: original ansible author here and I run engineering for AnsibleWorks. First off, ansible itself (which this post is about) is text based. I assume you're talking about AWX, which is coming out shortly in 1.4 form, which is our commercial server -- UI and REST API. (Ansible core is decentralized and doesn't even need a server installation).
AWX is designed around team workflow and wants to be the central hub around your automation tasks. i.e. how do you control who can access what, who's doing what, and make things push button in the hands of people who might not be the ones writing the content. You can delegate the ability of lab staff to manage inventory, but not allow them to deploy software, or let them only deploy specific projects, etc. Same for Dev vs QA vs Ops teams, etc.
I definitely don't think it's something everybody needs, but it's available for those that find it useful, and definitely recommend everybody try it out. In the last release, we added some nice source control integration features so you can still develop in your editor and retain the ability to have the web console and central logging. In the upcoming release, we do some neat things with graphically syncing cloud inventory and provide some bonus console information that is useful if you are working with teams who want to know what's been going on where, and it improves the ability to quickly drill down and see what parts of your infrastructure might need attention.
One of the other features is it's ability to hold onto credentials, so you can share source control, machine access, and other credentials with your team without them needing to actually know those credentials.
If you remove someone from LDAP, they can cease to have access.
Anyway, it's super important that we don't hold ansible core back, so what's going into the product is largely around team workflow, and things that automate workflows in Ansible, just like how Ansible automates your system. It's intended to be able to hand Ansible to other people -- and work better in your overall team context, even people who don't want to be writing playbooks. If you're a 1 or 2 man shop, you might not need it, but try it out anyway and let us know what you think!
Also, here's a blog post about the 1.4 Ansible release, which explains the changelog at a bit higher level:
Haven't used the web gui, so can't comment on it. The core open source ansible product is text-based. A few months ago, I migrated a provision and deploy system from a bundle of fabric and shell scripts to ansible. I'm happy with the results.
Some things are easier to do: builtin templating for things like config files is nice and all the modules I've used work as advertised. Some things are harder: reusing groups of similar tasks is kind of awkward but doable. The main advantage is that the ansible imposes a structure that is necessarily self-descriptive and that makes everything very readable. The docs are great and the learning curve is pretty linear so you can defer messing with advanced features until you need them (at that point you'll probably be happy they exist).
I don't want to hijack this thread, but I've found parameterized roles fit my use case perfectly. However, a couple related things caught me out earlier tonight: both the apt_key 'file' parameter, and 'with_file' seem to ignore the roles search paths. I have an apt role which handles installing the package keys, adding and updating repositories, and installing a list of packages. Passing e.g. 'nginx.key' from the nginx role wouldn't work, as they looked only in roles/apt/tasks rather than roles/*/files as I expected. Passing a full path worked. (If I remember correctly! I'm a little hazy on the exact details now, although if this isn't as expected I can do some legwork tomorrow and raise a bug.)
yeah shoot the list an email on this. All the lookup plugins should use the roles search path already, but it could be that one got missed. I'd probably want to see a snippet of the playbook to understand a little better too. Thanks!
Hi mpdehaan. I hadn't seen parametered roles - maybe I just overlooked them. I did use a lot of parameterized includes but roles would be more flexible. Thanks for the heads up.
Anyway, I am always very happy to see OSS projects like that making a living of paid services (or the opposite, whatever ;) ).