Azure Functions Python Developer Guide (Справочник по Функциям Azure для разработчика Python)

Статья
11/14/2023

Это руководство содержит общие сведения о разработке Функции Azure с помощью Python. В статье предполагается, что вы уже ознакомились с руководством разработчиков Функции Azure.

Внимание

Эта статья поддерживает модель программирования версии 1 и версии 2 для Python в Функции Azure. Модель Python версии 1 использует файл functions.json для определения функций, а новая модель версии 2 позволяет вместо этого использовать подход на основе декоратора. Этот новый подход приводит к более простой структуре файлов, и она более ориентирована на код. Выберите селектор версии 2 в верхней части статьи, чтобы узнать об этой новой модели программирования.

Разработчик Python может также заинтересоваться одной из следующих статей:

Начало работы	Основные понятия	Сценарии и примеры
Создание функций Python с помощью Visual Studio Code Создание функций Python с помощью терминала или командной строки	Руководство разработчика Параметры размещения Вопросы производительности	Классификация изображений с помощью PyTorch Пример службы автоматизации Azure Машинное обучение с TensorFlow Обзор примеров Python

Начало работы	Основные понятия	Примеры
Создание функций Python с помощью Visual Studio Code Создание функций Python с помощью терминала или командной строки	Руководство разработчика Параметры размещения Вопросы производительности	Примеры кода

Варианты разработки

Обе модели программирования функций Python поддерживают локальную разработку в одной из следующих сред:

Модель программирования Python версии 2:

Обратите внимание, что модель программирования Python версии 2 поддерживается только в среде выполнения функций 4.x. Дополнительные сведения см. в обзоре версий среды выполнения Функций Azure.

Модель программирования Python версии 1:

Вы также можете создать функции Python версии 1 в портал Azure.

Совет

Хотя вы можете разрабатывать функции Azure на основе Python локально в Windows, Python поддерживается только в плане размещения на основе Linux при работе в Azure. Дополнительные сведения см. в списке поддерживаемых сочетаний операционной системы и среды выполнения.

Модель программирования

Функция Azure должна быть реализована как метод без отслеживания состояния в сценарии Python, который обрабатывает входные данные и создает выходные данные. По умолчанию среда выполнения ожидает, что метод будет реализован в виде глобального метода, вызываемого main()в файле __init__.py . Можно также указать альтернативную точку входа.

Вы привязываете данные к функции из триггеров и привязок с помощью атрибутов метода, использующих свойство, name определенное в файле function.json . Например, следующий файл function.json описывает простую функцию, активированную HTTP-запросом req:

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

На основе этого определения файл __init__.py, содержащий код функции, может выглядеть следующим образом:

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

Также можно явно объявить для функции типы атрибутов и тип возвращаемого значения с помощью аннотации типов Python. Это помогает использовать функции IntelliSense и автозавершения, предоставляемые многими редакторами кода Python.

import azure.functions

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

Используйте заметки Python, включенные в пакет azure.functions.* для привязки входных и выходных данных к методам.

Функция Azure должна быть реализована как метод без отслеживания состояния в сценарии Python, который обрабатывает входные данные и создает выходные данные. По умолчанию среда выполнения ожидает, что метод будет реализован как глобальный метод в файле function_app.py .

Триггеры и привязки можно объявлять и использовать в функции в подходе на основе декоратора. Они определены в том же файле, function_app.py, что и функции. Например, следующий function_app.py-файл представляет триггер функции http-запросом.

@app.function_name(name="HttpTrigger1")
@app.route(route="req")
def main(req):
    user = req.params.get("user")
    return f"Hello, {user}!"

Также можно явно объявить для функции типы атрибутов и тип возвращаемого значения с помощью аннотации типов Python. Это помогает использовать функции IntelliSense и функции автозаполнения, предоставляемые многими редакторами кода Python.

import azure.functions as func

app = func.FunctionApp()

@app.function_name(name="HttpTrigger1")
@app.route(route="req")
def main(req: func.HttpRequest) -> str:
    user = req.params.get("user")
    return f"Hello, {user}!"

Сведения об известных ограничениях модели версии 2 и их обходных решениях см. в статье "Устранение ошибок Python в Функции Azure".

Альтернативная точка входа

Можно изменить поведение функции по умолчанию, при необходимости указав свойства scriptFile и entryPoint в файле function.json. Например, следующая function.json сообщает среде выполнения использовать customentry() метод в файле main.py в качестве точки входа для функции Azure.

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

Точка входа находится только в файле function_app.py . Однако можно ссылаться на функции в проекте в function_app.py с помощью схем или импорта.

Структура папок

Рекомендуемая структура папок для проекта функций Python выглядит следующим образом:

 <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

Основная папка проекта, <project_root>, может содержать следующие файлы:

local.settings.json. Используется для хранения параметров приложения и строка подключения при локальном запуске. Этот файл не публикуется в Azure. Дополнительные сведения см. в разделе local.settings.file.
requirements.txt: содержит список пакетов, которые должны быть установлены при публикации в Azure.
host.json: содержит параметры глобальной конфигурации, влияющие на все функции в экземпляре приложения-функции. Этот файл не публикуется в Azure. При локальном запуске поддерживаются не все параметры. Дополнительные сведения см. в разделе host.json.
VSCODE/: (Необязательно) Содержит хранимую конфигурацию Visual Studio Code. Дополнительные сведения см. в разделе параметров Visual Studio Code.
.venv/: (необязательно) Содержит виртуальную среду Python, используемую локальной разработкой.
Dockerfile: (необязательно) используется при публикации проекта в настраиваемом контейнере.
tests/: (необязательно) Содержит тест-кейсы для вашего приложения-функции.
.funcignore: (необязательно) объявляет файлы, которые не должны публиковаться в Azure. Обычно этот файл содержит vscode/ , чтобы игнорировать параметры редактора, .venv/ , чтобы игнорировать локальную виртуальную среду Python, тесты или игнорировать тестовые случаи и local.settings.json , чтобы предотвратить публикацию параметров локального приложения.

Каждая функция имеет собственный файл кода и файл конфигурации привязки, function.json.

Рекомендуемая структура папок для проекта функций Python выглядит следующим образом:

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

Основная папка проекта, <project_root>, может содержать следующие файлы:

.venv/: (необязательно) Содержит виртуальную среду Python, которая используется локальной разработкой.
VSCODE/: (Необязательно) Содержит хранимую конфигурацию Visual Studio Code. Дополнительные сведения см. в разделе параметров Visual Studio Code.
function_app.py. Расположение по умолчанию для всех функций и связанных с ними триггеров и привязок.
additional_functions.py: (необязательно) Любые другие файлы Python, содержащие функции (обычно для логической группировки), на которые ссылаются function_app.py с помощью схем.
tests/: (необязательно) Содержит тест-кейсы для вашего приложения-функции.
.funcignore: (необязательно) объявляет файлы, которые не должны публиковаться в Azure. Как правило, этот файл содержит vscode/, чтобы игнорировать параметр редактора, venv/, чтобы игнорировать локальную виртуальную среду Python, тесты или игнорировать тестовые случаи и local.settings.json, чтобы предотвратить публикацию параметров локального приложения.
host.json: содержит параметры глобальной конфигурации, влияющие на все функции в экземпляре приложения-функции. Этот файл не публикуется в Azure. При локальном запуске поддерживаются не все параметры. Дополнительные сведения см. в разделе host.json.
local.settings.json. Используется для хранения параметров приложения и строка подключения при локальном запуске. Этот файл не публикуется в Azure. Дополнительные сведения см. в разделе local.settings.file.
requirements.txt. Содержит список пакетов Python, которые система устанавливает при публикации в Azure.
Dockerfile: (необязательно) используется при публикации проекта в настраиваемом контейнере.

При развертывании проекта в приложении-функции в Azure все содержимое основной папки <проекта, project_root>, должно быть включено в пакет, но не в саму папку, что означает, что host.json должен находиться в корневом каталоге пакета. Рекомендуется поддерживать тесты в папке вместе с другими функциями (в этом примере — тесты/). Дополнительные сведения см. в разделе Модульное тестирование.

Соединение с базой данных

Функции Azure хорошо интегрируется с Azure Cosmos DB для многих вариантов использования, включая IoT, электронную коммерцию, игры и т. д.

Например, для источника событий две службы интегрированы в архитектуры, управляемые событиями, с помощью функции канала изменений Azure Cosmos DB. Канал изменений предоставляет нижестоящим микрослужбам возможность надежного и добавочного чтения вставок и обновлений (например, событий заказа). Этот компонент можно использовать в качестве постоянного хранилища событий, то есть брокера сообщений между несколькими микрослужбами, для событий с изменяющимся состоянием и рабочего процесса обработки заказов. Его можно реализовать в виде бессерверного приложения Функций Azure.

Эталонная архитектура конвейера заказов на основе Azure Cosmos DB

Чтобы подключиться к Cosmos DB, сначала создайте учетную запись, базу данных и контейнер. Затем вы можете подключить функции к Cosmos DB с помощью триггеров и привязок, как показано в этом примере.

Для реализации более сложной логики приложения можно также использовать библиотеку Python для Cosmos DB. Реализация операций ввода-вывода выглядит следующим образом:

pip install azure-cosmos
pip install aiohttp

from azure.cosmos.aio import CosmosClient
from azure.cosmos import exceptions
from azure.cosmos.partition_key import PartitionKey
import asyncio

# Replace these values with your Cosmos DB connection information
endpoint = "https://azure-cosmos-nosql.documents.azure.com:443/"
key = "master_key"
database_id = "cosmicwerx"
container_id = "cosmicontainer"
partition_key = "/partition_key"

# Set the total throughput (RU/s) for the database and container
database_throughput = 1000

# Singleton CosmosClient instance
client = CosmosClient(endpoint, credential=key)

# Helper function to get or create database and container
async def get_or_create_container(client, database_id, container_id, partition_key):
    database = await client.create_database_if_not_exists(id=database_id)
    print(f'Database "{database_id}" created or retrieved successfully.')

    container = await database.create_container_if_not_exists(id=container_id, partition_key=PartitionKey(path=partition_key))
    print(f'Container with id "{container_id}" created')
 
    return container
 
async def create_products():
    container = await get_or_create_container(client, database_id, container_id, partition_key)
    for i in range(10):
        await container.upsert_item({
            'id': f'item{i}',
            'productName': 'Widget',
            'productModel': f'Model {i}'
        })
 
async def get_products():
    items = []
    container = await get_or_create_container(client, database_id, container_id, partition_key)
    async for item in container.read_all_items():
        items.append(item)
    return items

async def query_products(product_name):
    container = await get_or_create_container(client, database_id, container_id, partition_key)
    query = f"SELECT * FROM c WHERE c.productName = '{product_name}'"
    items = []
    async for item in container.query_items(query=query, enable_cross_partition_query=True):
        items.append(item)
    return items

async def main():
    await create_products()
    all_products = await get_products()
    print('All Products:', all_products)

    queried_products = await query_products('Widget')
    print('Queried Products:', queried_products)

if __name__ == "__main__":
    asyncio.run(main())

Blueprints

Модель программирования Python версии 2 представляет концепцию схем. Схема — это новый класс, созданный для регистрации функций вне основного приложения-функции. Функции, зарегистрированные в экземплярах схемы, не индексируются непосредственно средой выполнения функции. Чтобы получить индексированные эти функции схемы, приложение-функция должна зарегистрировать функции из экземпляров схемы.

Использование схем обеспечивает следующие преимущества:

Позволяет разбить приложение-функцию на модульные компоненты, что позволяет определять функции в нескольких файлах Python и разделять их на разные компоненты на файл.
Предоставляет расширяемые интерфейсы приложений-функций для создания и повторного использования собственных API.

В следующем примере показано, как использовать схемы:

Во-первых, в файле http_blueprint.py функция с триггером HTTP сначала определяется и добавляется в объект схемы.

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 
        )

Затем в файле function_app.py объект схемы импортируется и его функции регистрируются в приложении-функции.

import azure.functions as func 
from http_blueprint import bp

app = func.FunctionApp() 

app.register_functions(bp)

Примечание.

Устойчивые функции также поддерживает схемы. Чтобы создать схемы для приложений Устойчивые функции, зарегистрируйте оркестрацию, действие и триггеры сущностей и привязки клиента с помощью azure-functions-durableBlueprint класса, как показано здесь. После этого результирующая схема может быть зарегистрирована как обычная. Пример см. в нашем примере .

Поведение при импорте

Вы можете импортировать модули в код функции, используя явные относительные и абсолютные ссылки. На основе ранее описанной структуры папок следующие импорты работают в файле <функции 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)

Примечание.

При использовании абсолютного синтаксиса импорта shared_code/ папка должна содержать файл __init__.py, чтобы пометить его как пакет Python.

Следующие __app__ импорт и за пределами относительного импорта верхнего уровня устарели, так как они не поддерживаются статическим типом проверка er и не поддерживаются платформами тестов Python:

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)

Триггеры и входные данные

Входные данные в Функциях Azure делятся на две категории: входные данные триггеров и другие входные данные. Хотя они отличаются в файле function.json, их использование идентично в коде Python. строки Подключение ion или секреты для триггеров и входных источников сопоставляются со значениями в файле local.settings.json при локальном запуске и сопоставляются с параметрами приложения при их запуске в Azure.

Например, следующий код демонстрирует разницу между двумя входными данными:

// 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": "STORAGE_CONNECTION_STRING"
    }
  ]
}

// local.settings.json
{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "python",
    "STORAGE_CONNECTION_STRING": "<AZURE_STORAGE_CONNECTION_STRING>",
    "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()}')

При активации этой функции HTTP-запрос передается в функцию с помощью req. Запись будет получена из учетной записи Хранилище BLOB-объектов Azure на основе идентификатора в URL-адресе маршрута и доступна как obj в тексте функции. Здесь указанная учетная запись хранения — это строка подключения, найденный в параметре CONNECTION_STRING приложения.

Входные данные в Функциях Azure делятся на две категории: входные данные триггеров и другие входные данные. Хотя они определены с помощью разных декораторов, их использование аналогично в коде Python. строки Подключение ion или секреты для триггеров и входных источников сопоставляются со значениями в файле local.settings.json при локальном запуске и сопоставляются с параметрами приложения при их запуске в Azure.

Например, в следующем коде показано, как определить служба хранилища входную привязку БОЛЬШОго двоичного объекта:

// local.settings.json
{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "python",
    "STORAGE_CONNECTION_STRING": "<AZURE_STORAGE_CONNECTION_STRING>",
    "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="STORAGE_CONNECTION_STRING")
def main(req: func.HttpRequest, obj: func.InputStream):
    logging.info(f'Python HTTP-triggered function processed: {obj.read()}')

Для операций с интенсивной привязкой данных может потребоваться использовать отдельную учетную запись хранения. Дополнительные сведения см. в руководстве по служба хранилища учетной записи.

Выходные данные

Выходные данные можно выразить как возвращаемое значение или параметры вывода. Если используется только один вывод, мы рекомендуем использовать возвращаемое значение. Для нескольких выводов нужно использовать параметры вывода.

Чтобы использовать возвращаемое значение функции в качестве значения выходной привязки, name свойство привязки должно быть задано $return в файле function.json .

Чтобы создать несколько выходных значений, используйте метод set() из интерфейса azure.functions.Out, чтобы присвоить значение привязке. Например, следующая функция может направлять сообщение в очередь и возвращает ответ HTTP.

{
  "scriptFile": "__init__.py",
  "bindings": [
    {
      "name": "req",
      "direction": "in",
      "type": "httpTrigger",
      "authLevel": "anonymous"
    },
    {
      "name": "msg",
      "direction": "out",
      "type": "queue",
      "queueName": "outqueue",
      "connection": "STORAGE_CONNECTION_STRING"
    },
    {
      "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

# function_app.py
import azure.functions as func

app = func.FunctionApp()

@app.write_blob(arg_name="msg", path="output-container/{name}",
                connection="CONNECTION_STRING")
def test_function(req: func.HttpRequest,
                  msg: func.Out[str]) -> str:

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

Ведение журнала

Доступ к средству ведения журнала среды выполнения Функций Azure предоставляется через корневой обработчик logging в приложении-функции. Это средство ведения журнала привязано к Application Insights и позволяет отмечать предупреждения и ошибки, которые возникают во время выполнения функции.

Следующий пример сохраняет в журнал информационное сообщение, когда функция вызывается с помощью триггера HTTP.

import logging

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

Доступны дополнительные методы ведения журнала, которые позволяют выводить сообщения в консоль на разных уровнях трассировки.

Метод	Description
`critical(_message_)`	Записывает сообщение с уровнем CRITICAL в корневое средство ведения журнала.
`error(_message_)`	Записывает сообщение с уровнем ERROR в корневое средство ведения журнала.
`warning(_message_)`	Записывает сообщение с уровнем WARNING в корневое средство ведения журнала.
`info(_message_)`	Записывает сообщение с уровнем INFO в корневое средство ведения журнала.
`debug(_message_)`	Записывает сообщение с уровнем DEBUG в корневое средство ведения журнала.

Дополнительные сведения о ведении журналов см. в статье Мониторинг Функций Azure.

Ведение журнала из созданных потоков

Чтобы просмотреть журналы, поступающие из созданных потоков, добавьте context аргумент в подпись функции. Этот аргумент содержит атрибут thread_local_storage , который сохраняет локальный invocation_id. Это можно задать для текущей invocation_id функции, чтобы убедиться, что контекст изменен.

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.')

Ведение журнала пользовательской телеметрии

По умолчанию среда выполнения Функций собирает журналы и другие данные телеметрии, созданные вашими функциями. Эти данные телеметрии завершаются как трассировки в Application Insights. Данные телеметрии запросов и зависимостей для определенных служб Azure также собираются по умолчанию с помощью триггеров и привязок.

Чтобы получить данные телеметрии пользовательских запросов и зависимостей (не через привязки), можно использовать расширения Python OpenCensus. Это расширение отправляет пользовательские данные телеметрии в ваш экземпляр Application Insights. Список поддерживаемых расширений можно найти в репозитории OpenCensus.

Примечание.

Чтобы использовать расширения Python OpenCensus, необходимо включить расширения рабочих ролей Python в приложении-функции, сменив в настройках PYTHON_ENABLE_WORKER_EXTENSIONS на 1. Кроме того, необходимо переключиться на использование строки подключения Application Insights, добавив APPLICATIONINSIGHTS_CONNECTION_STRING параметр в параметры приложения, если он еще не задан.

// 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

Триггер HTTP определяется в файле function.json. name привязки должен соответствовать именованному параметру в функции. В предыдущих примерах используется имя привязки req. Этот параметр является объектом HttpRequest, и возвращается объект HttpResponse.

Из объекта HttpRequest можно получить заголовки запроса, параметры запроса, параметры маршрута и текст сообщения.

Следующий пример относится к шаблону триггера HTTP для 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
        )

В этой функции вы получаете значение name параметра запроса из params параметра объекта HttpRequest . Текст сообщения в кодировке JSON с помощью get_json метода.

Аналогичным образом можно задать status_code и headers для ответного сообщения в возвращенном объекте HttpResponse.

Триггер HTTP определяется как метод, который принимает именованный параметр привязки, который является объектом HttpRequest и возвращает объект HttpResponse . Примените function_name декоратор к методу для определения имени функции, а конечная точка HTTP устанавливается путем применения route декоратора.

В этом примере используется шаблон триггера HTTP для модели программирования Python версии 2, где имя параметра привязки — req. Это пример кода, который предоставляется при создании функции с помощью Функции Azure Core Tools или 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
        )

Из объекта HttpRequest можно получить заголовки запроса, параметры запроса, параметры маршрута и текст сообщения. В этой функции вы получаете значение name параметра запроса из params параметра объекта HttpRequest . Текст сообщения в кодировке JSON с помощью get_json метода.

Аналогичным образом можно задать status_code и headers для ответного сообщения в возвращенном объекте HttpResponse.

Чтобы передать имя в этом примере, вставьте URL-адрес, предоставленный при запуске функции, а затем добавьте его."?name={name}"

Веб-платформы

Интерфейс шлюза веб-сервера (WSGI)совместимый и асинхронный интерфейс шлюза сервера (ASGI), совместимые с платформами, такими как Flask и FastAPI, с функциями Python с триггером HTTP. В этом разделе показано, как изменить функции для поддержки этих платформ.

Сначала необходимо обновить файл function.json, чтобы включить route его в триггер HTTP, как показано в следующем примере:

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

Файл host.json также должен быть обновлен, чтобы включить HTTProutePrefix, как показано в следующем примере:

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

Обновите файл кода Python init.py в зависимости от интерфейса, используемого платформой. В следующем примере показан подход с использованием обработчика ASGI или подход с использованием WSGI-оболочки для 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 func.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)

Полный пример см. в статье Использованием платформы Flask с функциями Azure.

Вы можете использовать платформы, совместимые с асинхронным интерфейсом шлюза сервера (ASGI) и интерфейсом шлюза веб-сервера (WSGI), совместимыми с Flask и FastAPI, с функциями Python, активировав HTTP. Сначала необходимо обновить файл host.json , чтобы включить HTTP routePrefix, как показано в следующем примере:

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

Код платформы выглядит следующим образом:

ASGI
WSGI

AsgiFunctionApp — это класс приложения-функции верхнего уровня для создания функций HTTP ASGI.

# 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 — это класс приложения-функции верхнего уровня для создания функций HTTP WSGI.

# function_app.py

import azure.functions as func 
from flask import Flask, Response 

flask_app = Flask(__name__) 

@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)

Масштабирование и производительность

Рекомендации по масштабированию и производительности приложений-функций Python см. в статье о масштабировании и производительности Python.

Контекст

Чтобы получить контекст вызова функции при запуске, добавьте context аргумент в подпись.

Например:

import azure.functions


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

Класс Context имеет следующие строковые атрибуты:

Атрибут	Description
`function_directory`	Каталог, в котором выполняется функция.
`function_name`	Имя функции.
`invocation_id`	Идентификатор вызова текущей функции.
`thread_local_storage`	Локальное хранилище потока функции. Содержит локальный `invocation_id` объект для ведения журнала из созданных потоков.
`trace_context`	Контекст распределенной трассировки. Дополнительные сведения см. в разделе `Trace Context`.
`retry_context`	Контекст повторных попыток в функцию. Дополнительные сведения см. в разделе `retry-policies`.

Глобальные переменные

Не гарантируется, что состояние приложения будет сохранено для будущих выполнений. Однако среда выполнения Функций Azure часто использует один и тот же процесс для нескольких выполнений одного и того же приложения. Чтобы кэшировать результаты дорогостоящих вычислений, объявите его как глобальную переменную.

CACHED_DATA = None


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

    # ... use CACHED_DATA in code

Переменные среды

В Функции Azure параметры приложения, такие как строка подключения службы, предоставляются в виде переменных среды при выполнении. Эти параметры в вашем коде доступны двумя основными способами.

Метод	Description
`os.environ["myAppSetting"]`	Пытается получить параметр приложения по имени ключа и вызывает ошибку при неудачном выполнении.
`os.getenv("myAppSetting")`	Пытается получить параметр приложения по имени ключа и возвращается `null` , когда это не удалось.

Оба этих способа должны объявляться import os.

В следующем примере используется os.environ["myAppSetting"] для получения параметра приложения по ключу с именем 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}')

Для локальной разработки параметры приложения сохраняются в файле local.settings.json.

Метод	Description
`os.environ["myAppSetting"]`	Пытается получить параметр приложения по имени ключа и вызывает ошибку при неудачном выполнении.
`os.getenv("myAppSetting")`	Пытается получить параметр приложения по имени ключа и возвращается `null` , когда это не удалось.

Оба этих способа должны объявляться import os.

import logging
import os

import azure.functions as func

app = func.FunctionApp()

@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}')

Для локальной разработки параметры приложения сохраняются в файле local.settings.json.

При использовании новой модели программирования включите следующий параметр приложения в файле local.settings.json , как показано ниже:

"AzureWebJobsFeatureFlags": "EnableWorkerIndexing"

При развертывании функции этот параметр не создается автоматически. Этот параметр необходимо явно создать в приложении-функции в Azure, чтобы он выполнялся с помощью модели версии 2.

Python version

Функции Azure поддерживают следующие версии Python:

Версия службы "Функции"	Версии Python*
4.x	3.11 3,10 3,9 3,8 3,7
3.x	3,9 3,8 3,7

* Официальные дистрибутивы Python

Чтобы запросить конкретную версию Python при создании приложения-функции в Azure, используйте параметр --runtime-version команды az functionapp create. Версия среды выполнения функций задается параметром --functions-version. Версия Python устанавливается при создании приложения-функции и не может быть изменена для приложений, работающих в плане потребления.

Среда выполнения использует доступную версию Python при локальном запуске.

Изменение версии Python

Чтобы установить приложение-функцию Python для определенной версии языка, необходимо указать язык и версию языка в LinuxFxVersion поле в конфигурации сайта. Например, чтобы изменить приложение Python на использование Python 3.8, установите значение linuxFxVersionpython|3.8.

Сведения о том, как просматривать и изменять параметры сайта, см. в статье "Как настроить целевые linuxFxVersion версии среды выполнения Функции Azure".

Дополнительные сведения см. в политике поддержки среды выполнения Функции Azure и поддерживаемых языках в Функции Azure.

Управление пакетами

При локальной разработке с помощью основных средств или Visual Studio Code добавьте имена и версии необходимых пакетов в файл requirements.txt , а затем установите их с помощью pip.

Например, можно использовать следующий файл requirements.txt и pip команду для установки requests пакета из PyPI.

requests==2.19.1

pip install -r requirements.txt

При выполнении функций в плане Служба приложений зависимости, определенные в requirements.txt, имеют приоритет над встроенными модулями Python, такими какlogging. Это приоритет может привести к конфликтам, если встроенные модули имеют те же имена, что и каталоги в коде. При выполнении плана потребления или плана Elastic Premium конфликты могут быть менее вероятными, так как зависимости по умолчанию не определяются приоритетами.

Чтобы предотвратить проблемы, выполняемые в плане Служба приложений, не назовите каталоги так же, как и любые собственные модули Python и не включают собственные библиотеки Python в файл requirements.txt проекта.

Публикация в Azure

Когда все будет готово к публикации, убедитесь, что все общедоступные зависимости перечислены в файле requirements.txt. Этот файл можно найти в корне каталога проекта.

Файлы и папки проекта, исключенные из публикации, включая папку виртуальной среды, можно найти в корневом каталоге проекта.

Для публикации проекта Python в Azure поддерживаются три действия сборки: удаленная сборка, локальная сборка и сборки с использованием пользовательских зависимостей.

Вы также можете использовать Azure Pipelines для создания зависимостей и публикации с помощью непрерывной поставки (CD). Дополнительные сведения см. в статье о непрерывной доставке с помощью Azure Pipelines.

Удаленная сборка

При использовании удаленной сборки зависимости, которые восстанавливаются на сервере и собственных зависимостях, соответствуют рабочей среде. Это приводит к уменьшению размера пакета развертывания. Используйте удаленную сборку при разработке приложений Python в Windows. Если в проекте есть пользовательские зависимости, можно использовать удаленную сборку с дополнительным URL-адресом индекса.

Зависимости получаются удаленно на основе содержимого файла requirements.txt. В качестве рекомендуемого метода сборки рекомендуется использовать удаленную сборку. По умолчанию Core Tools запрашивает удаленную сборку при использовании следующей func azure functionapp publish команды для публикации проекта Python в Azure.

func azure functionapp publish <APP_NAME>

Не забудьте заменить <APP_NAME> именем приложения-функции, размещенного в Azure.

Расширение Функций Azure для Visual Studio Code также запрашивает удаленную сборку по умолчанию.

Локальная сборка

Зависимости получаются локально на основе содержимого файла requirements.txt. Вы можете предотвратить выполнение удаленной сборки с помощью следующей func azure functionapp publish команды для публикации с помощью локальной сборки:

func azure functionapp publish <APP_NAME> --build local

Не забудьте заменить <APP_NAME> именем приложения-функции, размещенного в Azure.

При использовании --build local параметра зависимости проекта считываются из файла requirements.txt , а эти зависимые пакеты загружаются и устанавливаются локально. Файлы проекта и зависимости развертываются с локального компьютера в Azure. Это приводит к увеличению пакета развертывания, отправляемого в Azure. Если по какой-то причине вы не можете получить файл requirements.txt с помощью основных инструментов, необходимо использовать параметр пользовательских зависимостей для публикации.

При локальной разработке в Windows не рекомендуется использовать локальные сборки.

Настраиваемые зависимости.

Если в проекте есть зависимости, которые не найдены в индексе пакетов Python, можно создать проект двумя способами. Первый способ, метод сборки, зависит от того, как вы создаете проект.

Удаленная сборка с дополнительным URL-адресом индекса

Если пакеты доступны из доступного индекса настраиваемого пакета, используйте удаленную сборку. Перед публикацией обязательно создайте параметр приложения с именем PIP_EXTRA_INDEX_URL. Значение этого параметра — это URL-адрес пользовательского индекса пакета. При использовании этого параметра удаленная сборка будет выполняться pip install с помощью --extra-index-url параметра. Дополнительные сведения см. в документации по Pythonpip install.

Вы также можете использовать учетные данные обычной проверки подлинности с дополнительными URL-адресами индексов пакетов. Дополнительные сведения см . в документации по Python по базовым учетным данным проверки подлинности.

Установка локальных пакетов

Если в проекте используются пакеты, которые недоступны для наших инструментов, их можно сделать доступными для приложения, поместив их в каталог __app__/.python_packages . Перед публикацией выполните следующую команду, чтобы установить зависимости локально:

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

При использовании пользовательских зависимостей следует использовать --no-build параметр публикации, так как вы уже установили зависимости в папку проекта.

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

Не забудьте заменить <APP_NAME> именем приложения-функции, размещенного в Azure.

Модульное тестирование

Функции, написанные на Python, можно протестировать, как и другой код Python с помощью стандартных платформ тестирования. Для большинства привязок можно создать макет объекта ввода, создав экземпляр соответствующего класса из пакета azure.functions. azure.functions Так как пакет недоступен сразу же, не забудьте установить его с помощью файла requirements.txt, как описано в разделе управления пакетами выше.

При использовании my_second_function в качестве примера ниже приведен макетный тест функции, активируемой HTTP:

Сначала создайте <файл project_root>/my_second_function/function.json , а затем определите эту функцию как триггер HTTP.

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

Далее можно реализовать my_second_function и 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

Вы можете начать писать тестовые случаи для триггера HTTP.

# <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',)

В папке виртуальной среды Python venv установите любимую платформу тестов Python, напримерpip install pytest. Затем выполните команду pytest tests, чтобы проверить результат тестирования.

Сначала создайте файл project_root/function_app.py и реализуйте <функцию my_second_function в качестве триггера HTTP и shared_code.my_second_helper_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

Вы можете начать писать тестовые случаи для триггера HTTP.

# <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',
    )

Временные файлы

Метод tempfile.gettempdir() возвращает временную папку. В Linux это /tmp. Приложение может использовать этот каталог для хранения временных файлов, созданных и используемых функциями при их запуске.

Внимание

Файлы, записанные во временный каталог, не всегда сохраняются между вызовами. Во время масштабирования временные файлы не используются совместно экземплярами.

В следующем примере показано создание именованного временного файла во временном каталоге (/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)

Тесты рекомендуется хранить в папке, отдельной от папки проекта. Это действие позволяет не развертывать тестовый код в приложении.

Предустановленные библиотеки

Некоторые библиотеки входят в среду выполнения функций Python.

Стандартная библиотека Python

Стандартная библиотека Python содержит список встроенных модулей Python, которые поставляются с каждым дистрибутивом Python. Большинство этих библиотек помогают получить доступ к системным функциям, таким как входные и выходные данные файлов (ввода-вывода). В системах Windows эти библиотеки устанавливаются с Python. В системах под управлением Unix они предоставляются коллекциями пакетов.

Чтобы просмотреть библиотеку для версии Python, перейдите к следующим причинам:

Зависимости рабочих ролей Python в функциях Azure

Для рабочей роли Python Функции Azure требуется определенный набор библиотек. Эти библиотеки также можно использовать в функциях, но они не являются частью стандарта Python. Если функции полагаются на любую из этих библиотек, они могут быть недоступны для кода при запуске вне Функции Azure. Вы найдете подробный список зависимостей в разделе "install_requires" файла setup.py .

Примечание.

Если файл requirements.txt приложения-функции содержит запись azure-functions-worker, удалите ее. Рабочая роль функций автоматически управляется платформой Функции Azure, и мы регулярно обновляем ее с помощью новых функций и исправлений ошибок. Установка старой версии рабочей роли в файле requirements.txt может привести к непредвиденным проблемам.

Примечание.

Если пакет содержит определенные библиотеки, которые могут столкнуться с зависимостями рабочей роли (например, protobuf, tensorflow или grpcio), настройте их PYTHON_ISOLATE_WORKER_DEPENDENCIES1 в параметрах приложения, чтобы предотвратить обращение приложения к зависимостям рабочей роли.

Библиотека Python Функции Azure

Каждое обновление рабочей роли Python включает новую версию библиотеки Python Функции Azure (azure.functions). Такой подход упрощает непрерывное обновление приложений-функций Python, так как каждое обновление имеет обратную совместимость. Список выпусков этой библиотеки см. в azure-functions PyPi.

Версия библиотеки среды выполнения исправлена Azure, и ее нельзя переопределить requirements.txt. Запись azure-functions в файле requirements.txt относится только к анализу кода и предоставлена к сведению клиентов.

Используйте следующий код для отслеживания фактической версии библиотеки функций Python в среде выполнения:

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

Системные библиотеки среды выполнения

Список предварительно установленных системных библиотек в образах Docker рабочей роли Python см. в следующих статьях:

Functions runtime (Среда выполнения функций)	Версия Debian	Версии Python
Версия 3.x	Buster	Python 3.7. Python 3.8 Python 3.9

Расширения для рабочей роли Python

Процесс рабочей роли Python, который выполняется в Функциях Azure, позволяет интегрировать в приложение-функцию библиотеки сторонних поставщиков. Эти библиотеки расширений выполняют роль ПО промежуточного слоя для добавления определенных операций в жизненный цикл выполнения функции.

Расширения импортируются в коде функции примерно так же, как и стандартные модули библиотек Python. Расширения выполняются на основе следующих область:

Scope	Description
Уровень приложения	Если расширение импортируется в любом триггере функции, оно применяется ко всем выполнениям этой функции в приложении.
уровень функции.	Выполнение ограничивается только тем триггером функции, в котором импортируется расширение.

Просмотрите сведения о каждом расширении, чтобы узнать больше о область, в которой выполняется расширение.

Расширения реализуют интерфейс расширения рабочей роли Python. Это действие позволяет рабочему процессу Python вызывать код расширения во время жизненного цикла выполнения функции. Дополнительные сведения см. в статье "Создание расширений".

Применение расширений

Вы можете использовать библиотеку расширения рабочей роли Python в функциях Python, выполнив следующие действия:

Добавьте пакет расширений в файл requirements.txt для проекта.
Установите библиотеку в приложение.
Добавьте следующие параметры приложения:
- Локально: введите "PYTHON_ENABLE_WORKER_EXTENSIONS": "1"Values раздел файла local.settings.json.
- Azure: введите PYTHON_ENABLE_WORKER_EXTENSIONS=1 параметры приложения.
Импортируйте модуль расширения в триггер функции.
Настройте экземпляр расширения, если нужно. Заранее выясните требования к конфигурации, изучив документацию по расширению.

Внимание

Сторонние библиотеки рабочих расширений Python не поддерживаются и не гарантируются корпорацией Майкрософт. Необходимо убедиться, что все расширения, используемые в приложении-функции, являются надежными, и вы несете полный риск использования вредоносного или плохо написанного расширения.

Сторонние организации должны предоставить конкретную документацию по установке и использованию расширений в приложении-функции. Простой пример см. в разделе Использование расширения.

По этим ссылкам вы можете ознакомиться с применением расширений с разной областью действия в приложении-функции:

Уровень приложения
уровень функции.

# <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

Создание расширений

Расширения создаются сторонними разработчиками библиотек, которые предоставляют функции с поддержкой интеграции в Функциях Azure. Разработчик расширения самостоятельно проектирует, реализует и публикует пакеты Python, которые содержат специализированную логику для работы в контексте выполнения функций. Эти расширения могут публиковаться через реестр PyPI или репозитории GitHub.

Дополнительные сведения о создании, упаковке, публикации и использовании пакетов расширений для рабочей роли Python см. в статье Разработка рабочих расширений Python для Функций Azure.

Расширения уровня приложения

Расширение, унаследованное от AppExtensionBase запусков в область приложения.

AppExtensionBase предоставляет следующие абстрактные методы класса, которые вам нужно реализовать.

Метод	Description
`init`	Вызывается после завершения импорта расширения.
`configure`	Вызывается из кода функции, когда нужно настроить расширение.
`post_function_load_app_level`	Вызывается сразу после загрузки функции. В расширение передаются параметры с именем функции и каталогом, где она размещается. Помните, что каталог функций доступен только для чтения, и любая попытка записи в локальный файл в этом каталоге завершается ошибкой.
`pre_invocation_app_level`	Вызывается прямо перед активацией функции. В расширение передаются контекст функции и аргументы, указанные в вызове функции. Обычно вы также можете передавать другие атрибуты в объекте контекста, чтобы использовать их в коде функции.
`post_invocation_app_level`	Вызывается сразу после завершения выполнения функции. В расширение передаются контекст функции, аргументы вызова функции и возвращаемый объект вызова. Эта реализация очень удобна для проверки, успешно ли применены перехватчики жизненного цикла.

Расширения уровня функции

Расширение, наследуемое от FuncExtensionBase, выполняется только в определенном триггере функции.

FuncExtensionBase предоставляет следующие абстрактные методы класса, которые вам нужно реализовать.

Метод	Description
`__init__`	Конструктор расширения. Он вызывается при инициализации экземпляра приложения для конкретной функции. При реализации этого абстрактного метода может потребоваться принять `filename` параметр и передать его методу родительского объекта `super().__init__(filename)` для правильной регистрации расширений.
`post_function_load`	Вызывается сразу после загрузки функции. В расширение передаются параметры с именем функции и каталогом, где она размещается. Помните, что каталог функций доступен только для чтения, и любая попытка записи в локальный файл в этом каталоге завершается ошибкой.
`pre_invocation`	Вызывается прямо перед активацией функции. В расширение передаются контекст функции и аргументы, указанные в вызове функции. Обычно вы также можете передавать другие атрибуты в объекте контекста, чтобы использовать их в коде функции.
`post_invocation`	Вызывается сразу после завершения выполнения функции. В расширение передаются контекст функции, аргументы вызова функции и возвращаемый объект вызова. Эта реализация очень удобна для проверки, успешно ли применены перехватчики жизненного цикла.

Функции Azure поддерживают общий доступ к ресурсам независимо от источника (CORS). CORS настраивается на портале и через Azure CLI. Список разрешенных источников CORS применяется на уровне приложения-функции. При включении CORS ответы включают заголовок Access-Control-Allow-Origin. Дополнительные сведения см. в статье об общем доступе к ресурсам независимо от источника.

Общий доступ к ресурсам между источниками (CORS) полностью поддерживается для приложений-функций Python.

Асинхронная

По умолчанию экземпляр узла для Python может одновременно обрабатывать только один вызов функции. Это связано с тем, что Python является однопоточной средой выполнения. Для приложения-функции, обрабатывающего большое количество событий ввода-вывода и (или) связанных с вводом-выводом, можно повысить производительность, выполняя функции асинхронно. Подробную информацию см. в статье Повышение производительности приложений Python в Функциях Azure.

Общая память (предварительная версия)

Чтобы повысить пропускную способность, Функции Azure позволяет внепроцессной рабочей роли Python делиться памятью с узлом Функций. Когда приложение-функция достигает узких мест, вы можете включить общую память, добавив параметр приложения с именем FUNCTIONS_WORKER_SHARED_MEMORY_DATA_TRANSFER_ENABLED со значением 1. После включения общей памяти можно использовать параметр DOCKER_SHM_SIZE, чтобы задать общий объем памяти подобно 268435456, что эквивалентно 256 МБ.

Например, можно включить общую память для уменьшения узких мест при использовании привязок больших двоичных объектов служба хранилища для передачи полезных данных размером более 1 МБ.

Эта функция доступна только для приложений-функций, работающих в планах "Премиум" и "Выделенный" (приложение Azure служба). Дополнительные сведения см. в разделе Общая память.

Известные проблемы и часто задаваемые вопросы

Ниже приведены два руководства по устранению распространенных проблем:

Ниже приведены два руководства по устранению известных проблем с моделью программирования версии 2.

Все известные проблемы и запросы функций отслеживаются в списке проблем GitHub. Если возникла проблема и не удается найти проблему в GitHub, откройте новую проблему и включите подробное описание проблемы.

Следующие шаги

Дополнительные сведения см. на следующих ресурсах:

Проблемы с использованием Python? Расскажите нам, что происходит.

Azure Functions Python Developer Guide (Справочник по Функциям Azure для разработчика Python)

Варианты разработки

Модель программирования

Альтернативная точка входа

Структура папок

Соединение с базой данных

Blueprints

Поведение при импорте

Триггеры и входные данные

Выходные данные

Ведение журнала

Ведение журнала из созданных потоков

Ведение журнала пользовательской телеметрии

Триггер HTTP

Веб-платформы

Масштабирование и производительность

Контекст

Глобальные переменные

Переменные среды

Python version

Изменение версии Python

Управление пакетами

Публикация в Azure

Удаленная сборка

Локальная сборка

Настраиваемые зависимости.

Удаленная сборка с дополнительным URL-адресом индекса

Установка локальных пакетов

Модульное тестирование

Временные файлы

Предустановленные библиотеки

Стандартная библиотека Python

Зависимости рабочих ролей Python в функциях Azure

Библиотека Python Функции Azure

Системные библиотеки среды выполнения

Расширения для рабочей роли Python

Применение расширений

Создание расширений

Расширения уровня приложения

Расширения уровня функции

Предоставление общего доступа к ресурсам независимо от источника

Асинхронная

Общая память (предварительная версия)

Известные проблемы и часто задаваемые вопросы

Следующие шаги

Дополнительные ресурсы