Intranoggin

Blither, Blather, Web Content Management.
Blog » Using ngrok with Azure Functions

Using ngrok with Azure Functions

I develop solutions that are integrated with Office 365/SharePoint Online through Microsoft Flow, Logic Apps, and SharePoint Designer workflows. One of the difficulties in that type of development is the need to deploy code to Azure in order to debug and test any changes. I know there are methods for stepping through remote code that has been deployed to Azure, but it’s not as easy as debugging local code and certainly not as fast. That’s where ngrok comes in.

image

ngrok is a reverse proxy that lets you tunnel requests through your firewall to your local machine. They offer both free and paid version, so try out the free version and then buy in when you’re seeing value.

  • Go to http://ngrok.com and download the zip.
  • Unzip the file where you want to execute it. I created a folder in c:\program files\ngrok and dropped he ngrok.exe in there.
  • Edit your environmental variables and add the path to ngrok.exe into your path variable.

image

image

  • From a command prompt now, you’ll be able to launch ngrok. we just need to make it listen to the correct port.

image

  • Head back to http://ngrok.com and create a new account or sign in with your GitHub account.
  • After signing in, you’ll find the command to install your auth token on the get started page.

image

  • Go back to your command prompt and execute ngrok authtoken *your auth token*
  • That will create a ngrok.yml file in your user directory. mine was at c:\users\rlmiller\.ngrok2\ngrok.yml
  • ngrok.yml in a text editor
  • We just need to define a tunnel in there that attaches port 7071 to http. Because we are testing on localhost, we’ll add that host_header setting as well.

image

  • I named the tunnel azfunctions, so I can now start it with the command “ngrok start azfunctions”

image

 

At this point, you could point your SPD Workflow, Microsoft Flow, or Logic App at the ngrok url and it would route directly to your local process. The problem is that whenever you restart ngrok, you’ll get a new URL for the tunnel. When that URL changes, you’ll need to update the caller, which can be kind of a pain. Instead, I like to set  up a Azure Function Proxy. I covered proxies in Alexa on Azure: Part 9 – Azure Function Proxies, but as a recap, you can add proxies.json as a sibling to your host.json file. An example of one of my ngrok proxies looks like this:

image

I then just point the caller, an SPD workflow in this case, at the function proxy. Whenever I restart ngrok and get a new url, I do need to update the proxies.json file and deploy one time to update the proxy. after that all of my function changes can be executed on localhost.

I haven’t gone to the next step paying for an ngrok plan which would allow me to get the same ngrok url after each restart.

As an added benefit, ngrok gives you a local page on port 4040 which gives you some additional insight.

Gotcha Warning: In my local.settings.json file I define AzureWebJobsStorage and AzureWebJobsDashboard to “UseDevelopmentStorage=true”. If you do the same, you’ll need to ensure you’ve got the Azure Storage Emulator running – even if you aren’t actually using the local storage for anything in your function.


Posted: 7/19/2017 2:47:55 PM by Ryan Miller | with 0 comments