Here we are! This is the second part of the series about Microsoft Azure, Ansible automation, and opera orchestration. If you missed the first part consider having a look here as this could enlighten some things from this blog post you might not be familiar with. Here we will talk about the process of orchestration of the automated Azure Functions deployment.
Automation is not enough
In the previous blog post, we automated the deployment of Azure function. Is that it? Could be, but no! The true power shall come with the orchestration. This whole process can relieve us and arrange automated tasks in order. For this part, the opera, a TOSCA orchestration tool that is a part of in xOpera project, will shine helping to make a complete solution. Just lo and behold the diagram below that shows how the user can initiate the orchestration process that will use the prepared TOSCA YAML service templates along with the Ansible playbooks implementation with the developed Azure Function App Ansible Collection. As you can see, apart from the orchestrator, this whole process will also require installing Azure CLI Python package and a prepacked zip artifact containing Azure Python Function.
Orchestration and automation diagram for Azure function.
TOSCA and opera are performing together
The orchestration with OASIS Topology and Orchestration Specification for Cloud Applications or shorter OASIS TOSCA allows users to specify their full application topology, describing all the important parts and connections between them within a simple TOSCA YAML template. To be able to deploy (and later maybe undeploy) our solution we need to parse and equip TOSCA templates with the implementation. This is exactly what the opera orchestrator is capable of by executing Ansible playbooks as orchestration actuators. The orchestrator is available as a Python package on PyPI as a python package and can be installed easily (also look for more info in the opera’s documentation). All in all, we can see that TOSCA and opera are stronger together. Opera supports TOSCA and thereby becomes a general orchestrator for cloud solutions. On the other hand, TOSCA gets a practical meaning within the opera tool by linking TOSCA templates with Ansible playbook implementations, which are then executed, unlocking numerous automation possibilities.
From XLAB with love
One of the most important parts of orchestration is the preparation of the TOSCA service template which needs to be readable, user-friendly, and extensible. Basically you should just bring a little lovin’ when you write it. We did just that and created a roadmap for our TOSCA template showing all the orchestration inputs, node types, templates, and outputs.
TOSCA service template plan.
A sharp eye will notice that we also have an input for Azure credentials which is optional. And we really don’t want to expose our Azure username and password to anyone. So at this point, we need to set a reminder that whatever you do the security cannot be waved aside. True heroes know that with great power comes great responsibility. We do as well. And for that, we programmed our Ansible Function App module to read the credentials from environment variables which are not stored anywhere inside the orchestrator.
Prepared orchestration files.
We agreed that the process of orchestration should feature full solution deployment with the minimum amount of clicks in the Azure portal. So we prepared Azure CLI commands that would also set up a new Resource Group and a fresh Storage Account before the deployment of Azure function. This way the user would only need to have an Azure account and then he can just deploy everything.
Successful orchestration can surely make your day happier.
The orchestration process was successful and the function code was successfully transferred into the created Azure FaaS environment. Invoking the current time function in the Azure portal or somehow else worked nicely. Just imagine what we could do with more complex functions that could be used in big IT systems. To experience the full orchestration process take a look at the video below:
Part of the journey is the end
However, it’s not about the destination, it’s the journey that counts, right? Throughout our whole path and a series of the two blog posts, we learned a lot about the cloud, FaaS, automation, and orchestration. Our story here has a good ending since we managed to fully automate and orchestrate the deployment of Azure functions. There is of course always room for improvement but this is a good start. So, if curiosity can’t stop eating you and you are willing to see more, take a look at our Steampunk AWS Ansible Collection here.
