Azure

Apprenez à héberger PowerShell Universal dans Azure.

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

Application web de conteneur

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

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

Vous devez ensuite déployer l'image dans votre application web. Pour ce faire, sélectionnez le Deployment Center et configurez l'image à extraire. Vous pouvez extraire une version étiquetée statique (comme 2.7.3) ou extraire la dernière version, et votre application web se mettra automatiquement à jour avec les nouvelles versions de PowerShell Universal. Utilisez l'étiquette avec le suffixe azure. Elle est préconfigurée pour s'exécuter dans Azure.

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

Persistance locale

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

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

Git et SQL

Si vous choisissez d'utiliser l'intégration git dans PowerShell Universal, nous recommandons de configurer un serveur SQL et une base de données 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 les ressources telles que 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 extensions dans PowerShell Universal afin d'utiliser l'extension SQL dans la configuration de l'application pour votre application web.

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

Une fois SQL configuré, vous pouvez démarrer votre conteneur. Le schéma de la base de données sera créé au démarrage du conteneur. Vous devrez ensuite configurer git dans PowerShell Universal en cliquant sur Settings \ Git. Saisissez votre référentiel 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 uniquement 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 sur 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 ne seront pas informés de l'URL externe réelle sans configuration supplémentaire. Afin de garantir que les systèmes nécessitant l'URL externe, comme OpenID Connect, reçoivent les informations appropriées, vous devrez définir la variable d'environnement ASPNETCORE_FORWARDEDHEADERS_ENABLED sur true.

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

Bicep

Vous pouvez utiliser le modèle Bicep suivant pour déployer une application web de conteneur avec un stockage persistant.

@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|ironmansoftware/universal:${version}-azure'
    }
  }
}

resource siteWebAppsettingsResource 'Microsoft.Web/sites/config@2024-04-01' = {
  parent: siteResource
  name: 'appsettings'
  properties: {
    WEBSITES_ENABLE_APP_SERVICE_STORAGE: 'true'
  }
}

Application web standard

Création manuelle d'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 9. 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 accéder à Settings > Configuration > General setting > Platform et sélectionner 64 bits avant d'exécuter la commande Publish-AzWebApp, sinon l'installation échouera.

Commande de démarrage (Linux uniquement)

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 comme suit.

dotnet Universal.Server.dll

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

Vous devrez d'abord installer Azure PowerShell.

Install-Module Az

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

Connect-AzAccount

Déploiement des fichiers Windows

Si vous utilisez Windows, vous devrez télécharger le fichier ZIP Windows. Cela téléchargera la dernière version de PowerShell Universal.

$LatestVersion = Invoke-RestMethod https://imsreleases.blob.core.windows.net/universal/production/v3-version.txt
Invoke-WebRequest "https://imsreleases.blob.core.windows.net/universal/production/$LatestVersion/Universal.win7-x64.$LatestVersion.zip" -OutFile .\Universal.zip

Déploiement des fichiers Linux

Si vous utilisez Linux, vous devrez télécharger le fichier ZIP Linux. Cela téléchargera la dernière version de PowerShell Universal.

$LatestVersion = Invoke-RestMethod https://imsreleases.blob.core.windows.net/universal/production/v3-version.txt
Invoke-WebRequest "https://imsreleases.blob.core.windows.net/universal/production/$LatestVersion/Universal.linux-x64.$LatestVersion.zip" -OutFile .\Universal.zip

Maintenant que le module Az est configuré et que le fichier ZIP Universal est téléchargé, nous pouvons déployer l'application web.

$Parameters = @{
    Force = $true
    ResourceGroupName = 'psudemo2_group'
    Name = 'psudemo2'
    ArchivePath = '.\Universal.zip'
}
Publish-AzWebApp @Parameters

Vous pouvez vérifier dans Azure sous Deployment Center > Logs le statut Success (Active) pour vous assurer que les fichiers ont été déployés et installés avec succès.

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 être fait dans appsettings.json ou en utilisant des variables d'environnement.

appsettings.json

  "Jwt": {
    "SigningKey": "xXyt9UpJKB4Pb*4$hprd!JJoyOcK4ZOV**O7Hug9&@gYHc$",
    "Issuer": "IronmanSoftware",
    "Audience": "PowerShellUniversal"
  },

Variable d'environnement

$Env:Jwt__SigningKey = 'xXyt9UpJKB4Pb*4$hprd!JJoyOcK4ZOV**O7Hug9&@gYHc$'

URL de l'API

Les Azure Web Apps utilisent un proxy inverse et PowerShell Universal ne détecte pas correctement l'URL externe. Lors de l'exécution des tâches, Universal utilise l'API de gestion pour rechercher automatiquement les informations sur les tâches, les scripts et les planifications. Cela signifie que cela échouera si l'URL externe de l'API ne peut pas être correctement résolue.

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

appsettings.json

"Api": {
 "Url": "https://psudemo.azurewebsites.net"
 },

Variable d'environnement

$Env:Api__Url = "https://psudemo.azurewebsites.net"

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. Cela n'est pas requis pour les installations LiteDB.

$Env:NodeName = "psuazure"

PORT et WEBSITES_PORT (Linux uniquement)

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

Après la publication de l'application web, accédez à votre instance PowerShell Universal en naviguant vers l'URL de l'application web.

Stockage persistant

Le fichier appsettings.json par défaut stocke 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 pour Universal. Définissez la valeur comme suit.

D:\home\Data\PowerShellUniversal\Repository

Mise à jour de votre application web

Lorsqu'une nouvelle version de PowerShell Universal est publiée, vous devrez mettre à jour les fichiers d'application de votre application web. 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 application web en utilisant l'API de commande Kudu. Vos informations d'identification Kudu utilisent l'authentification Basic et sont les mêmes que vos informations d'identification de déploiement.

Pour supprimer tous les fichiers de votre application web, exécutez la commande suivante.

$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

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

Passerelle d'application

Vous pouvez configurer PowerShell Universal pour qu'il s'exécute derrière une passerelle d'application dans Azure. Cela est utile pour fournir un équilibrage de charge et une haute disponibilité à plusieurs instances PowerShell Universal.

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

Pour les paramètres du pool principal, vous devrez vous assurer d'utiliser HTTPS avec un certificat CA bien connu. L'affinité basée sur les cookies est requise pour garantir que les sessions sont liées à un nœud individuel.

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

Assurez-vous que la règle du pool principal 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 des URL en 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 passerelle d'application en utilisant un fournisseur DNS pour un nom d'hôte personnalisé. Créez un enregistrement A dans votre gestion DNS.

PrécédentHébergement SuivantHaute disponibilité

Mis à jour il y a 1 mois

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