Migrationsplan für Windows IIS-Dienste anpassen
Prüfen Sie die Migrationsplandatei, die bei der Erstellung der Migration ausgefüllt wurde. Sie können diesen Wert anpassen, bevor Sie die Migration ausführen. Die Details Ihres Migrationsplans werden verwendet, um die Containerartefakte der Arbeitslast aus der Quelle zu extrahieren.
In diesem Abschnitt werden der Inhalt des Migrationsplans und die Arten von Anpassungen dargestellt, die Sie vor dem Ausführen der Migration und vor dem Erstellen von Deployment-Artefakten prüfen sollten.
Hinweise
In diesem Dokument wird davon ausgegangen, dass Sie bereits eine Migration erstellt haben und die entsprechende Migrationsplandatei vorhanden ist.
Struktur des Migrationsplans
Im Folgenden ist die vollständige Struktur des Migrationsplans dargestellt. In den nächsten Abschnitten wird diese Struktur erläutert. Außerdem wird erläutert, was die einzelnen Teile sind und wie Sie sie ändern können.
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
Der Abschnitt globalSettings.
Im Abschnitt globalSettings werden grundlegende Anforderungen für Pods beschrieben, auf denen IIS-Websites von dieser VM ausgeführt werden. Beim Erkennungsprozess wird nach allgemeinen Konfigurationen in der Quell-VM gesucht und diese verwendet, um diesen Abschnitt zu füllen. Diese Konfigurationen enthalten Felder, die in den spezifischen Image-Konfigurationen vorhanden sind, wie im folgenden Abschnitt beschrieben. Sie betreffen alle Images gleichzeitig.
Der Abschnitt image.
Der Abschnitt image unter globalSettings beschreibt die Liste der Fensterfunktionen, die auf den Pods installiert werden sollen. Im Bereich zur Erkennung werden in diesem Abschnitt alle Windows-Funktionen aufgeführt, die auf der ursprünglichen VM vorhanden sind und in einem Windows-Container installiert werden können.
Der Abschnitt msvcRuntimes.
Bei der Migration einer Anwendung kann es zu einer Abhängigkeit von einer bestimmten Version oder Versionen einer Microsoft Visual C++ Runtime (MSVCRT) kommen. Migrate to Containers erkennt automatisch die auf der Quell-VM installierten Laufzeiten und fügt sie dem Migrationsplan hinzu.
Sie können die Liste der Laufzeiten im Migrationsplan ändern. Fügen Sie dazu Mitglieder von msvcRuntimes hinzu oder entfernen Sie sie:
Die vollständige Liste möglicher Werte ist: (Die 2015-Laufzeit unterstützt auch 2017, 2019 und 2022.)
msvcRuntimes:
- MSVC2012_x64
- MSVC2013_x64
- MSVC2015_x64
- MSVC2012_x86
- MSVC2013_x86
- MSVC2015_x86
Der Abschnitt pathEnvVarAdditionalEntries.
Windows-IIS-Anwendungen haben möglicherweise nicht standardmäßige PATH-Umgebungsvariableneinträge, die automatisch auf der Quell-VM erkannt und in den Migrationsplan aufgenommen werden. Sie können die Umgebungsvariablen PATH ändern, indem Sie die Mitglieder von pathEnvVarAdditionalEntries bearbeiten:
pathEnvVarAdditionalEntries:
- "C:\\myDllsFolder"
- "C:\\ProgramData\\SomeSoftware"
Image-Abschnitt bearbeiten
Möglicherweise möchten Sie den Abschnitt image in den folgenden Fällen bearbeiten:
Einige vorgeschlagene Funktionen sind für die migrierten Standorte nicht erforderlich. Dies ist der Fall, wenn die Quell-VM nicht zum Hosten von IIS-Websites verwendet wird.
Sie haben die IIS-Abschnitte im Migrationsplan geändert und Konfigurationen hinzugefügt, die von zusätzlichen Windows-Features abhängen. Die Windows-Authentifizierung hängt beispielsweise von der Fensterauthentifizierungsfunktion ab.
Der Abschnitt target.
Der Abschnitt target gibt an, welches Basis-Windows-Image Sie verwenden (z. B. 1909). Sie sollten dieses Feld nur selten bearbeiten.
Der Abschnitt images.
Jedes Unterelement des Abschnitts images gibt ein einzelnes Ausgabebild an.
In der Artefakt-ZIP-Datei hat jedes Image ein separates Unterverzeichnis mit eigenem Dockerfile und deployment_spec.yaml (siehe Container-Image bereitstellen).
Das Feld name
Das Feld name beschreibt den Image-Namen.
Er wirkt sich auf den Namen des Bildunterverzeichnisses und die Datei deployment_spec.yaml in den Artefakten aus.
Das Feld probes
Das Feld probes beschreibt die Konfiguration der Systemdiagnose für das Image. Weitere Informationen zu kubelet-Diagnosen finden Sie unter Aktivitäts-, Bereitschafts- und Startprüfungen konfigurieren.
IIS-Systemdiagnosen bearbeiten
Mit Systemdiagnosen können Sie den Ausfallstatus und den Bereitschaftsstatus Ihrer verwalteten Container überwachen. Mit einem Monitoring der Systemdiagnose können Sie die Ausfallzeiten migrierter Container reduzieren und ein besseres Monitoring bereitstellen.
Unbekannte Systemstatus können zu einer Beeinträchtigung der Verfügbarkeit, zu falsch-positivem Verfügbarkeits-Monitoring und zu einem möglichen Datenverlust führen. Ohne eine Systemdiagnose kann kubelet den Zustand eines Containers nur „vermuten“ und sendet Traffic eventuell an eine nicht bereite Containerinstanz. Wenn die Instanz nicht bereit ist, kann dies zu Trafficverlust führen. Außerdem kann Kubelet keine Container erkennen, die sich in einem fixierten Zustand befinden, d. h. es kann diese nicht neu starten.
Eine Systemdiagnose funktioniert durch Ausführen einer kleinen skriptbasierten Anweisung beim Starten des Containers. Das Script prüft jeden Zeitraum auf erfolgreiche Bedingungen, die durch die Art der verwendeten Diagnose definiert sind. Der Zeitraum wird im Migrationsplan durch ein periodSeconds-Feld definiert. Sie können diese Prüfungen manuell definieren, wenn Sie den Migrationsplan anpassen.
Es gibt drei Arten von Prüfungen, die konfiguriert werden können. Alle Prüfungen sind „Probe-v1-Kern”, definiert in der Prüfungs-v1-Kern-Referenz und haben dieselbe Funktion wie die entsprechenden Felder von container v1 core
*Aktivitätsprüfung: Aktivitätsprüfungen werden verwendet, um festzustellen, wann ein Container neu gestartet werden muss.
Bereitschaftsprüfung: Bereitschaftsprüfungen werden verwendet, um festzustellen, wann ein Container bereit ist, Traffic anzunehmen. Wenn Sie nur dann Traffic an einen Pod senden möchten, wenn eine Prüfung erfolgreich ist, geben Sie eine Bereitschaftsprüfung an. Eine Bereitschaftsprüfung kann ähnlich wie eine Aktivitätsprüfung sein. Eine Bereitschaftsprüfung gibt jedoch an, dass ein Pod gestartet wird, ohne Traffic zu empfangen, und empfängt erst dann Traffic, wenn die Prüfung erfolgreich ist.
Startprüfung: Das kubelet verwendet Startprüfungen, um zu ermitteln, wann eine Containeranwendung gestartet wurde. Wenn eine solche Prüfung konfiguriert ist, werden Aktivitäts- und Bereitschaftsprüfungen deaktiviert, bis sie erfolgreich sind. Bei diesen Prüfungen wird der Start der Anwendung nicht beeinträchtigt.
Nach der Erkennung wird die Diagnosekonfiguration dem Migrationsplan hinzugefügt. Die Prüfungen können in der Standardkonfiguration verwendet werden, wie im folgenden Beispiel gezeigt. Die Standardkonfiguration verwendet den Befehl exec für die Aktivitäts- und Bereitschaftsprüfungen. Beide verwenden ein PowerShell-Skript namens probe.ps1, das das IIS-Befehlszeilentool appcmd aufruft, um den Status der IIS-Websites zu prüfen.
Die Prüfungen sind standardmäßig deaktiviert. Um die Prüfungen zu aktivieren, legen Sie das Flag enabled auf true fest.
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
Der Abschnitt windowsServices.
Windows-Container, die während einer Migration erstellt wurden, führen einen einzelnen Windows-IIS-Dienst aus und überwachen ihn. Bei einigen Arbeitslasten müssen Sie jedoch möglicherweise zusätzliche Dienste ausführen (einschließlich einer Datenbank, eines Logging-Mechanismus, eines Proxys usw.), um ordnungsgemäß zu funktionieren.
Wenn Sie zusätzliche Dienste im migrierten Container ausführen möchten, fügen Sie im Abschnitt windowsServices Einträge hinzu und kopieren Sie die erforderlichen Binärdateien im Abschnitt 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
Der Abschnitt useractions.
Im Abschnitt useractions werden zusätzliche Dateien und Registry-Schlüssel angegeben, die Sie migrieren möchten.
Beispiel:
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
...
Die für currentcontrolset und software angegebenen Pfade sind Schlüssel im Registry-Hive HKEY_LOCAL_MACHINE\System\CurrentControlSet oder im Registry-Hive HKEY_LOCAL_MACHINE\Software.
Abschnitt useractions bearbeiten
Standardmäßig sind nur die virtuellen Dateien von Websites im angegebenen Image kopiert.
Wenn Ihr Code oder Ihre Konfigurationen Dateien von außerhalb dieses Verzeichnisses importieren, sollten Sie sie dem Abschnitt useractions hinzufügen.
Außerdem müssen Sie alle Registry-Werte, von denen Ihr Code abhängt, im Abschnitt useractions registry hinzufügen.
Einstellungen, die sich speziell auf IIS beziehen
Die IIS-bezogenen Einstellungen sind unterteilt in Einstellungen, die sich auf bestimmte Websites beziehen, die Teil der Image-Spezifikation sind, und in Einstellungen, die sich auf alle Websites beziehen, die sich im Abschnitt gloabalIis befinden.
Der Abschnitt sites.
Im Abschnitt Websites werden die Websites beschrieben, die zu einem bestimmten Image migriert werden. Es ist möglich, dass mehrere Bilder dieselbe Website enthalten.
Wenn Sie Cloud Load Balancing, Ingress oder Anthos Service Mesh zur Verarbeitung der SSL-Konfiguration verwenden möchten, müssen Sie protocol auf http setzen:
sites:
site:
- applications:
- path: /
virtualdirectories:
- path: /
physicalpath: '%SystemDrive%\inetpub\wwwroot'
bindings:
- port: 8080
protocol: http
name: Default Web Site
Der Abschnitt apppools.
Der Abschnitt apppools beschreibt die Anwendungspools, die auf den migrierten Pods erstellt wurden.
Das identitytype-Feld gibt die IIS-Identität eines Anwendungspools als ApplicationPoolIdentity (Standardeinstellung), NetworkService, LocalSystem oder LocalService an.
Weitere Informationen finden Sie unter Grundlegendes zu Identitäten in IIS und Anwendungspool-Identitäten.
Das folgende Beispiel zeigt einen Migrationsplan mit 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
Wenn Sie den Migrationsplan zum Generieren der Containerartefakte ausführen, fügt Migrate to Containers automatisch die erforderlichen Dockerfile-Anweisungen gemäß der Feldeinstellung identitytype hinzu.
Wenn Sie beispielsweise identitytype auf NetworkService setzen, sieht die Anweisung so aus:
RUN c:\windows\system32\inetsrv\appcmd.exe set apppool \"DefaultAppPool\" \"/-processModel.identityType:NetworkService\";
Migrate to Containers fügt Lese-ACL-Anweisungen automatisch den Ordnern der Website gemäß dem Ziel identitytype und dem für IUSR integrierten Nutzer hinzu.
Dies geschieht automatisch für Elemente des Anwendungsdateisystems, in dem das ursprüngliche Anwendungskonto entweder durch Übernahme oder explizit angegeben wurde.
Weitere Informationen finden Sie unter ACLs festlegen.
Das Feld enablegmsa
Das Feld enablegmsa ist im Migrationsplan syntaktischer Zustand. Dies ist ein Kurzbefehl zum Überschreiben des Felds Identität des Anwendungspools.
Die unterstützten Werte für das Feld enablegmsa sind:
auto(Standardeinstellung): transformiert den migrierten Container zur Verwendung eines gMSA, wenn Migrate to Containers feststellt, dass die aktuelle Konfiguration nicht zulässig ist.all: transformiert den migrierten Container immer zur Verwendung eines gMSA und ignoriert die Einstellung vonidentitytype. In diesem Fall wird füridentitytypeimmer vom WertNetworkServiceausgegangen.
Das folgende Beispiel zeigt einen Migrationsplan mit enablegmsa:
migrationPlan:
applications:
iis:
# Allowed values include: auto (default), all
enablegmsa: auto|all
Weitere Informationen finden Sie unter Konfigurieren Ihrer App für die Verwendung eines gMSAs.
Verbindungsstrings
Verbindungsstrings definieren eine Verbindung von der migrierten Containerarbeitslast zu einem .NET Framework-Datenanbieter.
Migrate to Containers unterstützt Verbindungsstrings auf Standort- und globaler Ebene.
Zum Hinzufügen eines Verbindungsstrings zu einem Standort bearbeiten Sie die Definition site im Migrationsplan, um das Attribut connectionstrings festzulegen:
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:
...
Wenn Sie einen globalen Verbindungsstring hinzufügen möchten, um ihn für alle Standorte zugänglich zu machen, bearbeiten Sie die Verbindungsstrings direkt unter globalIis:
globalIis:
enablegmsa: auto
connectionStrings:
connectionstring:
- name: connectionname3
providername: System.Data.SqlClient
connectionstring: Database=connectedDB3;Password=Welcome3;User=admin;
applicationhost:
...
Wobei:
namegibt den Verbindungsnamen an.providernamegibt optional den Datenanbietertyp an. Migrate to Containers unterstützt nur den WertSystem.Data.SqlClient. unterstützt den .NET Framework-Datenanbieter:System.Data.SqlClientSystem.Data.OleDbSystem.Data.OdbcSystem.Data.OracleClient
connectionstringgibt die Verbindungsstrings an, die für die Verbindung mit dem Datenanbieter verwendet werden.
Verbindungsstring-Abschnitte bearbeiten
Migrate to Containers kopiert automatisch die in der migrierten VM erkannten Verbindungsstrings in den Migrationsplan.
Einige Verbindungsstrings werden möglicherweise nicht erkannt und sollten durch Bearbeiten des Migrationsplans wie oben gezeigt hinzugefügt werden (d. h. wenn sich die Verbindungsstrings in einem verschlüsselten Abschnitt der Datei applicationhost.config befinden).
Eine Anleitung zum Ermitteln der Verbindungsstrings, die Ihrem Migrationsplan hinzugefügt werden sollen, finden Sie unter Verbindungsstrings zur Laufzeit abrufen in der Microsoft-Dokumentation.
Externe Abhängigkeiten des Verbindungsstrings
- Verbindungsstrings können Abhängigkeiten enthalten, z. B. einen Verweis auf eine Datei bei oder zu einem mit der Website verknüpften Windows-Nutzer. Sie können dem Migrationsplan benutzerdefinierte Nutzeraktionen hinzufügen, um eine zusätzliche Datei im Dateisystem zu kopieren. Bearbeiten Sie das Dockerfile manuell, um einen Windows-Nutzer hinzuzufügen.
- Verbindungsstrings können Abhängigkeiten enthalten, z. B. einen Verweis auf eine externe Datenquelle. Diese Abhängigkeiten müssen manuell migriert werden, damit die migrierte Containerarbeitslast Zugriff auf die Datenquelle hat.
Der Abschnitt security.
Die Sicherheitsabschnitte enthalten die Unterabschnitte Authentifizierung und Autorisierung.
- Mit der Windows-Authentifizierung werden Active Directory-Nutzer überprüft.
- Die Windows-Autorisierung ist der Mechanismus, mit dem angegeben wird, welche Nutzer welchen Zugriff auf eine IIS-Website haben. Die Zugriffstypen sind die HTTP-Verben (POST, GET, PUT, PATCH, DELETE).
Ähnlich wie bei Verbindungsstrings bearbeiten Sie globalIis wie im folgenden Beispiel, um die Autorisierung oder Authentifizierung für alle Websites festzulegen. Bearbeiten Sie das Website-Element, um die Autorisierung oder Authentifizierung für eine bestimmte Website festzulegen.
globalIis:
security:
authentication:
windowsAuthentication:
providers:
- NTLM
authorization:
- add:
user:John
access:
role:
- remove:
user:Jane
access: GET
role:
...
Wobei:
providersgibt den Anbieter Ihrer Sicherheitsprotokolle an.usergibt den Nutzernamen an.accessgibt die Berechtigungen des Nutzers an. Die Zugriffstypen sind die HTTP-Verben (POST, GET, PUT, PATCH, DELETE).rolegibt eine bestimmte Rolle für die Berechtigung an.