Prepara un clúster de Windows para la implementación

En esta página, se describe cómo preparar tu clúster de Windows para la implementación.

Antes de comenzar

Elige y configura tu registro de Docker

Como parte de la implementación, compilas y subes la imagen de Docker de tu contenedor a un registro de Docker.

En el registro de Docker, puedes elegir usar lo siguiente:

  • Artifact Registry

  • Cualquier registro de Docker que admita la autenticación básica

La solución recomendada es usar Artifact Registry en el mismo proyecto del clúster de implementación. GKE puede acceder al registro de forma predeterminada. Para obtener más información, consulta los requisitos para la integración con GKE.

Si deseas usar un registro privado de Docker, obtén información para configurarlo.

Configura las cargas de trabajo migradas para usar gMSA

Las cargas de trabajo de la aplicación IIS de Windows suelen estar unidas a Active Directory (AD) y operan con identidades de dominio. Cuando se migran estas VMs a contenedores, los contenedores en sí no se unen al dominio, sino que sus nodos host del clúster de Kubernetes pueden unirse a un dominio.

Cuando implementas tus contenedores migrados en un clúster, puedes usar una cuenta de servicio administrada grupal (gMSA). Usa gMSA para ejecutar el contenedor dentro de una identidad de cuenta de servicio específica. Adjunta una gMSA en el clúster de Kubernetes como parte de la configuración del pod, en lugar de hacerlo como parte de una configuración de identidad estática dentro de la imagen del contenedor.

Migrate to Containers te ayuda en el proceso de transformar tus cargas de trabajo. Migrate to Containers descubre automáticamente la configuración de los grupos de aplicaciones de IIS y agrega recomendaciones al plan de migración generado. Luego, puedes evaluar estas recomendaciones y modificarlas para tu entorno y requisitos específicos.

Si Migrate to Containers determina que la configuración de un grupo de aplicaciones no requiere una gMSA, se mantiene la configuración del grupo de aplicaciones original. Por ejemplo, cuando usa un tipo de cuenta integrada como ApplicationPoolIdentity, NetworkService, LocalSystem o LocalService.

Para admitir gMSA en un contenedor de Windows migrado, debes hacer lo siguiente:

  1. Edita el plan de migración con el fin de establecer las propiedades necesarias para configurar el contenedor migrado y así poder usar una gMSA.

  2. Configura el clúster de destino que aloja el contenedor implementado.

Configura un clúster de destino para admitir gMSA

Adjunta una gMSA en el clúster de Kubernetes como parte de la configuración del pod, en lugar de hacerlo como parte de una configuración de identidad estática dentro de la imagen del contenedor.

Para configurar un clúster que aloja el contenedor migrado de Windows para que admita gMSA, debes haber hecho lo siguiente:

  1. Configurado Active Directory para las VM a fin de que se unan automáticamente a un dominio

  2. Configurado GMSA para contenedores y Pods de Windows.

Para obtener más información, consulta lo siguiente:

Implementa un contenedor al almacenar certificados SSL como secretos de Kubernetes

Te recomendamos que uses Cloud Load Balancing, Ingress o Cloud Service Mesh como frontend de HTTPS para proteger el acceso externo a tu contenedor implementado. Esta opción te permite proteger la comunicación externa sin incluir certificados dentro del clúster. Para obtener más información, consulta Personaliza un plan de migración.

También puedes almacenar certificados de capa de conexión segura (SSL) como secretos de Kubernetes y montarlos en el tiempo de ejecución dentro del contenedor.

Para usar Secrets de Kubernetes, sigue estos pasos:

  1. Crea un archivo PFX con el certificado y la contraseña.

  2. Crea un yaml de configuración que defina el acceso al sitio:

    sites:
 - sitename: "sitename"
   sslport: 443
   pfxpath: c:\sslconfig\pfx
   password: "password"
   thumbprint: "3e858d0551fc0536f52d411dad92b680a4fad4da"

    Aquí:

    • sitename especifica el nombre del sitio configurado para usar SSL. La propiedad sites puede contener varias entradas sitename.

    • sslport especifica el puerto que se escuchará en las conexiones SSL (por lo general, 443).

    • pfxpath especifica la ruta al archivo PFX. Configúralo como parte del volumeMounts de la implementación del Pod.

    • password especifica la contraseña del archivo PFX.

    • thumbprint especifica la huella digital SHA-1 del archivo PFX que puede recuperarse con el comando de PowerShell:

      Get-PfxCertificate -FilePath "path to pfx"

      O visualizar en el administrador de certificados de Windows.

  3. Crea el secreto de Kubernetes:

    kubectl create secret generic secret-name --from-file=pfx=path-to-pfx --from-file=config=path-to-config

  4. Crea el volumen y la activación del volumen en la implementación de la imagen:

    apiVersion: v1
kind: Pod
metadata:
 name: iis-pod
 labels:
   app: iis-server-simple
 spec:
   nodeSelector:
     kubernetes.io/os: windows
   containers:
   - name: iis-server
     image: your-image-url
     volumeMounts:
     - name: ssl-secret
       mountPath: c:\sslconfig
     env:
     - name: M4A_CERT_YAML
       value: c:\sslconfig\config
   volumes:
   - name: ssl-secret
     secret:
       secretName: secret-name

    Aquí:

    • mountPath es la misma ruta que especifica pfxpath en el archivo de configuración que creaste en el paso 2.
    • M4A_CERT_YAML es una variable de entorno establecida en la ruta completa del archivo de configuración YAML que creaste en el paso 2.
    • secret-name es el nombre del secreto que creaste en el paso 3.

Configura SSL

No se recomienda almacenar claves privadas de certificados SSL dentro de una imagen de contenedor. Esto se debe a que cualquier persona que lea la imagen pueda acceder a ellas. Migrate to Containers proporciona varias formas de controlar la SSL para Windows.

Usa un certificado autofirmado generado de forma automática

De forma predeterminada, a un contenedor de Windows con una vinculación HTTPS se le asigna un certificado autofirmado generado de forma automática que se genera cuando se inicializa el contenedor de Docker. Esta configuración te permite probar la carga de trabajo migrada, pero no se puede usar en un entorno de producción. El certificado es autofirmado y se vuelve a generar cada vez que se ejecuta el contenedor.

Recomendación: Usa Cloud Load Balancing, Ingress o Cloud Service Mesh

Puedes personalizar las vinculaciones en el plan de migración para usar HTTP. Luego, usa Cloud Load Balancing, Ingress o Cloud Service Mesh como un frontend HTTPS para proteger el acceso externo. Esta opción te permite proteger la comunicación externa sin incluir certificados dentro del clúster.

  • Para personalizar la vinculación, edita la definición de site en el plan de migración que representa la migración con el fin de establecer protocol en http:

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

A continuación, puedes reenviar solicitudes del frontend HTTPS a la ruta HTTP y al puerto de la carga de trabajo de Windows.

Almacena certificados SSL como Secrets de Kubernetes

Se recomienda usar Cloud Load Balancing, Ingress o Cloud Service Mesh como frontend HTTPS para proteger el acceso externo. Sin embargo, también puedes almacenar certificados SSL como secretos de Kubernetes y activarlos en el tiempo de ejecución en el contenedor.

Para usar certificados SSL almacenados como secretos de Kubernetes, debes editar la imagen de implementación del contenedor. Para obtener más información, consulta Implementa un contenedor al almacenar certificados SSL como secretos de Kubernetes.

Configura el registro en Cloud Logging

Migrate to Containers usa la herramienta LogMonitor para extraer registros de un contenedor de Windows y reenviarlos al clúster de GKE. Luego, estos registros se reenvían de forma automática a Cloud Logging, el cual proporciona un paquete de herramientas para que supervises tus contenedores.

De forma predeterminada, Migrate to Containers habilita el registro de IIS para supervisar los registros de IIS, y también reenvía los registros de eventos de la aplicación y el sistema a Cloud Logging.

Configura el registro

Al expandir el archivo artifacts.zip generado, se crean varios directorios, lo que incluye el directorio m4a. El directorio contiene una carpeta para cada imagen. En el directorio m4a, se incluye el archivo LogMonitorConfig.json que puedes editar para controlar el registro.

Para obtener más información sobre cómo editar LogMonitorConfig.json, consulta Authoring a Config File (Crea un archivo de configuración).

Configurar LCA

Algunas aplicaciones IIS requieren que otorgues permisos de listas de control de acceso (LCA) específicos en archivos y carpetas para que las aplicaciones funcionen de forma correcta. De forma automática, Migrate to Containers analiza todas las aplicaciones IIS migradas y agrega todos los permisos específicos definidos en la VM de origen que se aplican a las cuentas IIS (la cuenta IUSR y el grupo IIS_IUSRS), además de aplicarlos a los archivos y los directorios copiados en la imagen de contenedor generada.

Debido a que las imágenes de contenedor de Windows no admiten la configuración de las LCA como parte del comando COPY de Docker, las LCA se configuran en una secuencia de comandos llamada set_acls.bat. De forma automática, Migrate to Containers crea set_acls.bat en el directorio de la imagen activada para la aplicación de windows específica. Luego, Migrate to Containers llama a set_acls.bat cuando ejecutas el comando docker build.

Edita set_acls.bat para agregar o quitar permisos personalizados, o editar permisos que no están relacionados con usuarios IIS específicos y que, por lo tanto, Migrate to Containers no detectó.

La secuencia de comandos usa la herramienta integrada icacls de Windows para establecer permisos.

Acerca de la caché de ensambles global de .NET

Migrate to Containers analiza la imagen de origen de la caché global de ensambles (GAC) de .NET para recursos de .NET instalados en la máquina de origen y que no están disponibles como parte de las imágenes oficiales. Cualquier DLL descubierto se copia en el contexto de Docker y se instala como parte de la compilación de la imagen de destino mediante una secuencia de comandos de utilidad install_gac.ps1.

Todos los ensambles de .NET se copian en el contexto de Docker en el directorio m4a\gac. Para quitar los ensambles de la imagen, bórralos del directorio m4a\gac.

Registro de DLL del objeto COM

Los DLLs que exponen objetos COM se analizan y registran automáticamente. Durante la fase de extracción, los archivos copiados se analizan en busca de DLL que se registran como objetos COM, que luego se registran en el contenedor.

Este proceso se realiza sin entrada del usuario. Sin embargo, puedes influir en este proceso si agregas más DLLs para copiar. En caso de ser necesario, se verifican y registran estos DLL.

¿Qué sigue?