Skip to content

Latest commit

 

History

History
225 lines (191 loc) · 11.7 KB

7-getting-started-with-azure-functions.md

File metadata and controls

225 lines (191 loc) · 11.7 KB

Workshop: Getting started with Azure Functions

Introduction

Now we are ahead for the next challenge, where we would like get familiar with Azure Functions and how to use them to build serverless applications. We will start by creating a new Azure Functions project, test and debug the a simple application make sure we have full understanding how to develop and enhance them, and then we will use Bicep to deploy the function app to Azure. Once we have it up and running, we will create a project solution file to organize our different projects.

Azure Functions Core Tools (func): is a command-line tool that lets you develop, manage, and deploy Azure Functions projects from your local computer. You can use Core Tools to create, add, and bind functions to your project, and start the Functions host to run or debug them. You can also use Core Tools to deploy your code to Azure and work with application settings.

Learning Objectives

  1. Developing Azure Functions applications.
  2. Organizing projects using a Project Solution (.sln).

Challenges

  1. Create your first containerized Azure Functions project.
  2. Deploy Azure Functions application to Azure using Bicep.
  3. (Optional) Organize projects using a Project Solution

Challenge 1: Create your first containerized Azure Functions project

  1. Initialize new dotnet Azure Functions project using Azure Functions Core Tools CLI (func).

    func init ./src/backend --worker-runtime dotnet --docker

    Note: The --docker flag is a command-line argument that generates a Dockerfile for a container. The Dockerfile uses a base image that matches the selected worker runtime. This is useful if you want to run your functionapp inside a container.

  2. Rename backend.csproj to Todo.Backend.csproj for naming consistency.

    mv ./src/backend/backend.csproj ./src/backend/Todo.Backend.csproj
  3. Review your new Todo.Backend project:

    • host.json - A metadata file that contains configuration options that affect all functions in an Azure Functions app instance. It is used to manage global settings for your function app, such as function timeouts, logging, and triggers. The file is located in the root directory of your function app and is automatically created when you create a new function app project. You can use the host.json file to configure settings such as the maximum number of concurrent function executions, the default function timeout, and the logging level for your function app
    • local.settings.json - A configuration file that is used to store app settings and connection strings when you develop and test your Azure Functions project locally. Since this file might contains secrets, it is excluded from source control by default, but we can have it in version control by updating ./src/backend/.gitignore following best practices and using with Managed Identities instead.
    • Dockerfile - A text file that contains a set of instructions and commands that are used to build a Docker image. The Dockerfile is used to automate the process of creating a Docker image by specifying the base image, adding layers, and defining the commands that should be run when the image is created. Docker images can be used to run applications in any environment that supports Docker, making them a popular choice for deploying applications to the cloud.
  4. Change to the backend project root directory

    pushd src/backend
  5. Create an HttpTrigger function:

    1. Review different C# available functions templates:

      func templates list --language c#
    2. Create a new HttpTrigger function

      func new --name "Healthz" --template "HttpTrigger" --authlevel "anonymous"

      This command will create a new Http Trigger function named Healthz with anonymous authentication level, which means that the function will be accessible without any authentication, and a default implementation that returns Http Status Code 200.

  6. Launch the functions runtime host with your function app locally:

    func start

    Once the build succedded the function app will start locally and you will be able to click on Open in browser button in the toast message or open manually http://localhost:7071 and see function home page is up and test your new HttpTrigger via the corresponded api endpoint http://localhost:7071/api/Healthz

  7. Stop the functions runtime host by pressing Ctrl + C in the terminal.

  8. Change back to root directory

    popd
  9. Run and debug your function locally:

    1. Add .vscode tasks and launch configurations for functions.
      1. Add the following tasks to .vscode/tasks.json under tasks array:
      {
          "label": "Start Backend",
          "type": "dotenv",
          "targetTasks": "Backend Functions Run",
          "file": "${input:dotEnvFilePath}"
      },
      {
          "label": "Clean Backend",
          "command": "dotnet",
          "args": [
              "clean",
              "${workspaceFolder}/src/backend/Todo.Backend.csproj",
              "/property:GenerateFullPaths=true",
              "/consoleloggerparameters:NoSummary"
          ],
          "options": {
              "cwd": "${workspaceFolder}/src/backend/"
          },
          "type": "process",
          "problemMatcher": "$msCompile"
      },
      {
          "label": "Build Backend",
          "command": "dotnet",
          "args": [
              "build",
              "${workspaceFolder}/src/backend/Todo.Backend.csproj",
              "/property:GenerateFullPaths=true",
              "/consoleloggerparameters:NoSummary"
          ],
          "type": "process",
          "dependsOn": "Clean Backend",
          "group": {
              "kind": "build",
              "isDefault": true
          },
          "problemMatcher": "$msCompile"
      },
      {
          "label": "Backend Functions Run",
          "detail": "Helper task--use 'Start Backend' task to ensure environment is set up correctly",
          "type": "func",
          "dependsOn": "Build Backend",
          "command": "host start",
          "options": {
              "cwd": "${workspaceFolder}/src/backend/"
          },
          "presentation": {
              "panel": "dedicated",
          },
          "problemMatcher": [
              "$func-dotnet-watch"
          ]
      }
    2. In order to attach to a running azure functions process, add the following launch configuration, to .vscode/launch.json under configurations array:
      {
          "name": "Attach to .NET Functions",
          "type": "coreclr",
          "request": "attach",
          "processId": "${command:azureFunctions.pickProcess}"
      }
    3. Start the function locally using command pallete Ctrl + Shift + P and type Tasks: Run Task and select Start Backend task.
    4. Place a breakpoint in your Healthz function.
    5. Open Run and Debug panel using Ctrl + Shift + D, select Attach to .NET Functions from the dropdown and then pressing F5 to start debugging.
    6. Trigger your Healthz function and validate the breakpoint is hit.
    7. Stop debugging by pressing Shift + F5 and stop the function app by pressing Ctrl + C in the terminal.

Challenge 2: Deploy Azure Functions application to Azure using Bicep

We could use different compute services like a Azure Container Instances (ACI) or Azure Kubernetes Service to host our function app, but for this workshop we will use an App Service Plan service.

  1. Create backend.bicep using infra/core/host/functions.bicep module.

    1. Understand functions.bicep - app service plan
    2. backend storage best practices and connection string for multicloud
  2. Add new backend service to main.bicep.

  3. Add new backend service to azure.yaml for azd.

  4. Deploy changes to your environment using azd up.

  5. Locate your service backend endpoint and test your function app

    azd show | grep "backend" | awk '{print $2 "api/healthz"}'

Challenge 3 (Optional): Organize projects using a Project Solution

A Project Solution (.sln) file is a solution file that is used to group one or more projects together in Visual Studio and now supported also in VSCode. It is a text-based file that stores metadata about your solution, including the projects that are associated with the solution, the items that are not associated with a particular project, and the build configurations that determine which project configurations to apply in each type of build.

There are several reasons why you might want to use a .sln file for your projects. Here are some of them:

  1. Different projects can be developed by different teams, and the solution file can help manage the dependencies between them.
  2. The solution file can be used to manage the configuration and deployment settings for all of the projects in the solution.
  3. Different projects can have different dependencies, either dependencies to other projects in your solution or dependencies to third-party DLLs, pre/post-build steps and more.

Organize the solution using a Project Solution (.sln):

  1. Open new terminal: Menu -> Terminal -> New Terminal (or Ctrl + Shift + ~).

  2. Create new .sln in the root directory:

    dotnet new sln -n Todo
  3. Add existing .NET projects to sln:

    dotnet sln Todo.sln add src/api/Todo.Api.csproj
  4. Close the opened solution in VSCode Solution Explorer, using one of the following options:

    1. Using Command Palette:

      1. Open the Command Palette using Ctrl + Shift + P.
      2. Type Close Solution and select .NET: Close Solution from the list.
    2. Using the Solution Explorer extension:

      1. Right click on the solution name in the Solution Explorer.
      2. Select Close Solution.

      Close solution

  5. Open the new Todo solution in VSCode Solution Explorer:

    1. Open the Command Palette with Ctrl + Shift + P.
    2. Type Open Solution and select .NET: Open Solution from the list.
    3. Pick Todo.sln.
  6. Add backend project to the sln:

    dotnet sln Todo.sln add src/backend/Todo.Backend.csproj
  7. Review the new solution in VSCode Solution Explorer:

    solution explorer

Additional Resources

Name Description
Understanding serverless cold start APIM - Consumption tier cold start