Azure
From Terraform version 1.10 and later we now have support for ephermal blocks which are resources that will not be persisted to the Terraform state. A reoccurring issue with Terraform is secrets and sensitive values in state management. Sure, state is for example encrypted at rest when residing in
Azure
In THIS previous post we looked at managing Entra Privileged Identity Management (PIM) with Terraform and working with Azure RBAC roles. That is great but did you know that you can onboard Entra Groups to PIM and therefor also manage them in Terraform? In todays post we'll look
Azure
If you are deploying Azure resources you are most likely doing so using the azurerm provider which requires you to supply a subscription_id and Terraform will run in the context of this subscription both from your local server and from your pipeline runners. Imagine that you have a CICD
Azure
Introduction There is no surprise to anyone who has seen my content before that I kind of love Infrastructure as Code (IaC), I really do. However, there seem to be a lot of people who think only about Azure resources when IaC is introduced into the conversation but that is
Azure
There are several ways you can manage Policy as Code with Microsoft Azure. There are things like Enterprise Policy as Code (EPAC) and Azure Landing Zone Conceptual Architecture (ALZ) (Both Terraform and Azure Bicep options exist). Not to mention the different ALZ accelerators that exist but they are more focused
Azure
There are two new pretty neat provider-defined functions with the new major release version of the Terraform AzureRM provider which I kind of missed initially but seem pretty cool to use. normalise_resource_id which tries to "normalise" the case-senitive segments of a resource ID in
Azure
You can apply precondition and postcondition blocks to your resources in Terraform if you want to assume some properties will be true/false before apply or if you want to guarantee some properties will be true/false after apply when supplying your modules to consumers. Rules for evaluating conditions When
Azure
When writing Terraform Modules that you intend to share with your team or customers so they can consume them and create infrastructure it is common that you will write some base code and accept some input variables. Input variables let you customize the modules to make the deployment fit the
Azure
Did you know that you can set up conditional deployments with Azure Bicep? Maybe the condition is that if this value is true = deploy the resource. It could also be if the var equals prod then deploy the resource into PROD or else deploy it into QA and use the
DevOps
We have on this website previously covered using scale set agents in Azure Devops for running your pipelines. They use Azure Virtual Machine Scale Set (VMSS) in the background and require you to configure this resource in the Azure Portal. This is beneficial if you want to make use of
Azure
Ansible is automation everything IT If you have maybe 1-5 servers in your setup managing them individually should still be pretty easy. Now think about managing 200+ servers. If you had to login to them all individually that would just not be feasible. This is something we have dealt
Azure
The custom script extension is an extension you can apply on your virtual machine or virtual machine scale set that can download and execute scripts inside your operating system. This is beneficial if you have some post deployment tasks that you want achieved once the VM is deployed. For example