Ansible 2 is out, and that means it’s time to upgrade the previous article on Running Ansible Programmatically for Ansible 2, which has significant API changes under the hood.
At work, we are spinning up hosted trials for a historically on-premise product (no multi-tenancy).
To ensure things run smoothly, we need logging and reporting of Ansible runs while these trials spin up or are updated.
Each server instance (installation of the application) has unique data (license, domain configuration, etc).
Running Ansible programmatically gives us the most flexibility and has proven to be a reliable way to go about this.
At the cost of some code complexity, we gain the ability to avoid generating host and variable files on the system (although dynamic host generations may have let us do this – this is certainly not THE WAY™ to solve this problem).
There are ways to accomplish all of this without diving into Ansible’s internal API. The trade-off seems to be control vs “running a CLI command from another program”, which always feels dirty.
Learning some of Ansible’s internals was fun, so I went ahead and did it.
Overall, there’s just more control when calling the Ansible API programmatically.
I wrote an earlier post about evaluating Ansible as an alternative to Chef. So after spending many years with Chef, I’ve found that Ansible is a lot easier to manage with startups. It’s easier to train developers, it’s easier to manage inventory and orchestration, and it works reasonably well on the scale of thousands of hosts. And let’s face it, if you have more than that, you’ll have to start partitioning. If you’re using Puppet, you’ll have multiple puppet masters, I’m assuming the same with Salt. For Chef, there’s the enterprise offering which gets pretty expensive and then you’ll have to deal with a slow search, so invariably there’s some usage of chef-solo going on and some self-configuration. But for most use cases, Ansible is just fine and is quick to both setup and is ridiculously easy to maintain. This is a fairly advanced post comparing Chef to Ansible and the patterns that are available…
“In this tutorial I will walk you through the steps for using Ansible to install and deploy the open source NGINX software and NGINX Plus, our commercial product. I’m showing deployment onto a CentOS server, but I have included details about deploying on Ubuntu servers in Creating an Ansible Playbook for Installing NGINX and NGINX Plus on Ubuntu below…”
“One reason I chose Ansible was due to its ability to maintain a fully immutable server architecture and design. We will get to exactly what I mean later, but it’s important to note –my goal in writing this post is not compare or contrast Ansible with other products.There are many articles available online regarding that. In fact, some of the things I love about Ansible are available in other configuration management tools.
My hope with this article is actually to be able to give you some Ansible use cases, practical applications, and best practices; with the ulterior motive of persuading you that Ansible is a product worth looking into. That way you may come to your own conclusions about whether or not Ansible is the right tool for your environment…”