Xylos brands

How to use code to define app rollouts

Which templates do you use to roll out apps and infrastructure using code? We recommend templates which contain a desired state and which you can roll out idempotently (this means you can execute the template multiple times without impacting the current state). Think of ARM templates and Kubernetes manifests, for example.

1. Getting started with ARM templates

ARM stands for Azure Resource Manager, Azure’s deployment and management service. ARM templates describe the components you want to roll out or edit. For example: you could use an ARM template to roll out AKS (Azure Kubernetes Service). In the ARM template, you specify the following:

  • the name of the AKS cluster
  • the number of nodes
  • the network integration

We used this template for our OASE application. You’ll notice these ARM templates look rather cryptic. They’re written in JavaScript Object Notation (JSON) and can contain specific ARM functions as well. Welcome to the wonderful world of Infrastructure-as-Code (IaC).

The execution of the template is idempotent, which means we can execute the template multiple times without impacting the result. If we adjust the number of servers on line 132 (see code in the above-mentioned link) and execute the template again, Azure will carry out the necessary adjustments. As an engineer, you don’t need to know how to edit the cluster; you just need to edit the template and let ARM take care of the rest.

2. Getting started with Kubernetes manifests

ARM templates are perfectly suited to roll out Azure components, but if you want to roll out an application in Kubernetes, you’ll need to use Kubernetes manifests. These follow the same principles as ARM templates: they contain the desired state and they’re idempotent.

Let’s create a manifest to roll out the web application from our earlier blog posts. Just like in the previous blog post, we’ll need two containers, a deployment, a service that’s available through an Azure Load Balancer and a public IP address. To do this, we’ll create a YAML file in which we first set up the service:

Just like in the previous blog post, we’ll use an Azure Load Balancer to make our application available on an external IP address on port 80. After defining the selector (app=nasnet), the service will make all containers labeled ‘nasnet’ available. To do this, we’ll need to label the containers, which can be done with the following deployment:

This definition creates a deployment with two containers (replicas: 2). We always use the container image xylos/nasnet. Internally, these containers respond to requests on port 9090.

Have a look at the complete YAML file.

  • Use the following command to start the rollout:

kubectl apply -f nasnet.yaml

  • If you’ve made an error, you can delete everything easily:

kubectl delete -f nasnet.yaml

3. Conclusion

ARM templates and Kubernetes manifests have several advantages compared to manual commands. You can easily enter them in a code library (such as git), you can store and compare versions, you can test if they’re correct, and much more.

Now that you know how to roll out the Azure infrastructure and application, it’s time to proceed to the next step: automating the rollout with Azure DevOps. Have you read these blog posts in our series ‘6 steps to the cloud’ yet?

We’ve already discussed the following topics on our journey through the world of containers:

  • How to use containers
  • How to create containers
  • How to roll out containers with the container orchestrator Kubernetes


Share this blogpost

Leave a reply

Your email address will not be published. Required fields are marked.