Python-utvecklarhandbok för Azure Functions

Artikel
03/18/2023
32 minuter för att läsa

Den här guiden är en introduktion till att utveckla Azure Functions med hjälp av Python. Artikeln förutsätter att du redan har läst Azure Functions utvecklarguiden.

Viktigt

Den här artikeln stöder programmeringsmodellen v1 och v2 för Python i Azure Functions. Programmeringsmodellen Python v2 är för närvarande i förhandsversion. Python v1-modellen använder en functions.json-fil för att definiera funktioner, och med den nya v2-modellen kan du i stället använda en dekoratörsbaserad metod. Den här nya metoden resulterar i en enklare filstruktur och är mer kodcentrerad. Välj v2-väljaren överst i artikeln för att lära dig mer om den nya programmeringsmodellen.

Som Python-utvecklare kanske du också är intresserad av någon av följande artiklar:

Komma igång	Begrepp	Scenarier och exempel
Skapa Python-funktioner med hjälp av Visual Studio Code Skapa Python-funktioner med hjälp av en terminal eller kommandotolk	Utvecklarguide Värdalternativ Saker att tänka på gällande prestanda	Bildklassificering med PyTorch Azure Automation exempel Maskininlärning med TensorFlow Bläddra bland Python-exempel

Komma igång	Begrepp	Exempel
Skapa Python-funktioner med hjälp av Visual Studio Code Skapa Python-funktioner med hjälp av en terminal eller kommandotolk	Utvecklarguide Värdalternativ Saker att tänka på gällande prestanda	Kodexempel

Utvecklingsalternativ

Båda Python Functions-programmeringsmodellerna stöder lokal utveckling i någon av följande miljöer:

Python v2-programmeringsmodell:

Observera att programmeringsmodellen Python v2 endast stöds i 4.x-funktionskörningen. Mer information finns i översikten över Azure Functions körningsversioner.

Python v1-programmeringsmodell:

Du kan också skapa Python v1-funktioner i Azure Portal.

Följande överväganden gäller för lokal Python-utveckling:

Även om du kan utveckla dina Python-baserade Azure-funktioner lokalt i Windows stöds Python endast på en Linux-baserad värdplan när den körs i Azure. Mer information finns i listan över operativsystem/körningskombinationer som stöds.
Functions stöder för närvarande inte lokal Python-funktionsutveckling på ARM64-enheter, inklusive på en Mac med ett M1-chip. Mer information finns i x86-emulering på ARM64.

Programmeringsmodell

Azure Functions förväntar sig att en funktion är en tillståndslös metod i Python-skriptet som bearbetar indata och genererar utdata. Som standard förväntar sig körningen att metoden implementeras som en global metod som heter main() i filen __init__.py . Du kan också ange en alternativ startpunkt.

Du binder data till funktionen från utlösare och bindningar via metodattribut som använder egenskapen name som definieras i filen function.json . Följande function.json-fil beskriver till exempel en enkel funktion som utlöses av en HTTP-begäran med namnet req:

{
    "scriptFile": "__init__.py",
    "bindings": [
        {
            "authLevel": "function",
            "type": "httpTrigger",
            "direction": "in",
            "name": "req",
            "methods": [
                "get",
                "post"
            ]
        },
        {
            "type": "http",
            "direction": "out",
            "name": "$return"
        }
    ]
}

Baserat på den här definitionen kan filen __init__.py som innehåller funktionskoden se ut som i följande exempel:

def main(req):
    user = req.params.get('user')
    return f'Hello, {user}!'

Du kan också uttryckligen deklarera attributtyperna och returtypen i funktionen med hjälp av Python-typanteckningar. På så sätt kan du använda IntelliSense- och autocomplete-funktionerna som tillhandahålls av många Python-kodredigerare.

import azure.functions


def main(req: azure.functions.HttpRequest) -> str:
    user = req.params.get('user')
    return f'Hello, {user}!'

Använd Python-anteckningarna som ingår i paketet azure.functions.* för att binda indata och utdata till dina metoder.

Utlösare och bindningar kan deklareras och användas i en funktion i en dekoratörsbaserad metod. De definieras i samma fil, function_app.py, som funktionerna. Till exempel representerar följande function_app.py-fil en funktionsutlösare av en HTTP-begäran.

@app.function_name(name="HttpTrigger1")
@app.route(route="req")

def main(req):
    user = req.params.get('user')
    return f'Hello, {user}!'

import azure.functions

@app.function_name(name="HttpTrigger1")
@app.route(route="req")

def main(req: azure.functions.HttpRequest) -> str:
    user = req.params.get('user')
    return f'Hello, {user}!'

För närvarande stöds endast specifika utlösare och bindningar av programmeringsmodellen Python v2. Mer information finns i Utlösare och indata.

Mer information om kända begränsningar med v2-modellen och deras lösningar finns i Felsöka Python-fel i Azure Functions.

Alternativ startpunkt

Du kan ändra standardbeteendet för en funktion genom att scriptFile ange egenskaperna och entryPoint i filen function.json . Följande function.json instruerar till exempel körningen customentry() att använda metoden i den main.py filen som startpunkt för din Azure-funktion.

{
  "scriptFile": "main.py",
  "entryPoint": "customentry",
  "bindings": [
      ...
  ]
}

Under förhandsversionen finns startpunkten bara i filen function_app.py . Du kan dock referera till funktioner i projektet i function_app.py med hjälp av skisser eller genom att importera.

Mappstrukturen

Den rekommenderade mappstrukturen för ett Python-funktionsprojekt ser ut som i följande exempel:

 <project_root>/
 | - .venv/
 | - .vscode/
 | - my_first_function/
 | | - __init__.py
 | | - function.json
 | | - example.py
 | - my_second_function/
 | | - __init__.py
 | | - function.json
 | - shared_code/
 | | - __init__.py
 | | - my_first_helper_function.py
 | | - my_second_helper_function.py
 | - tests/
 | | - test_my_second_function.py
 | - .funcignore
 | - host.json
 | - local.settings.json
 | - requirements.txt
 | - Dockerfile

Huvudprojektmappen,< project_root>, kan innehålla följande filer:

local.settings.json: Används för att lagra appinställningar och anslutningssträngar när de körs lokalt. Den här filen publiceras inte till Azure. Mer information finns i local.settings.file.
requirements.txt: Innehåller listan över Python-paket som systemet installerar vid publicering till Azure.
host.json: Innehåller konfigurationsalternativ som påverkar alla funktioner i en funktionsappinstans. Den här filen publiceras till Azure. Alla alternativ stöds inte när du kör lokalt. Mer information finns i host.json.
.vscode/: (Valfritt) innehåller den lagrade Visual Studio Code-konfigurationen. Mer information finns i Visual Studio Code-inställningar.
.venv/: (Valfritt) innehåller en virtuell Python-miljö som används av lokal utveckling.
Dockerfile: (Valfritt) Används när du publicerar projektet i en anpassad container.
tests/: (Valfritt) Innehåller testfallen för din funktionsapp.
.funcignore: (Valfritt) Deklarerar filer som inte ska publiceras till Azure. Den här filen innehåller vanligtvis .vscode/ för att ignorera redigeringsinställningen . venv/ för att ignorera den lokala virtuella Python-miljön, tester/ för att ignorera testfall och local.settings.json för att förhindra att lokala appinställningar publiceras.

Varje funktion har en egen kodfil och bindningskonfigurationsfil, function.json.

Den rekommenderade mappstrukturen för ett Python-funktionsprojekt ser ut som i följande exempel:

 <project_root>/
 | - .venv/
 | - .vscode/
 | - function_app.py
 | - additional_functions.py
 | - tests/
 | | - test_my_function.py
 | - .funcignore
 | - host.json
 | - local.settings.json
 | - requirements.txt
 | - Dockerfile

Huvudprojektmappen,< project_root>, kan innehålla följande filer:

.venv/: (Valfritt) innehåller en virtuell Python-miljö som används av lokal utveckling.
.vscode/: (Valfritt) innehåller den lagrade Visual Studio Code-konfigurationen. Mer information finns i Visual Studio Code-inställningar.
function_app.py: Standardplatsen för alla funktioner och deras relaterade utlösare och bindningar.
additional_functions.py: (Valfritt) Alla andra Python-filer som innehåller funktioner (vanligtvis för logisk gruppering) som refereras i function_app.py via skisser.
tests/: (Valfritt) Innehåller testfallen för din funktionsapp.
.funcignore: (Valfritt) Deklarerar filer som inte ska publiceras till Azure. Den här filen innehåller vanligtvis .vscode/ för att ignorera redigeringsinställningen . venv/ för att ignorera lokala virtuella Python-miljöer, tester/ för att ignorera testfall och local.settings.json för att förhindra att lokala appinställningar publiceras.
host.json: Innehåller konfigurationsalternativ som påverkar alla funktioner i en funktionsappinstans. Den här filen publiceras till Azure. Alla alternativ stöds inte när du kör lokalt. Mer information finns i host.json.
local.settings.json: Används för att lagra appinställningar och anslutningssträngar när den körs lokalt. Den här filen publiceras inte till Azure. Mer information finns i local.settings.file.
requirements.txt: Innehåller listan över Python-paket som systemet installerar när det publiceras till Azure.
Dockerfile: (Valfritt) Används när du publicerar projektet i en anpassad container.

När du distribuerar projektet till en funktionsapp i Azure ska hela innehållet i huvudprojektmappen project_root<> ingå i paketet, men inte själva mappen, vilket innebär att host.json ska finnas i paketroten. Vi rekommenderar att du underhåller dina tester i en mapp tillsammans med andra funktioner (i det här exemplet tester/). Mer information finns i Enhetstestning.

Skisser

Programmeringsmodellen Python v2 introducerar begreppet skisser. En skiss är en ny klass som instansieras för att registrera funktioner utanför kärnfunktionsprogrammet. Funktionerna som är registrerade i skissinstanser indexeras inte direkt av funktionskörningen. För att få dessa skissfunktioner indexerade måste funktionsappen registrera funktionerna från skissinstanser.

Användning av skisser ger följande fördelar:

Gör att du kan dela upp funktionsappen i modulära komponenter, vilket gör att du kan definiera funktioner i flera Python-filer och dela upp dem i olika komponenter per fil.
Tillhandahåller utökningsbara gränssnitt för offentliga funktionsappar för att skapa och återanvända dina egna API:er.

I följande exempel visas hur du använder skisser:

I en http_blueprint.py-fil definieras först en HTTP-utlöst funktion och läggs till i ett skissobjekt.

import logging 

import azure.functions as func 

bp = func.Blueprint() 

@bp.route(route="default_template") 
def default_template(req: func.HttpRequest) -> func.HttpResponse: 
    logging.info('Python HTTP trigger function processed a request.') 

    name = req.params.get('name') 
    if not name: 
        try: 
            req_body = req.get_json() 
        except ValueError: 
            pass 
        else: 
            name = req_body.get('name') 

    if name: 
        return func.HttpResponse( 
            f"Hello, {name}. This HTTP-triggered function " 
            f"executed successfully.") 
    else: 
        return func.HttpResponse( 
            "This HTTP-triggered function executed successfully. " 
            "Pass a name in the query string or in the request body for a" 
            " personalized response.", 
            status_code=200 
        )

I filen function_app.py importeras skissobjektet och dess funktioner registreras i funktionsappen.

import azure.functions as func 
from http_blueprint import bp

app = func.FunctionApp() 

app.register_functions(bp)

Importbeteende

Du kan importera moduler i funktionskoden med hjälp av både absoluta och relativa referenser. Baserat på den tidigare beskrivna mappstrukturen fungerar följande importer inifrån funktionsfilen <project_root>\my_first_function\__init__.py:

from shared_code import my_first_helper_function #(absolute)

import shared_code.my_second_helper_function #(absolute)

from . import example #(relative)

Anteckning

När du använder absolut importsyntax måste mappen shared_code/ innehålla en __init__.py-fil för att markera den som ett Python-paket.

Följande __app__ import och därefter relativ import på den översta nivån är inaktuella, eftersom de inte stöds av kontrollen av statisk typ och inte stöds av Python-testramverk:

from __app__.shared_code import my_first_helper_function #(deprecated __app__ import)

from ..shared_code import my_first_helper_function #(deprecated beyond top-level relative import)

Utlösare och indata

Indata är indelade i två kategorier i Azure Functions: utlösarindata och andra indata. Även om de skiljer sig åt i filen function.json är deras användning identisk i Python-kod. Anslutningssträngar eller hemligheter för utlösare och indatakällor mappar till värden i filen local.settings.json när de körs lokalt, och de mappas till programinställningarna när de körs i Azure.

Följande kod visar till exempel skillnaden mellan de två indata:

// function.json
{
  "scriptFile": "__init__.py",
  "bindings": [
    {
      "name": "req",
      "direction": "in",
      "type": "httpTrigger",
      "authLevel": "anonymous",
      "route": "items/{id}"
    },
    {
      "name": "obj",
      "direction": "in",
      "type": "blob",
      "path": "samples/{id}",
      "connection": "AzureWebJobsStorage"
    }
  ]
}

// local.settings.json
{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "python",
    "AzureWebJobsStorage": "<azure-storage-connection-string>"
  }
}

# __init__.py
import azure.functions as func
import logging


def main(req: func.HttpRequest,
         obj: func.InputStream):

    logging.info(f'Python HTTP-triggered function processed: {obj.read()}')

När funktionen anropas skickas HTTP-begäran till funktionen som req. En post hämtas från Azure Blob Storage-kontot baserat på ID:t i väg-URL:en och görs tillgänglig som obj i funktionstexten. Här är det angivna lagringskontot anslutningssträngen som finns i appinställningen AzureWebJobsStorage , vilket är samma lagringskonto som används av funktionsappen.

Indata är indelade i två kategorier i Azure Functions: utlösarindata och andra indata. Även om de definieras med olika dekoratörer är deras användning liknande i Python-kod. Anslutningssträngar eller hemligheter för utlösare och indatakällor mappar till värden i filen local.settings.json när de körs lokalt, och de mappas till programinställningarna när de körs i Azure.

Till exempel visar följande kod hur du definierar en Blob Storage-indatabindning:

// local.settings.json
{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "python",
    "AzureWebJobsStorage": "<azure-storage-connection-string>",
    "AzureWebJobsFeatureFlags": "EnableWorkerIndexing"
  }
}

# function_app.py
import azure.functions as func
import logging

app = func.FunctionApp()

@app.route(route="req")
@app.read_blob(arg_name="obj", path="samples/{id}", connection="AzureWebJobsStorage")

def main(req: func.HttpRequest,
         obj: func.InputStream):
    logging.info(f'Python HTTP-triggered function processed: {obj.read()}')

När funktionen anropas skickas HTTP-begäran till funktionen som req. En post hämtas från Azure Blob Storage-kontot baserat på ID:t i väg-URL:en och görs tillgänglig som obj i funktionstexten. Här är det angivna lagringskontot anslutningssträngen som finns i appinställningen AzureWebJobsStorage, som är samma lagringskonto som används av funktionsappen.

För dataintensiva bindningsåtgärder kanske du vill använda ett separat lagringskonto. Mer information finns i Vägledning för lagringskonto.

För närvarande stöds endast specifika utlösare och bindningar av programmeringsmodellen Python v2. Utlösare och bindningar som stöds är följande:

Typ	Utlösare	Indatabindning	Utdatabindning
HTTP	x
Timer	x
Azure Queue Storage	x		x
Azure Service Bus-ämne	x		x
Azure Service Bus-kö	x		x
Azure Cosmos DB	x	x	x
Azure Blob Storage	x	x	x
Azure Hub	x		x

Fler exempel finns i Python V2-modell Azure Functions utlösare och bindningar (förhandsversion).

Utdata

Utdata kan uttryckas både i returvärden och utdataparametrar. Om det bara finns en utdata rekommenderar vi att du använder returvärdet. För flera utdata måste du använda utdataparametrar.

Om du vill använda returvärdet för en funktion som värdet för en utdatabindning name ska egenskapen för bindningen anges till $return i filen function.json .

Om du vill skapa flera utdata använder du metoden set() som tillhandahålls av azure.functions.Out gränssnittet för att tilldela bindningen ett värde. Följande funktion kan till exempel skicka ett meddelande till en kö och även returnera ett HTTP-svar.

{
  "scriptFile": "__init__.py",
  "bindings": [
    {
      "name": "req",
      "direction": "in",
      "type": "httpTrigger",
      "authLevel": "anonymous"
    },
    {
      "name": "msg",
      "direction": "out",
      "type": "queue",
      "queueName": "outqueue",
      "connection": "AzureWebJobsStorage"
    },
    {
      "name": "$return",
      "direction": "out",
      "type": "http"
    }
  ]
}

import azure.functions as func


def main(req: func.HttpRequest,
         msg: func.Out[func.QueueMessage]) -> str:

    message = req.params.get('body')
    msg.set(message)
    return message

Utdata kan uttryckas både i returvärden och utdataparametrar. Om det bara finns en utdata rekommenderar vi att du använder returvärdet. För flera utdata måste du använda utdataparametrar.

# function_app.py
import azure.functions as func


@app.write_blob(arg_name="msg", path="output-container/{name}",
                connection="AzureWebJobsStorage")

def test_function(req: func.HttpRequest,
                  msg: func.Out[str]) -> str:

    message = req.params.get('body')
    msg.set(message)
    return message

Loggning

Åtkomst till Azure Functions-körningsloggaren är tillgänglig via en rothanterare logging i funktionsappen. Den här loggaren är knuten till Application Insights och gör att du kan flagga varningar och fel som inträffar under funktionskörningen.

I följande exempel loggas ett informationsmeddelande när funktionen anropas via en HTTP-utlösare.

import logging


def main(req):
    logging.info('Python HTTP trigger function processed a request.')

Det finns fler loggningsmetoder som gör att du kan skriva till konsolen på olika spårningsnivåer:

Metod	Beskrivning
`critical(_message_)`	Skriver ett meddelande med nivån KRITISK på rotloggaren.
`error(_message_)`	Skriver ett meddelande med nivåFEL på rotloggaren.
`warning(_message_)`	Skriver ett meddelande med nivå VARNING på rotloggaren.
`info(_message_)`	Skriver ett meddelande med nivåINFORMATION i rotloggaren.
`debug(_message_)`	Skriver ett meddelande med nivå DEBUG på rotloggaren.

Mer information om loggning finns i Övervaka Azure Functions.

Loggning från skapade trådar

Om du vill se loggar som kommer från dina skapade trådar inkluderar du context argumentet i funktionens signatur. Det här argumentet innehåller ett attribut thread_local_storage som lagrar en lokal invocation_id. Detta kan ställas in på funktionens aktuella invocation_id för att säkerställa att kontexten ändras.

import azure.functions as func
import logging
import threading


def main(req, context):
    logging.info('Python HTTP trigger function processed a request.')
    t = threading.Thread(target=log_function, args=(context,))
    t.start()


def log_function(context):
    context.thread_local_storage.invocation_id = context.invocation_id
    logging.info('Logging from thread.')

Logga anpassad telemetri

Som standard samlar Functions-körningen in loggar och andra telemetridata som genereras av dina funktioner. Den här telemetrin hamnar som spårningar i Application Insights. Telemetri för begäranden och beroenden för vissa Azure-tjänster samlas också in som standard av utlösare och bindningar.

Om du vill samla in anpassad begäran och anpassad beroendetelemetri utanför bindningar kan du använda OpenCensus Python-tillägg. Det här tillägget skickar anpassade telemetridata till Application Insights-instansen. Du hittar en lista över tillägg som stöds på OpenCensus-lagringsplatsen.

Anteckning

Om du vill använda OpenCensus Python-tillägg måste du aktivera Python-arbetstillägg i funktionsappen genom att ange PYTHON_ENABLE_WORKER_EXTENSIONS till 1. Du måste också växla till att använda Application Insights-anslutningssträngen APPLICATIONINSIGHTS_CONNECTION_STRING genom att lägga till inställningen i dina programinställningar, om den inte redan finns där.

// requirements.txt
...
opencensus-extension-azure-functions
opencensus-ext-requests

import json
import logging

import requests
from opencensus.extension.azure.functions import OpenCensusExtension
from opencensus.trace import config_integration

config_integration.trace_integrations(['requests'])

OpenCensusExtension.configure()

def main(req, context):
    logging.info('Executing HttpTrigger with OpenCensus extension')

    # You must use context.tracer to create spans
    with context.tracer.span("parent"):
        response = requests.get(url='http://example.com')

    return json.dumps({
        'method': req.method,
        'response': response.status_code,
        'ctx_func_name': context.function_name,
        'ctx_func_dir': context.function_directory,
        'ctx_invocation_id': context.invocation_id,
        'ctx_trace_context_Traceparent': context.trace_context.Traceparent,
        'ctx_trace_context_Tracestate': context.trace_context.Tracestate,
        'ctx_retry_context_RetryCount': context.retry_context.retry_count,
        'ctx_retry_context_MaxRetryCount': context.retry_context.max_retry_count,
    })

HTTP-utlösare

HTTP-utlösaren definieras i filen function.json . Bindningen name måste matcha den namngivna parametern i funktionen . I föregående exempel används ett bindningsnamn req . Den här parametern är ett HttpRequest-objekt och ett HttpResponse-objekt returneras.

Från HttpRequest-objektet kan du hämta begärandehuvuden, frågeparametrar, vägparametrar och meddelandetexten.

Följande exempel kommer från HTTP-utlösarmallen för Python.

def main(req: func.HttpRequest) -> func.HttpResponse:
    headers = {"my-http-header": "some-value"}

    name = req.params.get('name')
    if not name:
        try:
            req_body = req.get_json()
        except ValueError:
            pass
        else:
            name = req_body.get('name')

    if name:
        return func.HttpResponse(f"Hello {name}!", headers=headers)
    else:
        return func.HttpResponse(
             "Please pass a name on the query string or in the request body",
             headers=headers, status_code=400
        )

I den här funktionen hämtar du värdet för name frågeparametern från parametern params för HttpRequest-objektet . Du läser den JSON-kodade meddelandetexten get_json med hjälp av metoden .

På samma sätt kan du ange status_code och headers för svarsmeddelandet i det returnerade HttpResponse-objektet .

HTTP-utlösaren definieras i filen function.json . Bindningen name måste matcha den namngivna parametern i funktionen .

I föregående exempel används ett bindningsnamn req . Den här parametern är ett HttpRequest-objekt och ett HttpResponse-objekt returneras.

Från HttpRequest-objektet kan du hämta begärandehuvuden, frågeparametrar, vägparametrar och meddelandetexten.

Följande exempel kommer från HTTP-utlösarmallen för programmeringsmodellen Python v2. Det är exempelkoden som tillhandahålls när du skapar en funktion med hjälp av Azure Functions Core Tools eller Visual Studio Code.

@app.function_name(name="HttpTrigger1")
@app.route(route="hello")

def test_function(req: func.HttpRequest) -> func.HttpResponse:
     logging.info('Python HTTP trigger function processed a request.')

     name = req.params.get('name')
     if not name:
        try:
            req_body = req.get_json()
        except ValueError:
            pass
        else:
            name = req_body.get('name')

     if name:
        return func.HttpResponse(f"Hello, {name}. This HTTP-triggered function executed successfully.")
     else:
        return func.HttpResponse(
             "This HTTP-triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response.",
             status_code=200
        )

På samma sätt kan du ange status_code och headers för svarsmeddelandet i det returnerade HttpResponse-objektet .

Om du vill skicka ett namn i det här exemplet klistrar du in url:en som angavs när du kör funktionen och lägger sedan till den med "?name={name}".

Webbramverk

Du kan använda ramverk som är kompatibla med Web Server Gateway Interface (WSGI) och ASGI (Asynchronous Server Gateway Interface), till exempel Flask och FastAPI, med dina HTTP-utlösta Python-funktioner. Det här avsnittet visar hur du ändrar dina funktioner för att stödja dessa ramverk.

Först måste filen function.json uppdateras för att inkludera en route i HTTP-utlösaren, som du ser i följande exempel:

{
  "scriptFile": "__init__.py",
  "bindings": [
    {
       "authLevel": "anonymous",
       "type": "httpTrigger",
       "direction": "in",
       "name": "req",
       "methods": [
           "get",
           "post"
       ],
       "route": "{*route}"
    },
    {
       "type": "http",
       "direction": "out",
       "name": "$return"
    }
  ]
}

Filen host.json måste också uppdateras för att inkludera en HTTP routePrefix, som du ser i följande exempel:

{
  "version": "2.0",
  "logging": 
  {
    "applicationInsights": 
    {
      "samplingSettings": 
      {
        "isEnabled": true,
        "excludedTypes": "Request"
      }
    }
  },
  "extensionBundle": 
  {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[3.*, 4.0.0)"
  },
  "extensions": 
  {
    "http": 
    {
        "routePrefix": ""
    }
  }
}

Uppdatera Python-kodfilen init.py, beroende på vilket gränssnitt som används av ditt ramverk. I följande exempel visas antingen en ASGI-hanterarmetod eller en WSGI-omslutningsmetod för Flask:

ASGI
WSGI

app=fastapi.FastAPI()

@app.get("hello/{name}")
async def get_name(
  name: str,):
  return {
      "name": name,}

def main(req: func.HttpRequest, context: func.Context) -> func.HttpResponse:
    return AsgiMiddleware(app).handle(req, context)

app=Flask("Test")

@app.route("hello/<name>", methods=['GET'])
def hello(name: str):
    return f"hello {name}"

def main(req: func.HttpRequest, context) -> func.HttpResponse:
  logging.info('Python HTTP trigger function processed a request.')
  return func.WsgiMiddleware(app).handle(req, context)

Ett fullständigt exempel finns i Använda Flask Framework med Azure Functions.

Du kan använda ASGI-kompatibla (Asynchronous Server Gateway Interface) och WSGI-kompatibla ramverk (Web Server Gateway Interface), till exempel Flask och FastAPI, med dina HTTP-utlösta Python-funktioner. Du måste först uppdatera filen host.json så att den innehåller en HTTP routePrefix, som du ser i följande exempel:

{
  "version": "2.0",
  "logging": 
  {
    "applicationInsights": 
    {
      "samplingSettings": 
      {
        "isEnabled": true,
        "excludedTypes": "Request"
      }
    }
  },
  "extensionBundle": 
  {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[2.*, 3.0.0)"
  },
  "extensions": 
  {
    "http": 
    {
        "routePrefix": ""
    }
  }
}

Ramverkskoden ser ut som i följande exempel:

ASGI
WSGI

AsgiFunctionApp är den översta funktionsappklassen för att konstruera ASGI HTTP-funktioner.

# function_app.py

import azure.functions as func 
from fastapi import FastAPI, Request, Response 

fast_app = FastAPI() 

@fast_app.get("/return_http_no_body") 
async def return_http_no_body(): 
    return Response(content='', media_type="text/plain") 

app = func.AsgiFunctionApp(app=fast_app, 
                           http_auth_level=func.AuthLevel.ANONYMOUS)

WsgiFunctionApp är den översta funktionsappklassen för att konstruera WSGI HTTP-funktioner.

# function_app.py

import azure.functions as func 
from flask import Flask, request, Response, redirect, url_for 

flask_app = Flask(__name__) 
logger = logging.getLogger("my-function") 

@flask_app.get("/return_http") 
def return_http(): 
    return Response('<h1>Hello World™</h1>', mimetype='text/html') 

app = func.WsgiFunctionApp(app=flask_app.wsgi_app, 
                           http_auth_level=func.AuthLevel.ANONYMOUS)

Skalning och prestanda

Metodtips för skalning och prestanda för Python-funktionsappar finns i artikeln Python-skalning och prestanda .

Kontext

Om du vill hämta anropskontexten för en funktion när den context körs tar du med argumentet i dess signatur.

Exempel:

import azure.functions


def main(req: azure.functions.HttpRequest,
         context: azure.functions.Context) -> str:
    return f'{context.invocation_id}'

Klassen Context har följande strängattribut:

Attribut	Beskrivning
`function_directory`	Katalogen där funktionen körs.
`function_name`	Namnet på funktionen.
`invocation_id`	ID för det aktuella funktionsanropet.
`thread_local_storage`	Den lokala trådlagringen för funktionen. Innehåller en lokal `invocation_id` för loggning från skapade trådar.
`trace_context`	Kontexten för distribuerad spårning. Mer information finns i `Trace Context`.
`retry_context`	Kontexten för återförsök till funktionen. Mer information finns i `retry-policies`.

Globala variabler

Det är inte säkert att appens tillstånd bevaras för framtida körningar. Men Azure Functions-körning återanvänder ofta samma process för flera körningar av samma app. Om du vill cachelagra resultatet av en dyr beräkning deklarerar du den som en global variabel.

CACHED_DATA = None


def main(req):
    global CACHED_DATA
    if CACHED_DATA is None:
        CACHED_DATA = load_json()

    # ... use CACHED_DATA in code

Miljövariabler

I Azure Functions exponeras programinställningar, till exempel tjänstanslutningssträngar, som miljövariabler när de körs. Det finns två huvudsakliga sätt att komma åt de här inställningarna i koden.

Metod	Beskrivning
`os.environ["myAppSetting"]`	Försöker hämta programinställningen efter nyckelnamn och genererar ett fel när den misslyckas.
`os.getenv("myAppSetting")`	Försöker hämta programinställningen efter nyckelnamn och returnerar `null` när den misslyckas.

Båda dessa sätt kräver att du deklarerar import os.

I följande exempel används os.environ["myAppSetting"] för att hämta programinställningen med nyckeln med namnet myAppSetting:

import logging
import os
import azure.functions as func

def main(req: func.HttpRequest) -> func.HttpResponse:

    # Get the setting named 'myAppSetting'
    my_app_setting_value = os.environ["myAppSetting"]
    logging.info(f'My app setting value:{my_app_setting_value}')

För lokal utveckling underhålls programinställningarna i filen local.settings.json.

Metod	Beskrivning
`os.environ["myAppSetting"]`	Försöker hämta programinställningen efter nyckelnamn och genererar ett fel när den misslyckas.
`os.getenv("myAppSetting")`	Försöker hämta programinställningen efter nyckelnamn och returnerar `null` när den misslyckas.

Båda dessa sätt kräver att du deklarerar import os.

I följande exempel används os.environ["myAppSetting"] för att hämta programinställningen med nyckeln med namnet myAppSetting:

import logging
import os
import azure.functions as func

@app.function_name(name="HttpTrigger1")
@app.route(route="req")

def main(req: func.HttpRequest) -> func.HttpResponse:


    # Get the setting named 'myAppSetting'
    my_app_setting_value = os.environ["myAppSetting"]
    logging.info(f'My app setting value:{my_app_setting_value}')

För lokal utveckling underhålls programinställningarna i filen local.settings.json.

När du använder den nya programmeringsmodellen aktiverar du följande appinställning i filen local.settings.json , som du ser här:

"AzureWebJobsFeatureFlags": "EnableWorkerIndexing"

När du distribuerar funktionen skapas inte den här inställningen automatiskt. Du måste uttryckligen skapa den här inställningen i funktionsappen i Azure för att den ska kunna köras med hjälp av v2-modellen.

Inställningen för flera Python-arbetare stöds inte i programmeringsmodellen v2 just nu. Det innebär att inställningen FUNCTIONS_WORKER_PROCESS_COUNT till större än 1 inte stöds för funktioner som har utvecklats med hjälp av v2-modellen.

Python-version

Azure Functions stöder följande Python-versioner:

Functions-version	Python*-versioner
4.x	3.10 (förhandsversion) 3.9 3,8 3.7
3.x	3.9 3,8 3.7
2.x	3.7

* Officiella Python-distributioner

Om du vill begära en specifik Python-version när du skapar funktionsappen --runtime-version i Azure använder du alternativet för az functionapp create kommandot . Functions-körningsversionen anges av --functions-version alternativet . Python-versionen anges när funktionsappen skapas och den kan inte ändras för appar som körs i en förbrukningsplan.

Körningen använder den tillgängliga Python-versionen när du kör den lokalt.

Ändra Python-version

Om du vill ange en Python-funktionsapp till en specifik språkversion måste du ange språket och versionen av språket i LinuxFxVersion fältet i platskonfigurationen. Om du till exempel vill ändra Python-appen till att använda Python 3.8 anger du linuxFxVersion till python|3.8.

Information om hur du visar och ändrar webbplatsinställningen linuxFxVersion finns i Så här riktar du dig till Azure Functions körningsversioner.

Mer allmän information finns i supportprincipen för Azure Functions runtime och språk som stöds i Azure Functions.

Pakethantering

När du utvecklar lokalt med hjälp av Core Tools eller Visual Studio Code lägger du till namn och versioner av de nödvändiga paketen i requirements.txt-filen och installerar dem sedan med hjälp pipav .

Du kan till exempel använda följande requirements.txt fil och pip kommando för att installera requests paketet från PyPI.

requests==2.19.1

pip install -r requirements.txt

Publicera i Azure

När du är redo att publicera kontrollerar du att alla dina offentligt tillgängliga beroenden visas i requirements.txt filen. Du kan hitta den här filen i roten i projektkatalogen.

Du hittar projektfilerna och mapparna som undantas från publicering, inklusive mappen för den virtuella miljön, i rotkatalogen för projektet.

Det finns tre build-åtgärder som stöds för publicering av Python-projektet till Azure: fjärrbygge, lokal version och versioner med hjälp av anpassade beroenden.

Du kan också använda Azure Pipelines för att skapa dina beroenden och publicera med hjälp av kontinuerlig leverans (CD). Mer information finns i Kontinuerlig leverans med Azure Pipelines.

Fjärrbygge

När du använder fjärrbygge matchar beroenden som återställs på servern och interna beroenden produktionsmiljön. Detta resulterar i ett mindre distributionspaket att ladda upp. Använd fjärrbygge när du utvecklar Python-appar i Windows. Om projektet har anpassade beroenden kan du använda fjärrversion med extra index-URL.

Beroenden hämtas via fjärranslutning baserat på innehållet i denrequirements.txt filen. Fjärrbygge är den rekommenderade byggmetoden. Som standard begär Core Tools en fjärrversion när du använder följande func azure functionapp publish kommando för att publicera ditt Python-projekt till Azure.

func azure functionapp publish <APP_NAME>

Kom ihåg att ersätta <APP_NAME> med namnet på din funktionsapp i Azure.

Azure Functions-tillägget för Visual Studio Code begär också en fjärrversion som standard.

Lokal version

Beroenden hämtas lokalt baserat på innehållet i denrequirements.txt filen. Du kan förhindra att en fjärrversion utförs med hjälp av följande func azure functionapp publish kommando för att publicera med en lokal version:

func azure functionapp publish <APP_NAME> --build local

Kom ihåg att ersätta <APP_NAME> med namnet på din funktionsapp i Azure.

När du använder --build local alternativet läss projektberoenden från denrequirements.txt filen och de beroende paketen laddas ned och installeras lokalt. Projektfiler och beroenden distribueras från din lokala dator till Azure. Detta resulterar i att ett större distributionspaket laddas upp till Azure. Om du av någon anledning inte kan hämta requirements.txt-filen med hjälp av Core Tools måste du använda alternativet anpassade beroenden för publicering.

Vi rekommenderar inte att du använder lokala versioner när du utvecklar lokalt i Windows.

Anpassade beroenden

När projektet har beroenden som inte finns i Python Package Index finns det två sätt att skapa projektet. Det första sättet, build-metoden , beror på hur du skapar projektet.

Fjärrbygge med extra index-URL

När dina paket är tillgängliga från ett anpassat paketindex som är tillgängligt använder du en fjärrversion. Innan du publicerar måste du skapa en appinställning med namnet PIP_EXTRA_INDEX_URL. Värdet för den här inställningen är URL:en för ditt anpassade paketindex. Med den här inställningen instrueras fjärrversionen att köras pip install med hjälp --extra-index-url av alternativet . Mer information finns i Python-dokumentationenpip install.

Du kan också använda grundläggande autentiseringsuppgifter med dina extra paketindex-URL:er. Mer information finns i Grundläggande autentiseringsuppgifter i Python-dokumentationen.

Installera lokala paket

Om ditt projekt använder paket som inte är offentligt tillgängliga för våra verktyg kan du göra dem tillgängliga för din app genom att placera dem i katalogen __app__/.python_packages . Innan du publicerar kör du följande kommando för att installera beroendena lokalt:

pip install  --target="<PROJECT_DIR>/.python_packages/lib/site-packages"  -r requirements.txt

När du använder anpassade beroenden bör du använda publiceringsalternativet --no-build eftersom du redan har installerat beroendena i projektmappen.

func azure functionapp publish <APP_NAME> --no-build

Kom ihåg att ersätta <APP_NAME> med namnet på din funktionsapp i Azure.

Enhetstestning

Funktioner som skrivs i Python kan testas som annan Python-kod med hjälp av standardtestningsramverk. För de flesta bindningar är det möjligt att skapa ett simulerat indataobjekt genom att skapa en instans av en lämplig klass från azure.functions paketet. azure.functions Eftersom paketet inte är omedelbart tillgängligt måste du installera det via dinrequirements.txt-fil enligt beskrivningen i avsnittet om pakethantering ovan.

Med my_second_function som exempel är följande ett test av en HTTP-utlöst funktion:

Skapa först en <project_root>/my_second_function/function.json-fil och definiera sedan den här funktionen som en HTTP-utlösare.

{
  "scriptFile": "__init__.py",
  "entryPoint": "main",
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "$return"
    }
  ]
}

Sedan kan du implementera my_second_function och shared_code.my_second_helper_function.

# <project_root>/my_second_function/__init__.py
import azure.functions as func
import logging

# Use absolute import to resolve shared_code modules
from shared_code import my_second_helper_function

# Define an HTTP trigger that accepts the ?value=<int> query parameter
# Double the value and return the result in HttpResponse
def main(req: func.HttpRequest) -> func.HttpResponse:
    logging.info('Executing my_second_function.')

    initial_value: int = int(req.params.get('value'))
    doubled_value: int = my_second_helper_function.double(initial_value)

    return func.HttpResponse(
      body=f"{initial_value} * 2 = {doubled_value}",
      status_code=200
    )

# <project_root>/shared_code/__init__.py
# Empty __init__.py file marks shared_code folder as a Python package

# <project_root>/shared_code/my_second_helper_function.py

def double(value: int) -> int:
  return value * 2

Du kan börja skriva testfall för HTTP-utlösaren.

# <project_root>/tests/test_my_second_function.py
import unittest

import azure.functions as func
from my_second_function import main

class TestFunction(unittest.TestCase):
    def test_my_second_function(self):
        # Construct a mock HTTP request.
        req = func.HttpRequest(
            method='GET',
            body=None,
            url='/api/my_second_function',
            params={'value': '21'})

        # Call the function.
        resp = main(req)

        # Check the output.
        self.assertEqual(
            resp.get_body(),
            b'21 * 2 = 42',
        )

I mappen för den virtuella Python-miljön .venv installerar du ditt favorit-Python-testramverk, till exempel pip install pytest. Kör pytest tests sedan för att kontrollera testresultatet.

Skapa först filen project_root>/function_app.py och implementera funktionen som HTTP-utlösare och .<shared_code.my_second_helper_functionmy_second_function

# <project_root>/function_app.py
import azure.functions as func
import logging

# Use absolute import to resolve shared_code modules
from shared_code import my_second_helper_function

app = func.FunctionApp()


# Define the HTTP trigger that accepts the ?value=<int> query parameter
# Double the value and return the result in HttpResponse
@app.function_name(name="my_second_function")
@app.route(route="hello")
def main(req: func.HttpRequest) -> func.HttpResponse:
    logging.info('Executing my_second_function.')

    initial_value: int = int(req.params.get('value'))
    doubled_value: int = my_second_helper_function.double(initial_value)

    return func.HttpResponse(
        body=f"{initial_value} * 2 = {doubled_value}",
        status_code=200
    )

# <project_root>/shared_code/__init__.py
# Empty __init__.py file marks shared_code folder as a Python package

# <project_root>/shared_code/my_second_helper_function.py

def double(value: int) -> int:
  return value * 2

Du kan börja skriva testfall för HTTP-utlösaren.

# <project_root>/tests/test_my_second_function.py
import unittest
import azure.functions as func
from function_app import main


class TestFunction(unittest.TestCase):
    def test_my_second_function(self):
        # Construct a mock HTTP request.
        req = func.HttpRequest(
            method='GET',
            body=None,
            url='/api/my_second_function',
            params={'value': '21'})

        # Call the function.
        func_call = main.build().get_user_function()
        resp = func_call(req)

        # Check the output.
        self.assertEqual(
            resp.get_body(),
            b'21 * 2 = 42',
        )

I mappen för den virtuella Python-miljön .venv installerar du ditt favorit-Python-testramverk, till exempel pip install pytest. Kör pytest tests sedan för att kontrollera testresultatet.

Tillfälliga filer

Metoden tempfile.gettempdir() returnerar en tillfällig mapp som i Linux är /tmp. Ditt program kan använda den här katalogen för att lagra temporära filer som genereras och används av dina funktioner när de körs.

Viktigt

Filer som skrivs till den tillfälliga katalogen kommer inte garanterat att bevaras mellan anrop. Under utskalning delas inte temporära filer mellan instanser.

I följande exempel skapas en namngiven temporär fil i den tillfälliga katalogen (/tmp):

import logging
import azure.functions as func
import tempfile
from os import listdir

#---
   tempFilePath = tempfile.gettempdir()
   fp = tempfile.NamedTemporaryFile()
   fp.write(b'Hello world!')
   filesDirListInTemp = listdir(tempFilePath)

Vi rekommenderar att du underhåller dina tester i en mapp som är separat från projektmappen. Den här åtgärden hindrar dig från att distribuera testkod med din app.

Förinstallerade bibliotek

Några bibliotek levereras med Python Functions-körningen.

Pythons standardbibliotek

Pythons standardbibliotek innehåller en lista över inbyggda Python-moduler som levereras med varje Python-distribution. De flesta av dessa bibliotek hjälper dig att komma åt systemfunktioner, till exempel filindata/utdata (I/O). I Windows-system installeras dessa bibliotek med Python. I Unix-baserade system tillhandahålls de av paketsamlingar.

Om du vill visa biblioteket för din Python-version går du till:

Azure Functions Python-arbetsberoenden

Azure Functions Python Worker kräver en specifik uppsättning bibliotek. Du kan också använda dessa bibliotek i dina funktioner, men de ingår inte i Python-standarden. Om dina funktioner förlitar sig på något av dessa bibliotek kan de vara otillgängliga för din kod när den körs utanför Azure Functions. Du hittar en detaljerad lista över beroenden i avsnittet "install_requires" i setup.py filen.

Anteckning

Om funktionsappens requirements.txt fil innehåller en azure-functions-worker post tar du bort den. Funktionsarbetaren hanteras automatiskt av Azure Functions-plattformen och vi uppdaterar den regelbundet med nya funktioner och felkorrigeringar. Manuellt installation av en gammal arbetsversion i denrequirements.txt filen kan orsaka oväntade problem.

Anteckning

Om paketet innehåller vissa bibliotek som kan kollidera med arbetarberoenden (till exempel protobuf, tensorflow eller grpcio) konfigurerar PYTHON_ISOLATE_WORKER_DEPENDENCIES du till 1 i appinställningarna för att förhindra att ditt program refererar till arbetarberoenden. Den här funktionen är en förhandsversion.

Python-biblioteket Azure Functions

Varje Python-arbetsuppdatering innehåller en ny version av Azure Functions Python-biblioteket (azure.functions). Den här metoden gör det enklare att kontinuerligt uppdatera dina Python-funktionsappar eftersom varje uppdatering är bakåtkompatibel. En lista över versioner av det här biblioteket finns i Azure-Functions PyPi.

Körningsbiblioteksversionen har åtgärdats av Azure och kan inte åsidosättas av requirements.txt. Posten azure-functions i requirements.txt är endast avsedd för linting och kundmedvetenhet.

Använd följande kod för att spåra den faktiska versionen av Python-funktionsbiblioteket i din körning:

getattr(azure.functions, '__version__', '< 1.2.1')

Systembibliotek för körning

En lista över förinstallerade systembibliotek i Docker-avbildningar för Python-arbetare finns i följande:

Functions-körning	Debian-version	Python-versioner
Version 3.x	Buster	Python 3.7 Python 3.8 Python 3.9

Python Worker-tillägg

Med Python-arbetsprocessen som körs i Azure Functions kan du integrera bibliotek från tredje part i funktionsappen. Dessa tilläggsbibliotek fungerar som mellanprogram som kan mata in specifika åtgärder under livscykeln för funktionens körning.

Tillägg importeras i funktionskoden ungefär som en standardmodul för Python-bibliotek. Tillägg körs baserat på följande omfång:

Omfång	Beskrivning
Programnivå	När tillägget importeras till en funktionsutlösare gäller det för varje funktionskörning i appen.
Funktionsnivå	Körningen är begränsad till endast den specifika funktionsutlösare som den importeras till.

Granska informationen för varje tillägg om du vill veta mer om omfånget där tillägget körs.

Tillägg implementerar ett Python Worker-tilläggsgränssnitt. Med den här åtgärden kan Python-arbetsprocessen anropa tilläggskoden under funktionens körningslivscykel. Mer information finns i Skapa tillägg.

Använda tillägg

Du kan använda ett Python Worker-tilläggsbibliotek i dina Python-funktioner genom att göra följande:

Lägg till tilläggspaketet i requirements.txt-filen för projektet.
Installera biblioteket i din app.
Lägg till följande programinställningar:
- Lokalt: Ange "PYTHON_ENABLE_WORKER_EXTENSIONS": "1" i avsnittet i Valuesfilen local.settings.json.
- Azure: Ange PYTHON_ENABLE_WORKER_EXTENSIONS=1 i dina appinställningar.
Importera tilläggsmodulen till funktionsutlösaren.
Konfigurera tilläggsinstansen om det behövs. Konfigurationskrav bör framhävas i tilläggets dokumentation.

Viktigt

Bibliotek för Python-arbetstillägg från tredje part stöds inte eller motiveras inte av Microsoft. Du måste se till att alla tillägg som du använder i funktionsappen är tillförlitliga och att du har den fulla risken att använda ett skadligt eller dåligt skrivet tillägg.

Tredje parter bör tillhandahålla specifik dokumentation om hur de installerar och använder sina tillägg i funktionsappen. Ett grundläggande exempel på hur du använder ett tillägg finns i Använda tillägget.

Här är exempel på hur du använder tillägg i en funktionsapp, efter omfång:

Programnivå
Funktionsnivå

# <project_root>/requirements.txt
application-level-extension==1.0.0

# <project_root>/Trigger/__init__.py

from application_level_extension import AppExtension
AppExtension.configure(key=value)

def main(req, context):
  # Use context.app_ext_attributes here

# <project_root>/requirements.txt
function-level-extension==1.0.0


# <project_root>/Trigger/__init__.py

from function_level_extension import FuncExtension
func_ext_instance = FuncExtension(__file__)

def main(req, context):
  # Use func_ext_instance.attributes here

Skapa tillägg

Tillägg skapas av biblioteksutvecklare från tredje part som har skapat funktioner som kan integreras i Azure Functions. En tilläggsutvecklare utformar, implementerar och släpper Python-paket som innehåller anpassad logik som är särskilt utformad för att köras i samband med funktionskörning. Dessa tillägg kan publiceras antingen till PyPI-registret eller till GitHub-lagringsplatser.

Information om hur du skapar, paketar, publicerar och använder ett Python Worker-tilläggspaket finns i Utveckla Python Worker-tillägg för Azure Functions.

Tillägg på programnivå

Ett tillägg som ärvs från AppExtensionBase körningar i ett programomfång .

AppExtensionBase exponerar följande abstrakta klassmetoder som du kan implementera:

Metod	Beskrivning
`init`	Anropas efter att tillägget har importerats.
`configure`	Anropas från funktionskoden när det behövs för att konfigurera tillägget.
`post_function_load_app_level`	Anropas direkt efter att funktionen har lästs in. Funktionsnamnet och funktionskatalogen skickas till tillägget. Tänk på att funktionskatalogen är skrivskyddad och att alla försök att skriva till en lokal fil i den här katalogen misslyckas.
`pre_invocation_app_level`	Anropas precis innan funktionen utlöses. Argumenten för funktionskontext och funktionsanrop skickas till tillägget. Du kan vanligtvis skicka andra attribut i kontextobjektet som funktionskoden ska använda.
`post_invocation_app_level`	Anropas direkt när funktionskörningen har slutförts. Funktionskontexten, funktionsanropsargumenten och returobjektet för anrop skickas till tillägget. Den här implementeringen är en bra plats för att verifiera om körningen av livscykelhookarna lyckades.

Tillägg på funktionsnivå

Ett tillägg som ärver från FuncExtensionBase körs i en specifik funktionsutlösare.

FuncExtensionBase exponerar följande abstrakta klassmetoder för implementeringar:

Metod	Beskrivning
`__init__`	Konstruktorn för tillägget. Den anropas när en tilläggsinstans initieras i en specifik funktion. När du implementerar den här abstrakta metoden kanske du vill acceptera en `filename` parameter och skicka den till den överordnade metoden `super().__init__(filename)` för korrekt tilläggsregistrering.
`post_function_load`	Anropas direkt efter att funktionen har lästs in. Funktionsnamnet och funktionskatalogen skickas till tillägget. Tänk på att funktionskatalogen är skrivskyddad och att alla försök att skriva till en lokal fil i den här katalogen misslyckas.
`pre_invocation`	Anropas precis innan funktionen utlöses. Argumenten för funktionskontext och funktionsanrop skickas till tillägget. Du kan vanligtvis skicka andra attribut i kontextobjektet som funktionskoden ska använda.
`post_invocation`	Anropas direkt när funktionskörningen har slutförts. Funktionskontexten, funktionsanropsargumenten och returobjektet för anrop skickas till tillägget. Den här implementeringen är en bra plats för att verifiera om körningen av livscykelhookarna lyckades.

Azure Functions stöder resursdelning för korsande ursprung (CORS). CORS konfigureras i portalen och via Azure CLI. Listan över tillåtna CORS-ursprung gäller på funktionsappsnivå. När CORS är aktiverat innehåller Access-Control-Allow-Origin svaren huvudet. Mer information finns i Cross-origin resource sharing.

Resursdelning för korsande ursprung (CORS) stöds fullt ut för Python-funktionsappar.

Asynkrona

Som standard kan en värdinstans för Python endast bearbeta ett funktionsanrop i taget. Det beror på att Python är en enkeltrådad körning. För en funktionsapp som bearbetar ett stort antal I/O-händelser eller är I/O-bunden kan du avsevärt förbättra prestanda genom att köra funktioner asynkront. Mer information finns i Förbättra prestanda för Python-appar i Azure Functions.

Delat minne (förhandsversion)

För att förbättra dataflödet kan Azure Functions låta din out-of-process Python-språkarbetare dela minne med Functions-värdprocessen. När funktionsappen stöter på flaskhalsar kan du aktivera delat minne genom att lägga till en programinställning med namnet FUNCTIONS_WORKER_SHARED_MEMORY_DATA_TRANSFER_ENABLED med värdet 1. När delat minne är aktiverat kan du använda inställningen DOCKER_SHM_SIZE för att ställa in det delade minnet på något i stil 268435456med , vilket motsvarar 256 MB.

Du kan till exempel aktivera delat minne för att minska flaskhalsar när du använder Blob Storage-bindningar för att överföra nyttolaster som är större än 1 MB.

Den här funktionen är endast tillgänglig för funktionsappar som körs i Premium- och Dedicated-planer (Azure App Service). Mer information finns i Delat minne.

Kända problem och vanliga frågor och svar

Här följer två felsökningsguider för vanliga problem:

Här följer två felsökningsguider för kända problem med programmeringsmodellen v2:

Alla kända problem och funktionsbegäranden spåras i en GitHub-problemlista. Om du stöter på ett problem och inte hittar problemet i GitHub öppnar du ett nytt problem och tar med en detaljerad beskrivning av problemet.

Nästa steg

Mer information finns i följande resurser:

Har du problem med att använda Python? Berätta vad som händer.

Python-utvecklarhandbok för Azure Functions

Utvecklingsalternativ

Programmeringsmodell

Alternativ startpunkt

Mappstrukturen

Skisser

Importbeteende

Utlösare och indata

Utdata

Loggning

Loggning från skapade trådar

Logga anpassad telemetri

HTTP-utlösare

Webbramverk

Skalning och prestanda

Kontext

Globala variabler

Miljövariabler

Python-version

Ändra Python-version

Pakethantering

Publicera i Azure

Fjärrbygge

Lokal version

Anpassade beroenden

Fjärrbygge med extra index-URL

Installera lokala paket

Enhetstestning

Tillfälliga filer

Förinstallerade bibliotek

Pythons standardbibliotek

Azure Functions Python-arbetsberoenden

Python-biblioteket Azure Functions

Systembibliotek för körning

Python Worker-tillägg

Använda tillägg

Skapa tillägg

Tillägg på programnivå

Tillägg på funktionsnivå

Cross-origin resource sharing (CORS)

Asynkrona

Delat minne (förhandsversion)

Kända problem och vanliga frågor och svar

Nästa steg

Ytterligare resurser

Ytterligare resurser