While working on Azure, you might come across a requirement that says the resources being deployed should be in accordance with the organization’s policies. Suppose you might want to grant a particular or a set of permissions on the resource group or on the management group so that the owner of it should be restricted like denying deploying of resources by enforcing resource tagging, region enforcement, allowing approved Virtual machines (VM) images, and many more.
In this blog, we will try to resolve these issues by applying Azure policies.
First, let’s get familiar with the azure policy.
The azure policy is a service that has been designed to help you enforce different rules and to act based on the rule’s effect on your Azure resources. You can use it to create, assign and manage policies. Azure policy evaluates your resources for non-compliance with assigned policies and performs the assigned effect.
In this blog, we will create an active-active infrastructure on Microsoft Azure using Terraform and Jenkins.
Prime Reasons to have an active-active set-up of your infrastructure
Disaster recovery (DR) is an organization’s method of regaining access and functionality to its IT infrastructure after events like a natural disaster, cyber attack, or even business disruptions just like during the COVID-19 pandemic.
Ensure business resilience No matter what happens, a good DR plan can ensure that the business can return to full operations rapidly, without losing data or transactions.
Maintain competitiveness Loyalty is rare and when a business goes offline, customers turn to competitors to get the goods or services they require. A DR plan prevents this.
Avoid data loss The longer a business’s systems are down, the greater the risk that data will be lost. A robust DR plan minimizes this risk.
Maintain reputation A business that has trouble resuming operations after an outage can suffer brand damage. For that reason, a solid DR plan is critical.
Let’s consider a scenario in which you are deploying your infrastructure using a Terraform code (infrastructure-as-code) which is stored in a remote git repository. Now working in an organization you need to make sure that all your deployments are always tracked without an exception, an add-on to that whether your Terraform code is following your security and compliance policies or not. Or maybe what is the monthly cost that you can expect with that infra and whether it lies under your budget or not. You may also want to take note that all your resources are being created in the same region… etc… etc.
Sounds magical right !!! We all know that these concerns are very important when you’re looking for a highly consistent, fully tracked, and automated approach. That’s why in this article we are going to look for a simple step-by-step way to automate and streamline our Terraform code using Azure DevOps (ADO).
Why DevOps Rides on Immutable Infrastructure? The acceptance of “immutable infrastructure” has emerged as a viable way to improve DevOps processes and culture. By introducing standardisation in application deployment and management, the immutable infrastructure helps, among other things, to foster a better collaborative environment among developers, operations, and other stakeholders.
Let’s discuss a bit about Immutable Infra and the benefits which it brings to the table. Once we have a better understanding of it, we’ll really start to see the use case in our Deployments Model.