My ARM template has worked well, it creates a VNET, multiple subnets, NSGs, and necessary route-tables. I now need to do this same thing but across multiple subscriptions. Can't get it to work.
I know there is the nestedTemplate option. This allows you to specify a subscriptionID and requires that the resource group exist first. I built all this up and used the nestedTemplate but get an error "Subscription is not registered with NRP". Not sure how to make this work and I'm wondering if an ARM template is enough. I'm thinking of building a python script that will in turn run arm templates with separate parameter files.
I'd like to be able to take this single template and single parameter file but have it iterate through multiple subscriptions.
Couldn't get it to work, the nestedTemplates seem to require additional work. I built a python script that does the work instead.
Related
Getting started with ARM templates and trying to get a better understanding of what parameters go in a separate parameters file versus in the parameters section of the template itself. Do I have to have a separate parameters file? Seems like I can 't do a deployment from Visual Studio without identifying the parameters file.
You don't have to have a parameters file to deploy via ARM templates. You can certainly hardcode everything in your ARM template file if you like.
The next part is my opinion only on ARM template construction. I like following naming conventions for resources, such as [resource type]-[app]-[environment]. For example, a Web App for app Foo for the staging environment might be named wa-foo-prod. Following such a convention means that I can look at a resource and pretty much tell exactly what it's for.
That being said, I'm a big proponent of variables for naming resources in ARM templates. I might only pass in the environment and the region as parameters in an ARM template, then use variables to concatenate up all of the necessary resource names.
If every single resource name is passed in as a parameter, parameter management gets unwieldy.
As far as a required parameters file for deploying through VSTS, you may be right. But if you did NOT want any parameters, you could either deploy your ARM template through a Powershell script in VSTS, or just pass in an empty parameters file.
I have a ARM template which creates two scale sets, I need to retrieve the instance names from scale set 1 and use them as parameters in scale set 2 custom linux script extension. Is there a way to get the names only the fly when we are deploying the resources ?. I Have a powershell script which does the same. But I want my deployment to be using only ARM template , because we are creating the entire solution as a Managed app.
To reference first VM ip address use the following snippet:
"[reference('Microsoft.Compute/virtualMachineScaleSets/vmssName/virtualMachines/1/networkInterfaces/nicName/ipConfigurations/ipConfigurationName').ipConfigurations[0].properties.privateIPAddress]"
If you need all of those (ip from each vm in vmss) you could créate those values on the fly, you would most likely need a nested template to achieve that.
So I have this template that I've used to create my resource group. We are in the middle of development process, so it is pretty usual to add different resources from day to day.
How can I run the template to just add the ones that I am missing?
I've tried to deploy my template to my existing resource group, but I guess it just thinks that I want to create another set of resources.
What should I do?
ARM Templates are idempotent by default, so if you add resources to the template without changing anything else in it, it will just create\add new resources to your resource group. So that behavior is be default.
As for the parameters, it cannot magically infer the names (or anything) of things that you want to pass. You can either reuse existing deployments (it will prepopulate all the parameters), create a script that will pass in parameters, create a parameters file to pass in to the template.
Reference:
https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-template-deploy
How can you get the Azure automation script for just a single service?
In this case I've selected an App Service Plan, but when I click on it's "Automation script" in the Azure Portal, I get the script for everything (minus the various resource types "that cannot be exported yet" )
Unfortunately, export function only allows to export everything in the resource group, so you get an ARM template that represents the resource group.
If you want to get an ARM template solely for that resource, please deploy it into it's own resource group and then use the Automation script option.
Alternatively, you can use armviz to get a visual representation. When you click on a particular element, it will take you directly to that object in the arm template. Not exactly what you are looking for, but might give you enough.
You can't export just a single resource if there are multiple resources in the resource group, but maybe visual studio can help.
If you export the template and load it in VS as an arm template project, you can easily delete the other resources from the sidebar and leave just the one you need. You might also need to clean up the vars/params though.
I am creating multiple servers on Azure using Terraform template in a same Azure "Resource group", However when i try to run the template for individual servers each time, it is deleting the previous server while creating for next one.
Any idea how i can i reuse the same template for creating multiple server in a same Resource Group.
Thanks.
Terraform is intended to be idempotent, meaning that reapplying the same template makes no changes. If you edit the template, Terraform will edit the environment to reflect any changes or deletions.
If you need multiple VMs, you have at least two options:
Define multiple VM resources in your template.
Define a VM scale set and simply specify the number of VMs that you need.
I was able to achieve this, Here is what i did.
I created 2 separate .tf files under different folders.
1) For creating Resource group, NSG, Storage account, Vnet
2) For creating public ip, network interface and VM itself.
So i could use second configuration file for creating multiple server by just changing the values though parameters