Azure-functions-core-tools: Access Functions server from client on private LAN

[seniorquico]

I would like to run the Functions server locally and access it from a client on my private LAN. (I'm trying to test calling a Function from an Android client.) I am currently only able to to access the Functions server from localhost. Is this a limitation of the CLI, am I simply missing a configuration change?

[SteveALee]

Usually you set your local server to serve from IP 0.0.0.0 but unfortunately it looks like localhost (127.0.0.1) is hardwired if you set a port. Otherwise it comes from the secrets manager but I don't know how we configure that.

We need an option to set host as well as port.

[seniorquico]

It looks like the self-hosted server is started in StartHostAction, and it, too, is hardwired to use localhost.

[ahmelsayed]

So this used to be possible, if you remember the cli used to prompt you to run as admin the first time you launch it so it'd register a binding with http.sys to allow this. I thought you shouldn't need to run the cli as admin just to register an http server, so I changed that. I can added it back with a switch.

[ahmelsayed]

though with the move to .NET Core we can finally get rid of dependency on http.sys all together.

[SteveALee]

I agree shouldn't need to login as admin just to set the host. :(

Out of interest when is the Core work due to land?

[ahmelsayed]

@fabiocav is actively working on it, though I'm not sure there is an exact due date just yet. There are few PRs opened across all the runtime repos (I'm hoping to start moving the cli to consume these soon) You can follow the main PR for the core pieces of the runtime here https://github.com/Azure/azure-webjobs-sdk/pull/1193 Hopefully once that is in, the rest will follow suit.

[ahmelsayed]

oh and since we'll be targeting .NET Standard 2.0, it certainly won't be before .NET Core 2.0 RTM :)

[SteveALee]

Makes perfect sense :)

[seniorquico]

@ahmelsayed An optional switch to require admin privileges and bind to 0.0.0.0 (or as I've seen in other servers, explicitly specifying the IP address on which to bind) sounds good to me. Even with the move to .NET Core and without the http.sys dependency, we'll still need a switch to change the binding from 127.0.0.1, right? Do you have a pointer to a commit that was binding to 0.0.0.0?

[snoopdouglas]

Getting the CLI to bind to 0.0.0.0 would be very useful for developing Functions from within Docker; in order to expose container ports, they must be bound to 0.0.0.0 rather than 127.0.0.1 (localhost).

Workaround

For the moment, I've installed nginx as a reverse proxy inside my container. Use the following nginx config in /etc/nginx/sites-available/default:

server {
    listen 80;

    location / {
        proxy_pass http://localhost:7071;
    }
}

Set your CMD to a script similar to:

#!/bin/bash

func start &
nginx

wait

...then map 7071:80 when running the container. Viola, http://localhost:7071 routes correctly.

[seniorquico]

@snoopdouglas Thanks for the temporary workaround!

[Insanityisnice]

Any progress on this or is nginx still the only way?

[alexriziy]

Any progress on this or is nginx still the only way?

+1

[TonyHenrique]

I want to use Azure Functions, but I am really worried about it... we have to install nodejs to use a .net thing, and now, I can not access a internet thing outside localhost...

Please fix that;
How to configure Host : Port of Azure Functions on Visual Studio 2017 ?
I want that it accepts like ASP.Net Core (.UseUrls("http://+:7071")):

Now listening on: http://[::]:7071

but it is only listening on

http://localhost:7071

See https://stackoverflow.com/q/49267438/194717

[SDP190]

@alrod Even now with the update Bind to 0.0.0.0 instead of localhost, when using option
func host start --useHttps its still only binding to localhost.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.