I have an ARM template, that performs resource group deployment. It mainly consist of web apps and key vault. I want to go with blue/green deployment and sometimes need to add only blue slot settings to web app.
When we are deploying web app site all as one resource (https://learn.microsoft.com/en-us/azure/templates/microsoft.web/sites?tabs=json), it's quite easy as appSettings are being defined as key-values and we can add 3rd key as "slotSetting": true.
However, in my scenario, I want to deploy all in Complete mode, in the same time add dynamically key vault access policies. So based on this doc - https://learn.microsoft.com/en-us/azure/app-service/app-service-key-vault-references#azure-resource-manager-deployment - I need to configure appSettings as separate resource, which is an object, so there's no way to add this additional property.
With this, I have 2 questions:
Is there a way to add this slotSetting when deploying appSettings as separate resource?
Those are little bit off topic but about that case as well:
but I'm trying to find a best practise, when it comes to deploying resources + key vault and dynamic access policies. As on complete mode we can't just conditionally not deploy key vault (because it will try to remove it) and on the other hand when we define it, we need to add empty array of AccessPolicies (empty because we need to add accessPolicies in separate resources so we could loop over all web apps and get identity), so by and large, the apps are down for some time. Not the best practise when you want to reach 0 downtime deployment.
In what exact scenarios we want to use Complete mode deployment? My team leads are pushing for it but I don't see much added value. If we have ARM template well defined, all manual changes will be changed or moved to defaults in Incremental as well as Complete. Just additional resources are deleted. Do you have any interesting use case to share?
Not really sure I fully understand your question but when deploying slots you can deploy different app settings to the individual slot in the ARM template simply by specifying them in the slot setting itself when you create it.
You can create the RBAC policies first for the Vault and then apply them to the Vault at creation time but it gets a little complicated, and why dont you just use incremental mode, the only difference is that things not specified wont be deleted.
I have never found a good use case for Complete mode other than dev instances where I can specify a single resource and have it clean up all other things, but in a produciton environment running Complete mode seems to be totally weird
Related
I'm attempting to implement a Function slot and prevent any downtime during deployment. I can get this working but only if I never change any application settings. When an application setting is changed it causes a restart.
One pattern I've seen recommended for this is to not declare application settings in ARM for production slot. This seems to make sense and, surprisingly, works with Complete mode.
However, when deploying the Function for the first time to a clean environment without production app settings defined this will always fail on slot swap. Many of the Azure Functions are set in app settings. For example the Functions version, app insights key, storage, etc. If you omit these on a clean deploy and attempt to swap it will never deploy.
So I'm in a position where I need to omit application settings to get the deployment model to work but the application settings include mandatory settings for the infrastructure. I've tried switching to using az cli for the function app creation. I've had limited success but I also have ARM resources that depend on the function existing such as role assignments and alerts. I'd rather not go down a hybrid model if I can help it and I'd also like to keep the declarative target state that's provided with ARM's complete mode.
Am I missing an option here to get zero downtime, plus successful first deploy and allow updating of Function settings? Looks like it's not possible.
I'm working on an asp.net core project and I'm trying to figure out how to keep my source and my pipelines 100% secret free.
I've got a VM running the azure agent and an azure dev ops pipelines for build and release.
If i delete the site on the VM, the release pipeline will auto-magically recreate it for me and deploy the latest build.
Super cool.
Now I read up on best practices for configuring a .Net core app and I found this article: https://www.humankode.com/asp-net-core/asp-net-core-configuration-best-practices-for-keeping-secrets-out-of-source-control
So its a bad idea to keep secrets in code, that makes perfect sense.
But if i apply the same security principals to Yaml, then surely I shouldn't place secrets in my pipelines either.
But I need the pipelines to be able to just recreate the site from scratch and it should just work. Somehow the site needs to know where its default sql connection is, or it needs to have a key to the azure app config service. I shouldn't have to log onto the VM and create an appsettings.json manually after every release!
So whatever the site needs to operate needs to be included in the pipeline, therefore some artifact, or included in the code.
I've googled for days, but I can't seem to find any info on how to fully automate this.
I've considered creating a custom configuration provider that reads from the actual VM registry, but that feels wrong too.
I basically need a config option that is NOT hosted in the site itself. So i set it up once on the VM and never again.
The approach that Lex Li lists in the comments is the Microsoft recommended way of securing "secrets" in pipelines.
Ben Smith's answer in my opinion is just as good, maybe slightly less secure.
I use this approach in our organization. All of our release pipelines do the final configuration transformation with the appropriate settings based on the environment they are being deployed to.
i.e db connections are transformed at the dev, test and UAT and production deployment stages.
I keep the relevant secrets in the pipeline variables as protected secrets. I do this for 2 reasons:
Only a select number of trusted personnel have access to the release pipeline definitions.
Even if someone does have access to those definitions - you cannot see a secured variable. Even you you "undo the padlock" on the variable tab - you cannot see what the setting is.
Our actual secrets are then stored in our enterprise secret vault.
Using the Azure Key Vault is definitely a good approach. However we already have a centralized place to keep our stuff; I don't want it in 3 spots.
I would be remiss to not include Variable Groups as part of the pipeline process. Same concept as the build / release variables - the difference is you can now share them in one spot.
These are all opinions of course. This is just one way of doing this; which I feel is a pretty good balance of security and flexibility.
In addition to the suggestions in your questions comments, you can also store secrets in the pipeline "Variables" section.
In here you can add variables and then mark them as secret by selecting "Keep this value secret". Once you've saved a secret its value is then obfuscated i.e. you can make use of it but you can no long see its original value within Azure Devops (which admittedly can be rather frustrating if you want to revisit the variable to check it!).
You can then reference the secret variable in your pipeline YAML using the syntax:
$(variable-name)
So this approach keeps secrets safe within Azure Devops until they need to be resolved by the pipeline YAML script.
I am new to Azure as well as Devops, ARM template etc..I have deployed an ARM template for key valut with a name "ABC" via DevOPs. Now I would like to change some parameters. I don't have access to do it via portal and I am forced to use only ARM template. How can this be achieved via devops? Should I delete that resource and start from the scratch or any SOP to update resource parameters via ARM templates. For example I want to enable "“enabledForDeployment” for already deployed kay-vault. Thanks.
generally speaking you just re-run the same template with the changes you've introduced to the template. there are many ways of deploying the template (az cli, powershell, built-in steps, various sdk's).
just keep in mind, some properties are settable only at creation time, so effectively read only, you wouldn't be able to update those after the resource is created, some resource providers do not play well with idempotent behavior and this will also lead to issues when you try to redeploy the same template, some providers offer dodgy behavior when you need to use a completely different api call to update something compared to creating it.
So there's no single answer, but for what you are doing, just updating the template and running it again should work just fine.
You can do it through PowerShell,
Update a resource in an Azure Resource Manager template
Our company is having multiple web services deployed each having three environments- Dev, Staging, and Production. Each environment has separate resource groups which contain application insights for the service. It's a tedious task to fetch the instrumentation key for each environment and set in the appsettings file. Instead, we want to automate this process in a way.
We are thinking in the direction- we will provide the application insight name as a placeholder which will get replaced to the actual instrumentation key at the deployment time after fetching it from the respective resource group.
I have gone through some articles but I'm unable to achieve same.
Please suggest me some approaches for the same.
TLDR:
Add an output to your ARM template
Pick that up in the release as an variable
Use it to change your configuration
Details:
When you are using an ARM template for deploying Application Insights, you can specify the template to return the key as an output variable (https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-templates-outputs). The ARM template deployment task can pick these outputs up and make it available as a variable with an JSON object. A more easy approach is the ARM Outputs extension (https://marketplace.visualstudio.com/items?itemName=keesschollaart.arm-outputs) where you can directly make each individual output available as an variable.
After that, the 'Deploy Service Fabric Application' task allows you to override application parameters if names match (not very self-documenting) or you can use the tokenized approach you mentioned earlier. There are numerous extensions that can do that, including: https://marketplace.visualstudio.com/items?itemName=qetza.replacetokens (haven't tried it myself)
We are working on following within Azure portal
Azure Functions
Data Factory
Logic Apps
Storage account (not files)
Now as we are done with development, we need to deploy these azure resources in client's UAT environment
I looked around (might be missing something) and found that deployment of Azure resources is not straightforward.
In Azure, it is like another subscription, correct?
So found this blog, which works with different PowerShell scripts to copies from one subscription to another
This is the right approach? & it cover everything required for resources to execute flawless (I still need to go thru scripts) for e.g. permissions, Data Factory datasets, etc?
Any other way to deploy (kind of export & import)?
Basically what you need is to create a reusable arm template, your question lacks some details yet ARM templates are the way of automated deployment in Azure, on a high-level
start by authoring your arm template to deploy the vanilla required resources look here
https://learn.microsoft.com/en-us/azure/templates/microsoft.web/sites/functions
https://learn.microsoft.com/en-us/azure/templates/microsoft.datafactory/factories
https://learn.microsoft.com/en-us/azure/templates/microsoft.logic/integrationaccounts
https://learn.microsoft.com/en-us/azure/templates/microsoft.datalakeanalytics/accounts/storageaccounts
you can combine all of them in one big template using ARM template dependency and other functions
look here
https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-template-functions
after you finish ARM templates can be used in many ways including PowerShell, direct API calls or even you can create a deployment in Azure and save it to be reused with a click
look here, also if there will be a high volume of users consider adding it to market place.
https://learn.microsoft.com/en-us/azure/azure-resource-manager/
after finishing your implementation of vanilla resources you can then move into adding any customization you might have.
this is the right and best way to do "afaik"
also look here to see all of your existing resources in an arm template view
https://resources.azure.com/
my understanding of Azure is that almost everything with some few exceptions has an ARM template representation
hope this would help.