I'm wondering if it's possible to support both slot and no-slot azure functions deployment using one bicep template without if statements?
My main concern is setting function app configuration. When I want to configure a slot, I use a resource with type Microsoft.Web/sites/slots/config, but when it comes to configuring "main" slot on a non-slot function app, Microsoft.Web/sites/config type is used. I want to be able to deploy my function app to various environments - some of them use slots, but some of them do not. It would be nice if I could use Microsoft.Web/sites/slots/config resource to configure "main" slot on non-slot function app and additional slot on slot function app and use variable to select slot. Is it possible? Or the only way to do it is to use conditional deployment?
Background: I have separate azure environments for development, staging and production. Separate resource groups, separete function apps. On dev environments I don't want to use slot feature - to minimize deployment time. On the other hand, on the staging and production environment slots are must have. I don't want to maintain two separate templates. Using conditional deployment is also not satisfying. Ideal solution would be treating the only one slot in a non-slot environment just like a normal slot in a slot environment.
Related
I followed this article to learn about staging environments https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots. What are the code changes required in order to set up staging environments in Azure App Service?
What makes you think code changes are required? A staging slot is in its essence it is just a deployment target.
That said, the one thing I can think of is making sure your application does not contain hardcoded configuration that is different between test and prod environments.
If the ARM template is well parameterized it won't need any changes too. The build pipeline should be able to deploy to multiple environments (dev/test, prod etc) by supplying different parameters to the template.
I am planning to provision the logic app using terraform script. But the workflow of logic app, I am deploying through the arm templates.
Is this recommended approach?
Can anyone suggest me how to deploy the logic app with business flow?
Logic apps are kind of counter-intuitive when it comes to Terraform. It is an Azure service that is designed to abstract away custom coding with an easy-to-use user interface. Designing something in a user interface often does not work well when using multiple environments (e.g. test, staging, production). This conflicts heavily with one of the main purposes of Terraform: matching infrastructure across multiple environments.
Of course, you can turn to the magic of ARM templates, but mankind did not invent JSON to be readable. And Azure never had a plan to support YAML for ARM templates. So how to proceed from here? I set out our requirements, solution and a terraform example below.
Requirements
Infrastructure is deployed by Terraform.
Infrastructure is deployed in 4 matching environments (i.e. dev, tst, acc, prd).
Configuring parameters for logic apps should be an easy task.
Building logic apps is done in the GUI.
Solution
Create an "empty" logic app resource with azurerm_logic_app_workflow. This resource will be deployed across all environments. It is empty, so you will find the Logic App in the Azure Portal without any content. This means that in your dev environment, you can use the GUI to design the Logic App.
Create a resource which azurerm_resource_group_template_deployment which will only be deployed based on a condition. This condition is true when you supply an arm template path, which will not be the case in the dev environment.
Make sure that azurerm_resource_group_template_deployment depends on azurerm_logic_app_workflow and set deployment_mode = "Incremental". Furthermore you can supply parameters to the logic app by setting parameters_content = jsonencode(var.parameters_map).
Example
A working terraform example can be found on Github.
Note: another high-level Azure service is Data Factory, which faces the same problems when it comes to automatic deployments using Terraform.
I am stuck with an issue where I want to deploy an Azure function and the code with Azure Resource Group but it seems this isn't supported? I followed the steps here and edited it to include an Azure Function project instead of the web app
https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/create-visual-studio-deployment-project#deploy-code-with-your-infrastructure
We are wanting to list an app in the market place that will deploy an Azure function into the customer's environment (and not our own) - hence assuming this needs to be a 'managed app' and needs the ARM/ARG template
ARM can only be used to define the structure, but the deployment part still needs to use other methods.
Have a look of this doc:
https://learn.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code
I have a function app with a deployment slot for the purpose of development testing (e.g. blue/green)
One of the functions is setup as a ServiceBusTrigger bound to a service bus queue.
I do not want the function in the development deployment slot to be tripped by the queue elements in the service bus. I have disabled this function in the deployment slot in the Azure portal. What is the correct approach for this?
Edit: Disabling the function in the development slot is no good, because once the slots are swapped, the function becomes disabled in production. My current workaround is to create an entirely new "development" service bus, and use it's connection string for the development slot.
Azure Functions just like Azure WebApps have sticky slot settings. You could have two namespaces, green and blue, where each namespace stays with ("sticks to") the intended slot. You would not need to disable the function and separate between the production and the testing namespaces.
I found that going into the portal and manually disabling a function creates an app setting "AzureWebJobs.{FunctionName}.Disabled"=1
My solution was to add that to the slot-specific app settings in my environment and check "Deployment Slot Setting" so that the value doesn't get swapped during deployment as you observed.
I have created multiple slots(test, stage and prod) in my azure app service. Similarly I have created respective web.config files for each environment. I am deploying my application through octopus deployment tool in test environment slot, so initially it's picking web.test.config file and it's working fine.
But, I want to swap complete transformation section of web.config file when I swap it to stage or Prod slot while doing swapping through azure portal. Is there any way to do ?
using application setting and connection string of configuration setting, I am able to segregate the setting of each slot. But I am not sure how can I do it for other section like system.identityModel,system.web system.identityModel.services, etc. Therefore I want to replace complete transformation section according to environment while doing swapping.
When I talked with the app service team, they said slots are not meant for this purpose. The main purpose of slots is to allow deployment of new versions with little or no downtime. Or to test new features with a small percentage of the traffic. Not really for different environments, you should use have separate app services for that, to which you deploy separately.