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:

  1. 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.

  2. 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.

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 von identitytype. In diesem Fall wird für identitytype immer vom Wert NetworkService ausgegangen.

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:

  • name gibt den Verbindungsnamen an.
  • providername gibt optional den Datenanbietertyp an. Migrate to Containers unterstützt nur den Wert System.Data.SqlClient. unterstützt den .NET Framework-Datenanbieter:
    • System.Data.SqlClient
    • System.Data.OleDb
    • System.Data.Odbc
    • System.Data.OracleClient
  • connectionstring gibt 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:

  • providers gibt den Anbieter Ihrer Sicherheitsprotokolle an.
  • user gibt den Nutzernamen an.
  • access gibt die Berechtigungen des Nutzers an. Die Zugriffstypen sind die HTTP-Verben (POST, GET, PUT, PATCH, DELETE).
  • role gibt eine bestimmte Rolle für die Berechtigung an.

Nächste Schritte