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.
Related
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.
On Azure Cloud Portal I have one App Service Plan and under that I have one App service in which I have created some Deployment Slots, you can refer the below screen shot.
I have provided traffic % as per the requirement, now what happening is when I am triggering a request to my main App Service which is "wa-45210-jira-stg1-win" then it is routing through properly but when others are trying to trigger the request to same App service then it is getting redirected to other deployment slots like "wa-45210-jira-stg1-win-test". Please refer the screen shot below
Here the expectation are it should redirected to the desired app service for which the request has been triggered so that I can have dedicated deployment slots for particular environment.
I think traffic is getting divided because of the traffic % defined. If one app service is occupied then automatically the request will get redirected to other deployment slot which is not expected.
Can anyone suggest me What should I do in order to achieve this?
My goal is to create some deployment slots or something like that in one single app service so that I can manage Dev, Test & Stage environment related stuff in one App service and therefore I can save the cost.
Can anyone suggest me What should I do in order to achieve this? My
goal is to create some deployment slots or something like that in one
single app service so that I can manage Dev, Test & Stage environment
related stuff in one App service and therefore I can save the cost.
Yes, we can achieve the above requirement . To make sure that you have selected the correct target deployment slot which need to be trigger.
For example:-
Also make sure that ,
production is your target slot and that all settings in the source slot are setup exactly as you want them in production before swapping
an app from a deployment slot to production.
For complete configuration please refer this MICROSOFT DOCUMENTATION|Set up staging environments in Azure App Service
For more information please refer this MS Q&A as suggested by #ajkuma-MSFT.
I have an App Service Plan, and in this plan I have deployed 5 components of my solution as Web Apps. I use 'Release Management' in Azure DevOps to deploy code to these apps.
To minimise downtime during deployment, I deploy to staging slots first, and then swop the staging slots into production slots to complete deployment.
I have configured App Service Warmup (as detailed here) to call an endpoint that will 'warm up' the application during the slot swapping process.
This seems to work, but I have two issues:
Even though the warmup has run, the first request made to the app after slot swapping takes a long time. I suspect that this is due to the production slot having a 'sticky / slot settings', which as I understand it necessitates an app restart. To test this, I removed the slot settings, but the delay is still there.
The applications are dependent on each other, and the slot swapping (even though kicked off in parallel in Azure DevOps), is not guaranteed to complete at the same time, which means that it is possible for newer code to be interacting with old code. While we can engineer around this, this is not optimal.
From my investigations so far, the only way I can think of to work around these issues is to spin up a second app service plan, and configure traffic manager to sit in front of the two service plans. When deploying, I will prioritise one of the service plans while I deploy to the other service plan, and once that is complete divert traffic to the newly deployed service plan while upgrading the other, and then balancing the traffic between the two again once both are on the same code level.
What is the current 'best practice' for zero downtime deployments when using WebApps in Azure?
Is the duplicated service plan with traffic manager a viable option, and if not, what would you suggest?
Follow these more best practice recommendation.
SWAP BASED ON THE STATUS CODE
During the swap operation the site in the staging slot is warmed up by making an HTTP request to its root directory. More detailed explanation of that process is available at How to warm up Azure Web App during deployment slots swap.
By default the swap will proceed as long as the site responds with any status code. However, if you prefer the swap to not proceed if the application fails to warm up then you can configure it by using these app settings:
WEBSITE_SWAP_WARMUP_PING_PATH: The path to make the warm up request
to. Set this to a URL path that begins with a slash as the value. For
example, “/warmup.php”. The default value is /.
WEBSITE_SWAP_WARMUP_PING_STATUSES:Expected HTTP response codes for
the warm-up operation. Set this to a comma-separated list of HTTP
status codes. For example: “200,202” . If the returned status code is
not in the list, the swap operation will not complete. By default,
all response codes are valid.
MINIMIZE RANDOM COLD STARTS
WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG: setting this to “1”
will prevent web app’s worker process and app domain from recycling
when the App Service’s storage infrastructure gets reconfigured.
https://ruslany.net/2019/06/azure-app-service-deployment-slots-tips-and-tricks/#prevent-cold-start
CONTROL SLOT-STICKY CONFIGURATION
If however for any reason you need to revert to the old behavior of swapping these settings then you can add the app setting WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS to every slot of the app and set its value to “0” or “false”.
https://ruslany.net/2019/06/azure-app-service-deployment-slots-tips-and-tricks/#slot-sticky-config
I would suggest to use Local cache in conjunction with Deployment Slots to prevent any downtime.
Add the sticky app setting WEBSITE_LOCAL_CACHE_OPTION with the value Always to your Production slot. If you're using WEBSITE_LOCAL_CACHE_SIZEINMB, also add it as a sticky setting to your Production slot.
• Create a Staging slot and publish to your Staging slot. You typically don't set the staging slot to use Local Cache to enable a seamless build-deploy-test life-cycle for staging if you get the benefits of Local Cache for the production slot.
• Test your site against your Staging slot.
• When you are ready, issue a swap operation between your Staging and Production slots.
• Sticky settings include name and sticky to a slot. So when the Staging slot gets swapped into Production, it inherits the Local Cache app settings. The newly swapped Production slot will run against the local cache after a few minutes and will be warmed up as part of slot warmup after swap. So when the slot swap is complete, your Production slot is running against the local cache.
Refer the Azure Best Practice Document:
https://learn.microsoft.com/en-us/azure/app-service/deploy-best-practices
https://learn.microsoft.com/en-us/azure/app-service/overview-local-cache
I utilise the "Swap with Preview" feature before warming the sites.
The main problem with swapping slots is that the worker processes are restarted when you swap. This means the sites need to be re-warmed.
When you use Swap with Preview the worker processes are restarted but the swap does not complete, meaning you can warm the sites accordingly. Once you are happy with your testing and performance you simply "Complete Swap" and the sites will respond the same.
I'm using the Microsoft app service to deploy my web application,
and it have staging.domain.com and www.domain.com,
but now they are both link to the same redis,
How to I let them link to different redis, when I swap them?
I think it can solved by the app setting.
Is there any best solution or suggestion?
As shown here in the documentation, you can set different settings on different deployment slots in Web Apps, and set them "sticky". That will make them stay in the deployment slot. If you don't mark them sticky, they will swap with the app.
To configure an app setting or connection string to stick to a slot (not swapped), access the Application Settings blade for a specific slot, then select the Slot Setting box for the configuration elements that should stick the slot. Note that marking a configuration element as slot specific has the effect of establishing that element as not swappable across all the deployment slots associated with the app.
Our project is in sitecore and using Azure - App service for deployment. We have created staging slot and apart from application setting and connection string want to make some configuration file slot specific(stick to slot while swapping).
Is there a way to make whole configuration file to stick to a particular slot?
We also tried to write some sitecore configuration in app setting option in azure and ticked it to make it stick to slot but still it is getting swapped.
Please help me on this.
Is there a way to make whole configuration file to stick to a particular slot?
No, it is not possible (as of date of writing this answer, as azure is evolving all the time).
Here you can see details of slot swap procedure. My rewriting:
Production slot settings applied to staging slot -> site restart
Staging slot warmup
Host names for production & staging slots get swapped.
Staging slot settings applied to (new) staging slot -> (new) staging slot restart
So basically slot setting is really specific feature; other than that slots are just separate sites, with different host names, ftp shares etc.
Any logic like "I want to have file sticked to slot" should be implemented in some custom way.
For example you can consider using config transforms (you can use this question as a start).
In the Azure portal you can add AppSettings and mark them as "Slot Specific". These can be read from the application using normal System.Configuration.ConfigurationManager.AppSettings semantics.
There's no way to ask Azure programmatically which slot the app is running in to my knowledge.
Alternatively, you can add AppSettings into the Azure Portal's Application Settings and have those setting stick to the slot. These settings will override whatever is in the web.config. For example, if you have an Azure Portal AppSetting of key "Greeting" and value of "Welcome", and the web.config has the same AppSetting with value of "Hello" - the result will be "Welcome". If there is an AppSetting in the web.config that is not in the Azure settings, then it will use the web.config value.