IIS

Hosting in IIS

PowerShell Universal supporta l'hosting in IIS (Internet Information Services (IIS) per Windows® Server). Si noti che sono necessari una serie di prerequisiti dell'host e passaggi di configurazione specifici per consentire l'esecuzione di PowerShell Universal su IIS. Esamini attentamente ogni sezione, poiché IIS richiede molte impostazioni di configurazione specifiche per funzionare con applicazioni .NET Core moderne come PowerShell Universal.

Passaggio 1: preparazione dell'host IIS

I seguenti componenti sono necessari per ospitare PowerShell Universal in IIS.

Internet Information Services (IIS) versione 10.0
- Incluso: WebSocket Protocol
ASP.NET Core Hosting Bundle 10.0

È inoltre necessario abilitare sull'host IIS le seguenti funzionalità IIS di Windows Server:

Nome visualizzato della funzionalità

Requisito

Script di installazione

WebSocket Protocol

Necessario per eseguire PowerShell Universal

Install-WindowsFeature Web-WebSockets

Autenticazione di Windows

Necessario per utilizzare l'autenticazione di Windows

Install-WindowsFeature Web-Windows-Auth

Innanzitutto si assicuri di abilitare la funzionalità IIS in Windows Server e quindi installi l'ASP.NET Core hosting bundle.

NOTA: IIS richiede spesso il riavvio dell'host dopo l'installazione del .NET Core Hosting bundle! Si consiglia vivamente di RIAVVIARE l'host IIS dopo l'installazione del .NET Core Hosting bundle.

Una volta soddisfatti questi prerequisiti, è pronto per iniziare la configurazione di PowerShell Universal in IIS.

L'abilitazione della funzionalità IIS WebDav Publishing causerà problemi con Universal. WebDav Publishing filtra le richieste HTTP e per impostazione predefinita blocca i verbi PUT e DELETE. Se WebDav Publishing è abilitato, si assicuri che sia configurato correttamente per consentire questi verbi.

Passaggio 2: download di PowerShell Universal

Scarichi la copia più recente di PowerShell Universal. Dovrà scaricare la versione archivio ZIP di PowerShell Universal. Questo archivio è realizzato specificamente per chi desidera configurare PowerShell Universal per IIS o altri server web di terze parti. Estragga il contenuto dello zip nella posizione della cartella dell'host web prevista sul suo host IIS.

Deve assicurarsi che i file dell'applicazione PowerShell Universal siano sbloccati dopo l'estrazione. Può sbloccarli con il cmdlet Unblock-File.

Get-ChildItem C:\inetpub\wwwroot -Recurse | Unblock-File

Questa posizione è molto importante e verrà richiamata in tutto questo documento. Ancora più importante, questa posizione deve essere accessibile dall'identità utilizzata dal pool di applicazioni IIS.

Passaggio 3: configurazione del pool di applicazioni IIS

Ora che l'host è pronto e abbiamo scaricato PowerShell Universal, possiamo iniziare a configurare IIS.

Il primo passaggio del processo di configurazione di IIS consiste nel creare un nuovo pool di applicazioni in IIS. Prima di iniziare la configurazione dovremmo assicurarci di selezionare un'identità valida per il pool di applicazioni IIS.

3.1: scelta di un'identità per il pool di applicazioni

L'identità del pool di applicazioni è fondamentale per PowerShell Universal, poiché sarà l'"utente predefinito" con cui verranno eseguiti i processi e le app (precedentemente note come dashboard). Sarà inoltre l'utente che eseguirà le operazioni di lettura/scrittura sul database di Universal Automation e verrà utilizzato da IIS per leggere la directory dei contenuti web ed eseguire l'applicazione.

Si consiglia di utilizzare "LocalSystem" o un account di servizio a sua scelta.

A causa delle limitazioni di IIS, le impostazioni dell'identità del pool di applicazioni hanno conseguenze IMPORTANTI sul comportamento delle opzioni "Run As" quando si utilizza Universal Automation.

Limitazioni di IIS con Universal Automation

Servizio app configurato come Local System - Gli script verranno eseguiti per impostazione predefinita con l'account di sistema ed è POSSIBILE specificare account Run as durante l'esecuzione di uno script in Universal Automation
Servizio app configurato come account di servizio - Gli script possono essere eseguiti SOLO con l'account di servizio e NON è possibile specificare un **Run as Account _**_ durante l'esecuzione degli script.

Requisiti dell'identità dell'account di servizio

Accesso completo in lettura/scrittura alla cartella dell'applicazione PowerShell Universal estratta nel Passaggio 2
Accesso completo in lettura/scrittura al database di PowerShell Universal: predefinito: C:\ProgramData\Universal Automation
Diritti di accesso come processo batch (ad es. da secpol.msc > Criteri locali > Assegnazione diritti utente

Se lo si desidera, la posizione predefinita del database può essere personalizzata tramite il file appsettings.json di PowerShell Universal.

Una volta selezionata un'identità valida, siamo pronti a creare il pool di applicazioni in IIS.

3.2: creazione del nuovo pool di applicazioni IIS

Ora che abbiamo scelto un'identità per il pool di applicazioni con accesso in lettura/scrittura alle cartelle dell'applicazione e del database di PowerShell Universal, possiamo creare il pool di applicazioni in IIS.

In IIS Manager, scelga l'opzione Add Application Pool...
- Nome: utilizzi il nome che preferisce per il pool di applicazioni
- Versione .NET CLR: nessun codice gestito
- Faccia clic su OK per creare il pool di applicazioni.

3.3: configurazione delle "Advanced Settings" del pool di applicazioni IIS

Ora che il pool di applicazioni è stato creato, dovremo configurare le Advanced Settings

Apra le "Advanced Settings" del pool di applicazioni e applichi le seguenti configurazioni:
- General / Enable 32-Bit Applications: False
- Process Model / Identity: utilizzi l'identità selezionata per il pool di applicazioni nella sezione "Scelta di un'identità per il pool di applicazioni" qui sopra.
- Process Model / Load User Profile: True

Una volta applicate le Advanced Settings, il nostro pool di applicazioni è pronto; il passaggio successivo sarà configurare il sito web IIS che utilizzerà questo pool di applicazioni.

Passaggio 4: configurazione del sito web IIS

4.1: preparazione del web.config per il nostro sito web

Ora che abbiamo un pool di applicazioni valido, dobbiamo creare un sito web IIS per esporre l'applicazione. Prima di farlo, esamineremo il file web.config di PowerShell Universal per il nostro sito web. All'interno della cartella dell'applicazione PowerShell Universal estratta troveremo un file web.config. Questo file di configurazione è stato progettato specificamente per IIS e contiene una serie di configurazioni che dobbiamo esaminare prima di creare il sito web IIS.

Soprattutto, dovremo aggiornare il valore dell'argomento "processPath" di questo file di configurazione. Questo valore fornirà a IIS il percorso esatto del file binario dell'applicazione, in modo che possa avviarla correttamente.

Apra il file web.config nella cartella dell'applicazione PowerShell Universal
- Individui la sezione <aspNetCore processPath del file di configurazione
- Modifichi l'argomento processPath da ".\Universal.Server.exe" alla posizione esatta del percorso di Universal.Server.exe (vedere la figura seguente per un esempio)
- Salvi il file per applicare la configurazione

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="C:\Program Files (x86)\Universal\Universal.Server.exe" arguments="" forwardWindowsAuthToken="false" stdoutLogEnabled="true" stdoutLogFile=".\logs\log" hostingModel="InProcess"/>
  </system.webServer>
</configuration>

In questo file sono presenti diverse configurazioni aggiuntive. Le esamineremo in modo più dettagliato nella sezione "Configurazione avanzata", ma può fare riferimento a "Configurazioni aggiuntive di web.config" in questa pagina per maggiori dettagli

4.2: creazione del sito web IIS per IIS

Ora che è stato creato un pool di applicazioni per PowerShell Universal con un'identità valida e abbiamo configurato il file web.config, siamo finalmente pronti a creare il sito web IIS. Il componente Website di IIS carica gli artefatti dell'applicazione e la espone sull'endpoint web configurato.

In IIS Manager: faccia clic su "Add Website.."
Configuri le opzioni del nuovo sito web:
- Site Name: utilizzi il nome che preferisce, ad es.: PowerShell Universal.
- Application Pool: NON utilizzi il DefaultAppPool - selezioni il pool di applicazioni creato nel passaggio precedente.
- Physical Path: deve essere il percorso fisico del contenuto di PowerShell Universal estratto dal file .zip scaricato. NOTA: l'identità dell'AppPool deve avere accesso a questa posizione.
- Binding Settings: si noti che per la configurazione iniziale si consiglia di utilizzare i valori predefiniti di base; li aggiorneremo in seguito nella configurazione avanzata
  - Tipo http - per la configurazione iniziale
  - Indirizzo IP: All Unassigned
  - Porta: 80
  - Nome host: nome dell'host

Passaggio 5: avvio del sito web

A questo punto tutte le configurazioni necessarie dovrebbero essere presenti e il sito web IIS che ospita PowerShell Universal dovrebbe essere attivo e funzionante. Con un browser web, si colleghi alla posizione del sito web configurato per verificare che PowerShell Universal sia stato avviato. Da qui può seguire la guida "Guida introduttiva" per convalidare le funzionalità di base. Una volta certo che l'applicazione funzioni correttamente con una configurazione IIS di base, può procedere alla "Configurazione avanzata" per proteggere e finalizzare la configurazione IIS desiderata.

Se riscontra ancora problemi con la configurazione IIS di base, provi a controllare il percorso "Logs" specificato nel web.config per individuare i problemi comuni. Se i problemi persistono, si rivolga ai forum o al supporto per assistenza.

Applicazioni IIS annidate

È possibile annidare più istanze di PowerShell Universal in un unico pool di applicazioni e sito web, ma sono necessarie alcune configurazioni aggiuntive.

Dovrà disporre di due cartelle per i file dell'applicazione: una per ciascuna applicazione. Dovrà inoltre configurare due cartelle di dati: una per ciascuna applicazione.

Una volta configurata la struttura delle cartelle, dovrà creare due file appsettings.json e aggiornare i file web.config per ciascuna applicazione.

All'interno dei file appsettings.json dovrà impostare i percorsi corretti dei file di dati per ciascuna istanza. Dovrà inoltre configurare l'URL di base corretto per il sito annidato.

{
  "Kestrel": {
    "BasePath": "/psu1"
  },
  "Logging": {
    "Path": "C:\\src\\psu\\data1\\log.txt",
  },
  "Data": {
    "RepositoryPath": "C:\\src\\psu\\data1\\Repository",
    "ConnectionString": "filename=C:\\src\\psu\\data1\\database.db;upgrade=true",
  }
}

Successivamente dovrà aggiornare i file web.config di ciascun sito per utilizzare il file appsettings.json corretto e l'hosting OutOfProcess.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath=".\Universal.Server.exe" arguments="--appsettings C:\src\psu\appsettings.psu1.json" forwardWindowsAuthToken="false" stdoutLogEnabled="true" stdoutLogFile=".\logs\log" hostingModel="OutOfProcess" />
  </system.webServer>
</configuration>
<!--ProjectGuid: 588ACF2E-9AE5-4DF1-BC42-BCE16A4C4EDE-->

Ora, all'interno di IIS Manager, faccia clic con il pulsante destro del mouse sulle cartelle psu1 e psu2 per convertirle in applicazioni.

Ora dovrebbe essere in grado di accedere alla console di amministrazione di PowerShell Universal a entrambi i seguenti URL.

http://localhost/psu1/admin
http://localhost/psu2/admin

Configurazione per i processi

Impostazioni del pool di applicazioni non configurate correttamente possono causare la mancata esecuzione dei processi. La causa principale è il riciclo del pool di applicazioni o il mancato avvio dell'app web all'avvio del server. Questo non è un problema per funzionalità come API o App (precedentemente note come Dashboard), ma a causa dell'elaborazione in background dei processi dovrà assicurarsi che il server avvii il sito web e lo mantenga in esecuzione. Può saperne di più qui.

Se intende eseguire processi pianificati all'interno della sua istanza di PowerShell Universal ospitata in IIS, deve assicurarsi di configurare IIS in modo appropriato. Ci sono diverse impostazioni da verificare durante la configurazione del pool di applicazioni.

Application Initialization

Installi la funzionalità Application Initialization del ruolo Web Server.

Impostazioni del pool di applicazioni

Dovrà configurare le seguenti impostazioni:

General: versione .NET CLR = No Managed Code.
General: Start Mode = AlwaysRunning
Process Model: impostazione Idle Time-out = 0 (disabilitata)
Recycling: Regular Time Interval = 0.

Impostazioni del sito web

All'interno del sito IIS che ospita Universal, dovrà assicurarsi che Preload sia abilitato.

Variabili di ambiente

Sebbene cerchiamo di rilevare se PSU è in esecuzione all'interno di IIS, potrebbe riscontrare problemi con l'handler di autenticazione negotiate abilitato quando non è supportato in IIS. Per essere certo che questo non costituisca un problema, può disabilitarlo completamente creando la variabile di ambiente indicata di seguito sulla macchina IIS.

$Env:PSU_DISABLE_WIN_AUTH = true

Debug dei problemi con IIS e i processi

Se riscontra ancora problemi con IIS e i processi, dovrebbe considerare di attivare il logging del riciclo di IIS per verificare che IIS mantenga il sito in esecuzione.

A partire da PowerShell Universal 3.3, può ottenere (tramite l'uptime del sistema nella home page della console di amministrazione) un buon indicatore dell'ultima volta in cui il servizio è stato avviato.

Prima della versione 3.3, può visualizzare l'uptime del server visitando la dashboard di Hangfire e facendo clic sulla scheda Servers.

Autenticazione

PowerShell Universal può utilizzare l'autenticazione anonima e l'autenticazione di Windows in IIS.

Autenticazione di Windows

Per abilitare l'autenticazione di Windows, dovrà prima abilitarla per il Web Server e quindi per il sito web. Può trovare le impostazioni di autenticazione nella sezione Authentication di IIS Manager.

Per il sito web, imposti le stesse impostazioni.

Una volta abilitata l'autenticazione in IIS, dovrà assicurarsi che l'autenticazione di Windows sia abilitata per PowerShell Universal.

Innanzitutto, modifichi il file web.config per inoltrare il token di autenticazione di Windows.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath=".\Universal.Server.exe" arguments="" forwardWindowsAuthToken="true" stdoutLogEnabled="true" stdoutLogFile=".\logs\log" hostingModel="OutOfProcess" />
  </system.webServer>
</configuration>
<!--ProjectGuid: 588ACF2E-9AE5-4DF1-BC42-BCE16A4C4EDE-->

Successivamente, abiliti l'autenticazione di Windows nel file appsettings.json per PowerShell Universal.

    "Authentication" : {
    "Windows": {
      "Enabled": "true"
    },
  }

Riavvii il pool di applicazioni e ora dovrebbe essere in grado di accedere con le credenziali di Windows.

Quando si abilita l'autenticazione di Windows ma non l'autenticazione anonima, non sarà più possibile utilizzare gli AppTokens di PowerShell Universal. Dovrà abilitare entrambi i metodi di autenticazione per supportare sia le credenziali di Windows sia gli App Tokens.

Autenticazione anonima

L'autenticazione anonima può essere abilitata per consentire la trasmissione di app tokens e altre richieste attraverso il proxy IIS. Dovrà abilitare l'autenticazione anonima sia a livello di Server sia a livello di sito Web. Non è necessaria alcuna configurazione aggiuntiva all'interno di PowerShell Universal.

Configurazioni aggiuntive di web.config

Le impostazioni all'interno del file web.config di Universal possono essere modificate come ritiene opportuno. Di seguito troverà una descrizione di ciascuna impostazione.

ForwardWindowsAuthToken

Questa impostazione viene utilizzata per l'autenticazione di Windows. Se desidera utilizzare l'autenticazione di Windows con IIS, si assicuri di disabilitare l'autenticazione anonima e di abilitare l'autenticazione di Windows all'interno del suo sito IIS, quindi imposti questa impostazione su true.

StdoutLogEnabled e StdoutLogFile

Questa impostazione viene utilizzata per il debug dei problemi di avvio della sua configurazione di Universal. Si consiglia di abilitarla durante la prima configurazione dell'integrazione con IIS. Può disabilitarla una volta che tutto è configurato. Deve assicurarsi che l'identità del suo AppPool disponga dell'accesso in scrittura alla posizione di StdOutLogFile.

HostingModel

Il modello di hosting imposta la modalità di esecuzione del server Universal. Se impostato su InProcess, il server Universal verrà eseguito all'interno dell'agente IIS. Ciò offre prestazioni migliori rispetto all'hosting OutOfProcess. L'hosting InProcess non funziona con StdOutLogEnabled. Si consiglia di utilizzare l'hosting OutOfProcess solo durante la configurazione di Universal e InProcess al termine delle fasi di configurazione.

Aggiornamento

Durante l'aggiornamento, si assicuri di non copiare (sovrascrivere) i file sopra l'installazione esistente. Al contrario, (ad eccezione dei file web.config e *.json) elimini tutti i file dell'applicazione corrente e copi quelli nuovi nella directory. La copia sopra i file dell'applicazione può comportare la presenza nella directory di installazione di file binari non previsti e può causare problemi con PowerShell Universal.

PrecedenteAlta disponibilità

SuccessivoReverse proxy

Ultimo aggiornamento 7 giorni fa

È stato utile?