How to deploy and manage complex cloud applications using Alien 4 Cloud and Ansible playbooks.

With Alien4Cloud, IT teams can easily design portable applications and deploy them on any infrastructure (Physical, virtual, private or public). To do so, the application blueprint is composed of reusable components described with the OASIS TOSCA standard. On top of that, developers can use their favorite tools to define deployments operations that will be executed through Alien4cloud customizable workflows. Indeed, Alien4cloud can integrate with any tool that fits your IT team needs such as Ansible, Chef, Puppet or any other. Today, we will show you how we use Ansible to manage and execute deployments operations such as software install and configurations.

Let’s focus on a technical point of view. Our stack uses three different technologies:

The first one, Alien4Cloud is used as the main user interface: you can create TOSCA components and topologies, and deploy them in your private or public cloud.

Cloudify is a TOSCA-like orchestrator supported by Alien4Cloud, instances and workflows are managed by this software.

Finally, Ansible is the worker: software and SSH connections are handled thanks to playbooks that we need to give as inputs.

Our first challenge is about Ansible: how can we integrate it in our Alien4Cloud/Cloudify stack? This technology is not supported natively and is not TOSCA compliant. Hence, we need some work so users can play some Ansible from Alien4Cloud.

Natively, you can use shell (Unix-like) and batch (Windows©) from Alien4Cloud in your TOSCA operations. We have to add Ansible support so we could use playbooks as a TOSCA operation. The concept is to assimilate an Ansible playbook to a shell or batch script. We want to be able to write in our components’ operations, we assume the playbook needs two inputs:

        input_1: an input
        input_2: another input
      implementation: playbook/a_playbook.ansible

As you can see, we use a new implementation artifact called “ansible” for the create operation. This artifact is simply a zip file of our playbook. When unarchive, you can execute the playbook with the classic ansible-playbook command. Hence, you need to rewrite neither your TOSCA components nor your Ansible playbooks! The integration process is then made easy, just change your implementation. Moreover, the portability and the reusability are guaranteed by TOSCA and Ansible (if you wrote your components well ;)).

Ok, now we know how to tell Alien4Cloud that we want to execute Ansible. The question is: where the Ansible playbook is executed? As you may know, Cloudify is currently the only orchestrator supported by Alien4Cloud. So, with our implementation artifact in Ansible, we tell to Cloudify to execute the playbook. How? We worked on it, some modification on the driver between Alien4Cloud and Cloudify allow executing on the manager a command-line, and obviously, we chose to call the Ansible CLI with our playbook.

Nice, isn’t it? But, something is missing, what about SSH connection? Ansible needs information about the instance on which the playbook will be played: the private key, the IP address and the user are the minimal requirements. Well, we have an orchestrator, let’s use it! Cloudify is close to the infrastructure, when we want an instance (on AWS, Azure, OpenStack…), runtime information are set by the cloud provider. This information can be read thanks to a context shared within a deployment on Cloudify. So, when we call Ansible, we just need to retrieve the information in this context, and, we are done! The stack is complete, and we are now able to run Ansible playbook from Alien4Cloud.

Let’s just recap our architecture and workflow.



  1. Users write and upload their TOSCA components and/or topologies on Alien4Cloud with some playbooks. The relevant application is deployed on a location.
  2. Alien4Cloud interprets TOSCA application’s topology and spots Ansible playbook, the relevant directive is then given to Cloudify.
  3. Cloudify sets up required instances and retrieves all needed information such as IP address, user, and SSH private key.
  4. The orchestrator executes operations following the given workflow. Each operation is an Ansible playbook and is executed with the information given by Cloudify.
  5. For each operation, one execution of Ansible is launched on the relevant instance. The command output is redirected to Cloudify for treatment within the logs system, TOSCA attributes are set also.

Alright, we now have a fully TOSCA compliant stack with Ansible playbook enabled as implementation artifact. We can use playbook in our workflows and execute them as a classic shell script. In the project, Ansible is required as the security department only allows users connecting to instances with Ansible. The integration process is not that hard, even though, we had to patch the driver between Alien4Cloud and Ansible in order to enable the execution of Ansible playbook.

Leave a Reply