DEV Community: Daniel Reis

Running Azure Functions with .NET 5 on Docker

Daniel Reis — Fri, 13 Aug 2021 02:11:46 +0000

The Azure Functions .NET worker has been out for a while, and it finally enabled developers to use C# 9 and .NET 5 on function apps. This is a new way to create C# function apps, it now has a Program.cs class, with the good old generic Host builder and all the extension methods that we're used to see on regular ASP.NET Core and Worker service projects. This is how it can look:

using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureAppConfiguration(builder => builder.AddJsonFile("appsettings.json"))
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices(Startup.ConfigureServices)
    .Build();

await host.RunAsync();

Note that this is using top-level statements. This came with C# 9 and it basically hides the Program class and its namespace, removing some boilerplate and making it easier to understand for newcomers, looks nice!

If you want to run the .NET 5 function apps on Docker containers, as of the day of writing this, the Dockerfile generated by func init --docker --worker-runtime dotnetIsolated does not build correctly, you'll encounter the following error:

The framework 'Microsoft.NETCore.App', version '3.1.0' was not found.

This is because you'll still need .NET Core 3.1 installed for it to work. I don't know why this wasn't fixed in the core tools template, but until it's fixed, you can use the following workaround: copying the 3.1 SDK into the image.

FROM mcr.microsoft.com/dotnet/sdk:5.0 AS installer-env
# Add the line below and it'll build successfully
COPY --from=mcr.microsoft.com/dotnet/sdk:3.1 /usr/share/dotnet /usr/share/dotnet

COPY . /src/dotnet-function-app
RUN cd /src/dotnet-function-app && \
    mkdir -p /home/site/wwwroot && \
    dotnet publish src/functions/*.csproj --output /home/site/wwwroot

# To enable ssh & remote debugging on app service change the base image to the one below
# FROM mcr.microsoft.com/azure-functions/dotnet-isolated:3.0-dotnet-isolated5.0-appservice
FROM mcr.microsoft.com/azure-functions/dotnet-isolated:3.0-dotnet-isolated5.0
ENV AzureWebJobsScriptRoot=/home/site/wwwroot \
    AzureFunctionsJobHost__Logging__Console__IsEnabled=true

COPY --from=installer-env ["/home/site/wwwroot", "/home/site/wwwroot"]

This will hopefully get fixed soon, it's very weird to see a build error on a template like this.

Important: HTTP trigger authorization on Docker containers

If you're going to use Docker containers to run your function apps, you'll get 401 responses when testing your HTTP functions, there's a nice blog post by Martin Björkström explaining how to solve this problem, check it out!

Add authorization to your Azure Functions with Static Web Apps

Daniel Reis — Thu, 25 Feb 2021 05:35:15 +0000

Recently, the Azure Static Web Apps team released some changes to allow us to better configure our app. Although this came with some breaking changes, we are now able to simplify our routes' authorization config! I've been waiting for this for a while, I created an issue about this on August last year.

If you need any guidance on creating a Static Web App with functions, you can check out my other blog post: Using function proxies with Azure Static Web Apps

How it worked before

Previously, to add authorization to your SWA, you had to create a file named routes.json in the root of your app's build artifact folder. That generally changes from framework to framework, but this is well documented. On the file, you can define routes that are authorized based on a user role. The default roles in a Static Web App are anonymous (Someone who is not logged in) and authenticated (Someone who is logged in through any of the identity providers). This is how a routes.json file with authorization rules generally looks like:

{
  "routes": [
    {
      "route": "/*",
      "serve": "/index.html",
      "statusCode": 200,
      "allowedRoles": ["authenticated"]
    }
  ]
}

The file above says that to access any page, you have to be logged on. You can specify which routes require an user to be authenticated so you could, for example, allow any user to access your app's front page, but to access the user panel he would have to be logged on.

How it works now

The routes part of the file is mainly the same, with some fields renamed. The main breaking change is that there's a new file named staticwebapp.config.json. It has the same capabilities of the routes.json and more:

You can now define HTTP methods on your route definitions. Before, if you wanted to allow unauthenticated GET requests but require authentication for POST or PUT, you had to define a different route for the POST and PUT routes. Now, you can use the same route and specify the HTTP methods on the methods field. Here's an example:

{
    "routes": [
      {
        "route": "/api/*",
        "methods": ["POST", "PUT"],
        "allowedRoles": ["authenticated"]
      }
    ]
}

The JSON above says that every route starting with /api and the method is POST or PUT should only be called by users with the authenticated role.

NOTE: The methods field works on the routes.json file, but if you're starting a new application or modifying your routes file to use the new features, you should consider switching to the new file, since the old one is deprecated.

Custom roles

Azure Static Web Apps allow you to create custom roles to your users. Currently this is only possible when inviting users through the portal and it requires you to specify the Auth provider, email address, the apps's domain (for some reason) and the expiration (in hours, max 7 days), as well as the role name, of course. As far as I know, there's no way to do this outside the portal, but hopefully this will change in the future. You can invite an user to your app by going on your Static Web App resource, going on the Role management tab and clicking Invite.

Conclusion

Now that the configuration files allow you to define which HTTP method you want your route definition to run, you can specify which of your HTTP methods will have authorization rules. There are more features that came with the new staticwebapp.config.json file, some of them are really interesting! But I decided to focus this blog post on the authorization and HTTP methods part. You can read more about the new file here. If you have any questions or feedback, let me know!

Using function proxies with Azure Static Web Apps

Daniel Reis — Fri, 19 Feb 2021 04:18:20 +0000

Azure Static Web Apps is a service that provides you with a way to serve static content with an Azure Functions backend API. It's currently in preview, but it already looks promising, giving you a variety of useful features to build a web app. You can pull your code directly from GitHub, then Azure will add a GitHub Actions workflow to build and deploy to Azure Static Web Apps. It truly is a great service, and as of the day of writing this blog post, it's completely free, since it's on preview. You can read about all of Azure Static Web Apps features here.

The integrated API is a nice way to not worry about things like CORS, since it will be hosted on the same domain as the website on the /api route. However, it currently imposes some limitations on what you can do with your function app:

Not every language is supported. You can only create your function app on JavaScript, C# and Python. This will probably be fixed in the future, as there's no good reason to not support other languages IMO.
You can only add HTTP triggers. This one probably is going to remain this way, since it's purpose is to process requests from the frontend, but maybe I'm wrong. Input and output bindings works normally.
Logs are only available through Application Insights. This means that you can't really troubleshoot the resource without creating an Application Insights resource along with your Static Web App. I'm not sure if this means that you cannot add other log providers through DI, but I'll investigate further later.

With that in mind, being limited to only HTTP triggers is not so bad, as you can use the Static Web App's function app as a proxy to other services using function proxies.

Function Proxies

Azure Function Proxies allow you to specify routes that will be implemented by another resource, with the option to override the HTTP method, the query string or the request headers. It's a pretty good tool for breaking a big service into smaller parts in a serverless architecture.

To add a proxy to your function app, you just need to define a proxies.json file on your project (Don't forget to copy the file to the build output!) and configure it according to your needs. This is how a proxies file look like:

{
    "$schema": "http://json.schemastore.org/proxies",
    "proxies": {
        "<proxy-name>": {
            "matchCondition": {
                "route": "/api/todo"
            },
            "backendUri": "%service-url%/api/todo",
            "requestOverrides": {
                "backend.request.querystring.<querystring-name>": "example-value",
                "backend.request.header.<header-name>": "example-value",
            },
            "responseOverrides": {
                "response.body": {
                    "message": "Hello, world!"
                },
                "response.statusCode": "418"
            }
        }
    }
}

The example above does some things that are worth explaining, we're doing the following:

Creating a proxy with the name <proxy-name> that will be triggered when the app receives a request on the /api/todo route. You can also specify HTTP methods on the match condition.
Setting the backendUri to the service that implements our functionality. This is what will be called when the request matches the condition defined. %service-url% is the syntax used for configuration (your local.settings.json file or your environment variables).
Overriding the request's <header-name> header and <querystring-name> query string key with the value 'example-value'.
Overriding the response's body and status code.

There are more things that can be configured in your proxies file, you can read more about it here.

Function Proxies on SWAs

Since SWA allows us to use its function app as a proxy, I made a static app that calls two other function apps through function proxies. This is how our services will communicate:

The code for this blog post is available on this GitHub repository:

danielreis-dev / function-proxies-on-static-web-apps

Using Azure Functions proxies with Azure Static Web Apps

Azure functions proxies with Azure Static Web Apps

This repository contains the sample app used in this blog post.

Dependencies

.NET Core 3.1
.NET 5
Docker

Running the app

Install dotnet tye
Run the app with tye run
Open the dashboard on http://localhost:8000
Click the frontend app's URL

View on GitHub

Catalog Service

This function app has one HTTP function that returns an array of catalog items. You can page the results by changing the index value on the query string.

Orders Service

This function app also has one HTTP function that return an order creation result. If you send any order item on the request, you'll receive a 200 OK with an order ID and a status. If you send an empty array, you'll receive a 400 BAD REQUEST.

SWA Frontend

This is a Blazor WebAssembly app that allows you to browse through catalog items and add them to an in-memory shopping cart. After that, you can finish your shopping by creating an order. It also has a routes.json configured to serve the same file (index.html) on every route, this is required and you can read more about it here.

SWA Backend

This is a simple function app that includes a proxies.json file that maps to the two other function apps' backendUri using environment variables (%CONNECTIONSTRINGS__CATALOG% and %CONNECTIONSTRINGS__ORDERS%). Both proxies override the query string's code value to include the function app's function key that is required for authentication in production, we'll see how to set these values later on, but they're not required in your development environment.

NOTE: Currently, you can't add configuration settings on a SWA that doesn't have any functions in it, so I also included a dummy HTTP function to allow configuration in production. I believe that it should be a valid scenario to only have proxies on your backend function app, so I created an issue on the Static Web App's GitHub repository. I'll update this post with any info they provide me.

On the local.settings.json file, there are two important settings that are worth explaining:

    "AZURE_FUNCTION_PROXY_DISABLE_LOCAL_CALL": true,
    "SERVICE__CATALOG__KEY": "catalog_key" ,
    "SERVICE__ORDERS__KEY": "orders_key"
  },
  "Host": {
    "CORS": "*"

AZURE_FUNCTION_PROXY_DISABLE_LOCAL_CALL: For some reason, when calling your proxy in development gives an error saying that a recursive call was detected, even though it's correctly configured to call another function app listening in another port. Setting this variable to true fixes the problem.
CORS:*: Since we're running this app locally, you'll receive an error if this setting is not present. That's because the Blazor app is running on a different port than the Backend function app. It will work correctly on production.

Running the application

To make testing easier, I've added a tye.yaml file that spins up all four services with one command. It also gives us a nice dashboard with logs and other useful info about the running services. If you never heard about Tye, you should really check it out, it's a wonderful tool that helps a lot with the development of microservices, but all you need to know for now is how to install the tool (dotnet tool install -g Microsoft.Tye --version "0.6.0-alpha.21070.5") and run it (tye run).

name: my-store
services:
- name: frontend
  project: app/MyStore.App.csproj
  bindings:
    - protocol: http
- name: bff
  azureFunction: bff/
  bindings:
  - protocol: http
    port: 7070
- name: catalog
  azureFunction: catalog/
  bindings:
    - protocol: http
      connectionString: ${protocol}://${host}:${port}
- name: orders
  azureFunction: orders/
  bindings:
    - protocol: http
      connectionString: ${protocol}://${host}:${port}

The YAML file configures the SWA backend app to always run on the port 7070 and assign the other three services random ports. It also sets the environment variables required for the SWA backend to call the Orders and Catalog service, that happens through the connectionString binding defined on the file. When running the command tye run, you should see the following:

The dashboard is hosted on http://localhost:8000, it should list you all four services:

Finally, when you access the frontend app, you should be able to add items to your card and finish your order!

NOTE: For some reason, requests going through the proxy always take at least two seconds. Do not panic, as this does not seem to be happening in production.

Creating and configuring your Azure Static Web App

Now that you've seen the app in action, it's time to deploy it to production and configure it. If you need instructions on how to create an Azure Static Web App, check out this Microsoft article.

Now we need to configure our SWA function app and add our function keys and URLs. You can get the function key for each function app running the following commands on the Azure CLI :

az functionapp function keys list -g <ResourceGroupName> -n <CatalogFunctionAppName> --function-name get-catalog

az functionapp function keys list -g <ResourceGroupName> -n <OrdersFunctionAppName> --function-name create-order

These should be added in the Configuration section as SERVICE__CATALOG__KEY and SERVICE__ORDERS__KEY, respectively. As for the URLs, they should be add as CONNECTIONSTRINGS__CATALOG and CONNECTIONSTRINGS__ORDERS. You can get them using the following command:

az functionapp config hostname list -g <ResourceGroupName> --webapp-name <FunctionAppName>

After all that, your should be up and running, and your Configuration section should be looking like this:

Conclusion

I hope you found this post useful. Static Web Apps have amazing potential and I'm hopeful the service will only get better, if you have any questions or feedback, please let me know in the comments!