I have an Azure Function App with a single function.
I created a Deployment Slot.
I'd like to copy the function to this Deployment Slot.
( In other words I'd like to duplicate the Function App. )
Is this possible ?
Note that Swap is not the same because the Deployment Slot initially starts out with no functions.
We gave up slots - swapping/moving/"deploying" between them is actually a deploy so you just get a worse deploy experience overall, poor API and not enough control.
I believe to get what you're after you need to deploy the function again, specifying the other slot and then you have what you want.
We've found a better solution is:
ignore slots, they're constant pain, failure and instability
create 2x resource groups my-function-prod, my-function-dev and put a Function App in each of those
use Github Actions + Github releases to deploy to either the dev or prod Function
Related
I've created Azure function using Visual Studio as library project, have single project with 12 functions
e.g.
As of now my function hosted in Dedicated AppService Plan and one of function (EventHub listener) processes millions of message per-day, hence it utilizes 90%+ CPU all the time.
So we are planning to scale or Separate App Service plan for that single function. I see following possible solutions
Change dedicated app service plant to consumption. (not sure about pricing impact or SLA).
Create a new project, move single function in that project and deploy that function in a separate app service plan. (required code and CI/CD pipeline changes.)
Deploy same function dlls in 2 AppService Plan and remove functions according to scale. (not sure this is possible with Azure DevOps or not).
would like to know the better approach, if customer does not agree on consumption plan.
The advantage of a dedicated plan over a consumption plan is predictability. Running a workload on a consumption plan will usually work out faster and cheaper than running the same workload on a dedicated plan, but using a dedicated plan does prevent unexpected spikes in usage from leading to unexpected spikes in cost and also prevents cold start issues.
If you switch to the consumption model (option 1), you're paying for individual function execution so whether you run one or two function apps makes no difference from that point of view. You should decide how to split your functions based on how independent they are. If you'll only be deploying them as a single unit then stick to one function app, but if you may want to update the listener separately, put it in a separate project.
If you split into two apps running on separate dedicated service plans, creating a new project (option 2) is certainly the cleanest way to go about it. However, deploying the same project to both apps (option 3) is technically possible - you just need to disable the functions that shouldn't run on each app using app settings. Create settings named AzureWebJobs.MyFunction.Disabled with value true (see https://learn.microsoft.com/en-gb/azure/azure-functions/disable-function#functions-2x---all-languages).
wont help you, it scales all the functions in the function app
that will work
its the same as version, just with 2 app service plans, not one.
Better approach is - isolate this function into a single Azure Function App and then you can scale it independently.
I have a function app with three Timer Trigger functions in it. I want to use the staging/production functionality provided by the Slots (preview), so I set up the VSTS deployment for two separate branches. The primary function app polls master and the slot polls a branch called staging.
The problem is that when I start the function app, the main functions schedule and run, but the Slot functions don't seem to get scheduled to run at all. Things I've tried:
I set the hosts.json file for each with a separate 'id' field to avoid a conflict on the locks that determine whether or not they can run. Looking in the storage account, I can see a folder for each app (the main and the slot) and a folder for each function, which I think means they shouldn't be using the same locks.
Use a separate storage account for the Slot app
Stop the main function app while keeping the Slot app running
Can anyone tell me what might be wrong with my setup or if there's a known bug with Slots (preview) preventing this from working?
I'm using consumption plan functions.
I can add a new function to an existing App Service or I can create a new App Service. I just realized that I don't have an adequate understanding of in what situations one should add a new App Service. Would appreciate any high-level guidance on that.
Remember that the unit of scale for a function is the Function App. So if the runtime determines that one function needs to be scaled, it will scale the Function App and all functions within it.
If your function can run in the consumption plan (finish within 5 minutes) and is logically related to the other functions, then I would probably add it to the current consumption plan.
However, if it needs to run for longer than 5 minutes or it is not related to the other functions, I would separate it to its own plan.
As far as I'm aware, consumption plan can scale "indefinitely", so there is no real reason to create another App Service, unless you want to logically separate those, or give out specific permissions (as you can't have permissions to functions inside Azure Function) or say, you want some of them to be configured from Git and some not.
Here is my simplified Azure architecture:
ResourceGroup1 => AppServicePlan
ResourceGroup2 -> AppService1, AppService2
Once this architecture is in place, I remove the apps one by one. When i delete (tried in portal and with PowerShell as well) the last app, the plan gets also deleted...
Is it by design or a bug ?
It is by design. The reason it was done that way is to avoid continuing to charge for an unused Plan, which would take some customers by surprise if they don't fully grasp the distinction between Plan and Web App.
So the only time a Plan can be empty is right after it's created. After that, any transition from 1 to 0 contained Web Apps triggers the deletion of the Plan.
If you want to avoid this behavior, the simplest workaround is to include a 'dummy' Web App in the Plan to keep it alive. You can stop that Web App, so it doesn't consume any resources on the VMs.
I currently have a web application deployed to Azure on the App Service free plan and, as part of going live, I'm interested in moving to the use of slots.
This is primarily because it gives me the ability to deploy new code into staging and then seamlessly swap over once it's been validated.
Now, to use slots, I know I need the standard plan and this clocks in at a minimum of $X per VM.
What I don't know (and frustratingly haven't been able to find out from the Azure stuff on Microsoft's web pages) is whether a second slot counts as another VM.
In one place at least, it states that deployment slots are live web applications with their own hostname but that could be read in at least two ways. either as a separate app on the same VM or a separate VM altogether.
Since the difference is substantial ($2X/month rather than $X/month), it's rather important to planning. So does anyone know how (preferably with some supporting citation from Microsoft) the slots are handled and charged for?
All deployed Azure sites in a given Web App plan run on the same VM instances. Just as if you deployed mysite1.azurewebsites.net and mysite2.azurewebsites.net in the same plan, they'd share the same VM instances. So, too, do extra deployment slots.
If you scale to 3 instances, you pay for 3 instances, and all deployments (all slots for all deployments) run on all three instances.
One way to make this easier to think about: the 'production' (or main) deployment slot is just another slot.