Running Ansible without Ansible!
So before we start, let me try and explain where the idea came from, why we thought this was a problem that needed solving and then I’ll talk about how we did it.
Like I said in my previous story here, some of the clients I have worked with do not like having Ansible running on the localhost. And having a central orchestator for enterprise organisations comes with its’ own overheads. I wanted to build an Internet hosted service capable of executng Ansible, but done so in a way that was not only cloud agnostic and distributed the execution to the localhost. Ansibles native SSH plugin helps with this, but the drawback is that clients tend not to want to open SSH connections from the Internet to there cloud environments.
Now you may not be aware, but I’ve invented a cloud deployment tool — MAZE multicloud. You can find more about MAZE here.
At the moment, MAZE enables users to deploy infrastructure only within the four main cloud providers. I wanted to be able to add runtime configuration, so that when a user drags and drops a resource onto the canvas to be deployed with MAZE, they can specifiy an application configuration project they have established and saved, and MAZE will then deploy an “environment specific” version of your infrastructure. This functionality will be released later this year and will be known as “MAZE deploy”.
For MAZE deploy I wanted a deployment pattern where the host makes a request to “be configured”, passing in some form of configuration / App deployment ID and credentials to gain access to the config. I then wanted that host to “pull and run” the Ansible commands to give a more distributed deployment architecture, without having Ansible running locally as per my previous story here.
There was a number of requirements we had for this. Firstly we wanted to leverage all the investment we had made in Ansible (whether that’s playbooks, roles) that do installation, configuration or both.
Secondly, we did not want Ansible running on the local machines. The third was that we knew SSH connections from an Internet source into customer environments might not go down so well, so we wanted to solve that with a two pronged approach — we wanted to establish a connection over https, and we wanted the client to initate the connection!
So what we ended up implementing was a RESTFul client — server achitecture. We deploy a python client onto the host during execution time (through userdata or similar startup script) and pass in the neccessary application project vars (including ProjectID and credentials associated with the Project). The client then executes the python and makes a call to a RESTFul MAZE deploy service. The MAZE deploy service looks up the associated Application Project, verifies the credentials stored within it and once authenticated proceeds to execute the contents of the Project commands.
It’s here where the magic happens. The Application project will contain references to existing Ansible playbooks / roles and any associated vars defined for this project. MAZE deploy then turns all the Ansible commands read in and converts into Python commands (to be executed locally by the host).
Python interpreters are available for most systems and combned with the fact that under the covers, Ansible is written in Python, made for a sensible choice… we get to re-use all those Ansible playbooks and roles we have developed and re-used over the years, running them locally in a distributed model, without having Ansible installed on the localhost. We are hoping the addition of this makes for a happy security team (because Ansible is not installed locally), a happy DevOps team (because they get to re-use all the playbooks and Ansible roles in exactly the same way they did before), and a happy operations team (who don’t have to worry about scaling a central orchestrator to enormous proportions).
Here’s a work in progress of the output you might expect to see (we will pretify this later when we bring it into MAZEs’ UI).
We are hoping, that with MAZE deploy, MAZE will be able to provide runtime application / software configuration enabling MAZE users to specify deployment specific parameters, e.g. setting nginx specific configuration as quickly as they can build infrastructure with MAZEs’ drag and drop interface. Another benefit of MAZE and MAZE deploy is that it allows anyone to deploy to any cloud (and not have to worry about the differences / nuances between cloud providers). This will hopefully make your choice of cloud be entirely about cost, availability and performance over ease of use / familiarity.
