The concept of continuous deployment is a given. It’s the ability to deploy frequently – potentially many times per day. The purpose of these deployments is not – only – to fix bugs but to publish new functionalities quickly. By getting these new functionalities through all environments into production as smoothly and reliably as possible, you decrease time-to-value, generating ASAP new revenue streams. The infrastructure is key but requires transformation, as infrastructure platform deployments need to change, they require becoming code.
Today’s buzz term is Infrastructure as Code (IaC), with this blog I want to cut through the hype and dive-in. We at ASP believe that infrastructure as code is the logical next step in managing a hosting platform, on-premises or in the cloud. But what does it mean? Let’s ask Wikipedia:
“Infrastructure as code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools … The definitions may be in a version control system. It can use either scripts or declarative definitions, rather than manual processes, but the term is more often used to promote declarative approaches.”
When we focus upon infrastructure as code for the Cloud, Microsoft Azure is the logical choice. ASP is a Tier One Microsoft Cloud Solution Provider, which means that we have a direct hotline to Microsoft Azure. Microsoft Azure has all the functionalities to make the switch and manage a hosting platform as code.
It all starts by declaring the Infrastructure in Azure Resource Manager (ARM) templates, which have a basic JSON syntax. JSON files are easy for humans to read and write while they remain easy for machines to parse and generate. Based on a subset of JavaScript, it is built upon key/value pairs and arrays, also referred to as ordered list of values.
An ARM JSON file consists of multiple sections: the schema (mandatory), version (mandatory), parameters, variables, resources (mandatory) and outputs.
The schema and contentVersion define the location of the JSON schema file (URL) that describes template language and the version. The parameters are optional and can be considered as the input but can also be defined in a separate (JSON) file. The variables are reused throughout the JSON file. The resource section defines the resource that are deployed or updated in a resource group. Resource type examples are: a virtual machine (IaaS), a web app (PaaS), an SQL database (PaaS), a virtual network, a VPN gateway, a public IP address, etc. The output are values that are returned after deployment, such as the URL of the deployed solution. These (ARM) JSON files are the configuration files for your Azure infrastructure.
Deploying a basic infrastructure as code is “simple comme bonjour”. An entire infrastructure solution can be deployed with one single PowerShell command.
The PowerShell command is executed manually or through the deploy functionality of Visual Studio (Code). Microsoft Azure offers possibilities to deploy platform independently through Azure CLI and the ARM portal. Alternativity you can leverage your preferred programing language: .NET, Ruby or Java. In the background, they all leverage Azure REST API’s that handle the deployment.
Achieve efficiency and gain time by defining the configuration once and deploying it continuously is a game changer, the actual deployment takes seconds to minutes instead of hours to weeks. Every deployment can be reused, adjusted and redeployed as everything is described in the JSON file(s). Allowing you to replicate the same infrastructure from development, acceptance, testing to production environments.
Take note that I’m not speaking about just deploying one or two VM’s. ARM templates describe complete infrastructure platforms and tie them together. From VM’s, networking, load balancing, storage, firewall, proxies, to whatever you require.
The ARM portal offers the possibility to generate a resource group JSON template, that you can add to your library and work on through the portal or download and work on locally with a JSON editor: Visual Studio (Code).
When you want to create a new solution using JSON, you don’t need start from scratch: try using the Azure templates and resource code snippets in the Microsoft editors or alternatively, leverage the community on Github and fetch out-of-the-shelf templates:
- https://azure.microsoft.com/en-us/resources/templates
- https://github.com/Azure/azure-quickstart-templates
Next to the deployment automation with JSON files Microsoft Azure offers PowerShell Desired State Configuration (DSC) possibilities, which can be thought of as an extension of the JSON automated deployment. The DSC platform provides declarative, autonomous and idempotent configuration, conformance and remediation that prevents configuration drift! The DSC technology enables you to ensure components that are deployed through JSON files have the correct configuration, avoiding errors and preventing time costly deployment mistakes. It describes the configuration state of the guest OS running inside the Azure based IaaS virtual machine through PowerShell.
Microsoft Azure supports DSC through the Azure DSC extension handler and Azure Automation DSC. Both are intended for Azure Virtual Machines (IaaS). In this blog, we’ll focus upon the Azure automation DSC in combination with ARM templates. The DSC Extension is used only to apply settings to the Local Configuration Manager (LCM) and direct it to use the Azure Automation DSC service to deliver and maintain the state of the machine. The compliance state or any error messages from DSC can be viewed in the reporting available with the service.
To start the Azure DSC automation you’ll require an Azure Automation account, for the sake of this blog we’ve already have one setup: https://docs.microsoft.com/en-us/azure/automation/manage-runas-account
The desired state configuration is defined through a PowerShell script, in the example configuration illustrated below we make sure the windows features RSAT & BitLocker are installed, MyDscConfiguration.ps1:
Next, we’ll need to add a desired state configuration script to the automation account, by uploading the MyDscConfiguration.ps1 script (see image).Before you can apply a desired state to a node, a DSC configuration defining that state must be compiled into a node configuration (MOF document) and placed on the Automation DSC Pull Server. All of this is conducted from the automation account interface or -of course- PowerShell.
When the DSC script is compiled, it ready to be applied to Virtual Machine(s) or nodes.
The proof of the pudding is in the eating, the VM guest OS above now lists the Windows features RSAT, while Bitlocker remains installed.
The ARM template and DSC technologies presented in this blog are the enablers for the “continuous deployment” concepts driven by Infrastructure as Code. They reduce complexity, boost efficiency and eliminate manual configuration by driving automation.
Want to automate your hosting infrastructure?
Give us a call: +32 (0) 2 333 40 70 or contact us by email: info@asp.be.