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 una 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:
Los sitios migrados no requieren algunas funciones sugeridas si la VM de origen tiene usos además de alojar sitios de IIS.
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 registros 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.
Configuración relacionada específicamente con IIS
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 Anthos 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 deidentitytype. En este caso,identitytypesiempre se interpreta como establecido enNetworkService.
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.
Strings de conexión
Las strings 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í:
nameespecifica el nombre de la conexión.providernameespecifica de forma opcional el tipo de proveedor de datos. La migración a contenedores solo admite un valor deSystem.Data.SqlClient. Admite el proveedor de datos de .NET Framework:System.Data.SqlClientSystem.Data.OleDbSystem.Data.OdbcSystem.Data.OracleClient
connectionstringespecifica las strings 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é strings de conexión agregar a tu plan de migración, consulta Recupera strings 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í:
providersespecifica el proveedor de los protocolos de seguridad.useres el nombre de usuario.accessespecifica los permisos del usuario. Los tipos de acceso son los verbos HTTP (POST, GET, PUT, PATCH y DELETE).roleproduce un rol de permiso específica.
¿Qué sigue?
- Obtén información sobre cómo ejecutar la migración.