Personalizza il piano di migrazione per i servizi Windows IIS
Esamina il file del piano di migrazione che è stato compilato durante la creazione della migrazione. Puoi personalizzarlo prima di procedere con la migrazione. I dettagli del piano di migrazione vengono utilizzati per estrarre gli artefatti dei container dei carichi di lavoro dalla VM di origine.
Questa sezione descrive i contenuti del piano di migrazione e i tipi di personalizzazioni che potresti prendere in considerazione prima di eseguire la migrazione e generare gli artefatti di deployment.
Prima di iniziare
Questo documento presuppone che tu abbia già creato un piano di migrazione e disponga del file del piano di migrazione risultante.
Struttura del piano di migrazione
Di seguito è riportata la struttura completa del piano di migrazione. Nelle sezioni successive viene spiegata questa struttura, spiegando di cosa si tratta e come modificarla.
globalSettings:
globalIis:
enablegmsa: string
apppools:
- enable32bitapponwin64: bool
identitytype: string
managedruntimeversion: string
name: string
connectionStrings:
add:
- connectionstring: string
name: string
providername: string
security:
authentication:
windowsAuthentication:
enabled: bool
providers:
- value: string
authorization:
add:
- access_type: string
roles: string
users: string
verbs: string
remove:
- roles: string
users: string
verbs: string
image:
extraFeatures:
- string
target:
baseVersion: string
requirements:
- string
warnings:
- string
msvcRuntimes:
- string
pathEnvVarAdditionalEntries:
- string
images:
- name: string
probes:
enabled: bool
livenessProbe:
probehandler:
exec:
command:
- string
- string
initialdelayseconds: int
timeoutseconds: int
periodseconds: int
successthreshold: int
failurethreshold: int
terminationgraceperiodseconds: optional[int]
readinessProbe:
probehandler:
exec:
command:
- string
- string
initialdelayseconds: int
timeoutseconds: int
periodseconds: int
successthreshold: int
failurethreshold: int
terminationgraceperiodseconds: optional[int]
useractions:
files:
- source: string
target: string
registry:
currentcontrolset:
- path: string
software:
- path: string
workloads:
sites:
site:
- applications:
- applicationpool: string
path: string
virtualdirectories:
- path: string
physicalpath: string
bindings:
- port: int
protocol: string
sslflags: int
connectionstrings:
- connectionstring: string
name: string
providername: string
name: string
security:
authentication:
windowsAuthentication:
enabled: bool
providers:
- value: string
authorization:
add:
- access_type: string
roles: string
users: string
verbs: string
remove:
- roles: string
users: string
verbs: string
serverautostart: bool
version: string
La sezione globalSettings
La sezione globalSettings
descrive i requisiti di base per i pod che eseguono siti IIS da questa VM. Il processo di rilevamento cerca configurazioni generali nella VM di origine e le utilizza per completare questa sezione. Queste configurazioni
contengono i campi presenti nelle configurazioni immagine specifiche, come descritto nella
seguente sezione, e hanno effetto su tutte le immagini contemporaneamente.
La sezione image
La sezione image
che segue globalSettings
descrive l'elenco di
funzionalità di Windows
da installare nei pod. Il processo di rilevamento completa questa sezione con tutte le funzionalità di Windows che esistono sulla VM originale e possono essere installate in un container Windows.
La sezione msvcRuntimes
Quando si esegue la migrazione di un'applicazione, potrebbe dipendere da una o più versioni specifiche di Microsoft Visual C++ Runtime (MSVCRT). Migrate to Containers rileva automaticamente i runtime installati sulla VM di origine e li include nel piano di migrazione.
Puoi modificare l'elenco dei runtime nel piano di migrazione aggiungendo o rimuovendo i membri di msvcRuntimes
:
Ecco l'elenco completo dei valori possibili: (Il runtime 2015 include anche il supporto per il 2017, 2019 e 2022)
msvcRuntimes:
- MSVC2012_x64
- MSVC2013_x64
- MSVC2015_x64
- MSVC2012_x86
- MSVC2013_x86
- MSVC2015_x86
La sezione pathEnvVarAdditionalEntries
Le applicazioni Windows IIS potrebbero avere voci di variabile di ambiente PATH
non predefinite, che vengono rilevate automaticamente nella VM di origine e incluse nel piano di migrazione. Puoi modificare le variabili di ambiente PATH
modificando i membri di pathEnvVarAdditionalEntries
:
pathEnvVarAdditionalEntries:
- "C:\\myDllsFolder"
- "C:\\ProgramData\\SomeSoftware"
Modifica la sezione dell'immagine
Potrebbe essere opportuno modificare la sezione image
nei seguenti casi:
Alcune funzionalità suggerite non sono richieste dai siti sottoposti a migrazione. Questo si verifica se la VM di origine ha utilizzi diversi dall'hosting di siti IIS.
Hai modificato le sezioni IIS nel piano di migrazione e hai aggiunto configurazioni che dipendono da funzionalità aggiuntive di Windows. Ad esempio, l'autenticazione Windows dipende dalla funzionalità di autenticazione di Windows.
La sezione target
La sezione target
specifica quale immagine Windows di base stai utilizzando (ad esempio, 1909). Raramente è necessario modificare questo campo.
La sezione images
Ogni elemento secondario della sezione images
specifica una singola immagine di output.
Nel file ZIP degli artefatti, ogni immagine di questo tipo ha una sottodirectory separata, con i propri Dockerfile
e deployment_spec.yaml
(vedi Deployment dell'immagine container).
Il campo name
Il campo name
descrive il nome dell'immagine.
Interessa il nome della sottodirectory dell'immagine e il file deployment_spec.yaml
negli artefatti.
Il campo probes
Il campo probes
descrive la configurazione del probe di integrità dell'immagine. Per
scoprire di più sui probe kubelet, consulta
Configurare probe di attività, idoneità e avvio.
Modifica probe di integrità IIS
I probe di integrità possono monitorare il tempo di inattività e lo stato di pronto dei container gestiti. Il monitoraggio del probe di integrità può aiutare a ridurre i tempi di inattività dei container di cui è stata eseguita la migrazione e a fornire un monitoraggio migliore.
Gli stati di integrità sconosciuti possono causare un peggioramento della disponibilità, il monitoraggio della disponibilità di falsi positivi e la potenziale perdita di dati. Senza un probe di integrità, kubelet può assumere solo l'integrità di un container e potrebbe inviare traffico a un'istanza di container non pronta. Se l'istanza non è pronta, può causare perdita di traffico. Inoltre, kubelet potrebbe non rilevare i container che sono in uno stato bloccato e non li riavvia.
Un probe di integrità funziona eseguendo una piccola istruzione basata su script all'avvio del container. Lo script verifica a ogni periodo la presenza di condizioni riuscite, definite in base al tipo di probe utilizzato. Il periodo è definito nel piano di migrazione da un campo periodSeconds
. Puoi definire questi probe manualmente
quando personalizzi il piano di migrazione.
Sono disponibili tre tipi di probe da configurare. Tutti i probe sono probe v1 core definiti nel probe v1 core Reference e condividono la stessa funzione dei campi corrispondenti del container v1 core.
*Probe di attività: i probe di attività vengono utilizzati per sapere quando è necessario riavviare un container.
Probe di idoneità: i probe di idoneità vengono utilizzati per sapere quando un container è pronto per iniziare ad accettare traffico. Per iniziare a inviare traffico a un pod solo quando un probe ha esito positivo, specifica un probe di idoneità. Un probe di idoneità potrebbe funzionare in modo simile a un probe di attività. Tuttavia, un probe di idoneità indica che un pod si avvia senza ricevere traffico e a riceve traffico solo dopo l'esito positivo del probe.
Probe di avvio: kubelet utilizza i probe di avvio per sapere quando è stata avviata un'applicazione container. Se un probe di questo tipo è configurato, disabilita i controlli di attività e idoneità finché non riesce, assicurandosi che i probe non interferiscano con l'avvio dell'applicazione.
Dopo il rilevamento, la configurazione del probe viene aggiunta al piano di migrazione. I probe possono essere utilizzati nella loro configurazione predefinita, come mostrato nell'esempio che segue. La configurazione predefinita utilizza il comando exec
per i probe di attività e di idoneità. Entrambi utilizzano uno script PowerShell denominato probe.ps1
che chiama lo strumento a riga di comando IIS appcmd per controllare lo stato dei siti IIS.
I probe sono disabilitati per impostazione predefinita. Per abilitarli, imposta il flag enabled
su true
.
images: name: IMAGE_NAME probes: enabled: false livenessProbe: probehandler: exec: command: - powershell.exe - C:\m4a\probe.ps1 initialdelayseconds: 0 timeoutseconds: 1 periodseconds: 10 successthreshold: 1 failurethreshold: 3 terminationgraceperiodseconds: null readinessProbe: probehandler: exec: command: - powershell.exe - C:\m4a\probe.ps1 initialdelayseconds: 0 timeoutseconds: 1 periodseconds: 10 successthreshold: 1 failurethreshold: 3 terminationgraceperiodseconds: null
La sezione windowsServices
I container Windows creati durante una migrazione vengono eseguiti e monitorano un singolo servizio Windows IIS. Tuttavia, per funzionare correttamente, alcuni carichi di lavoro potrebbero richiedere l'esecuzione di servizi aggiuntivi, tra cui un database, un meccanismo di logging, un proxy e altro ancora.
Per eseguire altri servizi nel container di cui è stata eseguita la migrazione, aggiungi voci alla sezione windowsServices
e copia i programmi binari necessari nella sezione useractions
.
version: v1
globalSettings:
target:
…
globalIIS:
…
images:
- name: migrated-image-zgwb2
workloads:
sites:
site:
- applications:
...
bindings:
- port: 80
protocol: http
name: Default Web Site
…
windowsServices:
- MyService
useractions:
files:
- source: C:\Program Files\MyService
target: C:\Program Files\MyService
registry:
currentcontrolset:
- key: services\MyService
La sezione useractions
La sezione useractions
specifica file e chiavi di registro aggiuntivi di cui potresti voler eseguire la migrazione.
Ad esempio:
useractions: files: - source: DRIVE:\FOLDER-OR-FILE-PATH target: DRIVE:\FOLDER-OR-FILE-PATH - source: C:\myfolder target: C:\myfolder - source: D:\myfile target: D:\myfile - source: D:\myfile target: C:\myfile ... registry: currentcontrolset: - path: KEY ... software: - path: KEY ...
I percorsi specificati per currentcontrolset
e software
riguardano le chiavi nell'
hive del Registro di sistema
HKEY_LOCAL_MACHINE\System\CurrentControlSet
o nell'hive del Registro di sistema HKEY_LOCAL_MACHINE\Software
.
Modifica la sezione useractions
Per impostazione predefinita, gli unici file copiati nell'immagine sono le directory virtuali dei siti nell'immagine specificata.
Se il tuo codice o le tue configurazioni importano file dall'esterno di questa directory, devi aggiungerli alla sezione useractions
.
Inoltre, tutti i valori del Registro di sistema da cui dipende il codice devono essere aggiunti modificando
la sezione registry
di useractions
.
Impostazioni relative specificatamente a IIS
Le impostazioni relative a IIS sono suddivise in impostazioni relative a siti specifici, che fanno parte della specifica delle immagini, e impostazioni relative a tutti i siti, che seguono la sezione gloabalIis
.
La sezione sites
La sezione Siti descrive i siti di cui viene eseguita la migrazione a un'immagine specifica. È possibile che più immagini contengano lo stesso sito.
Se vuoi utilizzare
Cloud Load Balancing, Ingress o Anthos Service Mesh per gestire la configurazione SSL, devi impostare protocol
su
http
:
sites: site: - applications: - path: / virtualdirectories: - path: / physicalpath: '%SystemDrive%\inetpub\wwwroot' bindings: - port: 8080 protocol: http name: Default Web Site
La sezione apppools
La sezione apppools
descrive i pool di applicazioni creati nei pod di cui è stata eseguita la migrazione.
Il campo identitytype
specifica l'identità IIS di un pool di applicazioni come ApplicationPoolIdentity
(impostazione predefinita), NetworkService
, LocalSystem
o LocalService
.
Per ulteriori informazioni, consulta Informazioni sulle identità in IIS e Identità dei pool di applicazioni.
Di seguito è riportato un esempio di piano di migrazione contenente identitytype
:
migrationPlan: applications: iis: applicationhost: apppools: - name: DefaultAppPool # Allowed values include: ApplicationPoolIdentity (default), NetworkService, LocalSystem, LocalService identitytype="NetworkService" - managedruntimeversion: v4.0 name: .NET v4.5 Classic - managedruntimeversion: v4.0 name: .NET v4.5
Quando esegui il piano di migrazione per generare gli artefatti dei container, Migrate to Containers aggiunge automaticamente le direttive Dockerfile necessarie in base all'impostazione del campo identitytype
.
Ad esempio, se imposti identitytype
su NetworkService
, l'istruzione avrà il seguente formato:
RUN c:\windows\system32\inetsrv\appcmd.exe set apppool \"DefaultAppPool\" \"/-processModel.identityType:NetworkService\";
Migrate to Containers aggiunge automaticamente istruzioni ACL di lettura alle cartelle del sito in base al identitytype
di destinazione e per l'utente integrato IUSR.
Questa operazione viene eseguita automaticamente per gli elementi del file system dell'applicazione in cui l'account dell'applicazione originale è stato specificato per ereditarietà o in modo esplicito.
Per ulteriori informazioni, consulta Impostare gli ACL.
Il campo enablegmsa
Il campo enablegmsa
è la zucchero sintattica nel piano di migrazione. È una
scorciatoia per sovrascrivere il campo identity del pool di applicazioni.
I valori supportati per il campo enablegmsa
sono:
auto
(impostazione predefinita): converti il container di cui è stata eseguita la migrazione per utilizzare gMSA se Migrate to Containers determina che la configurazione attuale non è consentita.all
: converti sempre il container di cui è stata eseguita la migrazione in modo che utilizzi gMSA e ignora l'impostazione diidentitytype
. In questo caso,identitytype
viene sempre interpretato come impostato suNetworkService
.
Di seguito è riportato un esempio di piano di migrazione contenente enablegmsa
:
migrationPlan: applications: iis: # Allowed values include: auto (default), all enablegmsa: auto|all
Per scoprire di più, consulta Configurare l'app per l'utilizzo di un gMSA.
Stringhe di connessione
Le stringhe di connessione definiscono una connessione dal carico di lavoro del container di cui è stata eseguita la migrazione a un provider di dati .NET Framework.
Migrate to Containers supporta le stringhe di connessione a livello di sito e di ambito globale.
Per aggiungere una stringa di connessione a un sito, modifica la definizione di site
nel
piano di migrazione per impostare la proprietà connectionstrings
:
sites: site: # Add the site connection strings here. connectionstrings: - name: connectionname1 providername: System.Data.SqlClient connectionstring: Database=connectedDB1;Password=Welcome1;User=admin; - name: connectionname2 providername: System.Data.OleDb connectionstring: Database=connectedDB2;Password=Welcome2;User=admin; - applications: - path: / virtualdirectories: ...
Per aggiungere una stringa di connessione all'ambito globale (rendendola accessibile a tutti
i siti), modifica le stringhe di connessione direttamente dopo globalIis
:
globalIis: enablegmsa: auto connectionStrings: connectionstring: - name: connectionname3 providername: System.Data.SqlClient connectionstring: Database=connectedDB3;Password=Welcome3;User=admin; applicationhost: ...
Dove:
name
specifica il nome della connessione.providername
specifica facoltativamente il tipo di fornitore di dati. Migrate to Containers supporta solo il valoreSystem.Data.SqlClient
. supporta il provider di dati .NET Framework:System.Data.SqlClient
System.Data.OleDb
System.Data.Odbc
System.Data.OracleClient
connectionstring
specifica le stringhe di connessione utilizzate per la connessione al provider di dati.
Modifica le sezioni delle stringhe di connessione
Migrate to Containers copia automaticamente le stringhe di connessione rilevate nella VM di cui è stata eseguita la migrazione nel piano di migrazione.
Alcune stringhe di connessione potrebbero non essere rilevate e devono essere aggiunte modificando
il piano di migrazione come mostrato in precedenza. Ad esempio, se le stringhe di connessione si trovano in una sezione criptata del file applicationhost.config
.
Per indicazioni su come determinare quali stringhe di connessione aggiungere al piano di migrazione, consulta Recupero delle stringhe di connessione in fase di esecuzione nella documentazione di Microsoft.
Dipendenze esterne della stringa di connessione
- Le stringhe di connessione possono contenere dipendenze, ad esempio un riferimento a un file su o a un utente Windows associato al sito. Puoi aggiungere azioni utente personalizzate al piano di migrazione per copiare un file aggiuntivo nel file system. Modifica manualmente il Dockerfile per aggiungere un utente Windows.
- Le stringhe di connessione possono contenere dipendenze, ad esempio un riferimento a un'origine dati esterna. La migrazione di queste dipendenze deve essere eseguita manualmente per garantire che il carico di lavoro del container di cui è stata eseguita la migrazione abbia accesso all'origine dati.
La sezione security
Le sezioni sulla sicurezza contengono le sottosezioni relative all'autenticazione e all'autorizzazione.
- L'autenticazione Windows consente di verificare gli utenti di Active Directory.
- L'autorizzazione di Windows è il meccanismo che specifica a quali utenti sono consentiti i tipi di accesso a un sito web IIS. I tipi di accesso sono i verbi HTTP (POST, GET, PUT, PATCH, DELETE).
Analogamente alle stringhe di connessione, per impostare l'autorizzazione o l'autenticazione per tutti i siti, modifica globalIis
come nell'esempio seguente. Per impostare l'autorizzazione o l'autenticazione per un sito specifico, modifica l'elemento del sito.
globalIis: security: authentication: windowsAuthentication: providers: - NTLM authorization: - add: user:John access: role: - remove: user:Jane access: GET role: ...
Dove:
providers
specifica il provider dei tuoi protocolli di sicurezza.user
specifica il nome utente.access
specifica le autorizzazioni dell'utente. I tipi di accesso sono i verbi HTTP (POST, GET, PUT, PATCH, DELETE).role
specie un ruolo di autorizzazione specifico.
Passaggi successivi
- Scopri come eseguire la migrazione.