Can I deploy one Azure time trigger function from one repo to multiple App Services?
Example:
Currently I have a repo with one Azure function in it (name Function1, runs every few mins).
I have 5 customers, I have a database for each customer and therefore I have 5 connection strings. Each customer requires me to host the function in isolated environment independent from the other customers.
The function "Function1" does the same logic for each of my customers. It just accesses a different database for each using the different connection string.
Therefore, I created 5 App Services: Function1-Customer1, Function1-Customer2, ... to satisfy the "independent environment requirement".
Each App Service has the unique db connection string assigned in the App Settings.
I tried to deploy the "Function1" to all these 5 App Services. However, when then going to see the Log Stream for any of the App Services it seems that only one instance of that function is running, depending on which App Service deployed last.
So for example, if Function1-Customer1 deployed last and I go to Function1-Customer2 or Function1-Customer3 to see the Log Streams, both outputs a conn string of Function1-Customer1. If Function1-Customer2 deployed last then I would see its conn string in all other App Services.
Is it possible to deploy the Function1 to serve all these 5 App Services? Or do I need a different architecture here?
The functions coordinate by obtaining leases in the underlying blob storage. If two function apps end up fighting over the same lease, they will block each other even though they are supposed to do different things. You can explore this by looking at the blobs in the underlying storage account an check the "lease" status.
Based on our discussion in the comments, I would recommend to use a dedicated storage account for each function app. I would not recommend AzureFunctionsWebHost__hostid or similar solutions, since it adds more complexity.
For each trigger Azure function manages it's own queue in Azure Queue Storage. You can use single function app and trigger 5 different tasks for each customer or you can create separate Azure storage account for each function app.
Related
I have currently a WebAPI which has a GET method that reads 10,000 rows from a SQL Database and process to create a JSON object. I use Azure App Service Plan to host this WebAPI.
My question is, is Azure Function App a suitable platform to host the business logic which the WebAPI currently does by considering the amount of data retrieved and the processing has to be done.
I think Azure function is a choice for you as it is designed to architect serverless solutions. And in the Azure function document there is similar scenario as yours.
Also, just like #ThiagoCustodio mentioned in the comment, you still need to consider the function app timeout duration. Here is a reference of timeouts regarding different hosting plan.
Reference:
Optimize the performance and reliability of Azure Functions
I have a scenario where one of my Class has a static member whose value I can set from a Function App. Suppose another Function App belonging to same App Service Plan also uses this same class and also sets/relies on the value of the static member. Now, if the two function apps never run simultaneously, we have no issue. Also, if they don't run under same instance, then we also have no issue as each running instance will have their own definition of the class.
My question is, do each Function App from same App Service run on different instance?
I understand redesigning will eliminate any possible issues, but I am just curious on the interaction between Function Apps in same App Service.
I think it will be better for you to understand the process boundaries.
You have an Azure Function App (FuncApp1.azurewebsites.net) that may have one or more functions hosted on an App Service Plan. You're mentioning that you have another Azure Function App (FuncApp2.azurewebsites.net) with one or more of it's own set of functions hosted on the same App Service Plan. Is this correct?
FuncApp1 will have it's own process id, memory/cpu consumption, and threads on some machine in the cloud and the same for FuncApp2. The static member basically exists independently in two separate programs. In the case where your function app may scale out, each new instance will most likely have it's own process id, etc.
So NO your function apps will not step on each other. Your only concern should be if the static member is thread safe within the same process id. In what scenario are you relying on a static member that may be altered per request? Some incrementing ID?
My question is, do each Function App from same App Service run on
different instance?
I don't think this is possible, just as others have answered. All function apps are run on all the instances provisioned by your App Service Plan. But.. having said that, using per app scaling it is possible to limit the number of instance that a particular app service can be run on during scale out. I have not used this for Function Apps backed by App Service Plan; but an interesting read [https://learn.microsoft.com/en-us/azure/app-service/manage-scale-per-app]
From MS docs
When using App Service, you can scale your apps by scaling the App
Service plan they run on. When multiple apps are run in the same App
Service plan, each scaled-out instance runs all the apps in the plan.
Per-app scaling can be enabled at the App Service plan level to allow
for scaling an app independently from the App Service plan that hosts
it. This way, an App Service plan can be scaled to 10 instances, but
an app can be set to use only five.
Further, to your query on my comment; I think there are two cases here
a) Multiple Function Apps using the same App Service Plan using shared static class with static member
b) Multiple functions within the same Function App using shared static class with static member.
In both cases your static members are not shared. They are per function scope only. Just to be sure, I created two functions, FunctionA and FunctionB under a Function App (FunctionApp1). In both the functions, I refer to a static class Static1. I noticed that changes I make to the static members from FunctionA is not visible to FunctionB.
However, the static member state is preserved between multiple invocations of the same function under the Function App
I found a somewhat related question here https://stackoverflow.com/a/44971720/5344880
one another case would be different Function Apps using the same shared static class and I am reasonably sure that in this case the static class's static member's state is not shared.
Each function app from same App Service plan will run on every instances.
For example, if you have an app service plan which has 3 instances, your function app will run on each instances.
So for your question
do each Function App from same App Service run on different instance?
The answer is no, function apps from same App Service will run on the same instance.
I need to create a few Azure Function in the same region and same resourge group in Azure.
On the docs I read:
Function apps in the same region can be assigned to the same Consumption plan
But when I´m creating a new Functio App there´s no option to assign the new function to the same consumption plan that was created before.
As you can see, there´s no option to select an existing plan, even in the same region.
How can I prevent to create a new AppServicePlan(consumption) for each new function that I create?
This is not possible through the Azure portal, so you'll need to use the Azure CLI, powershell or ARM templates if you want the function to use an existing App Plan.
However, this doesn't really matter for this case, since you chose the "Consumption" plan type, no additional costs will be charged by creating a new plan of this type.
You only pay for the execution times of your functions.
Sharing the app service plan between Azure Functions (or other app service types) only makes sense if you are (already) using a dedicated app service plan for some services.
With this type, you basically provision a virtual machine that is hosting your functions. You pay a fixed amount for this (whether your functions are running or not), so to save costs, it would make sense to host multiple app services in the same plan, if the server can handle the load (whether they are Azure Functions or other Azure App Service types).
More info: https://learn.microsoft.com/en-us/azure/azure-functions/functions-scale
EDIT: maybe also good to add, is that you can add multiple functions in the Function app. So you don't need to create a new Azure Function App for each function. You could just group them together in the same Azure Function App
just dont use the portal and thats it. use arm templates, use azure powershell, use az cli, etc.
Summary: I have 2 different Azure Function Apps (Node.js), sharing a single file storage account, however if I go into the Kudu Invocation Logs for either of them I see the entries from both Apps.
Here is my setup:
1 File Storage (shared by both Function Apps)
Service Bus 1 (sb-prod), with a single queue (somequeue)
Service Bus 2 (sb-staging), with a single queue (somequeue)
Function App 1 (func-prod), with a single function (somefunc)
Function App 2 (func-staging), with a single function (somefunc)
Both func-prod and func-staging are setup for continuous deployment from the same Bitbucket repo, but different branches
When a message is received in sb-prod it triggers somefunc in func-prod
When a message is received in sb-staging it triggers somefunc in func-staging
Note that the queue name and function name are the same in both prod and staging. That all seems to work fine. However if I go into Kudu and look at the Invocation Logs for debugging, it shows the execution of functions across both Function Apps (prod and staging shown in the logs for both). It is not respecting the folder structure on the file storage to only show the logs from the appropriate App. As far as I can tell, this is only a log viewing issue, and the functions aren't being run twice or messages being sent to the wrong function app. Any ideas on how to fix this? Or is this a bug and I would need to add a second storage account to fix it so that Kudu doesn't get confused? Is there any risk with this setup that messages from staging service bus end up in the prod app or vice versa?
By 'Kudu', I assume you mean the WebJobs Dashboard (not related to Kudu). The behavior you are seeing is quirky, but is in fact by design. See https://github.com/Azure/azure-webjobs-sdk/issues/1541 for more info.
Workarounds:
The best is to use App Insights instead of the WebJobs Dashboard
If you must use the WebJobs Dashboard, use distinct storage accounts
I have an app (.exe) that picks up a file and imports it into a database. I have to move this set up into Azure. I am familiar with Azure SQL and Azure File Storage. What I am not familiar with is how I execute am app within Azure.
My app reads rows out of my Azure database to determine where the file is (in Azure File Storage) and then dumps the data into a specified table. I'm unsure if this scenario is appropriate for Azure Scheduler or if I need an App Service to set up a WebJob.
Is there any possibility I can put my app in a directly in Azure File Storage and point a task to that location to execute it (then it might be easier to resolve the file locations of the files to be imported).
thanks.
This is a good scenario for Azure Functions, if you want to just run some code on a schedule in Azure.
Functions are like Web Jobs (they share the same SDK in fact) so you can trigger on a schedule or from a storage queue, etc., but you don't need an app service to run your code in. There are some great intro videos here Azure Functions Documentation , and here is a link to a comparison of the hosting options between web jobs, functions, flow and logic apps.
You can edit the function directly in the portal (paste/type your c# or node.js code straight in), or use source control to manage it.
If you really want to keep your app as an exe and run it like that, then you will need to use the azure scheduler to do this instead, which is a basic job runner.
Decisions, decisions...!
Looking at https://azure.microsoft.com/en-gb/documentation/articles/scheduler-intro/ it seems that the only actions that are supported are:
HTTP, HTTPS,
a storage queue,
a service bus queue,
a service bus topic
so running a self contains .exe or script doesn't look to be possible.
Do you agree?