Dancing Around With Microsoft Azure and Ansible

As the usage of cloud providers like Amazon Web Services, Microsoft Azure, Google Cloud Platform, and so on is growing rapidly, the automation and orchestration also need to expand in order to reduce the human factor when deploying and delivering applications to the end users. We decided to explore some of the most exciting features and environments and have created a series of two blog posts. This one will talk about the Microsoft Azure platform and establishing the automation of its resources and the next one will cover the orchestration process.

Every story has a beginning

Our original goal was to develop an automated solution that would feature deploying Function as a Service environment on Microsoft Azure. The cloud environment can be a tough, but also a challenging place to start developing Ansible Collections. Each cloud provider has its specific features that need to be explored in detail to be able to provide a fully automated solution. So, let’s dive in and find out how we did it for Microsoft Azure.

The mysterious Microsoft Azure

Microsoft Azure is one of the most used cloud providers, present in more than 140 countries with 60 data centers around the world. To start using it we need an Azure Active Directory account with our credentials. For logging into Azure there are multiple possible ways. The usual path leads through the browser, but more advanced users may also use the REST API or Azure CLI tool. The former may be very complicated at the start and the latter is very helpful since you can easily modify cloud resources via console environment on almost any OS.

Then, finally, the more interesting part can start, which means that the user will create his own Azure resource group that serves him as an envelope where all his resources will reside. After that, he can continue creating other resources like the ones for storage or virtual machines. We will mostly focus on Azure Function Apps which turn out to be a promising Azure feature.

SaaS, PaaS, IaaS? No, FaaS!

The latest evolving technologies also support developing serverless applications which means that cloud providers will take care of the infrastructure management so that the developers can deeply focus on writing the application code. This is the driving force in the Function as a Service (FaaS) principle which is nowadays used for instance in microservices, bots, IoT, and machine learning. AWS Lambda, Azure Functions, Google Cloud Functions, IBM Cloud Functions, OpenFaaS all offer FaaS functionalities. Azure Functions live in an environment called Azure Function App which can include multiple functions that target the same OS type and also the same runtime environment. Below you can see how the code for Azure Python function for printing out the current time looks like.

    import json
    import logging
    
    import azure.functions as func
    
    '''
    Azure hello function for testing 
    '''
    
    
    def main(req: func.HttpRequest) -> func.HttpResponse:
        logging.info('Python HTTP trigger function processed a request.')
    
        hello_message = "Hello, I am Azure Python Function and I can be your best friend or partner in crime!"

A goal without a plan is just a wish

Azure Functions can be great but when you realize that before you can invoke the function, you have to create a Resource Group, Storage Account, and Function App, this may scare some users and drive them away. Nevertheless, we ignored that extra work because we will automate it anyway. The same applies for automating the deployment of Azure Functions which presented as a good challenge. “No time to lose”, we said and made a plan for our Ansible Azure Collection with Azure Function App being its very first Ansible module.

Developing, developing and more developing

We collected all the possible params for Azure Function App where the most important were Function App name, its location, OS type, and runtime. We formed the development of module which uses the Azure CLI PyPI package to authenticate to Azure and to manipulate the cloud resources (this is the part where we created a helper class for easier usage). The resulting tree structure of our Ansible Collection is shown in the following figure.

Testing is important yesterday, today, and forever

Every Ansible Collection should be properly tested. We included sanity, unit, and integration tests. With the unit tests, we tested the functionality of the aforementioned helper class and checked how the Azure CLI az command that is later executed is built. The integration tests featured creating and deleting multiple Function Apps with different OS types (Linux and Windows) and runtimes (Python, Java, C#,…).

We’re cloudbusting!

Finally, the time came to test the deployment of Azure Function App to the Microsoft Azure cloud with an actual Ansible playbook. We have chosen to deploy the Linux Function App with Python 3.7 runtime environment with the same current time Python function that was introduced above. There we also included packaging Python current time function to a zip archive that will get deployed and unpacked in the cloud.

To sum it up

We came to the end of the first part of the series. Now that we learned something about Azure and Ansible automation, we can move forward to see what power lies in the orchestration. See the sequel.