> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/powershell-universal/fr/config/hosting/azure.md). # Azure Déployez PowerShell Universal sur Azure à l'aide d'applications web conteneurisées ou d'applications web standard, en configurant la persistance, le stockage SQL et les en-têtes transférés. 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. {% hint style="info" %} 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. {% endhint %} ### 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. {% hint style="info" %} 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. {% endhint %} ### 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](https://devblogs.microsoft.com/dotnet/forwarded-headers-middleware-updates-in-net-core-3-0-preview-6/). ### Bicep Vous pouvez utiliser le modèle Bicep suivant pour déployer une application web conteneurisée avec du stockage persistant. {% code collapsedlinecount="10" %} ```bicep @description('Name of Azure Web App') param siteName string = 'psu-${uniqueString(resourceGroup().id)}' @description('The version of PowerShell Universal') param version string = '5.4.4' @description('App Service Plan Pricing Tier') @allowed([ 'B1' 'B2' 'B3' 'S1' 'S2' 'S3' 'P1V2' 'P2V2' 'P2V3' ]) param servicePlanPricingTier string = 'S2' var servicePlanName = '${siteName}-asp' @description('Location for all the resources.') param location string = resourceGroup().location var servicePlanPricingTiers = { F1: { tier: 'Free' } B1: { tier: 'Basic' } B2: { tier: 'Basic' } B3: { tier: 'Basic' } S1: { tier: 'Standard' } S2: { tier: 'Standard' } S3: { tier: 'Standard' } P1V2: { tier: 'Standard' } P2V2: { tier: 'Standard' } P2V3: { tier: 'Standard' } } resource planResource 'Microsoft.Web/serverfarms@2024-04-01' = { name: servicePlanName location: location sku: { name: servicePlanPricingTier tier: servicePlanPricingTiers[servicePlanPricingTier].tier capacity: 1 } kind: 'linux' properties: { reserved: true } } resource siteResource 'Microsoft.Web/sites@2024-04-01' = { name: siteName location: location properties: { serverFarmId: planResource.id siteConfig: { linuxFxVersion: 'DOCKER|devolutions/powershell-universal:${version}-azure' } } } resource siteWebAppsettingsResource 'Microsoft.Web/sites/config@2024-04-01' = { parent: siteResource name: 'appsettings' properties: { WEBSITES_ENABLE_APP_SERVICE_STORAGE: 'true' } } ``` {% endcode %} ### Conteneurs sidecar Les applications web conteneurisées prennent également en charge les [conteneurs sidecar](https://learn.microsoft.com/en-us/azure/app-service/overview-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. {% hint style="info" %} 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. {% endhint %} **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. {% code collapsedlinecount="10" %} ``` dotnet Universal.Server.dll ``` {% endcode %} 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. {% code collapsedlinecount="10" %} ```powershell Install-Module Az ``` {% endcode %} Une fois installé, vous devrez vous connecter à votre abonnement. {% code collapsedlinecount="10" %} ```powershell Connect-AzAccount ``` {% endcode %} ### 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. {% code collapsedlinecount="10" %} ```powershell $Version = '2026.3.0.0' Invoke-WebRequest "https://cdn.devolutions.net/download/Devolutions.PowerShellUniversal.win-x64.$Version.zip" -OutFile .\Universal.zip ``` {% endcode %} ### 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. {% code collapsedlinecount="10" %} ```powershell $Version = '2026.3.0.0' Invoke-WebRequest "https://cdn.devolutions.net/download/Devolutions.PowerShellUniversal.linux-x64.$Version.zip" -OutFile .\Universal.zip ``` {% endcode %} Maintenant que le module Az est configuré et que le ZIP de Universal est téléchargé, nous pouvons déployer la Web App. {% code collapsedlinecount="10" %} ```powershell $Parameters = @{ Force = $true ResourceGroupName = 'psudemo2_group' Name = 'psudemo2' ArchivePath = '.\Universal.zip' } Publish-AzWebApp @Parameters ``` {% endcode %} {% hint style="info" %} 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. {% endhint %} ### 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 {% code collapsedlinecount="10" %} ``` "Jwt": { "SigningKey": "xXyt9UpJKB4Pb*4$hprd!JJoyOcK4ZOV**O7Hug9&@gYHc$", "Issuer": "IronmanSoftware", "Audience": "PowerShellUniversal" }, ``` {% endcode %} #### Variable d'environnement {% code collapsedlinecount="10" %} ``` $Env:Jwt__SigningKey = 'xXyt9UpJKB4Pb*4$hprd!JJoyOcK4ZOV**O7Hug9&@gYHc$' ``` {% endcode %} #### 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 {% code collapsedlinecount="10" %} ``` "Api": { "Url": "https://psudemo.azurewebsites.net" }, ``` {% endcode %} #### Variable d'environnement {% code collapsedlinecount="10" %} ``` $Env:Api__Url = "https://psudemo.azurewebsites.net" ``` {% endcode %} #### 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. {% code collapsedlinecount="10" %} ``` $Env:NodeName = "psuazure" ``` {% endcode %} #### 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. {% code collapsedlinecount="10" %} ``` D:\home\Data\PowerShellUniversal\Repository ``` {% endcode %} ### 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](https://github.com/projectkudu/kudu/wiki/Deployment-credentials). Pour supprimer tous les fichiers de votre Web App, exécutez la commande suivante. {% code collapsedlinecount="10" %} ```powershell $Parameters = @{ Uri = "https://psudemo2.scm.azurewebsites.net/api/command" Credential = (Get-Credential) Body = (@{ command = "rd /s /q D:\home\site\wwwroot" dir = "D:\home\site\wwwroot" } | ConvertTo-Json) } Invoke-RestMethod @Parameters ``` {% endcode %} 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.devolutions.net/powershell-universal/fr/config/hosting/azure.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.