Infrastructure as Code (IaC) – Part 1
This post is the beginning of a series about several tools and services for provisioning and managing on-premises and cloud infrastructures. The tools and services will describe, provision and finally ensure a desired state for our provisioned infrastructure (resources) by just using code.
Below I will list all these tools and services with a short description and also link to a separate post where I will show them in action.
In a nutshell, with IaC you can automate and manage your infrastructure by just using code instead a graphical user interface.
Introduction
Infrastructure as Code, often abbreviated as IaC, is an approach to managing and provisioning IT infrastructure using code and automation. In essence, it treats infrastructure elements such as servers, networks, and databases as programmable entities, allowing organizations to deploy, configure, and scale their infrastructure with speed, consistency, and precision.
Iac represents a powerful approach that enables organizations to efficiently and dynamically create, configure, and manage their infrastructure, treating it as if it were software code.
Traditionally, infrastructure provisioning and management were often manual, error-prone, and time-consuming processes. System administrators and operations teams would painstakingly set up servers, networks, and other resources, often resulting in inconsistencies, delays, and an overall lack of scalability. However, with the advent of IaC, this status quo has been disrupted.
IaC promotes consistency and repeatability, reducing the risk of configuration drift and ensuring that infrastructure is always in the desired state. It facilitates collaboration between development and operations teams, fostering a DevOps culture where infrastructure and application development are tightly integrated.
Below I will list some tools and services we can use to for provisioning and managing on-premises and cloud infrastructures by just using code.
Each of theses tools I will show in action and describe it in detail in the following posts.
First we will see all native Microsoft tools and services for Iac which are namely Azure Resource Manager (ARM) templates, PowerShell Desired State Configuration (DSC), Azure Automation State and finally the newest product from Microsoft named Azure Automanage Machine Configuration (formerly called Azure Policy Guest Configuration).
Native Microsoft and Azure Support for IaC
Microsoft offers several tools and services for Infrastructure as Code (IAC) to help users automate the provisioning and management of their infrastructure. Below I will show some of these tools and services mostly used for.
These tools and services from Microsoft can help you implement Infrastructure as Code practices, automate infrastructure provisioning, and manage your cloud resources efficiently within the Azure ecosystem. Depending on your specific needs and preferences, you can choose the tools and services that best fit your IAC workflows.
ARM templates
Azure Resource Manager (ARM) templates can be used for defining, deploying and managing Azure resources in a consistent, repeatable, and scalable manner.
ARM templates, at their core, are JSON (JavaScript Object Notation) files that encapsulate the desired state of your Azure infrastructure. They serve as blueprints for your cloud resources, allowing you to declarative specify everything from virtual machines and databases to networks and storage accounts.
In Part 2 of this series, you will get detailed information about ARM templates and I will show how you can use them to deploy Azure resources.
Desired State Configuration (DSC)
DSC is a powerful framework developed by Microsoft that enables the declarative definition and automated maintenance of the desired state of your systems and applications. This approach is a reliable way of ensuring that your systems consistently adhere to their intended configuration.
At its core, DSC allows you to express what you want your systems to look like, rather than prescribing a sequence of steps to achieve that state. This concept has far-reaching implications for system administrators, DevOps teams, and organizations at large, as it enhances scalability, repeatability, and agility while reducing manual configuration errors.
In Part 3 of this series, I will show how you can use DSC to accomplish and ensure a final desired configuration of a system.
Azure Automation State
Azure Automation State Configuration is an Azure configuration management service that allows you to write, manage, and compile PowerShell Desired State Configuration (DSC) configurations for nodes in any cloud or on-premises datacenter. The service also imports DSC Resources, and assigns configurations to target nodes, all in the cloud.
You can use Azure Automation State Configuration to manage a variety of machines:
- Azure virtual machines
- Azure virtual machines (classic)
- Physical/virtual Windows machines on-premises, or in a cloud other than Azure (including AWS EC2 instances)
- Physical/virtual Linux machines on-premises, in Azure, or in a cloud other than Azure
Managing Azure VMs with Azure Automation State Configuration is included at no extra charge if the installed Azure VM Desired State Configuration extension version is greater than 2.70. For more information, see Automation pricing page.
Azure Automation State Configuration provides several advantages over the use of DSC outside of Azure. This service enables scalability across thousands of machines quickly and easily from a central, secure location. You can easily enable machines, assign them declarative configurations, and view reports showing each machine’s compliance with the desired state you specify.
Azure Automation State Configuration provides a DSC pull server similar to the Windows Feature DSC-Service. Target nodes can automatically receive configurations, conform to the desired state, and report on their compliance. The built-in pull server in Azure Automation eliminates the need to set up and maintain your own pull server. Azure Automation can target virtual or physical Windows or Linux machines, in the cloud or on-premises.
Source: https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview
Azure Automation State Configuration is built on PowerShell Desired State Configuration (DSC). You can find the documentation for the DSC language and syntax in the PowerShell DSC Docs.
Before you enable Automation State Configuration, we would like you to know that a newer version of DSC is now generally available, managed by a feature of Azure Policy named guest configuration.
The guest configuration service combines features of DSC Extension, Azure Automation State Configuration, and the most commonly requested features from customer feedback. Guest configuration also includes hybrid machine support through Arc-enabled servers.
Source: https://learn.microsoft.com/en-us/azure/automation/automation-dsc-getting-started
As usually nothing in cloud computing and especially Microsoft Azure lasts for long, also the successor (Azure Policy Guest Configuration) of Azure Automation State meanwhile changed its name and is moving under the Automanage brand umbrella.
!!! Note !!!
Azure Policy Guest Configuration is now called Azure Automanage Machine Configuration.
Source: https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview
In Part 4 of this series, I will show how you can use Azure Automation State to accomplish a final desired configuration of a system.
Azure Automanage Machine Configuration (formerly called Azure Policy Guest Configuration)
Azure Policy’s machine configuration feature provides native capability to audit or configure operating system settings as code for machines running in Azure and hybrid Arc-enabled machines. You can use the feature directly per-machine, or orchestrate it at scale by using Azure Policy.
Configuration resources in Azure are designed as an extension resource. You can imagine each configuration as an extra set of properties for the machine. Configurations can include settings such as:
- Operating system settings
- Application configuration or presence
- Environment settings
Configurations are distinct from policy definitions. Machine configuration uses Azure Policy to dynamically assign configurations to machines. You can also assign configurations to machines manually, or by using other Azure services such as Automanage.
Source: https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview
Azure Automanage itself will monitor for drifts and corrects for it when detected. What this means is if your virtual machine or Arc-enabled server is onboarded to Azure Automanage, it will monitor the machines to ensure that it continues to comply with its configuration profile across its entire lifecycle.
If the virtual machine does drift or deviate from the profile (for example, if a service is off-boarded), it will correct it and pull the machine back into the desired state.
Not just the configuration profiles like the built-in best practices profiles from Automanage will be monitored and corrected in case of a drift but also the machine configuration (our PowerShell DSC )
In Part 5 of this series, I will show how you can use Azure Automanage Machine Configuration to accomplish a final desired configuration of a system.
Third-party Platforms Support for IaC
The following third-party platforms also support IaC to manage automated infrastructure.
Terraform
Hashicorp Terraform is an open-source IaC (Infrastructure-as-Code) tool for provisioning and managing cloud infrastructure. It codifies infrastructure in configuration files that describe the desired state for your topology. Terraform enables the management of any infrastructure – such as public clouds, private clouds, and SaaS services – by using Terraform providers.
Source: https://learn.microsoft.com/en-us/azure/developer/terraform/overview
Terraform relies on plugins called providers to interact with cloud providers, SaaS providers, and other APIs.
Terraform configurations must declare which providers they require so that Terraform can install and use them. Additionally, some providers require configuration (like endpoint URLs or cloud regions) before they can be used.
Terraform providers for Azure infrastructure
There are several Terraform providers that enable the management of Azure infrastructure:
- AzureRM: Manage stable Azure resources and functionality such as virtual machines, storage accounts, and networking interfaces.
- AzureAD: Manage Azure Active directory resources such as groups, users, service principals, and applications.
- AzureDevops: Manage Azure DevOps resources such as agents, repositories, projects, pipelines, and queries.
- AzAPI: Manage Azure resources and functionality using the Azure Resource Manager APIs directly. This provider compliments the AzureRM provider by enabling the management of Azure resources that aren’t released. For more information about the AzAPI provider, see Terraform AzAPI provider.
- Azure Stack: Manage Azure Stack resources such as virtual machines, DNS, VNet, and storage.
In Part 6 of this series, I will show how you can use Terraform to provision and automate the creation of Azure resources.
Ansible
Ansible is an open-source product that automates cloud provisioning, configuration management, and application deployments. Using Ansible you can provision virtual machines, containers, and network and complete cloud infrastructures. Also, Ansible allows you to automate the deployment and configuration of resources in your environment.
Source: https://learn.microsoft.com/en-us/azure/developer/ansible/overview
Progress Chef (formerly Chef)
Chef is an automation company. Ever since it was founded in 2008, we have been bringing together developers and system administrators with our namesake product, Chef Infra. Over the years, what we mean by automation has expanded. Today, Chef has a complete automation solution for both infrastructure and applications that takes you all the way from development to production.
Source: https://docs.chef.io/platform_overview
Chef Infra
Chef Infra is a powerful automation platform that transforms infrastructure into code. Whether you’re operating in the cloud, on-premises, or in a hybrid environment, Chef Infra automates how infrastructure is configured, deployed, and managed across your network, no matter its size.
Source: https://docs.chef.io/platform_overview/#chef-infra
Puppet
Puppet is designed to manage the configuration of Unix-like and Microsoft Windows systems declaratively. The user describes system resources and their state, either using Puppet’s declarative language or a Ruby DSL (domain-specific language). This information is stored in files called Puppet manifests. Puppet discovers the system information via a utility called Facter, and compiles the Puppet manifests into a system-specific catalog containing resources and resource dependency, which are applied against the target systems. Any actions taken by Puppet are then reported.
Source: https://en.wikipedia.org/wiki/Puppet_(software)
Infrastructure Automation & Compliance at Enterprise Scale
https://www.puppet.com/
Pulumi
Pulumi enables us to perform Infrastructure as code using existing programming languages. So what’s the difference you may be asking?
Pulumi versus Traditional IaC
Infrastructure as Code as we already know it, typically uses language-independent data formats, such as JSON or YAML to define our infrastructure. Terraform is slightly different, and uses a Domain Specific Language (DSL), Hashicorp Configuration Language (HCL) to construct our templates.
This is where Pulumi is slightly different. With Pulumi, we don’t need to learn a DSL or use JSON or YAML. If we’re already familiar with a programming language, Pulumi enables us to define our infrastructure using that language.
This means that we can also leverage the standard functions within those programming languages too, things like loops, variables, error handling etc.
These functions are available in the other tools we’ve mentioned too. For example, creating multiple resources could be achieved by using a for loop in Python if using Pulumi or by using the copy functionality if using Azure Resource Manager (ARM).
Pulumi is just, as we’ve already covered, enabling you to do this using existing programming languages. For someone who is a Developer, this may sound great, however, for a Cloud Engineer who lives and breathes JSON or YAML, other tools may be more preferable. As always, choose the tool that meets your own requirements.
Source: https://devblogs.microsoft.com/devops/infrastructure-as-code-azure-python-wpulumi/
Series Summary
- Infrastructure as Code (IaC) – Part 1
- Infrastructure as Code (IaC) – Part 2 – Azure Resource Manager (ARM) templates
- Infrastructure as Code (IaC) – Part 3 – Desired State Configuration (DSC)
- Infrastructure as Code (IaC) – Part 4 – Azure Automation State
- Infrastructure as Code (IaC) – Part 5 – Azure Automanage Machine Configuration (formerly called Azure Policy Guest Configuration)
- Infrastructure as Code (IaC) – Part 6 – Terraform
Links
ARM template documentation
https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/PowerShell Desired State Configuration overview
https://learn.microsoft.com/en-us/powershell/dsc/overview?view=dsc-3.0Get started with Azure Automation State Configuration
https://learn.microsoft.com/en-us/azure/automation/automation-dsc-getting-startedAzure Automanage Machine Configuration documentation
https://learn.microsoft.com/en-us/azure/governance/machine-configuration/Overview of Terraform on Azure – What is Terraform?
https://learn.microsoft.com/en-us/azure/developer/terraform/overviewUsing Ansible with Azure
https://learn.microsoft.com/en-us/azure/developer/ansible/overviewProgress Chef (formerly Chef)
https://docs.chef.io/platform_overview/Infrastructure Automation & Compliance at Enterprise Scale
https://www.puppet.com/
