Personalizar el plan de migración de servicios IIS de Windows
Revisa el archivo del plan de migración que se ha rellenado durante la creación de la migración. Puedes personalizarla antes de ejecutar la migración. Los detalles de tu plan de migración se usan para extraer los artefactos del contenedor de la carga de trabajo de la VM de origen.
En esta sección se describe el contenido del plan de 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 empezar
En este documento se da por hecho que ya has creado un plan de migración y que tienes el archivo correspondiente.
Estructura del plan de migración
A continuación, se muestra la estructura completa del plan de migración. En las siguientes secciones se analiza esta estructura, 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 de los pods que ejecutan sitios de IIS desde esta VM. El proceso de detección busca configuraciones generales en la VM de origen y las usa para rellenar esta sección. Estas configuraciones contienen campos presentes en las configuraciones de imagen específicas, tal como se describe en la siguiente sección, y afectan a todas las imágenes al mismo tiempo.
La sección image
En la sección image que sigue a globalSettings se describe la lista de funciones de Windows que se deben instalar en los pods. El proceso de descubrimiento rellena esta sección con todas las funciones de Windows que existen en la VM original y que se pueden instalar en un contenedor de Windows.
La sección msvcRuntimes
Al migrar una aplicación, puede que tenga una dependencia de una versión o versiones específicas de Microsoft Visual C++ Runtime (MSVCRT). Migrate to Containers detecta automáticamente los tiempos de ejecución instalados en la VM de origen y los incluye en el plan de migración.
Puedes modificar la lista de tiempos de ejecución del plan de migración añadiendo o quitando miembros de msvcRuntimes:
La lista completa de valores posibles es la siguiente: (El tiempo de ejecución del 2015 también incluye compatibilidad con 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 variables de entorno PATH no predeterminadas, que se detectan automáticamente en la VM de origen y se incluyen en el plan de migración. Puedes modificar las variables de entorno de PATH editando los miembros de pathEnvVarAdditionalEntries:
pathEnvVarAdditionalEntries:
- "C:\\myDllsFolder"
- "C:\\ProgramData\\SomeSoftware"
Editar la sección de imagen
Puede que quieras editar la sección image en los siguientes casos:
Es posible que los sitios migrados no necesiten algunas de las funciones sugeridas. Esto ocurre si la VM de origen tiene otros usos además de alojar sitios de IIS.
Has modificado las secciones de IIS en el plan de migración y has añadido configuraciones que dependen de funciones adicionales de Windows. Por ejemplo, la autenticación de Windows depende de la función de autenticación de Windows.
La sección target
La sección target especifica qué imagen base de Windows estás usando (por ejemplo, 1909). Rara vez tendrás que editar este campo.
La sección images
Cada subelemento de la sección images especifica una sola imagen de salida.
En el archivo ZIP de artefactos, cada imagen tiene un subdirectorio independiente con sus propios archivos Dockerfile y deployment_spec.yaml (consulta Desplegar la imagen de contenedor).
Campo name
El campo name describe el nombre de la imagen.
Afecta al nombre del subdirectorio de imágenes y al archivo deployment_spec.yaml
de los artefactos.
Campo probes
El campo probes describe la configuración de la sonda de estado de la imagen. Para obtener más información sobre las comprobaciones de kubelet, consulta Configurar comprobaciones de vivacidad, preparación e inicio.
Editar comprobaciones de estado de IIS
Las sondas de estado pueden monitorizar el tiempo de inactividad y el estado de disponibilidad de los contenedores gestionados. La monitorización de sondas de estado puede ayudar a reducir el tiempo de inactividad de los contenedores migrados y proporcionar una mejor monitorización.
Los estados de salud desconocidos pueden provocar una degradación de la disponibilidad, una monitorización de la disponibilidad con falsos positivos y una posible pérdida de datos. Sin una sonda de estado, kubelet solo puede asumir el estado de un contenedor y podría enviar tráfico a una instancia de contenedor que no esté lista. Si la instancia no está lista, puede provocar una pérdida de tráfico. Es posible que Kubelet tampoco detecte los contenedores que estén en estado de congelación y no los reinicie.
Una sonda de estado funciona ejecutando una pequeña instrucción de script cuando se inicia el contenedor. La secuencia de comandos comprueba si se cumplen las condiciones, que se definen por el tipo de sonda utilizada, cada periodo. El periodo se define en el plan de migración mediante el campo periodSeconds. Puedes definir estas sondas manualmente
cuando personalices el plan de migración.
Hay tres tipos de sondas que se pueden configurar. Todas las sondas son sondas principales de la versión 1 definidas en la referencia de la versión 1 de la sonda y comparten la misma función que los campos correspondientes de la versión 1 del contenedor.
*Comprobación de actividad: las comprobaciones de actividad se usan para saber cuándo reiniciar un contenedor.
Sondeo de disponibilidad: se usa para saber cuándo está listo un contenedor para empezar a aceptar tráfico. Para empezar a enviar tráfico a un pod solo cuando una sonda se complete correctamente, especifica una sonda de preparación. Una comprobación de preparación puede actuar de forma similar a una comprobación de actividad. Sin embargo, una sonda de disponibilidad indica que un pod se inicia sin recibir tráfico y solo empieza a recibir tráfico después de que la sonda se complete correctamente.
Sondeo de inicio: el kubelet usa sondeos de inicio para saber cuándo se ha iniciado una aplicación de contenedor. Si se configura una sonda de este tipo, se inhabilitan las comprobaciones de actividad y de disponibilidad hasta que se complete correctamente, lo que asegura que esas sondas no interfieran con el inicio de la aplicación.
Una vez descubierto, la configuración de la sonda se añade al plan de migración. Las sondas se pueden usar en su configuración predeterminada, como se muestra en el siguiente ejemplo. La configuración predeterminada usa el comando exec para las comprobaciones de vivacidad y 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 comprobar el estado de los sitios de IIS.
Las sondas están inhabilitadas de forma predeterminada. Para habilitarlas, define la marca enabled como 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
Contenedores de Windows creados durante una ejecución de migración y monitorizan un solo servicio IIS de Windows. Sin embargo, es posible que algunas cargas de trabajo requieran ejecutar servicios adicionales (como una base de datos, un mecanismo de registro o un proxy) para funcionar correctamente.
Para ejecutar servicios adicionales en el contenedor migrado, añade entradas a la sección windowsServices y copia los archivos binarios necesarios en la sección 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 sección useractions
En la sección useractions se especifican archivos y claves de registro adicionales que puede que quieras 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 las claves del HKEY_LOCAL_MACHINE\System\CurrentControlSet registro o del HKEY_LOCAL_MACHINE\Software registro.
Edita la sección useractions.
De forma predeterminada, los únicos archivos que se copian en la imagen son los directorios virtuales de los sitios de la imagen especificada.
Si tu código o tus configuraciones importan archivos de fuera de este directorio, debes añadirlos a la sección useractions.
Además, los valores del registro de los que dependa tu código se deben añadir editando
la sección useractions registry.
Ajustes relacionados específicamente con IIS
Los ajustes relacionados con IIS se dividen en ajustes relacionados con sitios específicos, que forman parte de la especificación de la imagen, y ajustes relacionados con todos los sitios, que se indican en la sección gloabalIis.
La sección sites
En la sección Sitios se describen los sitios que se han migrado a una imagen concreta. Es posible que varias imágenes contengan el mismo sitio.
Si quieres usar Cloud Load Balancing, Ingress o Cloud Service Mesh para gestionar la configuración de SSL, debes definir protocol en 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 creados en los pods migrados.
El campo identitytype especifica la identidad de IIS de un grupo de aplicaciones como ApplicationPoolIdentity (valor predeterminado), NetworkService, LocalSystem o LocalService.
Para obtener más información, consulta Understanding identities in IIS (Información sobre las identidades en IIS) y Application Pool Identities (Identidades de grupos de aplicaciones).
A continuación, se muestra un ejemplo de plan de migración 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
Cuando ejecutas el plan de migración para generar los artefactos del contenedor, Migrate to Containers añade automáticamente las directivas de Dockerfile necesarias según el ajuste del campo identitytype.
Por ejemplo, si asignas el valor NetworkService a identitytype, la directiva tendrá el siguiente formato:
RUN c:\windows\system32\inetsrv\appcmd.exe set apppool \"DefaultAppPool\" \"/-processModel.identityType:NetworkService\";Migrate to Containers añade automáticamente directivas de ACL de lectura a las carpetas del sitio según el identitytype de destino y para el usuario integrado IUSR.
Esto se hace automáticamente en los elementos del sistema de archivos de la aplicación en los que se ha especificado la cuenta de aplicación original, ya sea por herencia o de forma explícita.
Para obtener más información, consulta Asignar LCAs.
Campo enablegmsa
El campo enablegmsa es un azúcar sintáctico en el plan de migración. Es un acceso directo para sobrescribir el campo identity del grupo de aplicaciones.
Los valores admitidos para el campo enablegmsa son los siguientes:
auto(opción predeterminada): convierte el contenedor migrado para que use gMSA si Migrar a contenedores determina que su configuración actual no está permitida.all: convierte siempre el contenedor migrado para que use gMSA e ignora el ajuste deidentitytype. En este caso,identitytypesiempre se interpreta comoNetworkService.
A continuación, se muestra un ejemplo de plan de migración que contiene enablegmsa:
migrationPlan: applications: iis: # Allowed values include: auto (default), all enablegmsa: auto|all
Para obtener más información, consulta Configurar una aplicación para que use una gMSA.
Cadenas de conexión
Las cadenas de conexión definen una conexión desde la carga de trabajo del contenedor migrado a un proveedor de datos de .NET Framework.
Migrate to Containers admite cadenas de conexión a nivel de sitio y global.
Para añadir una cadena de conexión a un sitio, edita la definición de site en el plan de migración para definir 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 añadir una cadena de conexión al ámbito global (de forma que sea accesible para todos los sitios), edita las cadenas 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: ...
Donde:
nameespecifica el nombre de la conexión.providernameespecifica de forma opcional el tipo de proveedor de datos. Migrate to Containers solo admite el valorSystem.Data.SqlClient. admite el proveedor de datos de .NET Framework:System.Data.SqlClientSystem.Data.OleDbSystem.Data.OdbcSystem.Data.OracleClient
connectionstringespecifica las cadenas de conexión que se usan para conectarse al proveedor de datos.
Editar las secciones de cadenas de conexión
Migrar a contenedores copia automáticamente las cadenas de conexión detectadas en la máquina virtual migrada al plan de migración.
Es posible que no se detecten algunas cadenas de conexión, por lo que se deben añadir editando el plan de migración como se ha mostrado anteriormente. Por ejemplo, si las cadenas de conexión se encuentran en una sección cifrada del archivo applicationhost.config.
Para obtener información sobre qué cadenas de conexión debes añadir a tu plan de migración, consulta el artículo Retrieving Connection Strings at Run Time (Obtener cadenas de conexión en tiempo de ejecución) de la documentación de Microsoft.
Dependencias externas de la cadena de conexión
- Las cadenas de conexión pueden contener dependencias, como una referencia a un archivo o a un usuario de Windows asociado al sitio. Puede añadir acciones de usuario personalizadas al plan de migración para copiar un archivo adicional en el sistema de archivos. Edita manualmente el archivo Dockerfile para añadir un usuario de Windows.
- Las cadenas de conexión pueden contener dependencias, como una referencia a una fuente de datos externa. Estas dependencias deben migrarse manualmente para asegurarse de que la carga de trabajo del contenedor migrado tenga acceso a la fuente de datos.
La sección security
Las secciones de seguridad contienen las subsecciones de autenticación y autorización.
- La autenticación de Windows verifica a los usuarios de Active Directory.
- La autorización de Windows es el mecanismo para especificar qué usuarios tienen permiso para acceder a un sitio web de IIS y de qué tipo. Los tipos de acceso son los verbos HTTP (POST, GET, PUT, PATCH y DELETE).
Al igual que con las cadenas de conexión, para definir la autorización o la autenticación de todos los sitios, edita globalIis como en el siguiente ejemplo. Para definir la autorización o la 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: ...
Donde:
providersespecifica el proveedor de tus protocolos de seguridad.userel nombre de usuario.accessespecifica los permisos del usuario. Los tipos de acceso son los verbos HTTP (POST, GET, PUT, PATCH y DELETE).roleespecifica un rol de permiso concreto.
Siguientes pasos
- Consulta cómo ejecutar la migración.