Référence Azure Functions Core Tools
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 les suivantes : net9.0 (préversion), net8.0 (valeur par défaut) net6.0 et net48 (.NET Framework 4.8). |
Remarque
Lorsque vous utilisez l'option--docker
ou --docker-only
, 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.
func logs
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 Niveau d’autorisation. |
--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.
func run
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\"}'
func start
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 authentifiées azure . |
--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 authentifiées azure . |
--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 stocker les clés d’accès. |
--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 clés d’accès en tant que 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.
Azure Functions prend en charge l’hébergement de vos fonctions conteneurisées dans Azure Container Apps ou dans Azure Functions. L’exécution de vos conteneurs directement dans un cluster Kubernetes ou dans Azure Kubernetes Service (AKS) n’est pas officiellement prise en charge par Azure Functions. Pour en savoir plus, consultez la prise en charge des conteneurs Linux dans Azure Functions.
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. |