I'm testing an Azure Functions app locally with the Azure Functions CLI tooling. Is there any way I can configure CORS settings for the local host?
You can configure CORS in the local settings file local.settings.json:
{
"Values": {
},
"Host": {
"CORS": "*"
}
}
Settings in the local.settings.json file are used only when you're
running projects locally
You can start the host like this
func host start --cors *
You can also be more specific and provide a comma delimited list of allowed urls
More here: https://github.com/Azure/azure-webjobs-sdk-script/issues/1012
Another easy way to configure CORS on Azure Functions is to use Azure Portal,
1- Go to the Function App Settings in Azure Portal
2 - Click on CORS and add your local host url
And there you have it!!
Hope this helps someone.
If you're having issues passing in the params via Visual Studio's Debug's "Application Arguments". This is how to pass the params from the command line:
1) Open an ordinary command prompt.
2) cd to your solution's compiled dll, i.e. "Your Solution Path"\bin\Debug\netstandard2.0
3) start the Azure function runtime from the command line, i.e.:
dotnet "C:\Users\USER\AppData\Local\Azure.Functions.V2.Cli\func.dll" host start --port 7071 --cors * --pause-on-error
4) To debug in Visual Studio, Debug->Attach to Process.. and attach to the donet.exe that will be running.
Hope that helps prevent someone from banging their head too much...
Related
I'm trying to start a headless chrome with a puppeteer in Azure Functions on Linux.
What do I do? I have a “Function App” that looks this way:
And I have a function:
I build this function remotely this way:
func azure functionapp publish {appname} --build remote
And this is what I get when I try to run a function:
Result: Failure
Exception: Failed to launch the browser process!
/home/site/wwwroot/node_modules/puppeteer/.local-chromium/linux-1011831/chrome-linux/chrome: error while loading shared libraries: libgobject-2.0.so.0: cannot open shared object file: No such file or directory
I've seen this topic already (Puppeteer throws launch exception when deployed on azure functions node on Linux) but they recommend do a remote build, which I do and it still doesn't help.
Maybe I'm using wrong App Service Plan, but I checked and there were nothing related to special linux setup there.
The reason was that I was indeed using the wrong App Service Plan. I needed a “Function App” one. When I recreated a function with the right service plan, everything worked just fine.
I was able to deploy the azure function without the use of func azure functionapp publish {appname} --build remote. I did it using the visual studio code.
But before that I installed the puppeteer inside the function folder using
npm install puppeteer
Then I added the node_modules name in the .funcignore file.
Then I added the following setting in setting.json in the .vscode folder
"azureFunctions.scmDoBuildDuringDeployment": true
Then deploy the function normally through vscode
As title, when I try to run my nodejs based azure function, I come across the following error:
The following 1 functions are in error: [7/2/19 1:41:17 AM] ***: The binding type(s) 'blobTrigger' are not registered. Please ensure the type is correct and the binding extension is installed.
I tried func extensions install --force with no luck still, any idea? My development environment is macOS and I tried both nodejs based azure-functions-core-tools and brew based install both doesn't work.
The most scary part is this used to work fine on the same machine, all a sudden it just failed to work.
Basically, you can refer to the offical tutorial for Linux Create your first function hosted on Linux using Core Tools and the Azure CLI (preview) to start up your work.
Due to the same shell bash used in MacOS and Linux, I will start up my sample demo for you on Linux and avoid using those incompatible operations. First of all, assumed that there is an usable NodeJS runtime in your environment. The version of node and npm is v10.16.0 and 6.9.0.
To install azure-functions-core-tools via npm and inspect it, as the figure below.
Next to init a project MyFunctionProj via func
Then to new a function with blob trigger
There is an issue about the requirement for .NET Core SDK. So I move to https://www.microsoft.com/net/download to install it, here is incompatible with MacOS, but I think you can easy to fix it by yourself. So I followed the offical installation instruction to install it.
After installed .NET Core SDK, try to func new again.
And completed like this.
To change two configuration files MyFunctionProj/local.settings.json and MyFunctionProj/MyBlobTrigger/function.json, as below.
MyFunctionProj/local.settings.json
{
"IsEncrypted": false,
"Values": {
"FUNCTIONS_WORKER_RUNTIME": "node",
"AzureWebJobsStorage": "<your real storage connection string like `DefaultEndpointsProtocol=https;AccountName=<your account name>;AccountKey=<your account key>;EndpointSuffix=core.windows.net`"
}
}
MyFunctionProj/MyBlobTrigger/function.json
{
"bindings": [
{
"name": "myBlob",
"type": "blobTrigger",
"direction": "in",
"path": "<the container name you want to monitor>/{name}",
"connection": "AzureWebJobsStorage"
}
]
}
Then, command func host start --build to start up it without any error.
Let's upload a test file named test.txt via Azure Storage Explorer to the container <the container name you want to monitor> which be configured in the function.json file. And you will see that MyBlobTrigger has been triggered and work fine.
Hope it helps.
Under Ubuntu environment, NodeJS Google Vision complains:
Error: Unable to detect a Project Id in the current environment.
Even though I already put json credential through
$ export GOOGLE_APPLICATION_CREDENTIALS=/var/credential_google.json"
Please help.
As a quick hack you can try this :
$ GOOGLE_APPLICATION_CREDENTIALS="/var/credential_google.json" node app.js
It's not recommended to use a .json config file locally. I've seen these leak on production servers causing whole platforms to be deleted + the introduce environmental switching and security issues.
Setup Google Cloud CLI.
Now the server will 'look' at the local environment and use that.
If you get the error "Unable to detect a Project Id in the current environment.", it means the auth library cannot find the project default id.
You need to have a base project in Google Cloud set, regardless of environmental variables and project you're running.
Run
gcloud config set project [some-project-id]
Now if you run (node example)
"dev": "NODE_ENV=dev GCP_PROJECT=some-project-id nodemon index.ts",
It will load the project environment. This also allows you to deploy easier with:
"deploy:dev": "y | gcloud app deploy --project some-dev-project app.yaml",
"deploy:prod": "y | gcloud app deploy --project some-prod-project app.yaml"
App engine has security setup automatically with standard environments. With flex you can use one of the manage images Google Provides.
If you are usually a windows user and trying out Ubuntu (like me), the problem is likely with the assumptions that the export command exports variable to all terminal sessions and that you need to open a new terminal to get it to use (as expected in a windows terminal for an environment variable).
The export command doesn't export the variable to another terminal session. So if you export it in a terminal, you use it on the same terminal.
If you would like to export it permanently, then you can try the solution listed here
You can put the path to the JSON credentials directly when instantiating the client, by passing it as an argument.
For example:
const client = new speech.SpeechClient( {keyFilename: "credential_google.json"});
Also, for me setting it in the terminal didn't work.
I am setting local host port in local.setting.json. Referring Microsoft doc https://learn.microsoft.com/en-us/azure/azure-functions/functions-run-local
The file looks like below
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "",
"AzureWebJobsDashboard": ""
},
"Host": {
"LocalHttpPort": 7073
}
}
When I run/debug the solution , VS still host the app on default port (7071)
I have checked the bin directory, the local.setting.json file is geting there with above settings.
Running Azure Fucntion CLI (func host start) from bin directory correctly read the port number.
Looks like VS is not using the "LocalHttpPort" port. Is there any other changes required in the settings. I have Visual Studio 2017 Preview (2)
I am using the CLI version 1.2.1, and the following Application arguments setting in Project Properties -> Debug worked for me.
host start --port 7074 --nodeDebugPort 5860
Update: If you're just looking to change the port, you don't have to set it through the file specified in the question. Check Thuc Nguyen answer
Original answer:
the command line takes precedence over the settings file, the problem is that VS passes an explicit port on the command line.
work around is to go through project -> properties -> Debug, then under Application arguments take control of the args. you can type host start --pause-on-error
Edit from ravinsp:
Update for .Net Core 2.0 function project:
The command line arguments you have to pass are different. You have to pass in the path to a dll in front. Like this:
%AppData%\..\Local\Azure.Functions.V2.Cli\2.0.1-beta.22\Azure.Functions.Cli.dll host start --pause-on-error You can see for yourself by running the function in Visual Studio and using the process explorer to see command line args to dotnet.exe process.
edit: a word
Update Project Properties -> Debug to following
host start --port 7073 --pause-on-error
As of this version:
Azure Functions Core Tools (3.0.2912 Commit hash: bfcbbe48ed6fdacdf9b309261ecc8093df3b83f2)
Function Runtime Version: 3.0.14287.0
you only have to type start --port 7074 in the Application Arguments box
Correct answer for .NET Core 2.0 / .NET Standard 2.0 Azure Functions project in Visual Studio 2017 when you have installed Azure Functions Core Tools 2.x Runtime via NPM
I followed #ahmelsayed's answer and in particular, #ravinsp's comments for .net core 2.0 comments. While very helpful and putting me on the right track, they did not work for me without a crucial and non-intuitive modification so I'm adding a fresh answer.
TL;DR;
If you've used NPM to install Azure Functions Core Tools 2.x Runtime then you may need to set Project/Properties/Debug/Application Arguments to:
C:\Users\<myuserid>\AppData\Roaming\npm\node_modules\azure-functions-core-tools\bin\func.dll host start --port 8888 --pause-on-error
Long answer follows ...
My Setup
During this exercise, my setup is fully up to date (at time of writing) and as follows:
Visual Studio 2017 Professional: 15.6.2
Azure Functions and Web Job Tools: 15.0.40215.0
Windows 10 10.0.16299 Build 16299
Azure Functions Core Tools (installed as per the Develop and run Azure functions locally document from Microsoft) reports (in Git Bash):
me#MYDESKTOP ~
$ func
<snip/>
Azure Functions Core Tools (2.0.1-beta.24)
Function Runtime Version: 2.0.11587.0
fwiw, the Functions App settings tab for this Functions App on Azure reads:
Runtime version: 2.0.11587.0 (beta)
My Issue
When I run my functions project (with no application arguments) I get this in the console output:
[17/03/2018 21:06:38] Starting Host (HostId=MYMACHINE, Version=2.0.11353.0, ProcessId=<snip/>
Listening on http://localhost:7071/
This in and of itself might not be a problem, but I'm getting annoying "works on my machine, fails when publishing to azure" type issues, so I want to make sure that local execution is using same functions runtime as azure (i.e. 2.0.11587.0 which, as per the setup notes above, it is/should be, right?)
So, based on #ravinsp's instructions, I run a find on my C drive to locate Azure.Functions.Cli.dll - there's only one, and it's located at C:\Users\<myuserid>\AppData\Local\Azure.Functions.V2.Cli\2.0.1-beta\Azure.Functions.Cli.dll which seems very consistent with #ravinsp's answer.
So, I add the following Project/Properties/Debug/Application Arguments:
C:\Users\<myuserid>\AppData\Local\Azure.Functions.V2.Cli\2.0.1-beta\Azure.Functions.Cli.dll host start --port 8888 --pause-on-error
then I DO get port 8888, but runtime weirdly is still being reported as 2.0.11353.
[17/03/2018 21:13:02] Starting Host (HostId=MYMACHINE, Version=2.0.11353.0, ProcessId=<snip/>
Listening on http://localhost:8888/
Solution
Given that running func from Git Bash as per the above showed runtime of 2.0.11587.0, I tried which func which returned /c/Users/<myuserid>/AppData/Roaming/npm/func
. I did a cat on it and long story short I could see that ultimately it was running C:\Users\<myuserid>\AppData\Roaming\npm\node_modules\azure-functions-core-tools\bin\func.exe, and that in that same directory there was a func.dll.
So, I tried the following Project/Properties/Debug/Application Arguments:
C:\Users\<myuserid>\AppData\Roaming\npm\node_modules\azure-functions-core-tools\bin\func.dll host start --port 8888 --pause-on-error
then finally I do get ...
[17/03/2018 21:16:29] Starting Host (HostId=MYMACHINE, Version=2.0.11587.0, ProcessId=<snip/>
Listening on http://localhost:8888/
and, crucially, the error I was getting when publishing to Azure starts manifesting itself locally too.
Ok, now the runtimes all in sync, time to get down to fixing my actual bug :)
To do this
Select the Function App Project in Visual Studio -> Hit Alt+Enter and navigate to Debug settings and set
host start --port 8085 --nodeDebugPort 6890
I used the accepted answer but I still got an error when the debugger port was trying to bind because both function apps were trying to bind to 5858.
To get around that I added one more attribute to the application arguments in the project settings and my arguments look like this:
host start --pause-on-error --nodeDebugPort 5860
If you're using Visual Studio for MacOS right click on your project, click Options, click on Run -> Configurations -> Default and enter host start --port 7073 --pause-on-error in the Arguments field.
Using Visual Studio 2022 and Function v4, you could set the port in the launchSettings.json file:
{
"profiles": {
"<functionapp project name>": {
"commandName": "Project",
"commandLineArgs": "--port 7137",
"launchBrowser": false
}
}
}
This setting can also be updated through UI:
Properties > Debug > General > Open debug launch profiles UI:
This is the way I use a different port in local.settings.json file, while running this in Intellij. You can use any other IDE as well, local.settings.json works everywhere.
{
"IsEncrypted": false,
"Values": {
"FUNCTIONS_WORKER_RUNTIME": "java"
},
"Host": {
"LocalHttpPort": 7072
},
"ConnectionStrings": {}
}
Using the following in the "Command line arguments" in VS 2022 and .Net 6 works:
start --port 7074
I'm trying to run some pre deployment tasks (unit tests etc) with NPM on an Azure website, however the version of node on the VM is v0.10.32, the current version of node is v4.2.4.
I have non administrative access to the command line via the SCM website, no RDP etc.
Is there any way to upgrade?
Ensure the Azure Web App has the node version you want.
Go to yoursite.scm.azurewebsites.net
Choose Debug Console (PowerShell or CMD)
Navigate to D:\Program Files (x86)\nodejs
Run dir to see the available nodejs versions.
For instance, if there is a directory named 6.3.0, then you can use it.
// App Setting
WEBSITE_NODE_DEFAULT_VERSION 6.3.0
// package.json
engines":{"node": "6.3.0"}
You can specify the version of node that the app is running on using the package.json file. Add:
"engines":{"node":version}
e.g.:
"engines":{"node": "0.12.x"},
More info: https://azure.microsoft.com/en-us/documentation/articles/nodejs-specify-node-version-azure-apps/
2017 update. All above didn't work for me in.
I changed:
// package.json
engines":{"node": "8.0.0"}
and then I added app settings value
<appSettings>
<add key="WEBSITE_NODE_DEFAULT_VERSION" value="8.0.0" />
</appSettings>
I restarted an app million times, and the solution was to change iisnode.yml
nodeProcessCommandLine: "D:\Program Files (x86)\nodejs\8.0.0\node.exe"
That's it. I hope it will help someone.
Update
Just to clarify things: I'm talking about App Service
And if you ftp to your App you will see iisnode.yml here:
Changing NodeJs Version in Azure Portal
Navigate to your web app in azure portal
Click on Application settings in Settings blade.
You can include WEBSITE_NODE_DEFAULT_VERSION as key and version of nodejs you want as value in app settings.
Example: WEBSITE_NODE_DEFAULT_VERSION 8.0.0
For me, the solution was neither to set the engine version in package.json, nor to set WEBSITE_NODE_DEFAULT_VERSION, but to use the az command line as described here:
az webapp config set \
--resource-group <resource-group-name> \
--name <app-name> \
--linux-fx-version "NODE|14-lts"