Référence Azure Functions Core Tools

  • Article

Cet article fournit une documentation de référence pour le Azure Functions Core Tools, qui vous permet de développer, de gérer et de déployer des projets Azure Functions à partir de votre ordinateur local. Pour plus d’informations sur l’utilisation de Core Tools, consultez Utiliser Azure Functions Core Tools.

Les commandes des outils principaux sont organisées dans les contextes suivants, chacun fournissant un ensemble unique d’actions.

Contexte de commande Description
func Commandes utilisées pour créer et exécuter des fonctions sur votre ordinateur local.
func azure Commandes permettant d’utiliser des ressources Azure, notamment la publication.
func azurecontainerapps Déployez une application de fonction conteneurisée sur Azure Container Apps.
func durable Commandes permettant d’utiliser Durable Functions.
func extensions Commandes pour l’installation et la gestion des extensions.
func kubernetes Commandes pour travailler avec Kubernetes et Azure Functions.
func settings Commandes pour la gestion des paramètres d’environnement pour l’hôte Functions local.
func templates Commandes pour répertorier les modèles de fonction disponibles.

Avant d’utiliser les commandes de cet article, vous devez installer Core Tools.

func init

Crée un projet de fonctions dans un langage spécifique.

func init <PROJECT_FOLDER>

Lorsque vous fournissez <PROJECT_FOLDER>, le projet est créé dans un nouveau dossier portant ce nom. Sinon, le dossier actif est initialisé.

func init prend en charge les options suivantes, qui, sauf indication contraire, ne prend pas en charge la version 1.x :

Option Description
--csx Crée des fonctions .NET en tant que script C#, ce qui correspond au comportement de la version 1.x. Valide uniquement avec --worker-runtime dotnet.
--docker Crée un fichier Dockerfile pour un conteneur à l’aide d’une image de base définie par le --worker-runtime choisi. Utilisez cette option lorsque vous envisagez le déploiement d’une application de fonction conteneurisée.
--docker-only Ajoute un fichier Dockerfile à un projet existant. Demande le runtime Worker s’il n’est pas spécifié ou défini dans local.settings.json. Utilisez cette option lorsque vous souhaitez déployer une application de fonction conteneurisée, avec un projet déjà existant.
--force Initialiser le projet même lorsque celui-ci contient des fichiers existants. Ce paramètre remplace les fichiers existants portant le même nom. D’autres fichiers dans le dossier du projet ne sont pas affectés.
--language Initialise un projet spécifique au langage. Actuellement pris en charge lorsque --worker-runtime est défini sur node. Les options sont typescript et javascript. Vous pouvez également utiliser --worker-runtime javascript ou --worker-runtime typescript.
--managed-dependencies Installe des dépendances gérées. Actuellement, seul un runtime worker PowerShell prend en charge cette fonctionnalité.
--model Définit le modèle de programmation souhaité pour un langage cible quand plusieurs modèles sont disponibles. Les options prises en charge sont V1 et V2 pour Python, et V3 et V4 pour Node.js. Pour plus d’informations, consultez respectivement le guide du développeur Python et le guide du développeur Node.js.
--source-control Contrôle la création d’un référentiel git. Par défaut, un référentiel n’est pas créé. Un référentiel est créé lorsque true.
--worker-runtime Définit le runtime de langage pour le projet. Les valeurs prises en charge sont csharp, dotnet, dotnet-isolated, javascript,node (JavaScript), powershell, python et typescript. Pour Java, utilisez Maven. Pour générer un projet indépendant du langage avec uniquement les fichiers projet, utilisez custom. Lorsqu’il n’est pas défini, vous êtes invité à choisir votre runtime pendant l’initialisation.
--target-framework Définit l’infrastructure cible pour le projet d’application de fonction. Valide uniquement avec --worker-runtime dotnet-isolated. Les valeurs prises en charge sont : net6.0 (par défaut), net7.0, net8.0 et net48 (.NET Framework 4.8).

Remarque

Lorsque vous utilisez l'option--docker ou --dockerfile, Core Tools crée automatiquement le fichier dockerfile pour les fonctions C#, JavaScript, Python et PowerShell. Pour les fonctions Java, vous devez créer manuellement le fichier Dockerfile. Pour plus d’informations, consultez Création d’applications de fonction conteneurisées.

journaux func

Obtient les journaux pour les fonctions qui s’exécutent dans un cluster Kubernetes.

func logs --platform kubernetes --name <APP_NAME>

L’action func logs prend en charge les options suivantes :

Option Description
--platform Plateforme d’hébergement pour l’application de fonction. Options prises en charge : kubernetes.
--name Nom de l’application de fonction dans Azure.

Pour en savoir plus, voir Azure Functions sur Kubernetes avec KEDA.

func new

Crée une fonction dans le projet actuel à partir d’un modèle.

func new

Quand vous exécutez func new sans l’option --template, vous êtes invité à choisir un modèle. Dans la version 1.x, vous êtes également invité à choisir le langage.

L’action func new prend en charge les options suivantes :

Option Description
--authlevel Vous permet de définir le niveau d’autorisation pour un déclencheur HTTP. Les valeurs prises en charge sont les suivantes : function, anonymous, admin. L’autorisation n’est pas appliquée lors de l’exécution locale. Pour plus d’informations, consultez l’article sur la liaison HTTP.
--csx (Version 2.x et versions ultérieures.) Génère les mêmes modèles de script C# (.csx) que ceux utilisés dans la version 1.x et dans le portail.
--language, -l Langage de programmation du modèle, tel que C#, F# ou JavaScript. Cette option est requise dans la version 1.x. Dans la version 2. x et les versions ultérieures, vous n’utilisez pas cette option, car la langue est définie par le runtime du Worker.
--name, -n Nom de la fonction.
--template, -t Utilisez la commande func templates list pour afficher la liste complète des modèles disponibles pour chaque langage pris en charge.

Pour plus d’informations, consultez Créer une fonction.

exécution func

Version 1.x uniquement.

Permet d'invoquer directement une fonction, ce qui est similaire à l’exécution d’une fonction à l’aide de l’onglet Test dans le portail Azure. Cette action est uniquement prise en charge dans la version 1. x. Pour les versions ultérieures, utilisez func start et appelez directement le point de terminaison de la fonction .

func run

L’action func run prend en charge les options suivantes :

Option Description
--content Contenu inclus passé à la fonction.
--debug Joindre un débogueur au processus hôte avant d’exécuter la fonction.
--file Nom du fichier à utiliser en tant que contenu.
--no-interactive Ne demande pas d’entrée, ce qui est utile pour les scénarios d’automatisation.
--timeout Délai d’attente (en secondes) jusqu’à ce que l’hôte Functions local soit prêt.

Par exemple, pour appeler une fonction déclenchée par HTTP et passer un corps de contenu, exécutez la commande suivante :

func run MyHttpTrigger --content '{\"name\": \"Azure\"}'

début de la func

Démarre l’hôte du runtime local et charge le projet de fonction dans le dossier actif.

La commande spécifique dépend de la version du runtime.

func start

func start prend en charge les options suivantes :

Option Description
--cert Le chemin d’accès vers un fichier .pfx qui contient une clé privée. Pris en charge uniquement sur --useHttps.
--cors Liste séparée par des virgules d’origines CORS, sans espaces.
--cors-credentials Autoriser les demandes authentifiées cross-origin (autrement dit, les cookies et l’en-tête d’authentification).
--dotnet-isolated-debug Quand la valeur true est affectée, interrompt le processus de travail .NET jusqu’à ce qu’un débogueur soit attaché à partir du projet isolé .NET en cours de débogage.
--enable-json-output Émet les journaux de la console au format JSON, lorsque cela est possible.
--enableAuth Activer la gestion complète du pipeline d'authentification, avec des exigences en matière d'autorisation.
--functions Liste séparée par des espaces des fonctions à charger.
--language-worker Arguments pour configurer le travailleur de langage. Par exemple, vous pouvez activer le débogage pour le Worker du langage en fournissant un port de débogage et d’autres arguments requis.
--no-build Ne générez pas le projet actif avant l’exécution. Pour les projets de classe .NET uniquement. Par défaut, il s’agit de false.
--password Le mot de passe ou un fichier qui contient le mot de passe pour un fichier .pfx. Utilisé uniquement avec --cert.
--port Port local à écouter. Valeur par défaut : 7071.
--timeout Délai d’expiration pour le démarrage de l’hôte Functions, en secondes. Valeur par défaut : 20 secondes.
--useHttps Liaison avec https://localhost:{port} plutôt que http://localhost:{port}. Par défaut, cette option crée un certificat de confiance sur votre ordinateur.

Une fois le projet en cours d’exécution, vous pouvez vérifier des points de terminaison de fonction individuels.

func azure functionapp fetch-app-settings

Obtient les paramètres d’une application de fonction spécifique.

func azure functionapp fetch-app-settings <APP_NAME>

Pour plus d’informations, consultez la section Télécharger les paramètres d’application.

Les paramètres sont téléchargés dans le fichier local.settings.jsdu projet. Les valeurs affichées à l’écran sont masquées pour la sécurité. Vous pouvez protéger les paramètres dans le fichier local.settings.json enactivant le chiffrement local.

func azure functionapp list-functions

Retourne une liste des fonctions dans l’application de fonction spécifiée.

func azure functionapp list-functions <APP_NAME>

func azure functionapp logstream

Connecte l’invite de commandes locale aux journaux de diffusion en continu pour l’application de fonction dans Azure.

func azure functionapp logstream <APP_NAME>

Le délai d’expiration par défaut de la connexion est de 2 heures. Vous pouvez modifier le délai d'attente en ajoutant un paramètre d'application appelé SCM_LOGSTREAM_TIMEOUT, avec une valeur de délai d'attente en secondes. Pas encore pris en charge pour les applications Linux dans le plan de consommation. Pour ces applications, utilisez l'option --browser permettant d'afficher les journaux dans le portail.

L’action deploy prend en charge les options suivantes :

Option Description
--browser Ouvrez Azure Application Insights Live Stream pour l’application de fonction dans le navigateur par défaut.

Pour plus d’informations, consultez Activer les journaux d’exécution de streaming dans Azure Functions.

func azure functionapp publish

Déploie un projet de fonctions sur une ressource function app existante dans Azure.

func azure functionapp publish <APP_NAME>

Pour plus d'informations, consultez Déployer des fichiers projet.

Les options de publication suivantes s’appliquent, selon les versions :

Option Description
--access-token Vous permet d’utiliser un jeton d’accès spécifique lors de l’exécution d’actions Azure authentifiées.
--access-token-stdin Lit un jeton d’accès spécifique à partir d’une entrée standard. À utiliser lors de la lecture du jeton directement à partir d’une commande précédente, telle que az account get-access-token.
--additional-packages Liste des packages à installer lors de la création des dépendances natives. Par exemple : python3-dev libevent-dev.
--build, -b Exécute l’action de génération lors du déploiement dans une application de fonction Linux. Accepte : remote et local.
--build-native-deps Ignore la génération du dossier .wheels lors de la publication des applications de fonction Python.
--csx Publiez un projet de Script C# (.csx).
--dotnet-cli-params Lors de la publication de fonctions C# (. csproj) compilées, les outils principaux appellent dotnet build --output bin/publish. Tout paramètre transmis sera ajouté à la ligne de commande.
--force Ignorez la vérification de la prépublication dans certains scénarios.
--list-ignored-files Affiche une liste de fichiers ignorés lors de la publication basée sur le fichier .funcignore.
--list-included-files Affiche une liste de fichiers publiés basée sur le fichier .funcignore.
--management-url Définit l’URL de gestion pour votre cloud. À utiliser lors de l’exécution dans un cloud souverain.
--no-build Le projet n’est pas généré lors de la publication. Pour Python, pip install n’intervient pas.
--nozip Désactive le mode par défaut Run-From-Package.
--overwrite-settings -y Supprimer l’invite de remplacement des paramètres de l’application lorsque --publish-local-settings -i est utilisé.
--publish-local-settings -i Publier dans Azure les paramètres figurant dans local.settings.json, avec demande de confirmation du remplacement si le paramètre existe déjà. Si vous utilisez un émulateur de stockage local, changez d’abord le paramètre d’application en choisissant une connexion de stockage réelle.
--publish-settings-only, -o Publiez les paramètres uniquement et ignorez le contenu. Par défaut, l’accord de l’utilisateur est sollicité.
--slot Nom facultatif d’un emplacement spécifique dans lequel effectuer la publication.
--subscription Définit l’abonnement par défaut à utiliser.

func azure storage fetch-connection-string

Définit la chaîne de connexion pour le compte de stockage Azure spécifié.

func azure storage fetch-connection-string <STORAGE_ACCOUNT_NAME>

Pour plus d’informations, consultez la section Télécharger une chaîne de connexion de stockage.

func azurecontainerapps deploy

Déploie une application de fonction conteneurisée dans un environnement Azure Container Apps. Le compte de stockage utilisé par l’application de fonction et l’environnement doivent déjà exister. Pour plus d’informations, consultez Hébergement Azure Container Apps d’Azure Functions.

func azurecontainerapps deploy --name <APP_NAME> --environment <ENVIRONMENT_NAME> --storage-account <STORAGE_CONNECTION> --resource-group <RESOURCE_GROUP> --image-name <IMAGE_NAME> --registry-server <REGISTRY_SERVER> --registry-username <USERNAME> --registry-password <PASSWORD>

Les options de déploiement suivantes s’appliquent :

Option Description
--access-token Vous permet d’utiliser un jeton d’accès spécifique lors de l’exécution d’actions Azure authentifiées.
--access-token-stdin Lit un jeton d’accès spécifique à partir d’une entrée standard. À utiliser lors de la lecture du jeton directement à partir d’une commande précédente, telle que az account get-access-token.
--environment Nom d’un environnement Container Apps existant.
--image-build Quand la valeur est définie sur true, ignore la build Docker locale.
--image-name Nom d’image d’un conteneur existant dans un registre de conteneurs. Le nom de l’image inclut le nom de la balise.
--location Région pour le déploiement. Dans l’idéal, il s’agit de la même région que les ressources de l’environnement et du compte de stockage.
--management-url Définit l’URL de gestion pour votre cloud. À utiliser lors de l’exécution dans un cloud souverain.
--name Nom utilisé pour le déploiement de l’application de fonction dans l’environnement Container Apps. Ce même nom est également utilisé lors de la gestion de l’application de fonction dans le portail. Le nom doit être unique dans l’environnement.
--registry Quand elle est définie, une build d’ancrage est exécutée et l’image est envoyée au registre défini dans --registry. Vous ne pouvez pas utiliser --registry avec --image-name. Pour Docker Hub, utilisez également --registry-username.
--registry-password Mot de passe ou jeton utilisé pour récupérer l’image à partir d’un registre privé.
--registry-username Nom d’utilisateur utilisé pour récupérer l’image à partir d’un registre privé.
--resource-group Groupe de ressources dans lequel créer les ressources liées aux fonctions.
--storage-account Chaîne de connexion pour le compte de stockage à utiliser par l’application de fonction.
--subscription Définit l’abonnement par défaut à utiliser.
--worker-runtime Définit le langage runtime de l’application de fonction. Ce paramètre est utilisé uniquement avec --image-name et --image-build, sinon le langage est déterminé pendant la build locale. Les valeurs prises en charge sont : dotnet, dotnetIsolated, node, python, powershell et custom (pour les gestionnaires de clients).

Important

Les chaînes de connexion de stockage et les autres informations de connexion au service sont des secrets importants. Assurez-vous de stocker en sécurité les fichiers de script à l’aide de func azurecontainerapps deploy et de ne pas les stocker dans un contrôle de code source accessible publiquement.

func deploy

La commande func deploy est déconseillée. Utilisez func kubernetes deploy à la place.

func durable delete-task-hub

Supprime tous les artefacts de stockage dans le hub de tâches Durable Functions.

func durable delete-task-hub

L’action delete-task-hub prend en charge les options suivantes :

Option Description
--connection-string-setting Nom facultatif du paramètre d’application contenant la chaîne de connexion de stockage à utiliser.
--task-hub-name Nom facultatif du hub de tâches durable à utiliser.

Pour plus d’informations, consultez la documentation relative à Durable Functions.

func durable get-history

Retourne l’historique de l’instance d’orchestration spécifiée.

func durable get-history --id <INSTANCE_ID>

L’action get-history prend en charge les options suivantes :

Option Description
--id Spécifie l’ID d’une instance d’orchestration (obligatoire).
--connection-string-setting Nom facultatif du paramètre d’application contenant la chaîne de connexion de stockage à utiliser.
--task-hub-name Nom facultatif du hub de tâches durable à utiliser.

Pour plus d’informations, consultez la documentation relative à Durable Functions.

func durable get-instances

Retourne l’état de toutes les instances d’orchestration. Supporte la pagination en utilisant le paramètre top.

func durable get-instances

L’action get-instances prend en charge les options suivantes :

Option Description
--continuation-token Jeton facultatif qui indique une page/section spécifique des demandes à retourner.
--connection-string-setting Nom facultatif d’un paramètre d’application comportant la chaîne de connexion de stockage à utiliser.
--created-after Facultatif, récupère les instances créées après cette date/heure (UTC). Toutes les dates et heures au format ISO 8601 sont acceptées.
--created-before Si vous le souhaitez, vous pouvez obtenir les instances créées avant une date/heure spécifique (UTC). Toutes les dates et heures au format ISO 8601 sont acceptées.
--runtime-status Si vous le souhaitez, vous pouvez obtenir les instances dont l’état correspond à un état spécifique, notamment running, completed et failed. Vous pouvez fournir un ou plusieurs statuts séparés par des espaces.
--top Limitez éventuellement le nombre d’enregistrements retournés dans une demande donnée.
--task-hub-name Nom facultatif du hub de tâches Durable Functions à utiliser.

Pour plus d’informations, consultez la documentation relative à Durable Functions.

func durable get-runtime-status

Retourne le statut de l’instance d’orchestration spécifiée.

func durable get-runtime-status --id <INSTANCE_ID>

L’action get-runtime-status prend en charge les options suivantes :

Option Description
--connection-string-setting Nom facultatif du paramètre d’application contenant la chaîne de connexion de stockage à utiliser.
--id Spécifie l’ID d’une instance d’orchestration (obligatoire).
--show-input Une fois définie, la réponse contient l’entrée de la fonction.
--show-output Une fois définie, la réponse contient l’historique d’exécution.
--task-hub-name Nom facultatif du hub de tâches Durable Functions à utiliser.

Pour plus d’informations, consultez la documentation relative à Durable Functions.

func durable purge-history

Purge l’état de l’instance d’orchestration, l’historique et le stockage d’objets BLOB pour les orchestrations antérieures au seuil spécifié.

func durable purge-history

L’action purge-history prend en charge les options suivantes :

Option Description
--connection-string-setting Nom facultatif du paramètre d’application contenant la chaîne de connexion de stockage à utiliser.
--created-after Facultatif, purge l’historique des instances créées après cette date/heure (UTC). Toutes les dates et heures au format ISO 8601 sont acceptées.
--created-before Facultatif, purge l’historique des instances créées avant cette date/heure (UTC). Toutes les dates et heures au format ISO 8601 sont acceptées.
--runtime-status Si vous le souhaitez, vous pouvez obtenir les instances dont l’état correspond à un état spécifique, notamment completd, terminated, canceled et failed. Vous pouvez fournir un ou plusieurs statuts séparés par des espaces. Si vous n’incluez pas --runtime-status, l’historique des instances est supprimé, quel que soit l’état.
--task-hub-name Nom facultatif du hub de tâches Durable Functions à utiliser.

Pour plus d’informations, consultez la documentation relative à Durable Functions.

func durable raise-event

Déclenche un événement à l’instance d’orchestration spécifiée.

func durable raise-event --event-name <EVENT_NAME> --event-data <DATA>

L’action raise-event prend en charge les options suivantes :

Option Description
--connection-string-setting Nom facultatif du paramètre d’application contenant la chaîne de connexion de stockage à utiliser.
--event-data Données à passer à l’événement, incluses ou à partir d’un fichier JSON (obligatoire). Pour les fichiers, préfixez le chemin du fichier avec une esperluette(@), par exemple, @path/to/file.json.
--event-name Nom de l’événement à déclencher (obligatoire).
--id Spécifie l’ID d’une instance d’orchestration (obligatoire).
--task-hub-name Nom facultatif du hub de tâches Durable Functions à utiliser.

Pour plus d’informations, consultez la documentation relative à Durable Functions.

func durable rewind

Rembobine l’instance d’orchestration spécifiée.

func durable rewind --id <INSTANCE_ID> --reason <REASON>

L’action rewind prend en charge les options suivantes :

Option Description
--connection-string-setting Nom facultatif du paramètre d’application contenant la chaîne de connexion de stockage à utiliser.
--id Spécifie l’ID d’une instance d’orchestration (obligatoire).
--reason Motif de rembobinage de l’instance d’orchestration (obligatoire).
--task-hub-name Nom facultatif du hub de tâches Durable Functions à utiliser.

Pour plus d’informations, consultez la documentation relative à Durable Functions.

func durable start-new

Démarre l’exécution d’une nouvelle instance de la fonction d’orchestrateur spécifiée.

func durable start-new --id <INSTANCE_ID> --function-name <FUNCTION_NAME> --input <INPUT>

L’action start-new prend en charge les options suivantes :

Option Description
--connection-string-setting Nom facultatif du paramètre d’application contenant la chaîne de connexion de stockage à utiliser.
--function-name Nom de la fonction d’orchestrateur à démarrer (obligatoire).
--id Spécifie l’ID d’une instance d’orchestration (obligatoire).
--input Entrée de la fonction d'orchestration, soit en ligne, soit à partir d'un fichier JSON (obligatoire). Pour les fichiers, préfixez le chemin du fichier avec une esperluette(@), par exemple, @path/to/file.json.
--task-hub-name Nom facultatif du hub de tâches Durable Functions à utiliser.

Pour plus d’informations, consultez la documentation relative à Durable Functions.

func durable terminate

Arrête l’instance d’orchestration spécifiée.

func durable terminate --id <INSTANCE_ID> --reason <REASON>

L’action terminate prend en charge les options suivantes :

Option Description
--connection-string-setting Nom facultatif du paramètre d’application contenant la chaîne de connexion de stockage à utiliser.
--id Spécifie l’ID d’une instance d’orchestration (obligatoire).
--reason Motif d’arrêt de l’instance d’orchestration (obligatoire).
--task-hub-name Nom facultatif du hub de tâches Durable Functions à utiliser.

Pour plus d’informations, consultez la documentation relative à Durable Functions.

func extensions install

Installe manuellement les extensions Functions dans un projet non-.NET ou dans un projet de script C#.

func extensions install --package Microsoft.Azure.WebJobs.Extensions.<EXTENSION> --version <VERSION>

L’action install prend en charge les options suivantes :

Option Description
--configPath Chemin d’accès du répertoire contenant le fichier extensions. csproj.
--csx Prend en charge les projets de script C# (.csx).
--force Mettez à jour les versions des extensions existantes.
--output Chemin de sortie pour les extensions.
--package Identificateur d’un package d’extension spécifique. Lorsqu’elles ne sont pas spécifiées, toutes les extensions référencées sont installées, comme avec func extensions sync .
--source Source de flux NuGet si vous n’utilisez pas NuGet.org.
--version Fichier de package d’extension.

L’exemple suivant installe la version 5.0.1 de l’extension Event Hubs dans le projet local :

func extensions install --package Microsoft.Azure.WebJobs.Extensions.EventHubs --version 5.0.1

Les considérations suivantes s’appliquent lors de l’utilisation de func extensions install :

  • Pour les projets C# compilés (à la fois dans le processus et dans le processus de travail isolé), utilisez plutôt les méthodes d'installation standard des paquets NuGet, telles que dotnet add package.

  • Pour installer manuellement des extensions avec Core Tools, vous devez avoir installé le SDK .NET 6.0.

  • Dans la mesure du possible, vous devez utiliser à la place des bundles d’extensions. Voici certaines raisons pour lesquelles vous devez installer des extensions manuellement :

    • Vous devez accéder à une version spécifique d’une extension qui n’est pas disponible dans un bundle.
    • Vous devez accéder à une extension personnalisée qui n’est pas disponible dans un bundle.
    • Vous devez accéder à une combinaison spécifique d’extensions non disponibles dans un seul bundle.

  • Avant de pouvoir installer manuellement des extensions, vous devez d’abord supprimer l’objet extensionBundle du fichier host.json qui définit le bundle. Aucune action n’est effectuée quand un bundle d’extension est déjà défini dans votre fichier host.json.

  • Lors de la première installation explicite d’une extension, un fichier de projet .NET nommé extensions.csproj est ajouté à la racine de votre projet d’application. Ce fichier définit l’ensemble des packages NuGet requis par vos fonctions. Bien que vous puissiez utiliser les références de package NuGet dans ce fichier, Core Tools vous permet d’installer des extensions sans avoir à modifier manuellement le fichier projet C#.

func extensions sync

Installe toutes les extensions ajoutées à l’application de fonction.

L’action sync prend en charge les options suivantes :

Option Description
--configPath Chemin d’accès du répertoire contenant le fichier extensions. csproj.
--csx Prend en charge les projets de script C# (.csx).
--output Chemin de sortie pour les extensions.

Régénère un fichier extensions. csproj manquant. Aucune action n’est effectuée lorsqu’un bundle d’extension est défini dans votre host.json sur le fichier.

func kubernetes deploy

Déploie un projet de fonctions en tant que conteneur d’ancrage personnalisé sur un cluster Kubernetes.

func kubernetes deploy

Cette commande construit votre projet en tant que conteneur personnalisé et le publie sur un cluster Kubernetes. Les conteneurs personnalisés doivent contenir un fichier Dockerfile. Pour créer une application avec un fichier Dockerfile, utilisez l’option --dockerfile avec la commande func init.

Les options de déploiement de Kubernetes suivantes sont disponibles :

Option Description
--dry-run Affiche éventuellement le modèle de déploiement, sans exécution.
--config-map-name Nom facultatif d'un ConfigMap existant contenant les paramètres des applications fonctionnelles à utiliser dans le déploiement. Exige --use-config-map. Le comportement par défaut est de créer des paramètres basés sur l'objetValues dans le fichier local.settings.json.
--cooldown-period La période de refroidissement (en secondes) après la fin de tous les déclencheurs n’est plus active avant que le déploiement ne soit mis à l’échelle à zéro, avec une valeur par défaut de 300 s.
--ignore-errors Poursuit le déploiement après qu’une ressource a retourné une erreur. Le comportement par défaut est d’arrêter en cas d’erreur.
--image-name Nom de l’image à utiliser pour le déploiement du pod et à partir duquel lire les fonctions.
--keda-version Définit la version de KEDA à installer. Les options valides sont : v1 et v2 (par défaut).
--keys-secret-name Nom d’une collection de secrets Kubernetes à utiliser pour le stockage des clés d’accès aux fonctions.
--max-replicas Définit le nombre maximal de réplicas pour les mises à l’échelle du Pod horizontal (HPA).
--min-replicas Définit le nombre minimal de réplicas sous lequel HPA n’est pas mis à l’échelle.
--mount-funckeys-as-containervolume Monte les touches d'accès aux fonctions comme un volume de conteneur.
--name Nom utilisé pour le déploiement et d’autres artefacts dans Kubernetes.
--namespace Définit l’espace de noms Kubernetes sur lequel effectuer le déploiement, qui est par défaut l’espace de noms par défaut.
--no-docker Les fonctions sont lues à partir du répertoire actif et non à partir d’une image. Nécessite le montage du système de fichiers image.
--registry Quand elle est définie, une build d’ancrage est exécutée et l’image est envoyée à un registre de ce nom. Vous ne pouvez pas utiliser --registry avec --image-name. Pour l’ancrage, utilisez votre nom d’utilisateur.
--polling-interval Intervalle d’interrogation (en secondes) pour vérifier les déclencheurs non-HTTP, avec la valeur par défaut 30 s.
--pull-secret Le secret utilisé pour accéder aux informations d’identification du registre privé.
--secret-name Le nom d'une collection de secrets Kubernetes existante qui contient les paramètres des applications fonctionnelles à utiliser dans le déploiement. Le comportement par défaut est de créer des paramètres basés sur l'objetValues dans le fichier local.settings.json.
--show-service-fqdn Affiche les URL des déclencheurs HTTP avec le nom de domaine complet Kubernetes au lieu du comportement par défaut de l’utilisation d’une adresse IP.
--service-type Définit le type de service Kubernetes. Les valeurs prises en charge sont : ClusterIP, NodePort et LoadBalancer (par défaut).
--use-config-map Utilisez un objet ConfigMap (v1) au lieu d'un objet Secret (v1) pour configurer les paramètres de l'application fonctionnelle. Le nom de mappage est défini à l’aide de --config-map-name.

Core Tools tirera parti de l’interface de ligne de commande de Docker pour créer et publier l’image. Assurez-vous que votre Docker est déjà installé localement. Utilisez la commande docker login pour vous connecter à votre cluster.

Pour en savoir plus, consultez Déploiement d’une application de fonction sur Kubernetes.

func kubernetes install

Installe KEDA dans un cluster Kubernetes.

func kubernetes install

Installe KEDA sur le cluster défini dans le fichier de configuration kubectl.

L’action install prend en charge les options suivantes :

Option Description
--dry-run Affiche éventuellement le modèle de déploiement, sans exécution.
--keda-version Définit la version de KEDA à installer. Les options valides sont : v1 et v2 (par défaut).
--namespace Prend en charge l’installation sur un espace de noms Kubernetes spécifique. S'il n'est pas défini, l'espace de noms par défaut est utilisé.

Pour en savoir plus, consultez Gestion de KEDA et des fonctions dans Kubernetes.

func kubernetes remove

Supprime KEDA du cluster Kubernetes défini dans le fichier de configuration kubectl.

func kubernetes remove

Supprime KEDA du cluster défini dans le fichier de configuration kubectl.

L’action remove prend en charge les options suivantes :

Option Description
--namespace Prend en charge la désinstallation d’un espace de noms Kubernetes spécifique. S'il n'est pas défini, l'espace de noms par défaut est utilisé.

Pour en savoir plus, consultez Désinstallation de KEDA de Kubernetes.

func settings add

Ajoute un nouveau paramètre à la collectionValues du fichier local.settings.json.

func settings add <SETTING_NAME> <VALUE>

Remplacez <SETTING_NAME> par le nom du paramètre d’application, et <VALUE> par la valeur à assigner à celui-ci.

L’action add prend en charge les options suivantes :

Option Description
--connectionString Ajoute la paire nom-valeur à la collection ConnectionStrings au lieu de la collection Values. N'utiliser la collection ConnectionStrings que lorsque certaines infrastructures l'exigent. Pour en savoir plus, consultez la section fichier local.settings.json.

func settings decrypt

Décrypte les valeurs précédemment cryptées dans la collection Values du fichier local.settings.json.

func settings decrypt

Les valeurs de chaîne de connexion dans la collection ConnectionStrings sont également déchiffrées. Dans local.settings.json, IsEncrypted est également défini à false . Chiffrez les paramètres locaux pour réduire le risque de fuite d’informations précieuses de local.settings.json. Dans Azure, les paramètres d’application sont toujours stockés chiffrés.

func settings delete

Supprime un paramètre existant à la collectionValues du fichier local.settings.json.

func settings delete <SETTING_NAME>

Remplacez <SETTING_NAME> par le nom du paramètre d’application, et <VALUE> par la valeur à assigner à celui-ci.

L’action delete prend en charge les options suivantes :

Option Description
--connectionString Supprime la paire nom-valeur à la collection ConnectionStrings au lieu de la collection Values.

func settings encrypt

Crypte les valeurs des éléments individuels dans la collection Values du fichier local.settings.json.

func settings encrypt

Les valeurs de chaîne de connexion dans la collection ConnectionStrings sont également chiffrées. Dans local.settings.json, IsEncrypted est également défini sur true, ce qui indique que le runtime local déchiffre les paramètres avant de les utiliser. Chiffrez les paramètres locaux pour réduire le risque de fuite d’informations précieuses de local.settings.json. Dans Azure, les paramètres d’application sont toujours stockés chiffrés.

func settings list

Produit une liste des paramètres de la collection Values dans le fichier local.settings.json.

func settings list

Les chaînes de connexion de la collection ConnectionStrings sont également éditées. Par défaut, les valeurs affichées sont masquées pour la sécurité. Vous pouvez utiliser l'option --showValue pour afficher la valeur réelle.

L’action list prend en charge les options suivantes :

Option Description
--showValue Affiche les valeurs non masquées réelles dans la sortie.

func templates list

Répertorie les modèles de fonction (déclencheur) disponibles.

L’action list prend en charge les options suivantes :

Option Description
--language Langue pour laquelle filtrer les modèles retournés. Par défaut, tous les langages sont retournés.