Personaliza el plan de migración para los servicios de Windows IIS

Revisa el archivo del plan de migración que se propagó durante la creación de la migración. Puedes personalizarlo antes de ejecutar la migración. Los detalles de tu plan de migración se usan para extraer los artefactos de contenedor de la carga de trabajo de la VM fuente.

En esta sección, se describe el contenido de la migración y los tipos de personalizaciones que puedes tener en cuenta antes de ejecutar la migración y generar artefactos de implementación.

Antes de comenzar

En este documento, se supone que ya creaste un plan de migración y que tienes el archivo del plan de migración resultante.

Estructura del plan de migración

A continuación, se muestra la estructura completa del plan de migración. En las secciones siguientes, se analiza esta estructura y se explica qué es cada parte y cómo 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 sección globalSettings.

En la sección globalSettings, se describen los requisitos básicos para los Pods que ejecutan sitios de IIS desde esta VM. El proceso de descubrimiento busca configuraciones generales en la VM de origen y las usa para propagar esta sección. Estos parámetros de configuración contienen campos presentes en los parámetros específicos de la imagen, como se describe en la siguiente sección, y afectan a todas las imágenes al mismo tiempo.

La sección image.

En la siguiente sección image en globalSettings, se describe la lista de funciones de Windows para instalar en los Pods. El proceso de descubrimiento propaga esta sección con todas las funciones de Windows que existen en la VM original y se pueden instalar en un contenedor de Windows.

La sección msvcRuntimes.

Al migrar una aplicación, esta podría tener una dependencia en una versión o versiones específicas del entorno de ejecución de Microsoft Visual C++ (MSVCRT). Migrate to Containers detecta automáticamente los entornos de ejecución instalados en la VM de origen y los incluye en el plan de migración.

Puedes modificar la lista de entornos de ejecución en el plan de migración al agregar o quitar miembros de msvcRuntimes:

La lista completa de valores posibles es la siguiente: (El entorno de ejecución de 2015 también incluye asistencia para 2017, 2019 y 2022)

    msvcRuntimes:
        - MSVC2012_x64
        - MSVC2013_x64
        - MSVC2015_x64
        - MSVC2012_x86
        - MSVC2013_x86
        - MSVC2015_x86

La sección pathEnvVarAdditionalEntries.

Las aplicaciones IIS de Windows pueden tener entradas de variable de entorno PATH no predeterminadas, que se detectan de forma automática en la VM de origen y se incluyen en el plan de migración. Puedes modificar las variables de entorno PATH si editas los miembros de pathEnvVarAdditionalEntries:

    pathEnvVarAdditionalEntries:
      - "C:\\myDllsFolder"
      - "C:\\ProgramData\\SomeSoftware"

Edita la sección de la imagen

Recomendamos editar la sección image en los siguientes casos:

  1. Los sitios migrados no requieren algunas funciones sugeridas si la VM de origen tiene usos además de alojar sitios de IIS.

  2. Modificaste las secciones IIS del plan de migración y agregaste parámetros de configuración que dependen de características adicionales de Windows. (por ejemplo, la autenticación de Windows depende de la función de autenticación de Windows).

La sección target.

En la sección target, se especifica la imagen base de Windows que usas (por ejemplo, 1909). En pocas ocasiones deberás editar este campo.

La sección images.

Cada subelemento de la sección images especifica una sola imagen de salida.
En el ZIP con los artefactos, cada imagen tiene un subdirectorio independiente, con sus propios Dockerfile y deployment_spec.yaml (consulta Implementa la imagen de contenedor).

El campo name

El campo name describe el nombre de la imagen. Afecta el nombre del subdirectorio de imagen y el archivo deployment_spec.yaml en los artefactos.

El campo probes

El campo probes describe la configuración del sondeo de estado de la imagen. Para obtener más información sobre los sondeos de kubelet, consulta Configura sondeos de funcionamiento, inicio y preparación.

Edita los sondeos de estado de IIS

Los sondeos de estado pueden supervisar el tiempo de inactividad y el estado preparación de tus contenedores administrados. La supervisión del sondeo de estado puede ayudar a reducir el tiempo de inactividad de los contenedores migrados y proporcionar una mejor supervisión.

Los estados desconocidos pueden causar una degradación de la disponibilidad, una supervisión de disponibilidad falso positivo y una posible pérdida de datos. Sin un sondeo de estado, kubelet solo puede suponer el estado de un contenedor y puede enviar tráfico a una instancia de contenedor que no esté lista. Si la instancia no está lista, se puede provocar la pérdida de tráfico. Es posible que kubelet tampoco detecte los contenedores que están en estado inmovilizado y no los reinicia.

Un sondeo de estado ejecuta una declaración con una secuencia de comandos pequeña cuando se inicia el contenedor. La secuencia de comandos verifica las condiciones correctas, que se definen según el tipo de sondeo que se usa, en cada período. El período se define en el plan de migración mediante un campo periodSeconds. Puedes definir estos sondeos de forma manual cuando personalizas el plan de migración.

Hay tres tipos de sondeos disponibles para configurar. Todos los sondeos son probe v1-core definido en la referencia de probe v1-core, y comparten la misma función que los campos correspondientes de container v1-core.

  • *Sondeo en funcionamiento:: los sondeos en funcionamiento se usan para saber cuándo reiniciar un contenedor.

  • Sondeo de preparación: Los sondeos de preparación se usan para saber cuándo un contenedor está listo para comenzar a aceptar tráfico. Para comenzar a enviar tráfico a un Pod solo cuando un sondeo es correcto, especifica un sondeo de preparación. Un sondeo en preparación puede actuar de manera similar a un sondeo en funcionamiento. Sin embargo, un sondeo en preparación indica que un pod comenzará sin recibir tráfico y solo empezará a recibirlo después de que el sondeo tenga éxito.

  • Sondeo de inicio: Kubelet usa sondeos de inicio para saber cuándo se inició una aplicación de contenedor. Si este sondeo está configurado, inhabilita las verificaciones en funcionamiento y en preparación hasta que tenga éxito, lo que garantiza que esos sondeos no interfieran en el inicio de la aplicación.

Después de la detección, la configuración del sondeo se agrega al plan de migración. Los sondeos se pueden usar en la configuración predeterminada, como se muestra en el siguiente ejemplo. La configuración predeterminada usa el comando exec para los sondeos de funcionamiento y de preparación. Ambos usan una secuencia de comandos de PowerShell llamada probe.ps1 que llama a la herramienta de línea de comandos de IIS appcmd para verificar el estado de los sitios de IIS.

Los sondeos están inhabilitados de forma predeterminada. Para habilitarlos, establece la marca enabled en 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 sección windowsServices.

Son los contenedores de Windows creados durante una ejecución de migración y supervisión de un solo servicio de IIS de Windows. Sin embargo, algunas cargas de trabajo pueden requerir la ejecución de servicios adicionales (incluida una base de datos, un mecanismo de registro, un proxy y mucho más) para funcionar de manera correcta.

Para ejecutar servicios adicionales en el contenedor migrado, añade entradas a la sección windowsServices y copia los objetos binarios necesarios en la useractionssección.

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 sección useractions.

En la sección useractions, se especifican los archivos adicionales y las claves de registro que puedes migrar.

Por ejemplo:

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

Las rutas especificadas para currentcontrolset y software son rutas a claves en los subárboles de registro HKEY_LOCAL_MACHINE\System\CurrentControlSet o en los subárboles de registro HKEY_LOCAL_MACHINE\Software.

Edita la sección useractions

De forma predeterminada, los únicos archivos que se copian en la imagen son los directorios virtuales de los sitios en la imagen especificada.
Si tu código o configuración importan archivos desde fuera de este directorio, debes agregarlos a la sección useractions.
Además, cualquier valor de registro del que dependa tu código debe agregarse mediante la edición de la sección registry de useractions.

La configuración relacionada con IIS se divide en configuraciones relacionadas con sitios específicos, que forman parte de la especificación de imagen, y configuraciones relacionada con todos los sitios, que se encuentran en la sección gloabalIis.

La sección sites.

En la sección sites, se describen los sitios que se migran a una imagen específica. Es posible que varias imágenes contengan el mismo sitio.

Si deseas usar Cloud Load Balancing, Ingress o Cloud Service Mesh para controlar la configuración de SSL, debes establecer protocol como http:

sites:
  site:
  - applications:
    - path: /
      virtualdirectories:
        - path: /
          physicalpath: '%SystemDrive%\inetpub\wwwroot'
          bindings:
          - port: 8080
            protocol: http
          name: Default Web Site

La sección apppools.

En la sección apppools, se describen los grupos de aplicaciones que se crearon en los Pods migrados.

El campo identitytype especifica la identidad de IIS de un grupo de aplicaciones como ApplicationPoolIdentity (predeterminado), NetworkService, LocalSystem o LocalService.

Para obtener más información, consulta Información sobre las identidades en IIS y también Identidades del grupo de aplicaciones.

Lo siguiente es un plan de migración de ejemplo que contiene 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

Al ejecutar el plan de migración para generar los artefactos del contenedor, Migrate to Containers agrega de forma automática las directivas de Dockerfile necesarias según la configuración del campo identitytype.

Por ejemplo, si configuras identitytype como NetworkService, la directiva tiene la siguiente forma:

RUN c:\windows\system32\inetsrv\appcmd.exe set apppool \"DefaultAppPool\" \"/-processModel.identityType:NetworkService\";

Migrate to Containers agrega automáticamente directivas de LCA de lectura a las carpetas del sitio, de acuerdo con el identitytype de destino y para el usuario integrado en IUSR. Esto se hace de forma automática para los elementos del sistema de archivos de la aplicación en los que la cuenta de la aplicación original se especificó mediante una herencia o de manera explícita.

Para obtener más información, consulta Establece las LCA.

El campo enablegmsa

El campo enablegmsa es una sintaxis edulcorada sintética en el plan de migración. Es un acceso directo para reemplazar el campo identity del grupo de aplicaciones.

Estos son los valores admitidos para el campo enablegmsa:

  • auto (predeterminado): Convierte el contenedor migrado para usar gMSA si Migrate to Containers determina que no se permite su configuración actual.
  • all: Siempre convierte el contenedor migrado para que use gMSA e ignora la configuración de identitytype. En este caso, identitytype siempre se interpreta como establecido en NetworkService.

Lo siguiente es un plan de migración de ejemplo que contiene enablegmsa:

migrationPlan:
    applications:
      iis:
        # Allowed values include: auto (default), all
        enablegmsa: auto|all

Para obtener más información, consulta Cómo configurar tu app para usar una gMSA.

Cadenas de conexión

Las cadenas de conexión definen una conexión desde la carga de trabajo del contenedor migrada a un proveedor de datos de .NET Framework.

Migrate to Containers admite strings de conexión en el sitio y el permiso global.

Para agregar un string de conexión a un sitio, edita la definición site en el plan de migración para configurar la propiedad 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:
      ...

Para agregar una string de conexión al alcance global (para que todos los sitios sean accesibles), edita las strings de conexión directamente después de globalIis:

globalIis:
  enablegmsa: auto
  connectionStrings:
  connectionstring:
    - name: connectionname3
      providername: System.Data.SqlClient
      connectionstring: Database=connectedDB3;Password=Welcome3;User=admin;
  applicationhost:
      ...

Aquí:

  • name especifica el nombre de la conexión.
  • providername especifica de forma opcional el tipo de proveedor de datos. La migración a contenedores solo admite un valor de System.Data.SqlClient. Admite el proveedor de datos de .NET Framework:
    • System.Data.SqlClient
    • System.Data.OleDb
    • System.Data.Odbc
    • System.Data.OracleClient
  • connectionstring especifica las cadenas de conexión que se usan para conectarse al proveedor de datos.

Edita las secciones de strings de conexión

Migrate to Containers copia automáticamente las strings de conexión detectadas en la VM asignada al plan de migración.

Es posible que algunas strings de conexión no se detecten y deban agregarse mediante la edición del plan de migración como se muestró anteriormente (es decir, que si las strings de conexión están en la sección encriptada del archivo applicationhost.config).

Para obtener una orientación sobre cómo determinar qué cadenas de conexión agregar a tu plan de migración, consulta Recupera cadenas de conexión en el entorno de ejecución en la documentación de Microsoft.

Dependencias externas de la string de conexión

  • Las strings de conexión pueden contener dependencias, como una referencia a un archivo o un usuario de Windows asociado con el sitio. Puedes agregar acciones de usuario personalizadas al plan de migración para copiar un archivo adicional en el sistema de archivos. Edita el Dockerfile de forma manual para agregar un usuario de Windows.
  • Las strings de conexión pueden contener dependencias, como una referencia a una fuente de datos externa. Estas dependencias se deben migrar de forma manual para garantizar que la carga de trabajo del contenedor migrado tenga acceso a la fuente de datos.

La sección security.

La sección security contiene las subsecciones authentication y authorization.

  • La autenticación de Windows verifica que los usuarios de Active Directory estén activos.
  • La autorización de Windows es el mecanismo que permite especificar qué usuarios están autorizados a acceder a un sitio web IIS. Los tipos de acceso son los verbos HTTP (POST, GET, PUT, PATCH y DELETE).

Al igual que con las strings de conexión, para configurar la autorización o la autenticación de todos los sitios, edita globalIis como en el siguiente ejemplo. Para establecer la autorización o autenticación de un sitio específico, edita el elemento del sitio.

globalIis:
    security:
      authentication:
        windowsAuthentication:
          providers:
          - NTLM
      authorization:
        - add:
          user:John
          access:
          role:
         - remove:
              user:Jane
              access: GET
              role: 
            ...

Aquí:

  • providers especifica el proveedor de los protocolos de seguridad.
  • user es el nombre de usuario.
  • access especifica los permisos del usuario. Los tipos de acceso son los verbos HTTP (POST, GET, PUT, PATCH y DELETE).
  • role produce un rol de permiso específica.

¿Qué sigue?