Custom Script Extension – Automation, Deployment, and Configuration of Resources

Custom Script Extension – Automation, Deployment, and Configuration of Resources

As the name suggests, you can use the Custom Script for Linux Extension (CSE) to automatically invoke scripts and run them on virtual machines post-deployment. The script may include commands for configuration, and these commands will be executed on the VM once it is deployed.

You can install this extension from the Azure portal, as you saw in Figure 8.23. From an automated perspective, you can include this extension in your ARM template and have the script executed once the deployment is completed. The following is an excerpt from the ARM template showing the provisioning of CSE:

     “properties”:{
        “publisher”: ”Microsoft.Azure.Extensions”,
        “type”: ”CustomScript”,
        “typeHandlerVersion”: ”2.1″,
        “autoUpgradeMinorVersion”: true,
        “settings”: {
           “fileUris”: [
              “https://github.com/rithinskaria/customConfig/customScript.sh”
                 ],
                    “commandToExecute”: ”sh customScript.sh”
                },
            }

Here you can see that we are passing in the URL to the script using the fileUris property and then executing the script using the commandToExecute option. CSEs have 90 minutes to execute the script, so you need to make sure that the actions you specify in the script can be completed in 90 minutes. If the script takes longer than 90 minutes, it is marked as timed out. Also, your VM should be running to execute the script. One downside is if your VM requires a reboot, then CSE cannot continue the execution of the script as the execution process will be terminated during the reboot.

To make sure our VMs can overcome the reboot and execute the script, you have another extension called the Desired State Configuration (DSC) extension.

Desired State Configuration

In the case of CSE, you cannot deal with complex installation procedures such as reboots. Desired State Configuration helps you overcome this crisis and define a state for your virtual machines instead of writing scripts. Desired state configuration files are easy to interpret and implement.

You can define the state of a machine and enforce the state using the DSC extension handler. You could store these configuration files in Azure Storage, in internal storage, or even in source control. The handler is responsible for pulling the configuration and implementing the desired state on the virtual machine. Even if there are installations that require reboots, DSC will continue the execution of the remaining scripts after reboot.

Similar to the CSE implementation, you can add the DSC handler extension to the virtual machine from the Azure portal. You could also incorporate the extension in an ARM template and make sure the target machine achieves the desired state post-deployment. The following is an excerpt from the ARM template showing how to use the DSC extension:

“properties”:{
        “publisher”: ”Microsoft.Powershell”,
        “type”: ”DSC”,
        “typeHandlerVersion”: ”2.9″,
        “autoUpgradeMinorVersion”: true,
        “settings”: {
           “modulesUrl”: ”https://rithin.blob.core.windows.net/DSCModules/dsc.zip'”,
           “sasToken”: ”artifactsLocationSasToken”,
           “configurationFunction”: ”Configure”
                },
           “protectedSettings”: {}
            }

In this template, you are storing the configuration in Azure Blob Storage and injecting that to the target virtual machine for the desired state configuration.

Summary

In this chapter, you studied Azure Resource Manager and Azure Resource Manager templates. As you know, ARM acts like a consistent management layer for resource management, and the ARM template is the declarative automation method for creating resources in Azure. You studied the template design, template modes, and template sections. Then you focused on different sections of an ARM template. Later, you started composing ARM templates using Visual Studio Code. The ARM extension in Visual Studio Code is a boon, and you can create code snippets easily using this extension. Also, you saw how you can export the template of a resource that is already deployed using the Azure portal, Azure PowerShell, and the Azure CLI.

Further, you studied how to create generalized and specialized virtual images in Azure. Using these images, you can create more virtual machines in Azure without the need to configure the VMs. Also, you explored Azure virtual machine extensions. Using extensions, you will be able to perform post-deployment configurations in an automated fashion. Mainly you studied two extensions: Custom Script for Linux Extension and Desired State Configuration extension. The advantage DSC has over CSE is it can be used for a configuration that requires complex procedures such as reboots. Both scripts can be incorporated into ARM templates, and the scripts can be pulled into the target VM for configuration after the deployment is completed.

When you are modernizing applications, it’s recommended that you always take a PaaS-first approach. PaaS solutions offer more productivity, features, and better pricing than IaaS machines. From a shared responsibility model, PaaS requires less effort as most of the underlying infrastructure and runtime management tasks are done by Microsoft. In Chapter 9, “PaaS Compute Options,” you will start exploring some PaaS solutions.