Guide des développeurs Python sur Azure FunctionsAzure Functions Python developer guide

Cet article est une introduction au développement d’Azure Functions avec Python.This article is an introduction to developing Azure Functions using Python. Le contenu ci-dessous suppose d’avoir lu le Guide de développement Azure Functions.The content below assumes that you've already read the Azure Functions developers guide.

Pour obtenir des exemples de projets Functions autonomes en Python, consultez les exemples Functions en Python.For standalone Function sample projects in Python, see the Python Functions samples.

Modèle de programmationProgramming model

Azure Functions s’attend à ce qu’une fonction soit une méthode sans état qui traite une entrée et produit une sortie dans un script Python.Azure Functions expects a function to be a stateless method in your Python script that processes input and produces output. Par défaut, le runtime s’attend à ce que la méthode soit implémentée en tant que méthode globale nommée main() dans le fichier __init__.py.By default, the runtime expects the method to be implemented as a global method called main() in the __init__.py file. Vous pouvez également spécifier un autre point d’entrée.You can also specify an alternate entry point.

Les données issues des déclencheurs et des liaisons sont liées à la fonction par des attributs de méthode avec la propriété name qui est définie dans le fichier function.json.Data from triggers and bindings is bound to the function via method attributes using the name property defined in the function.json file. L’exemple de fichier function.json ci-dessous décrit une fonction simple déclenchée par une requête HTTP nommée req :For example, the function.json below describes a simple function triggered by an HTTP request named req:

{
  "bindings": [
    {
      "name": "req",
      "direction": "in",
      "type": "httpTrigger",
      "authLevel": "anonymous"
    },
    {
      "name": "$return",
      "direction": "out",
      "type": "http"
    }
  ]
}

Le fichier __init__.py contient le code de fonction suivant :The __init__.py file contains the following function code:

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

Vous pouvez également déclarer explicitement les types d’attributs et le type de retour dans la fonction à l’aide des annotations de type Python.you can also explicitly declare the attribute types and return type in the function using Python type annotations. L’utilisation des fonctionnalités IntelliSense et de saisie semi-automatique fournies par de nombreux éditeurs de code Python s’en trouve facilitée.This helps you use the intellisense and autocomplete features provided by many Python code editors.

import azure.functions


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

Utilisez les annotations Python incluses dans le package azure.functions.* pour lier des entrées et des sorties à vos méthodes.Use the Python annotations included in the azure.functions.* package to bind input and outputs to your methods.

Autre point d’entréeAlternate entry point

Vous pouvez changer le comportement par défaut d’une fonction en spécifiant éventuellement les propriétés scriptFile et entryPoint dans le fichier function.json.You can change the default behavior of a function by optionally specifying the scriptFile and entryPoint properties in the function.json file. Par exemple, le fichier function.json (voir ci-dessous) indique au runtime d’utiliser la méthode customentry() dans le fichier main.py comme point d’entrée de la fonction Azure.For example, the function.json below tells the runtime to use the customentry() method in the main.py file, as the entry point for your Azure Function.

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

Structure de dossiersFolder structure

La structure de dossiers recommandée d’un projet Python Functions se présente comme l’exemple suivant :The recommended folder structure for a Python Functions project looks like the following example:

 __app__
 | - MyFirstFunction
 | | - __init__.py
 | | - function.json
 | | - example.py
 | - MySecondFunction
 | | - __init__.py
 | | - function.json
 | - SharedCode
 | | - myFirstHelperFunction.py
 | | - mySecondHelperFunction.py
 | - host.json
 | - requirements.txt
 tests

Le dossier principal du projet (__app__) peut contenir les fichiers suivants :The main project folder (__app__) can contain the following files:

  • local.settings.json : Utilisé pour stocker les paramètres d’application et les chaînes de connexion lors d’une exécution locale.local.settings.json: Used to store app settings and connection strings when running locally. Ce fichier n’est pas publié sur Azure.This file doesn't get published to Azure. Pour en savoir plus, consultez la section local.settings.file.To learn more, see local.settings.file.
  • requirements.txt : Contient la liste des packages que le système installe lors de la publication sur Azure.requirements.txt: Contains the list of packages the system installs when publishing to Azure.
  • host.json : Contient les options de configuration globale qui affectent toutes les fonctions d’une application de fonction.host.json: Contains global configuration options that affect all functions in a function app. Ce fichier est publié sur Azure.This file does get published to Azure. Toutes les options ne sont pas prises en charge lors de l’exécution locale.Not all options are supported when running locally. Pour en savoir plus, consultez la section host.json.To learn more, see host.json.
  • .funcignore : (facultatif) déclare des fichiers qui ne devraient pas être publiés dans Azure..funcignore: (Optional) declares files that shouldn't get published to Azure.
  • .gitignore : (facultatif) déclare des fichiers qui sont exclus d’un référentiel git, tel que local.settings.json..gitignore: (Optional) declares files that are excluded from a git repo, such as local.settings.json.

Chaque fonction a son propre fichier de code et son propre fichier de configuration de liaison (function.json).Each function has its own code file and binding configuration file (function.json).

Le code partagé doit être conservé dans un dossier distinct dans __app__.Shared code should be kept in a separate folder in __app__. Pour faire référence à des modules dans le dossier SharedCode, vous pouvez utiliser la syntaxe suivante :To reference modules in the SharedCode folder, you can use the following syntax:

from __app__.SharedCode import myFirstHelperFunction

Si vous voulez faire référence à des modules locaux pour une fonction, vous pouvez utiliser la syntaxe d’importation relative de la façon suivante :To reference modules local to a function, you can use the relative import syntax as follows:

from . import example

Quand vous déployez votre projet vers une application de fonction sur Azure, tout le contenu du dossier FunctionApp (et non le dossier proprement dit) doit être inclus dans le package.When deploying your project to a function app in Azure, the entire content of the FunctionApp folder should be included in the package, but not the folder itself. Nous vous recommandons de conserver vos tests dans un dossier distinct du dossier de projet, dans cet exemple tests.We recommend that you maintain your tests in a folder separate from the project folder, in this example tests. Cela vous évite de déployer du code de test avec votre application.This keeps you from deploying test code with your app. Pour plus d’informations, consultez Test unitaire.For more information, see Unit Testing.

Déclencheurs et entréesTriggers and Inputs

Les entrées sont réparties en deux catégories dans Azure Functions : l’entrée du déclencheur et l’entrée supplémentaire.Inputs are divided into two categories in Azure Functions: trigger input and additional input. Ces entrées sont différentes dans le fichier function.json, mais leur utilisation est identique dans le code Python.Although they are different in the function.json file, usage is identical in Python code. Les chaînes de connexion ou les secrets pour les sources de déclencheur et d’entrée sont mappés aux valeurs dans le fichier local.settings.json lors d’une exécution locale, et aux paramètres d’application lors d’une exécution dans Azure.Connection strings or secrets for trigger and input sources map to values in the local.settings.json file when running locally, and the application settings when running in Azure.

L’exemple de code suivant illustre la différence entre les deux :For example, the following code demonstrates the difference between the two:

// 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()}')

Quand la fonction est appelée, la requête HTTP est passée à la fonction dans req.When the function is invoked, the HTTP request is passed to the function as req. Une entrée est récupérée du Stockage Blob Azure sur la base de l’ID présent dans l’URL de la route, puis elle est mise à disposition comme obj dans le corps de la fonction.An entry will be retrieved from the Azure Blob Storage based on the ID in the route URL and made available as obj in the function body. Ici, le compte de stockage spécifié est la chaîne de connexion trouvée dans le paramètre d’application AzureWebJobsStorage, qui est le même compte de stockage utilisé par l’application de fonction.Here, the storage account specified is the connection string found in the AzureWebJobsStorage app setting, which is the same storage account used by the function app.

OutputsOutputs

Les sorties peuvent être exprimées aussi bien dans une valeur de retour que dans des paramètres de sortie.Output can be expressed both in return value and output parameters. S’il n’y a qu’une seule sortie, nous recommandons d’utiliser la valeur de retour.If there's only one output, we recommend using the return value. Lorsqu’il y en a plusieurs, il est nécessaire d’utiliser les paramètres de sortie.For multiple outputs, you'll have to use output parameters.

Pour utiliser la valeur de retour d’une fonction comme valeur d’une liaison de sortie, la propriété name de la liaison doit être définie sur $return dans function.json.To use the return value of a function as the value of an output binding, the name property of the binding should be set to $return in function.json.

Pour produire plusieurs sorties, utilisez la méthode set() fournie par l’interface azure.functions.Out afin d’affecter une valeur à la liaison.To produce multiple outputs, use the set() method provided by the azure.functions.Out interface to assign a value to the binding. Par exemple, la fonction suivante peut placer un message dans une file d’attente tout en renvoyant une réponse HTTP.For example, the following function can push a message to a queue and also return an HTTP response.

{
  "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

JournalisationLogging

L’accès à l’enregistreur d’événements du runtime d’Azure Functions se fait par l’intermédiaire du gestionnaire logging racine dans l’application de fonction.Access to the Azure Functions runtime logger is available via a root logging handler in your function app. Cet enregistreur, lié à Application Insights, permet de signaler les avertissements et les erreurs générés lors de l’exécution de la fonction.This logger is tied to Application Insights and allows you to flag warnings and errors encountered during the function execution.

L’exemple suivant enregistre un message d’informations lorsque la fonction est appelée avec un déclencheur HTTP.The following example logs an info message when the function is invoked via an HTTP trigger.

import logging


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

Des méthodes d’enregistrement supplémentaires permettent d’écrire dans la console à différents niveaux de trace :Additional logging methods are available that let you write to the console at different trace levels:

MéthodeMethod DescriptionDescription
critical(_message_) Écrit un message de niveau CRITIQUE sur l’enregistreur racine.Writes a message with level CRITICAL on the root logger.
error(_message_) Écrit un message de niveau ERREUR sur l’enregistreur racine.Writes a message with level ERROR on the root logger.
warning(_message_) Écrit un message de niveau AVERTISSEMENT sur l’enregistreur racine.Writes a message with level WARNING on the root logger.
info(_message_) Écrit un message de niveau INFO sur l’enregistreur racine.Writes a message with level INFO on the root logger.
debug(_message_) Écrit un message de niveau DÉBOGAGE sur l’enregistreur racine.Writes a message with level DEBUG on the root logger.

Pour en savoir plus sur la journalisation, consultez Surveiller l’exécution des fonctions Azure.To learn more about logging, see Monitor Azure Functions.

Déclencheur et liaisons HTTPHTTP Trigger and bindings

Le déclencheur HTTP est défini dans le fichier function.jon.The HTTP trigger is defined in the function.jon file. Le name de la liaison doit correspondre au paramètre nommé dans la fonction.The name of the binding must match the named parameter in the function. Dans les exemples précédents, un nom de liaison req est utilisé.In the previous examples, a binding name req is used. Ce paramètre est un objet HttpRequest, et un objet HttpResponse est retourné.This parameter is an HttpRequest object, and an HttpResponse object is returned.

À partir de l’objet HttpRequest, vous pouvez obtenir des en-têtes de demande, des paramètres de requête, des paramètres de route et le corps du message.From the HttpRequest object, you can get request headers, query parameters, route parameters, and the message body.

L’exemple suivant provient du modèle de déclencheur HTTP pour Python.The following example is from the HTTP trigger template for 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
        )

Dans cette fonction, la valeur du paramètre de requête name est obtenue à partir du paramètre params de l’objet HttpRequest.In this function, the value of the name query parameter is obtained from the params parameter of the HttpRequest object. Le corps du message encodé JSON est lu à l’aide de la méthode get_json.The JSON-encoded message body is read using the get_json method.

De même, vous pouvez définir les status_code et headers pour le message de réponse dans l’objet HttpResponse retourné.Likewise, you can set the status_code and headers for the response message in the returned HttpResponse object.

Mise à l’échelle et accès concurrentielScaling and concurrency

Par défaut, Azure Functions surveille automatiquement la charge sur votre application et crée des instances d’hôte supplémentaires pour Python, si nécessaire.By default, Azure Functions automatically monitors the load on your application and creates additional host instances for Python as needed. Functions utilise des seuils intégrés (non configurables par l’utilisateur) pour différents types de déclencheurs pour décider quand ajouter des instances, comme l’ancienneté des messages et la taille de la file d’attente pour QueueTrigger.Functions uses built-in (not user configurable) thresholds for different trigger types to decide when to add instances, such as the age of messages and queue size for QueueTrigger. Pour plus d’informations, consultez Fonctionnement des plans Consommation et Premium.For more information, see How the Consumption and Premium plans work.

Ce comportement de mise à l’échelle est suffisant pour de nombreuses applications.This scaling behavior is sufficient for many applications. Toutefois, les applications présentant l’une des caractéristiques suivantes ne peuvent pas être mises à l’échelle de manière aussi efficace :Applications with any of the following characteristics, however, may not scale as effectively:

  • L’application doit gérer un grand nombre d’appels simultanés.The application needs to handle many concurrent invocations.
  • L’application traite un grand nombre d’événements d’E/S.The application processes a large number of I/O events.
  • L’application est liée aux E/S.The application is I/O bound.

Dans de tels cas, vous pouvez améliorer encore plus les performances en ayant recours à des modèles asynchrones et en utilisant plusieurs processus Worker de langage.In such cases, you can improve performance further by employing async patterns and by using multiple language worker processes.

AsyncAsync

Étant donné que Python est un runtime à thread unique, une instance de l’hôte pour Python ne peut traiter qu’un seul appel de fonction à la fois.Because Python is a single-threaded runtime, a host instance for Python can process only one function invocation at a time. Pour les applications qui traitent un grand nombre d’événements d’E/S et/ou qui sont liés à des E/S, vous pouvez améliorer les performances en exécutant des fonctions de manière asynchrone.For applications that process a large number of I/O events and/or is I/O bound, you can improve performance by running functions asynchronously.

Pour exécuter une fonction de manière asynchrone, utilisez l’instruction async def, qui exécute la fonction avec asyncio directement :To run a function asynchronously, use the async def statement, which runs the function with asyncio directly:

async def main():
    await some_nonblocking_socket_io_op()

Une fonction sans le mot clé async est exécutée automatiquement dans un pool de threads asyncio :A function without the async keyword is run automatically in an asyncio thread-pool:

# Runs in an asyncio thread-pool

def main():
    some_blocking_socket_io()

Utiliser plusieurs processus Worker de langageUse multiple language worker processes

Par défaut, chaque instance d’hôte Functions a un seul processus Worker de langage.By default, every Functions host instance has a single language worker process. Vous pouvez augmenter le nombre de processus Worker par hôte (jusqu’à 10) à l’aide du paramètre d’application FUNCTIONS_WORKER_PROCESS_COUNT.You can increase the number of worker processes per host (up to 10) by using the FUNCTIONS_WORKER_PROCESS_COUNT application setting. Azure Functions essaie ensuite de distribuer uniformément les appels de fonction simultanés à ces différents Workers.Azure Functions then tries to evenly distribute simultaneous function invocations across these workers.

FUNCTIONS_WORKER_PROCESS_COUNT s’applique à chaque hôte créé par Functions lors du scale-out de votre application pour répondre à la demande.The FUNCTIONS_WORKER_PROCESS_COUNT applies to each host that Functions creates when scaling out your application to meet demand.

ContextContext

Pour obtenir le contexte d’appel d’une fonction pendant l’exécution, ajoutez l’argument context à sa signature.To get the invocation context of a function during execution, include the context argument in its signature.

Par exemple :For example:

import azure.functions


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

La classe Contexte contient les attributs de chaîne suivants :The Context class has the following string attributes:

function_directory
Répertoire dans lequel s’exécute la fonction.The directory in which the function is running.

function_name
Nom de la fonction.Name of the function.

invocation_id
ID de l’appel de fonction en cours.ID of the current function invocation.

Variables globalesGlobal variables

L’état de votre application n’est pas systématiquement conservé en vue des exécutions ultérieures.It is not guaranteed that the state of your app will be preserved for future executions. Toutefois, le runtime Azure Functions réutilise souvent le même processus pour plusieurs exécutions de la même application.However, the Azure Functions runtime often reuses the same process for multiple executions of the same app. Pour mettre en cache les résultats d’un calcul coûteux, vous devez le déclarer en tant que variable globale.In order to cache the results of an expensive computation, declare it as a global variable.

CACHED_DATA = None


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

    # ... use CACHED_DATA in code

Variables d'environnementEnvironment variables

Dans Functions, les paramètres de l’application, par exemple, les chaînes de connexion de service, sont exposés en tant que variables d’environnement pendant l’exécution.In Functions, application settings, such as service connection strings, are exposed as environment variables during execution. Vous pouvez accéder à ces paramètres en déclarant import os puis en utilisant setting = os.environ["setting-name"].You can access these settings by declaring import os and then using, setting = os.environ["setting-name"].

L’exemple suivant obtient le paramètre d’application, avec la clé nommée myAppSetting :The following example gets the application setting, with the key named 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}')

Pour le développement local, les paramètres d’application sont conservés dans le fichier local.settings.json.For local development, application settings are maintained in the local.settings.json file.

Version PythonPython version

Actuellement, Azure Functions prend en charge Python 3.6.x et 3.7.x (distributions officielles de CPython).Currently, Azure Functions supports both Python 3.6.x and 3.7.x (official CPython distributions). Lors d’une exécution locale, le runtime utilise la version de Python disponible.When running locally, the runtime uses the available Python version. Pour demander une version de Python particulière lorsque vous créez votre application de fonction dans Azure, utilisez l’option --runtime-version de la commande az functionapp create.To request a specific Python version when you create your function app in Azure, use the --runtime-version option of the az functionapp create command. La modification de version est autorisée uniquement lors de la création d’une Function App.Version change is allowed only on Function App creation.

Gestion des packagesPackage management

Si vous développez en local avec Azure Functions Core Tools ou Visual Studio Code, ajoutez les noms et les versions des packages requis au fichier requirements.txt et installez-les avec pip.When developing locally using the Azure Functions Core Tools or Visual Studio Code, add the names and versions of the required packages to the requirements.txt file and install them using pip.

Par exemple, le fichier de configuration requise suivant et la commande pip permettent d’installer le package requests à partir de PyPI.For example, the following requirements file and pip command can be used to install the requests package from PyPI.

requests==2.19.1
pip install -r requirements.txt

Publier sur AzurePublishing to Azure

Avant de procéder à la publication, vérifiez que toutes les dépendances disponibles publiquement sont listées dans le fichier requirements.txt, situé à la racine de votre répertoire de projet.When you're ready to publish, make sure that all your publicly available dependencies are listed in the requirements.txt file, which is located at the root of your project directory.

Les dossiers et fichiers projet qui sont exclus de la publication, y compris le dossier d’environnement virtuel, sont listés dans le fichier .funcignore.Project files and folders that are excluded from publishing, including the virtual environment folder, are listed in the .funcignore file.

Trois actions de génération sont prises en charge pour la publication de votre projet Python dans Azure :There are three build actions supported for publishing your Python project to Azure:

  • Build distante : les dépendances sont obtenues à distance en fonction du contenu du fichier requirements.txt.Remote build: Dependencies are obtained remotely based on the contents of the requirements.txt file. L’option Build distante est la méthode de génération recommandée.Remote build is the recommended build method. Il s’agit également de l’option de génération par défaut des outils Azure.Remote is also the default build option of Azure tooling.
  • Build locale : les dépendances sont obtenues localement en fonction du contenu du fichier requirements.txt.Local build: Dependencies are obtained locally based on the contents of the requirements.txt file.
  • Dépendances personnalisées : votre projet utilise des packages qui ne sont pas disponibles publiquement pour nos outilsCustom dependencies: Your project uses packages not publicly available to our tools. (nécessite Docker).(Requires Docker.)

Pour générer les dépendances et effectuer la publication au moyen d’un système de livraison continue (CD), utilisez Azure Pipelines.To build your dependencies and publish using a continuous delivery (CD) system, use Azure Pipelines.

Build distanteRemote build

Par défaut, Azure Functions Core Tools demande une build distante lorsque vous utilisez la commande func azure functionapp publish suivante pour publier votre projet Python dans Azure.By default, the Azure Functions Core Tools requests a remote build when you use the following func azure functionapp publish command to publish your Python project to Azure.

func azure functionapp publish <APP_NAME>

Veillez à remplacer <APP_NAME> par le nom de votre application de fonction dans Azure.Remember to replace <APP_NAME> with the name of your function app in Azure.

L’extension Azure Functions pour Visual Studio Code demande également une build distante par défaut.The Azure Functions Extension for Visual Studio Code also requests a remote build by default.

Build localeLocal build

Vous pouvez éviter d’effectuer une build distante en utilisant la commande func azure functionapp publish suivante pour publier avec une build locale.You can prevent doing a remote build by using the following func azure functionapp publish command to publish with a local build.

func azure functionapp publish <APP_NAME> --build local

Veillez à remplacer <APP_NAME> par le nom de votre application de fonction dans Azure.Remember to replace <APP_NAME> with the name of your function app in Azure.

Avec l’option --build local, les dépendances de projet sont lues à partir du fichier requirements.txt et les packages dépendants sont téléchargés et installés localement.Using the --build local option, project dependencies are read from the requirements.txt file and those dependent packages are downloaded and installed locally. Les fichiers de projet et les dépendances sont déployés de votre ordinateur local vers Azure,Project files and dependencies are deployed from your local computer to Azure. ce qui entraîne le chargement d’un package de déploiement plus important sur Azure.This results in a larger deployment package being uploaded to Azure. Si, pour une raison quelconque, les dépendances de votre fichier requirements.txt ne peuvent pas être acquises par Core Tools, vous devez utiliser l’option de dépendances personnalisées pour la publication.If for some reason, dependencies in your requirements.txt file can't be acquired by Core Tools, you must use the custom dependencies option for publishing.

Dépendances personnaliséesCustom dependencies

Si votre projet utilise des packages non disponibles publiquement pour nos outils, vous pouvez les rendre disponibles pour votre application en les plaçant dans le répertoire __app__/.python_packages directory.If your project uses packages not publicly available to our tools, you can make them available to your app by putting them in the __app__/.python_packages directory. Avant d’effectuer la publication, exécutez la commande suivante pour installer les dépendances localement :Before publishing, run the following command to install the dependencies locally:

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

Lors de l’utilisation des dépendances personnalisées, vous devez utiliser l’option de publication --no-build étant donné que vous avez déjà installé les dépendances.When using custom dependencies, you should use the --no-build publishing option, since you have already installed the dependencies.

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

Veillez à remplacer <APP_NAME> par le nom de votre application de fonction dans Azure.Remember to replace <APP_NAME> with the name of your function app in Azure.

Tests unitairesUnit Testing

Les fonctions écrites en Python peuvent être testées comme tout autre code Python à l’aide des frameworks de test standard.Functions written in Python can be tested like other Python code using standard testing frameworks. Pour la plupart des liaisons, il est possible de créer un objet d’entrée factice en créant une instance d’une classe appropriée à partir du package azure.functions.For most bindings, it's possible to create a mock input object by creating an instance of an appropriate class from the azure.functions package. Comme le package azure.functions n’est pas immédiatement disponible, assurez-vous de l’installer via votre fichier requirements.txt, comme décrit dans la section gestion des packages ci-dessus.Since the azure.functions package is not immediately available, be sure to install it via your requirements.txt file as described in the package management section above.

Voici un exemple de test factice d’une fonction déclenchée via HTTP :For example, following is a mock test of an HTTP triggered function:

{
  "scriptFile": "__init__.py",
  "entryPoint": "my_function",
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "$return"
    }
  ]
}
# __app__/HttpTrigger/__init__.py
import azure.functions as func
import logging

def my_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}")
    else:
        return func.HttpResponse(
             "Please pass a name on the query string or in the request body",
             status_code=400
        )
# tests/test_httptrigger.py
import unittest

import azure.functions as func
from __app__.HttpTrigger import my_function

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

        # Call the function.
        resp = my_function(req)

        # Check the output.
        self.assertEqual(
            resp.get_body(),
            b'Hello Test',
        )

Voici un autre exemple, avec une fonction déclenchée d’une file d’attente :Here is another example, with a queue triggered function:

{
  "scriptFile": "__init__.py",
  "entryPoint": "my_function",
  "bindings": [
    {
      "name": "msg",
      "type": "queueTrigger",
      "direction": "in",
      "queueName": "python-queue-items",
      "connection": "AzureWebJobsStorage"
    }
  ]
}
# __app__/QueueTrigger/__init__.py
import azure.functions as func

def my_function(msg: func.QueueMessage) -> str:
    return f'msg body: {msg.get_body().decode()}'
# tests/test_queuetrigger.py
import unittest

import azure.functions as func
from __app__.QueueTrigger import my_function

class TestFunction(unittest.TestCase):
    def test_my_function(self):
        # Construct a mock Queue message.
        req = func.QueueMessage(
            body=b'test')

        # Call the function.
        resp = my_function(req)

        # Check the output.
        self.assertEqual(
            resp,
            'msg body: test',
        )

Fichiers temporairesTemporary files

La méthode tempfile.gettempdir() retourne un dossier temporaire, /tmp sous Linux.The tempfile.gettempdir() method returns a temporary folder, which on Linux is /tmp. Votre application peut utiliser ce répertoire pour stocker les fichiers temporaires générés et utilisés par vos fonctions lors de l’exécution.Your application can use this directory to store temporary files generated and used by your functions during execution.

Important

Il n’est pas garanti que les fichiers écrits dans le répertoire temporaire persistent d’un appel à l’autre.Files written to the temporary directory aren't guaranteed to persist across invocations. Lors de la montée en charge (scale out), les fichiers temporaires ne sont pas partagés entre les instances.During scale out, temporary files aren't shared between instances.

L’exemple suivant crée un fichier temporaire nommé dans le répertoire temporaire (/tmp) :The following example creates a named temporary file in the temporary directory (/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)     

Nous vous recommandons de conserver vos tests dans un dossier distinct du dossier de projet.We recommend that you maintain your tests in a folder separate from the project folder. Cela vous évite de déployer du code de test avec votre application.This keeps you from deploying test code with your app.

Problèmes connus et FAQKnown issues and FAQ

Tous les problèmes connus et les demandes de fonctionnalités sont listés dans Problèmes GitHub.All known issues and feature requests are tracked using GitHub issues list. Si vous rencontrez un problème qui n’apparaît pas dans GitHub, soumettez un nouveau problème en incluant une description détaillée.If you run into a problem and can't find the issue in GitHub, open a new issue and include a detailed description of the problem.

Partage de ressources cross-originCross-origin resource sharing

Azure Functions prend en charge le partage des ressources cross-origin (CORS).Azure Functions supports cross-origin resource sharing (CORS). CORS est configuré dans le portail et par le biais d’Azure CLI.CORS is configured in the portal and through the Azure CLI. La liste des origines autorisées CORS s’applique au niveau de l’application de fonction.The CORS allowed origins list applies at the function app level. Quand CORS est activé, les réponses incluent l’en-tête Access-Control-Allow-Origin.With CORS enabled, responses include the Access-Control-Allow-Origin header. Pour plus d'informations, consultez la page Partage des ressources cross-origin.For more information, see Cross-origin resource sharing.

La liste des origines autorisées n’est pas prise en charge pour les applications de fonction Python.The allowed origins list isn't currently supported for Python function apps. En raison de cette limitation, vous devez définir expressément l’en-tête Access-Control-Allow-Origin dans vos fonctions HTTP, comme indiqué dans l’exemple suivant :Because of this limitation, you must expressly set the Access-Control-Allow-Origin header in your HTTP functions, as shown in the following example:

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

    # Define the allow origin headers.
    headers = {"Access-Control-Allow-Origin": "https://contoso.com"}

    # Set the headers in the response.
    return func.HttpResponse(
            f"Allowed origin '{headers}'.",
            headers=headers, status_code=200
    )

Veillez également à mettre à jour votre fichier function.json pour prendre en charge la méthode HTTP :Make sure that you also update your function.json to support the OPTIONS HTTP method:

    ...
      "methods": [
        "get",
        "post",
        "options"
      ]
    ...

Les navigateurs web utilisent cette méthode HTTP pour négocier la liste des origines autorisées.This HTTP method is used by web browsers to negotiate the allowed origins list.

Étapes suivantesNext steps

Pour plus d’informations, consultez les ressources suivantes :For more information, see the following resources: