On the one hand, we have accelerated with these developments, and on the other hand, we continued to make manual configurations for each environment in the infrastructures we created through cloud portals. This time, different methods have been developed to reduce manual configuration effort and error probabilities, and to fully automate the deployments of all environments. Some of these methods include the frameworks and various tools that provide infrastructure automation. In this article, I will discuss how we can provide infrastructure automation with a method based on Infrastructure As Code approach. I will also give examples by explaining the automation creates App Service and AKS infrastructure with scripts on Azure DevOps, which are among the most preferred PaaS services in Azure.
Before moving on to the AKS and App Service examples, I would like to state that the approach we are trying to apply here is named "Infrastructure As Code" and give details on the content of the concept.
The first step of the "Infrastructure As Code" is to write the infrastructure features in a language specific to the domain the infrastructure will be created for and store these codes / scripts in the version control tool. The next step is to create the infrastructures by running the codes / scripts received from the source control via automation tools. This approach not only reduces configuration costs and guarantees the creation of standard environments, but also enables to quickly return to previous configurations in case of error in configuration changes. In addition, since the code that creates the infrastructure is a constantly updated content, it also provides living documentation.
Create App Service through Azure DevOps
First, we create a simple script to create App Service in Azure. The App Service has the ability to support traditional runtime, but in this example, we want to run containers on the App Service. We save this script we have prepared with a .bat extension and add it to Azure Repos.
Then we create a release pipeline with the empty template option. We choose the script that we added to
Azure Repos
as
artifact.
We add the
Azure CLI
choose the
Script Type batch
and select the
Script Path
information file that we specified in the artifact. Finally, we add the variables expected by the script to the
Variables
section with their default values.
For the subscription and resource group that we want to create App Service, we create a service connection as below and select this connection in the pipeline.
Then we come to the variables tab and create the
appname, resource group, appplan
and
image
variables that our script expects. Thus, we have established the infrastructure to create the same App Service for as many environments as we want.
Before creating our first App Service, we give the values we want to our variables in the Variable section. Since multiple App Services can run under the same Application Plan, our sample script here does not include creating
appplan, so we make sure to select an existing application plan when specifying the value of the
appplan
variable. Now we trigger our pipeline to create our App Service. At the next stage, we can check the App Service we created through the Azure Portal.
Create AKS through Azure DevOps
Although it is easy to create AKS through the Azure portal, the portal also offers limitations in many configurations. Since our aim is to provide AKS infrastructure automation, we create AKS Script as follows without dealing with subnet / vnet definitions and AAD integrations. Even if it looks confusing when you look at the script, do not be afraid, its automation is as simple as the App Service, there is only a small key point we need to pay attention to.
First, we connect to the subscription we want to create AKS via CLI, create a service principal, and store the information returned to us after the following command we run to use when creating Azure Resource connection.
This time, we select the Service Principal (manual) and enter the information of the Service Principal that we created through the CLI to create the Authentication method for Service connection. Otherwise, when we run the pipeline to create AKS, we may encounter the following and similar authorization errors.
We define the Service Connection by giving the appid, password and tenant id information of the service principal we created, as well as the Azure subscription id and name as below.
In our release pipeline, we use the same pipeline we created in App Service, except for the Service Connection type. Of course, we have more variables defined for AKS. We determine these variables according to our needs and run the pipeline.
After the pipeline is successfully completed, we can check the Azure Kubernetes Services we created through the Azure Portal.
ARM Templates and Terraform are also frequently preferred to create App Service and AKS infrastructure. In my next article, I will talk about how we can achieve automation using these tools.
Sources
