deploy each function in a separate Azure function app - azure

my project has 3 Service bus and 2 HTTP triggers. (5 functions)
How to deploy each function in a separate Azure function app?

The easiest way is to copy the code of the trigger you created before and create a new function app with a single trigger, then put the code into it(Deploy function app must be based on function app, and the function app should correspond to the project on local.).
The more complicated method is, first make sure the structure of your function app(this needs to check the language. function app has two types, one type is a scripting language and another type needs to be compiled.) For this, you can have a check of this official doc:
https://learn.microsoft.com/en-us/azure/azure-functions/supported-languages
Go to the language you are using and search the folder structure(your deployment structure should like the 'folder structure' in the doc. What needs to pay attention to is for the language like C# and java, you need to deploy the compiled files. Azure can't identify the source files.) Then you just need to imitate the structure and deploy based on this structure.
'Deploy' operation is just a upload operation, so you just needs to upload the files in specific structure, then azure can identify it.
Finally, you can use zip deploy to deploy your function app(Or to say deploy a project, a structure that azure can run must first run success on local.).
az webapp deployment source config-zip --resource-group <group-name> --name <app-name> --src clouddrive/<filename>.zip
(Above command is been used by some Integrated Development Environment, such as Visual Studio.)
I suggest you to use the first way, because it is simpler.

Related

How can I prevent deploying code to the wrong function app?

I have developed a number of JavaScript functions that all get deployed to an Azure Function App. I have two different code sets intended for two different Azure FAs. Unfortunately, when the FAs were created they were not given a meaningful name, and instead are just a random string of letters and numbers.
I primarily deploy my code to Azure from within VSCode, and that seems to work fine. However, I have a strong concern that one day I will deploy one set of functions to the wrong FA, which would of course cause big problems.
Is there anywhere that I can define a list of "allowed" function apps, so that if I were to attempt deploying the code to another FA it would fail? Or is there another method to achieve a similar result?
As of right now, I can deploy any codebase to any FA.
To prevent deploying code to the wrong function:
There are few methods for restricting deployment to only particular Function Apps and preventing deployment to undesired Function Apps.
Use Deployment slots:
As detailed in MSDoc, You can choose a deployment slot for a function app which has a different URL than function app.
Instead of executing immediately in a production environment, you can test any fixes or incorrect deployments in a different deployment slot before it goes live by deploying it into a secondary deployment slot.
Because it is your production environment slot, your users will be accessing your original Function App.
How to work with Deployment Slots:
Goto Function App and you will find Deployment slots under deployment and then Add a slot as described in the below image:
You can also create a deployment slot using Az CLI command az functionapp deployment slot.
Use below format:
az functionapp deployment slot create --name <Functionapp> --resource-group <ResourceGroup> --slot "slot1"
Use Deployment Scripts:
When you deploy your code, you can specify a deployment script, which can be a CLI or PowerShell script.
You can create a deployment script that verifies the target Function App's name and fails if it does not match one of the given Function Apps.
Goto Azure Portal and search for Deployment Scripts to work with this.

How do I get into the folder of a Web App in Azure

Recently I am trying to use:
func azure functionapp publish WebAppName --publish-local-settings -i
to publish local.settings.json to a web app (actually an Azure function) but I get this error message:
Unable to find project root. Expecting to find one of host.json in project root.
I have logged in to Azure with az login but it looks like I need to get into the folder where I have deployed the Azure function where all those json files are.
A little background, we are using Octopus Deploy to deploy to an Azure function. After the deployment, we want to add a step so that the local.setting.json will be used to populate app settings.
So how do we change the current folder to be in the Azure function root where all those json files are?
Thanks a lot in advance!
You need to go to your local function project folder to run the command, for example, my function project is under MyFunctionProj folder.
Execute the command
func azure functionapp publish tonyfunc --publish-local-settings -i --publish-settings-only
By the way, if you just want to update the settings, you need add --publish-settings-only parameter.
Reference:
Core Tools development

Deploy azure functions across resource groups

I have looked at the Azure functions documentation but couldn't quit find answer to my question and hence I thought I asked the wider user community.
We have a single Azure subscription with multiple resource groups for our different environments, so one group for dev, one for test and one for prod.
We have developed multiple Azure functions in dev and would like to use CI/CD to deploy to test and prod.
However, doing this manually Azure complains that the name of the function app already exists which is weird because that would imply that the function app name must be unique to the subscription or globally across Azure? Does that mean you need to name your function apps func-dev, func-test etc? That seems very ugly.
How have you managed to solve this?
azure function name has to be globally unique (not just in your subscription), because the name would be like:
functionName.azurewebsites.net
so you cannot have a function with name functionName if you already created one, because the dns name for that is occupied.
you can use subfunctions to work around that, so create a subfunction called dev, test, and prod inside the function and call those
Function App, as any App Service application, has to have globally unique name:
Naming Conventions -> Compute.
Indeed, it's typical to include your environment into the App name.
Function names have to be unique within a single Function App, but may repeat in different apps.

Azure Function how to move appsettings from local to server and vice versa

I m a little new to Azure.
Issue is I m developing Azure Functions and some times I have to work locally (code/ test etc) and other times on Azure. Every time I switch I have to compare and change app settings manually.
Is there a way I can avoid it ? Something where if I run locally I may get latest from server without manual and when I go to server Azure may be aware of my changes ?
Thanks
Yes, use the Azure Functions Core Tools —
Usage: func azure functionapp <action> [-/--options]
fetch-app-settings Retrieve App Settings from your Azure-hosted
Function App and store locally Aliases:
fetch-app-settings, fetch
and
Usage: func azure functionapp <action> [-/--options]
publish Publish the current directory contents to an
Azure Function App. Locally deleted files
are not removed from destination.
<FunctionAppName> Function App name
--publish-local-settings [-i] Updates App Settings for the
function app in Azure during deployment.
--publish-settings-only [-o] Only publish settings and skip the
content. Default is prompt.
--overwrite-settings [-y] Only to be used in conjunction with -i or -o.
Overwrites AppSettings in Azure with local
value if different. Default is prompt.
There's also encryption for the local file if you feel a little adventurous —
run func settings to get usage.

Clear an App Service instance and upload new content from a zip file

On App Service, what's the best way of deploying new content from a zip file, such that it replaces any existing content?
Please note:
I am running on linux
I cannot use msdeploy
I cannot use git
I cannot use VSTS
It needs to be simple
It cant be prone to timing out
It has to be supported by all subscription levels of App Service
Commands should only return after their respective operation(s) have completed
I have access to ARM templates
Provided it isn't as difficult, I'm sure I could upload files to storage blobs
For more information, see this discussion here: https://github.com/projectkudu/kudu/issues/2367
There is a solution that consists in calling the ARM msdeploy provider to deploy a cloud hosted zip package. This requires no msdeploy on your client, so the fact that msdeploy technology is involved is mostly an implementation detail you can ignore.
There are a couple gotchas that I will call out at the end.
The steps are:
First, get your zip hosted in the cloud. e.g. I have a test one here you can play around with: https://davidebbostorage.blob.core.windows.net/arm/FunctionMsDeploy.zip (note that this zip uses special msdeploy packaging, but you can also use a plain old zip with just your files).
Then run the following command using cli 2.0, replacing your resource group, app name and zip url:
az resource update --resource-group MyRG --namespace Microsoft.Web --parent sites/MySite --resource-type Extensions --name MSDeploy --set properties.packageUri=https://davidebbostorage.blob.core.windows.net/arm/FunctionMsDeploy.zip --api-version 2015-08-01
This will result in the package getting deployed to your wwwroot, and any existing content that's not in the zip getting deleted. It's efficient as it won't touch any files that already exist and are identical to what's in the zip. So it's far faster than trying to clean out everything and unzipping clean (but results are identical).
Now a couple gotchas:
Due to what seems like a bug in CLI 2.0, I wasn't able to pass a URL that contains an equal sign, which rules out SAS URLs. I'll report that to them. For now, test the process with a public zip, like my test package above.
The command line is more complex than it should be. I will also ask the CLI team about this.

Resources