Introduction
Many of our customers are trying to balance the productivity vs security scale at this point in time. On the one end you can provide access to the Azure Portal but that could provide certain risks and requires an understanding of the portal. On the other hand, if you do not give access to the portal your Operational Teams will not only have to deal with their original workloads of building infrastructure on premises but also creating infrastructure in multiple online clouds. That leads us to think that maybe automation is the answer. During this article I will showcase a recent scenario where we ran into an issue and how we managed to solve that to achieve our final goal.
High Level Overview
The idea with the automation is to free up time for infrastructure engineers while staying secure but increase the velocity of VM deployments for users. This also means the approach should be structured in such a way that we can expand on it later.
Let's take a quick look at the components:
1. PowerApps: The new standard for Low-Code-No-Code apps. Empowering millions every day to create applications without the need for Full Stack Developer skills. In our example we used PowerApps to create the form for our users.
2. SharePoint: Secure file sharing and also the powerful enough to back tools like OneDrive, why not use SharePoint. It's easy to connect it to PowerApps and we can ensure users are signed in and secured. We use a SharePoint page to keep track of our lists.
3. PowerAutomate: This If-This-Then-That from Microsoft. With hundreds of connectors and loads of templates this component we used PowerAutomate for approvals, emails, teams messages and logic for handling DevOps. This means we do not have to authenticate in any weird ways before we could kick of a pipeline build.
4. Azure DevOps Connector: This connector written by Microsoft helps us connect to Azure DevOps from the PowerAutomate flow editor.
5. Azure DevOps Repos: Source control, source control, SOURCE CONTROL! Please store your code in source control. The only way we can embrace the world of DevOps is by improving our habits, templates and code with easy-to-revert options in case we make a mistake. The repos are where we stored our ARM Templates for our Virtual Machines.
6. Azure DevOps Pipelines: Nothing is as cool as running your code on another machine that runs on another machine in some kind of magical container in some cloud. The Pipelines are the agents that will be handling our connection to Azure and our deployment of our VMs.
7. Azure: We need a powerful cloud platform to handle requests these days and Azure works so well with Azure DevOps and integrates well with PowerAutomate so we are deploying VM's in Azure.
Power Automate, the glue that holds no-code-low-code together.
If you have never use PowerAutomate before do yourself a favor and log in to Power Automate | Microsoft Power Platform and look at some of the templates. It is a collection of awesome connectors that can do a vast array of things to make our lives easier. Amazing.
But as I promised at the beginning of this article, we did run into a small issue that would have probably been nothing for an experienced developer.
To understand what we need we need to explain the background of the parameter flow.
Parameter Flow
When building things, we must always ask ourselves what are the ingredients for this "thing" I am building. Only in IT do we bake an entire cake and afterwards see we missed the strawberries. Same goes for Infrastructure as code and parameters. We only try to add the VMName afterwards.
Okay let's take a look at the example we built [can be found on GitHub]
1. We use the parameters feature of YAML in Azure DevOps Pipelines to set up the least number of parameters required to deploy a VM using an ARM Template. The parameters are VMNAME, ADMINUSERNAME, ADMINPASSWORD, LOCATION.
2. In the original PowerApp we also ask the users to fill in those requirements.
3. Then for the tricky bit, in PowerAutomate we used the connector to send a HTTP Request to Azure DevOps. (We tried to use the queue a build but for some reason the JSON payload never seemed to work and I couldn't find any documentation that tells me what to fill in there).
How to structure the body for this HTTP Call:
{
"resources": {
"repositories": {
"self": {
"refName": "refs/heads/main"
}
}
},
"templateParameters": {
"param1": "VM1",
"param2": "Labadmin",
"param3": "xxxxxxxxxxxxxx",
"param4": "eastus"
}
}
Closing
And voila, now Power Automate can be used to run those pipelines and build resources in Azure. now you have an idea of how we managed to create an end-to-end process for VM Creation. I know this didn't go into all the details, but I hope it was useful to some folks out there.
Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts or Power BI Dashboards are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts or Power BI Dashboards be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.