Ansible GIT Configuration Solution Design
Ansible is a widely used automation tool for infrastructure configuration that Cloudify interacts with via the new Ansible Plugin. The plugin connects lifecycle steps in Cloudify blueprints to Ansible playbooks. The operational model of the plugin dictates that the playbooks be included as part of the blueprint that uses them. But what if the user wishes the playbook repository be managed apart from Cloudify? This post describes a recent solution architecture that combines Git goodness, especially shared access and versioning, to an Ansible playbook file system.
Ansible organizes automations into "Playbooks". Playbooks are text files in YAML syntax, composed of "plays". Plays are high level automation steps consisting of tasks. Tasks are run sequentially and ultimately implemented by the platform remote shell (typically ssh or winrm). Playbooks are associated with "inventory", which represent host targets for the playbook. Inventory is represented by a file that is supplied to Ansible during playbook run. Ansible goes far beyond these basic primitives, but these basic concepts are sufficient for understanding the solution.
The solution requirements included playbook management external to Cloudify blueprints. Using a shared file system would be error prone, given possible simultaneous edits, and the possibility of Cloudify accessing the playbook during an heal or scale workflow while the playbook was partially updated. To deal with both of these scenarios, and to add overall flexibility in managing playbooks, git was chosen to manage the playbooks. Playbook creation, editing, and deletion would be managed by git, and Cloudify blueprints would be configured to refer to specific repository tags.
Clearly git itself could be controlled on an externally managed HA filesystem, but the simplest, most generally usable solution was to expose GIT over HTTPS, and run it on the Cloudify server node itself. To do so, the git server installation and the playbooks would be provided by via a Cloudify blueprint. The job of the blueprint is to initialize the git repo on the manager, populate a Cloudify server replicated directory with the playbooks, and start the server on a well know port. This pattern is an example of using Cloudify blueprints to extend Cloudify itself, in the sense of adding additional APIs and capabilities. Post installation, subsequent blueprints can refer to the Cloudify git server, and ordinary git clients can access repository.
With a versioned, HA playbook repository on the Cloudify Manager, the remaining missing piece is how to command Ansible to run playbooks from the repo with the proper inventory (derived from the Cloudify topology). The execution of Ansible playbooks is already covered by the existing Cloudify Ansible plugin. The plugin presumes a blueprint contained playbook directory, not a git repo. The fetching of git managed content is not something we want to blend with a plugin targeting Ansible. A relatively clean approach is to add a step prior to the Ansible plugin being used, that prepares the file system environment that the plugin expects. The plugin provides a type (Executor) that take a path to a playbook. Rather than having this be preconfigured in the blueprint, we can substitute a node attribute. By defining a new node type that represents a git repo, version, and path, we can define logic to checkout the proper version into a temporary location and make the path available to the Ansible plugin for use.
Now having seen the solution requirements, one might ask, what about Ansible Tower? In this case, Ansible Tower was not desired by the end user, but it certainly would be a valid alternative (along with an Ansible Tower Cloudify plugin of course). The main takeaways from this post are that Ansible and Git together with a little Cloudify glue can combine the best of two worlds to enable externally managed configuration, and not just for NFV use cases. Another thing to notice is the way a user blueprint can be used to provide light weight extensions to Cloudify itself, not just user orchestration by installing shared services on the manager. Of course give careful consideration to long running services on the manager with regards to CPU and storage impact, as well as high availability/failover survivability.