Ouvrez un shell conteneur (SSH) et exécutez des commandes dans Azure App Service

App Service offre un accès SSH basé sur navigateur aux applications hébergées dans des conteneurs personnalisés Windows. Aucune configuration spéciale d’image n’est requise pour la session du navigateur.

La commande Azure CLI az webapp exec n’est prise en charge que pour les applications web Linux. N'utilisez pas les exemples de la ligne de commande Linux dans cet article avec les plans application Windows Service.

Pour les conteneurs Linux intégrés et personnalisés, le nouveau terminal de navigateur et az webapp exec utilisent Kudu comme proxy authentifié pour se connecter au conteneur en cours d’exécution. Ces options ne nécessitent pas d’installer un serveur SSH, d’intégrer un mot de passe SSH, d’exposer un port SSH ou de lancer un démon SSH dans votre image personnalisée. L’accès à Legacy Kudu WebSSH et à az webapp ssh peut encore nécessiter un serveur SSH dans une image personnalisée.

Utilisez le portail Azure pour une session de navigateur, ou utilisez la commande d’aperçu az webapp exec pour une session terminale locale ou une exécution de commande détachée. Le terminal du navigateur nécessite la présence de /bin/bash dans l’image et ne permet pas actuellement de sélectionner un autre shell. Si l’image a une coque différente, utilisez az webapp exec --shell /bin/sh à la place. Les images sans shell, y compris les images distroless, ne peuvent pas ouvrir une session interactive.

• Pour les exemples de CLI, installez Azure CLI 2.90.0 ou une version ultérieure et connectez-vous. Vérifiez votre version à l’aide de az version. Vous pouvez aussi utiliser Azure Cloud Shell si son CLI répond à cette exigence.
• Pour une session interactive CLI, utilisez un terminal interactif et un shell qui existe dans votre image. Par défaut est /bin/bash; pour une image sans bash, spécifier --shell /bin/sh si ce shell est disponible.

Ouvrir une session SSH avec Azure CLI

La commande d’aperçu az webapp exec ouvre un shell interactif dans le conteneur principal de votre application. La session utilise votre terminal local sous Windows, macOS et Linux. Elle n’ouvre pas de navigateur.

az webapp exec --resource-group <resource-group-name> --name <app-name>

Pour une image qui utilise /bin/sh au lieu de bash :

az webapp exec --resource-group <resource-group-name> --name <app-name> --shell /bin/sh

Vous pouvez exécuter des commandes et inspecter leur sortie lors de cette session. Par exemple, utilisez top s’il est installé dans l’image. Pour inspecter le conteneur SCM/Kudu au lieu du conteneur d’application :

az webapp exec --resource-group <resource-group-name> --name <app-name> --target kudu

L’application et les conteneurs Kudu sont des environnements différents. Exécutez des commandes qui dépendent de l’exécution de votre application, des dépendances ou de la connectivité réseau dans le conteneur de l’application.

Sélectionnez une instance ou un emplacement de déploiement

Par défaut, la ligne de commande se connecte à une instance d’application. Pour trouver les identifiants d’instance :

az webapp list-instances --resource-group <resource-group-name> --name <app-name> --output table

Pour se connecter à une instance spécifique :

az webapp exec --resource-group <resource-group-name> --name <app-name> --instance <instance-id>

Ajoutez --slot <slot-name> pour accéder à un slot de déploiement. Lorsque vous sélectionnez l’instance d’un emplacement, ajoutez --slot également à az webapp list-instances.

Le mode shell interactif ne prend en charge qu’une seule instance à la fois.

Exécuter des commandes sans ouvrir de session interactive

Utilisez --mode execute pour soumettre une commande au conteneur principal de l’application sans ouvrir une session terminale. La commande s’exécute en arrière-plan. Ce mode est utile pour les diagnostics en arrière-plan ou tout autre travail qui ne nécessite pas de sortie immédiate.

Exécutez un programme directement

Utilisez --command pour spécifier un programme et ses arguments. Placez l’intégralité de la commande entre guillemets :

az webapp exec --resource-group <resource-group-name> --name <app-name> --mode execute --command "python3 /home/site/wwwroot/scripts/diagnostics.py" --working-directory /home/site/wwwroot --instance <instance-id>

Remplacez le chemin du script par un script déployé dans votre application. L’exécutable et ses dépendances doivent exister dans le conteneur.

--command n’interprète pas les opérateurs de shell tels que >, |, ou &&. Utilisez --shell-command plutôt lorsque vous avez besoin d’un shell. Ces deux options sont mutuellement exclusives.

Capturez la sortie et vérifiez que l’exécution est terminée

L’exemple suivant utilise les règles de mise entre guillemets du client Bash, comme dans Cloud Shell. Il envoie une commande de diagnostic en lecture seule à une instance et enregistre séparément sa sortie et son statut de sortie. Remplacez <run-id> par un nouvel identifiant pour chaque invocation et <instance-id> par un ID de az webapp list-instances.

az webapp exec --resource-group <resource-group-name> --name <app-name> \
  --mode execute --instance <instance-id> --shell /bin/sh \
  --shell-command 'uname -a > /home/LogFiles/diagnostics-<run-id>.log 2>&1; result=$?; printf "%s\n" "$result" > /home/LogFiles/diagnostics-<run-id>.exit'

Assurez-vous que /bin/sh et la commande de diagnostic existent, et que /home/LogFiles existe et est accessible en écriture. La persistance de /home dans les conteneurs personnalisés dépend de la configuration de stockage de l’application. Les guillemets simples empêchent l’interpréteur de commandes client de développer $? et $result avant que la requête n’atteigne le conteneur.

Après la soumission, ouvrez un shell d’application interactif sur la même instance et inspectez les fichiers :

cat /home/LogFiles/diagnostics-<run-id>.log
cat /home/LogFiles/diagnostics-<run-id>.exit

Un état de sortie enregistré de 0 indique que la commande de diagnostic a réussi. Un statut non nul indique un échec ; inspectez le journal. Si le fichier d’état n’existe pas, il n’est pas établi que l’exécution est terminée : la commande peut être toujours en cours d’exécution, ne pas avoir démarré ou avoir été interrompue. Ne déduis pas le succès de l’acceptation ou de la présence d’un journal partiel. Utilisez un nouvel identifiant de run pour éviter qu’un ancien fichier d’état soit confondu avec le résultat actuel.

La CLI ne fournit pas d’API d’interrogation de complétion. Rediriger la sortie vers un fichier ne rend pas automatiquement la sortie disponible dans le flux de journaux d’App Service.

Pour les migrations de base de données ou autres opérations qui modifient l’état partagé, sélectionnez une instance, vérifiez la complétion séparément, et ne relancez pas l’opération uniquement parce que la soumission n’a pas renvoyé de sortie. Gardez le flux de travail interactif lorsque vous devez vérifier la réussite avant de continuer.

Exécutez des commandes indépendantes sur plusieurs instances

Le mode d’exécution accepte également une liste d’ID d’instance séparés par des virgules ou --instance all. Les demandes pour plusieurs instances sont soumises en parallèle. Par exemple, exécutez un script de diagnostic déployé par instance sur chaque instance :

az webapp exec --resource-group <resource-group-name> --name <app-name> --mode execute --command "python3 /home/site/wwwroot/scripts/diagnostics.py" --instance all

Le script doit capturer ses propres résultats. Utilisez des chemins de sortie distincts par instance et par exécution si le stockage est partagé. N’utilisez pas all pour des migrations de bases de données partagées ou d’autres opérations qui ne doivent s’exécuter qu’une seule fois. Si certaines soumissions échouent, la CLI signale une erreur alors que d’autres instances ont peut-être accepté la commande.

Ajouter --slot <slot-name> pour exécuter contre un emplacement de déploiement.

Limitations

• Le mode exécution cible uniquement le conteneur principal de l’application. Vous pouvez utiliser --target kudu qu’en mode shell interactif.
• Utilisez --working-directory ou --cwd uniquement en mode exécution, et fournissez un chemin absolu.
• Fournir un chemin absolu pour --shell. En mode exécution, vous ne pouvez l’utiliser qu’avec --shell-command.
• Cette prévisualisation ne propose pas de transfert de fichiers, de redirection de port, ni d’option pour sélectionner des conteneurs sidecar arbitraires. Utilisez les méthodes de déploiement prises en charge pour charger des fichiers.
• L’exécution détachée n’est pas un Job Scheduler durable. Un redémarrage ou un remplacement du conteneur peut interrompre le travail. Ne partez pas du principe que les nouvelles tentatives sont automatiques ou que l’exécution a lieu exactement une fois.