Working with cloud is rather like waiting for expected features than waiting for breakthroughs. Few times a year we have a major announcements about new, but expected features in Azure - and I don't know how it is about you, but I am, in most cases, really greatful for all the engineers working on making our lives
But sometimes there is a chance to "catch" something BIG. A breakthrough. And now I can show you something like this. Not because of new, spectacular tech, like quantum computing, but because of making our lives really easier and more server...less.
Around a week ago, a new functionality was added to Azure Logic Apps. Azure Container Instances connector. With this connector, we are able to perform actions on ACI:
At this point we have 6 actions on the list:
- Create container group
- Delete container group
- Get a list of container groups in resource group
- Get a list of container groups in subscription
- Get logs of a container
- get properties of a container group
Assuming that you have a function (algorithm) written in any language you want (supported by Linux or Windows), running on container, you can run it without maintaining a server, on Azure. And you will pay only for RAM and CPU used by container and Logic Apps actions and triggers.
Everything you need is to point the Docker image you want to use for deployment, a container group to deploy to and few configuration parameters:
As you see, working with ACI (Azure Container Instances), we are creating so-called Container Group, not just deploying single container. It means, that you can deploy more than one container at once - you just need to define the whole group:
A group definition is just a simple JSON:
Another action possible with ACI connector for Azure Logic Apps is a container group deletion action. In ACI (at this point in time), we have no "shut down the container" option nor CI/CD pipeline. It means, that we need to delete a container group, if we want to stop it or redeploy new version. It is much simpler in configuration than creation action:
As you see, I'm using
name variable pointing container group to be deleted. I'm getting this variable from the "Create container group" action - so I'm operating on the same group all the time.
For complete runtime - where container group is making some task at a specified time and then containers are ending their life - we need an Azure Logic Apps action checking group's state. When a container group will succeed with the task (and all the containers will be terminated), our logic should catch this state and delete the group.
So, the complete flow should look like this:
Of course the trigger depends on your needs. In my sample, the container group is created every 30min.
The "Until" loop contains an action, which is checking the group's state in time and if the state is equal to "Succeeded", then "Delete container group" action is performed. To do that, we need to use "Get properties of a container group" action:
The loop is constantly checking a state of the group (with 1h timeout defined).
The action itself is also very simple in configuration:
We just need to define for which container group we need to get properties - as in previous example, I'm using a
name variable from the first action (group creation).
After triggering the flow, we can monitor it (even live):
Of course the completion time (time to "Succeed" state) depends on what your containers are doing. In my example, there are two containers with just a simple
curl command, requesting my own web server. The first container has a 60s
sleep command after
curl and the second one has 120s
sleep - just to show you, that you don't need to have the same, symetric functions in all containers.
FROM alpine:latest RUN apk add --update curl && rm -rf /var/cache/apk/* COPY myscript.sh / CMD /myscript.sh
#!/bin/sh curl http://mywebserver.tld && sleep 60
#!/bin/sh curl http://mywebserver.tld && sleep 120
Depends on the number of containers in the group, the view of the newly created container group will be different. Just after triggering the flow you will see that a Container Group is created:
Then, you can check what is inside the container group:
Containers are starting almost at the same time and with the same outgoing public IP:
Notice the request time in log above, where source IP's are the same. At the end of the log you can see, that my containers have been created behind the same outgoing public IP - probably placed on the same cluster. There is no warranty for having the same outgoing IP every time you create a container group. If you will use also an incoming public IP address, it will probably change after every container group re-creation.
sleep command in my scripts, I'm able to catch the "Running" state of my containers. For short running containers it can be not possible.
Container which ends it's task is going to the "Terminated" state:
When all the containers will go to the "Terminated" state, the whole group will go to the "Succeeded" state and the delete action will take place:
As you can see, the group's state has been checked more than 200 times - it's because there is no "Delay" action in the "Until" loop. If you want to check the state less frequently, just add a "Delay" action to the loop. It's important if you create a lot of flows like this in the future, because in Logic Apps we are paying for each action - so here we need to pay for more than 200 checks.
But remember, that you are also paying for every second of the container's life. So maybe it's better to check more frequent and delete the container group quicker? Of course it depends. You need to calculate it. It's a cloud.