For the complete documentation index, see llms.txt. This page is also available as Markdown.

Azure

PowerShell Universal est une application web ASP.NET Core et peut être hébergée dans Windows Azure Web Apps.

Application web conteneurisée

Les applications web conteneurisées permettent d'utiliser des images Docker comme applications web dans Azure. Dans le portail Azure, vous pouvez créer une application web Docker Container à l'aide de l'assistant App Services \ Create Web App.

Une fois que vous avez sélectionné un groupe de ressources, attribué un nom et sélectionné un plan de calcul, vous pourrez créer l'application web.

Ensuite, vous devrez déployer l'image dans votre application web. Pour ce faire, sélectionnez le Deployment Center et configurez l'image à récupérer. Vous pouvez soit récupérer une version étiquetée statique (comme 2.7.3), soit récupérer la plus récente, et votre application web restera automatiquement à jour avec les nouvelles versions de PowerShell Universal. Utilisez l'étiquette avec le suffixe azure. Elle est préconfigurée pour fonctionner dans Azure.

Pour les environnements de production, nous suggérons de définir une version étiquetée afin d'éviter les mises à jour involontaires de votre conteneur lors de son redémarrage. Par défaut, Azure met automatiquement à jour les conteneurs lorsqu'une étiquette, comme latest, est mise à jour. Cela vous permettra de contrôler les mises à jour de votre version de PowerShell Universal.

Persistance locale

Par défaut, le conteneur écrira dans le répertoire /home.

Vous devrez vous assurer que la variable d'environnement WEBSITES_ENABLE_APP_SERVICE_STORAGE est définie à true. Cela configure le conteneur pour rendre le dossier /home persistant, et c'est là que les données de configuration de PowerShell Universal sont stockées.

Git et SQL

Si vous choisissez d'utiliser l'intégration git dans PowerShell Universal, nous recommandons de mettre en place un serveur et une base de données SQL pour le stockage. Git sera utilisé pour synchroniser les fichiers de configuration au démarrage du conteneur. SQL stockera les paramètres de configuration git ainsi que des ressources comme les tâches, les jetons d'application et les identités.

Vous aurez besoin d'une base de données Azure SQL pour commencer. Une fois la ressource créée, vous devrez copier la chaîne de connexion de la base de données pour la fournir à PowerShell Universal.

Assurez-vous d'avoir autorisé les services Azure à accéder à la base de données.

Pour activer la prise en charge de SQL, vous devez configurer les plugins dans PowerShell Universal afin d'utiliser le plugin SQL dans l'Application Configuration de votre application web.

Créez un paramètre Plugins__0 avec la valeur SQL. Ensuite, définissez la valeur Data__ConnectionString avec celle de votre base de données SQL Server.

Une fois SQL configuré, vous pouvez démarrer votre conteneur. Le schéma de base de données sera créé au démarrage du conteneur. Ensuite, vous devrez configurer git dans PowerShell Universal en cliquant sur Source Control > Git > Settings. Saisissez votre dépôt distant, la branche, le nom d'utilisateur, le mot de passe ou le jeton d'accès personnel, ainsi que le mode de synchronisation. Le mode Push-only n'est pas recommandé dans cette configuration, car l'état du conteneur est perdu entre les redémarrages. Assurez-vous que le mode d'initialisation est défini à Clone.

Les paramètres git sont stockés dans votre base de données SQL et seront récupérés à chaque démarrage du conteneur.

En-têtes transférés

Les conteneurs sont généralement hébergés derrière un proxy inverse et n'auront pas connaissance de l'URL externe réelle sans configuration supplémentaire. Afin de s'assurer que les systèmes qui requièrent l'URL externe, comme OpenID Connect, reçoivent les bonnes informations, vous devrez définir la variable d'environnement ASPNETCORE_FORWARDEDHEADERS_ENABLED à true.

Pour plus d'informations, vous pouvez lire cet article de blogue de Microsoft.

Bicep

Vous pouvez utiliser le modèle Bicep suivant pour déployer une application web conteneurisée avec du stockage persistant.

Conteneurs sidecar

Les applications web conteneurisées prennent également en charge les conteneurs sidecar, qui vous permettent d'exécuter des conteneurs supplémentaires aux côtés du conteneur PowerShell Universal. C'est utile pour prendre en charge des services tels que des proxys, des agents, des collecteurs ou d'autres processus connexes. Lorsque vous hébergez PowerShell Universal dans cette configuration, assurez-vous que le conteneur web expose le bon port HTTP. Par défaut, PowerShell Universal écoute sur le port 5000.

Application web standard

Créer manuellement une application web

Dans le portail Azure, vous devrez créer une nouvelle ressource Web App. PowerShell Universal requiert actuellement la pile d'exécution .NET 10. Vous pouvez utiliser Linux ou Windows.

Si vous choisissez un plan d'hébergement Windows plutôt qu'un plan d'hébergement Linux dans Azure lors de la configuration de votre WebApp, vous devez choisir un plan Basic (B1) ou supérieur pour pouvoir utiliser des applications 64 bits. Vous devez également aller dans Settings > Configuration > General setting > Platform et sélectionner 64-bit avant d'exécuter la commande Publish-AzWebApp, sinon l'installation échouera.

Commande de démarrage (Linux seulement)

Lors de l'hébergement dans un environnement Linux, vous devrez définir la commande de démarrage sous Settings \ Configuration \ General Settings \ Startup Command avec la valeur suivante.

Dans l'exemple ci-dessous, nous utiliserons le module Azure PowerShell pour déployer manuellement la Web App.

Vous devrez d'abord installer Azure PowerShell.

Une fois installé, vous devrez vous connecter à votre abonnement.

Déployer les fichiers Windows

Si vous utilisez Windows, vous devrez télécharger le fichier ZIP Windows. Cet exemple télécharge PowerShell Universal 2026.3.0.0.

Déployer les fichiers Linux

Si vous utilisez Linux, vous devrez télécharger le fichier ZIP Linux. Cet exemple télécharge PowerShell Universal 2026.3.0.0.

Maintenant que le module Az est configuré et que le ZIP de Universal est téléchargé, nous pouvons déployer la Web App.

Vous pouvez vérifier dans Azure sous Deployment Center > Logs si le statut est Success (Active) afin de vous assurer que les fichiers ont été déployés et installés correctement.

Ajustements de paramètres requis

Ces paramètres peuvent être définis dans l'onglet Configuration, dans les paramètres de l'application.

Clé de signature JWT

La clé de signature JWT par défaut n'est pas d'une longueur suffisante et devra être mise à jour. Cela peut se faire dans appsettings.json ou en utilisant des variables d'environnement.

appsettings.json

Variable d'environnement

URL de l'API

Les Azure Web Apps utilisent un proxy inverse et PowerShell Universal ne détecte pas l'URL externe adéquatement. Lors de l'exécution de tâches, Universal utilise la Management API pour rechercher automatiquement les informations sur les tâches, les scripts et les horaires. Cela signifie que cette opération échouera s'il ne peut pas adresser correctement l'URL externe de l'API.

L'URL de l'API doit être l'adresse HTTP externe de votre Web App. Vous pouvez la mettre à jour dans appsettings.json ou en utilisant une variable d'environnement.

appsettings.json

Variable d'environnement

NodeName

Vous pouvez définir le nom de l'instance PowerShell Universal en spécifiant le NodeName. Cela garantira que les redémarrages n'affecteront pas la base de données PowerShell Universal. Ce n'est pas requis pour les installations LiteDB.

PORT et WEBSITES_PORT (Linux seulement)

Pour remplacer le port par défaut dans une application web Linux, vous devez définir les paramètres PORT et WEBSITES_PORT à 5000.

Après avoir publié la Web App, consultez votre instance PowerShell Universal en naviguant vers l'URL de la Web App.

Stockage persistant

Le fichier appsettings.json par défaut stockera la base de données et les fichiers de configuration dans un emplacement non persistant. Vous pouvez ajouter des variables d'environnement pour les déplacer vers un stockage persistant dans votre application web.

Data__RepositoryPath

La variable d'environnement Data__RepositoryPath définit l'emplacement des fichiers de configuration de Universal. Définissez la valeur suivante.

Mettre à jour votre Web App

Lorsqu'une nouvelle version de PowerShell Universal est publiée, vous devrez mettre à jour les fichiers d'application de votre Web App. Nous recommandons de supprimer le répertoire de l'application et de redéployer les fichiers. La base de données et les fichiers de configuration ne sont pas stockés dans le répertoire de l'application.

Vous pouvez supprimer les fichiers de votre Web App en utilisant l'API de commande Kudu. Vos identifiants Kudu utilisent l'authentification Basic et sont les mêmes que vos identifiants de déploiement.

Pour supprimer tous les fichiers de votre Web App, exécutez la commande suivante.

Une fois les fichiers d'application supprimés, vous pouvez les redéployer en exécutant à nouveau les étapes de création manuelle.

Application Gateway

Vous pouvez configurer PowerShell Universal pour qu'il s'exécute derrière un Application Gateway dans Azure. C'est utile pour fournir l'équilibrage des charges et une haute disponibilité à plusieurs instances de PowerShell Universal.

D'abord, configurez un pool backend qui cible une ou plusieurs Azure Web Apps exécutant PowerShell Universal.

Pour les paramètres du backend, vous voudrez vous assurer d'utiliser HTTPS avec un certificat d'une AC bien connue. L'affinité basée sur les témoins est requise pour garantir que les sessions restent rattachées à un nœud individuel.

Afin de permettre à Azure de servir la bonne application web, vous devrez vous assurer que le paramètre Override with new host name est configuré. Utilisez le nom d'hôte de la cible backend.

Assurez-vous que la règle du pool backend est configurée comme cible et non comme redirection.

Configurez une règle de réécriture d'en-tête pour transmettre le nom d'hôte public en tant qu'en-tête X-Forwarded-Host. PowerShell Universal l'utilisera pour construire les URL à l'interne.

La règle de réécriture ci-dessus est une exigence des méthodes d'authentification OpenID Connect et SAML2.

Enfin, vous pouvez configurer l'adresse IP publique de votre Application Gateway à l'aide d'un fournisseur DNS vers un nom d'hôte personnalisé. Créez un enregistrement A dans votre gestion DNS.

Mis à jour

Ce contenu vous a-t-il été utile ?