I am performing multi-region deployment in Azure using ARM. The only approach I could find so far is by using copy operation as explained here
However, in the beginning of the post author wrote that some of you might think that it’s not such great idea, and I can appreciate that.
Why is that? What could be alternative to copy function? What is ‘official’ recommendation from MSFT to implement multi-region deployment in ARM?
I don't know of a single best practice recommendation here but there are a few other things you can think about for the scenario. If you think of a resource group as a management boundary, then having everything in the same resource group may not be ideal. For example if you wanted to tear down one region and rebuild it, this is much more complicated within a single resource group. If you wanted to simply add a new region, while you could do this with the same template and an incremental deployment, it's faster and maybe cleaner in a separate deployment. If you wanted to assign permissions based on region, again more complicated.
OTOH, if you deploy each region into it's own resource group, this becomes much easier to manage. The only difference is then that the copy loops aren't needed in the template and you do multiple deployments of the same template (to each region).
Again, no hard/fast rule, but some ways to think about it...
Related
I'm currently busy with an internship. In this internship I need to create a program which automatically creates "snapshots" of the current state of Azure Resources (And sometimes their dependencies) which need to be deployed to another environment. e.g. Acceptance -> Production. These snapshots must then be deployed to the new environment at a later date which has been coordinated with the client.
A solution can consists out of >100 Azure resources, ranging from API Managers, to LogicApps, CosmosDB's, etc. When a customer accepts or says "ok" to a few resources (= a part of the total solution) a snapshot needs to be made of that resource, in the specific state when the client said OK. That means that I also have to create a snapshot of the dependencies of that specific resource (LogicApp can depend on a CosmosDB, Keyvault etc).
And I can't just take a reference to the resource in the Acceptance environment, I need to bring that dependency over to production as well, seeing as it might be possible that another developer will continue working on said dependency which might break things.
I am bit of at a loss as to which direction to take here. I don't have a lot of experience with ARM (Templates) and I have been making several prototypes for a month now.
I have first tried to generate my own ARM (and Bicep) files through gathering information from the Azure Rest API, but I soon discovered this is not viable because I cannot extract all of the information from that API to create said ARM file.
I then looked into modifying the generated ARM files from Azure itself. Whilst this is an option, it contains a lot of information which I do not need or want to transfer over to another environment. It is also very hard to determine which parts of the generated ARM file must be deleted, updated, copied or left alone. And then I still need to recursively get the ARM templates of the dependencies and go through those in an automated way as well.
Is modifying existing ARM templates the best route to go here? Or does a similar product already exist which might help achieve my goal?
Thank you!!
In this case, I would not go with the approach to modify exported ARM templates but I would go with approach of Infrastructure as Code i.e., I would created ARM templates as granular as possible i.e., may be one template per resource at the least and store that infrastructure code in a source repository and if required version it to use it in different environments. The reason for recommending one template per resource is to take care of the dependencies in a complex environment. I know this might look like a bigger activity for the first-time implementation but once the templates are integrated into any continuous integration and continuous deployment (CI/CD) tool like Azure DevOps then all of it can be automated with the help of release pipelines for fast and reliable application and infrastructure updates. For more information in this regard, please refer this and this Azure documents.
If one has multiple environments(dev/qa/prod) in different subscriptions, there might be some restrictions with Azure DevOPs pipelines. I think currently Azure DevOps cannot span multiple subscription.
Considering this, will it be a good design to say have multiple synapse workspaces(one for each environment - dev/qa/prod) for each project in the same subscription but different resource groups?
There is always more than one way to do things but I do not think one subscription is always the right answer. It brings a bit of risk that someone could accidentally 'deploy to prod', and although this could happen in any situation, having only one subscription makes this more likely. The environments should of course be properly ring-fenced with permissions, resource groups, resource locks, clearly defined release pipelines with gateways etc which will help reduce that risk.
Multiple subscriptions, or at least a dedicated prod subscription housing a single prod environment and a non-prod subscription housing dev, test, QA (and other environments) is another option. This should reduce the risk of a single subscription but introduces additional complexity.
One way to think about it then, and what is best for your organisation is to think about a grid or matrix, with axes for Risk, DevOps maturity and Complexity versus number of Azure subscriptions you have. Ask a series of questions to help decide your position on this chart. A simple example and some sample questions:
Regarding "easy life", DevOps engineers and architects do not think like this and you shouldn't either.
You should have a single Subscription and within that subscription you can have multiple resource groups like Dev/Prod/QA. Deploy and manage your resources for different environment under a corresponding resource group for easy and hustle free experience.
Check the below diagram for your reference.
For better understanding, refer Microsoft official document.
I want to delete azure resource by service or group type. ( for example delete resource related to Virtual Machine, App Service with Application Insights or Storage etc.)
Planning to build the tool using C# or Power shell script. Please provide recommended reusable approach.
this is too generic. there can be none, best you can do is do filtering based on the resource type (so delete all of the resources of the same type, you can add resource group\tag as a filter). But in essence this is not possible. you would have to create a database where you store relationships between different resources and resource types.
Also, how do you solve conflicts? If you delete 1 thing and another thing depends on it? what if its not a hard dependency? etc.
How to configure the default type and number of VM that gets allocated in AKS cluster? Is there a way we can do this per Resource Group?
Why am I asking this? From the point of view of saving costs by default in non-prod environments and minimize human error in general to automate and streamline things as part of DevOps group.
Your solution-recipe is much appreciated.
you can use powershell\az cli\arm template\sdk's to generate AKS. either way works. you can also use third party solutions like pulumi, ansible.
all of these solutions would allow you to pass in parameters to define vm size. you can restrict those with pre-validation
I think you should check this one which has lot of information regarding your ask.
Why don't you use az aks create: https://learn.microsoft.com/en-us/cli/azure/aks?view=azure-cli-latest#az-aks-create
The PowerShell equivalent New-AzAks is not as configurable but it does allow for the definition of the node count. You can always execute cli from PowerShell if you prefer to work with PowerShell in Automation.
If you modify a resource through the Azure Portal, you may forget to update your ARM JSON before your next deployment and this would lead to an outdated deployment.
Also, if you have system admins taking care of your Azure Portal and your developers keeping track of ARM JSON in the source control, you need a good way to make sure to keep the environments consistent.
What would be the best practise to do that?
That's an easy question, don't modify anything through the portal. Or follow the change process as described by ITIL, or invent your own wheel.
But apart from that, there is no answer, there is no way your repository will magically sync with what you actually have.