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

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

Antes de empezar

Elegir y configurar un registro de Docker

Como parte del despliegue, compila y sube la imagen Docker de tu contenedor a un registro de Docker.

En el caso del registro de Docker, puedes 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 integrar GKE.

Si quieres usar un registro de Docker privado, consulta cómo configurarlo.

Configurar cargas de trabajo migradas para usar gMSA

Las cargas de trabajo de aplicaciones de IIS de Windows suelen estar unidas a Active Directory (AD) y funcionan con identidades de dominio. Al migrar estas VMs a contenedores, los contenedores no se unen a ningún dominio, sino que pueden unirse a un dominio los nodos del clúster de Kubernetes del host.

Cuando implementas los contenedores migrados en un clúster, puedes usar una cuenta de servicio gestionada por grupos (gMSA). Usa gMSA para ejecutar el contenedor en 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 como una configuración de identidad estática dentro de la imagen de contenedor.

Migrate to Containers te ayuda en el proceso de transformación de tus cargas de trabajo. Migrate to Containers descubre automáticamente la configuración de los grupos de aplicaciones de IIS y añade recomendaciones al plan de migración generado. Después, puede evaluar estas recomendaciones y modificarlas en función de su entorno y sus requisitos específicos.

Si Migrate to Containers determina que la configuración de un grupo de aplicaciones no requiere una cuenta de servicio administrada de grupo (gMSA), mantiene la configuración original del grupo de aplicaciones. 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 para definir las propiedades necesarias para configurar el contenedor migrado de forma que use una cuenta de servicio administrada por grupos.

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

Configurar un clúster de destino para admitir gMSA

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

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

  1. Configurar Active Directory para que las máquinas virtuales se unan automáticamente a un dominio.

  2. Configurar gMSA para pods y contenedores de Windows.

Para obtener más información, consulta las siguientes secciones:

Desplegar un contenedor al almacenar certificados SSL como secretos de Kubernetes

Te recomendamos que uses Cloud Load Balancing, Ingress o Cloud Service Mesh como frontend HTTPS para proteger el acceso externo a tu contenedor implementado. Esta opción te permite proteger las comunicaciones externas sin incluir ningún certificado en el clúster. Para obtener más información, consulta Personalizar 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 contenedor en tiempo de ejecución.

Para usar secretos de Kubernetes, sigue estos pasos:

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

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

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

    Donde:

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

    • sslport especifica el puerto que se debe usar para las conexiones SSL (normalmente, 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 se puede obtener mediante el comando de PowerShell:

      Get-PfxCertificate -FilePath "path to pfx"

      También puedes verlo 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 el montaje 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

    Donde:

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

Configurar SSL

No se recomienda almacenar claves privadas de certificados SSL en una imagen de contenedor, ya que cualquier persona que lea la imagen puede acceder a ellas. Migrate to Containers ofrece varias formas de gestionar SSL en Windows.

Usar un certificado autofirmado generado automáticamente

De forma predeterminada, a un contenedor de Windows con un enlace HTTPS se le asigna un certificado autofirmado generado automáticamente que se genera en la inicialización del contenedor de Docker. Esta configuración te permite probar tu carga de trabajo migrada, pero no se puede usar en un entorno de producción. El certificado tiene una firma automática y se regenera cada vez que se ejecuta el contenedor.

Recomendado: usa Cloud Load Balancing, Ingress o Cloud Service Mesh

Puedes personalizar las vinculaciones del plan de migración para usar HTTP. A continuación, usa Cloud Load Balancing, Ingress o Cloud Service Mesh como frontend HTTPS para proteger el acceso externo. Esta opción te permite proteger las comunicaciones externas sin incluir ningún certificado en el clúster.

  • Para personalizar la vinculación, edita la definición de site en el plan de migración que representa la migración para definir protocol como http:

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

Después, puede reenviar las solicitudes del frontend HTTPS a la ruta y el puerto HTTP de la carga de trabajo de Windows.

Almacenar certificados SSL como secretos de Kubernetes

Te recomendamos que uses 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 montarlos en el contenedor durante el tiempo de ejecución.

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

Configurar el registro en Cloud Logging

Migrate to Containers usa la herramienta LogMonitor para extraer los registros de un contenedor de Windows y reenviarlos a tu clúster de GKE. Estos registros se reenvían automáticamente a Cloud Logging, que proporciona un conjunto de herramientas para monitorizar tus contenedores.

De forma predeterminada, Migrate to Containers habilita el registro de IIS para monitorizar los registros de IIS y también reenvía los registros de eventos de aplicaciones o del sistema a Cloud Logging.

Configurar el almacenamiento de registros

Al expandir el archivo artifacts.zip generado, se crean varios directorios, incluido el directorio m4a. El directorio contiene una carpeta por 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 Crear un archivo de configuración.

Establecer LCAs

Algunas aplicaciones de IIS requieren que establezca permisos de listas de control de acceso (LCA) específicos en archivos y carpetas para que las aplicaciones funcionen correctamente. Migrate to Containers analiza automáticamente todas las aplicaciones de IIS migradas y añade los permisos específicos definidos en la VM de origen que se aplican a las cuentas de IIS (la cuenta IUSR y el grupo IIS_IUSRS) y los aplica a los archivos y directorios copiados en la imagen de contenedor generada.

Como las imágenes de contenedor de Windows no admiten la configuración de ACLs como parte del comando COPY de Docker, las ACLs se definen en una secuencia de comandos llamada set_acls.bat. Migrate to Containers crea automáticamente un set_acls.bat en el directorio de la imagen generada para tu aplicación de Windows específica. Migra a Containers y, a continuación, llama a set_acls.bat cuando ejecutes el comando docker build.

Edita set_acls.bat para añadir o quitar permisos personalizados, o bien edita los permisos que no estén relacionados con usuarios específicos de IIS y, por lo tanto, no los haya detectado Migrate to Containers.

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

Acerca de la caché de ensamblados global de .NET

Migrate to Containers analiza la caché de ensamblado global (GAC) de .NET de la imagen de origen para buscar recursos de .NET que estén instalados en la máquina de origen y no estén disponibles en las imágenes oficiales. Cualquier DLL detectada 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 ensamblados de .NET se copian en el contexto de Docker en el directorio m4a\gac. Para quitar ensamblados de la imagen, elimínelos del directorio m4a\gac.

Registro de DLL de objetos COM

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

Este proceso se lleva a cabo sin que el usuario tenga que hacer nada. Sin embargo, puedes influir en este proceso añadiendo más DLLs para que se copien. Si es necesario, estos archivos DLL se comprueban por turnos y se registran.

Siguientes pasos