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

En esta página, se analizan algunas situaciones que pueden requerir que personalices los artefactos de migración.

Antes de comenzar

En este documento, se asume que completaste la migración.

Asegúrate de que el clúster de destino tenga acceso de lectura al registro de Docker

Como parte de la migración, Migrate to Containers sube las imágenes de Docker que representan una VM migrada a un registro de Docker. Estas imágenes de Docker representan los archivos y directorios de la VM que se migra.

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

• Container Registry

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

Para obtener más información, consulta Define repositorios de datos.

Implementa una carga de trabajo en un proyecto de Google Cloud que no sea el que se usa para la migración

A menudo, tendrás varios proyectos de Google Cloud en tu entorno. Si realizas una migración en un proyecto de Google Cloud, pero luego deseas implementar la carga de trabajo migrada en un clúster alojado en un proyecto diferente, debes asegurarte de tener los permisos configurados correctamente.

Por ejemplo, si realizas la migración en el proyecto A. En este caso, la carga de trabajo migrada se copia en un bucket de Container Registry en el proyecto A. Por ejemplo:

gcr.io/project-a/image_name:image_tag

Luego, quieres implementar la carga de trabajo en un clúster del proyecto B. Si no configuras los permisos correctamente, el Pod de carga de trabajo no se ejecuta porque el clúster del proyecto B no tiene acceso para extraer imágenes en el proyecto A. Entonces, verás un evento en el Pod que contiene un mensaje con el siguiente formato:

Failed to pull image "gcr.io/project-a/image_name:image_tag...
pull access denied...
repository does not exist or may acquire 'docker login'...

Todos los proyectos que tienen habilitada la API de Compute Engine tienen una cuenta de servicio predeterminada, cuya dirección de correo electrónico es la siguiente:

[e-mail]

En este ejemplo, PROJECT_NUMBER es el número de proyecto para el proyecto B.

Para solucionar este problema, asegúrate de que la cuenta de servicio predeterminada de Compute Engine del proyecto B tenga los permisos necesarios para acceder al bucket de Container Registry. Por ejemplo, puedes usar el siguiente comando de gsutil para habilitar el acceso:

gsutil iam ch serviceAccount:[e-mail]:objectViewer gs://artifacts.project-a.appspot.com

Implementa cargas de trabajo en el clúster de procesamiento

Importante: La IU de Migrate to Containers en la consola de Google Cloud, migctl y las CRD que usan clústeres de procesamiento para migrar cargas de trabajo a Google Cloud están obsoletas. Se admitirán para los usuarios existentes hasta mayo de 2024, después de lo cual dejarán de estar disponibles.

Puedes implementar la carga de trabajo migrada en el mismo clúster que usaste para realizar la migración, el cual es el clúster de procesamiento de Migrate to Containers. En la mayoría de las situaciones, no es necesario que realices ninguna configuración adicional en el clúster de procesamiento porque el clúster ya requiere acceso de lectura o escritura al registro de Docker para realizar una migración.

Implementa en un clúster de destino con Container Registry como registro de Docker

Para asegurarte de que un clúster de destino tenga acceso a Container Registry, crea un secreto de Kubernetes que contenga las credenciales necesarias para acceder a Container Registry:

1. Crea una cuenta de servicio para implementar una migración como se describe en Crea una cuenta de servicio para acceder a Container Registry y Cloud Storage.

   Este proceso te permite descargar un archivo de claves JSON con el nombre m4a-install.json.

2. Crea un secreto de Kubernetes que contenga las credenciales necesarias para acceder a Container Registry:

   kubectl create secret docker-registry gcr-json-key \
    --docker-server=gcr.io --docker-username=_json_key --docker-password="$(cat ~/m4a-install.json.json)" \
    --docker-email=[e-mail]

   Dónde:

   • docker-registry especifica el nombre del secreto de Kubernetes, que se trata de gcr-json-key en este ejemplo.
   • docker-server=gcr.io especifica Container Registry como el servidor.
   • docker-username=_json_key especifica que el nombre de usuario está contenido en el archivo de claves JSON.
   • docker-password especifica que se use una contraseña del archivo de claves JSON.
   • docker-email especifica la dirección de correo electrónico de la cuenta de servicio.

3. Configura el Secret de Kubernetes de las siguientes maneras:

   • Cambia el valor imagePullSecrets predeterminado:

     kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "gcr-json-key"}]}'

   • Edita el archivo deployment_spec.yaml para agregar el valor imagePullSecrets a la definición spec.template.spec. Al usar WebSphere tradicional, el archivo de implementación YAML se llama twas_deployment_spec.yaml, liberty_deployment_spec.yaml o openliberty_deployment_spec.yaml, según cuál sea tu destino.

     spec:
       containers:
       - image: gcr.io/PROJECT_ID/mycontainer-instance:v1.0.0
         name: mycontainer-instance
         ...
       volumes:
       - hostPath:
           path: /sys/fs/cgroup
           type: Directory
         name: cgroups
       imagePullSecrets:
       - name: gcr-json-key

     Reemplaza PROJECT_ID con el ID del proyecto.

4. Implementa el secreto de carga de trabajo, si existe secrets.yaml. Habrá un archivo de secretos para cargas de trabajo basadas en Tomcat y cargas de trabajo basadas en WebSphere tradicional con Liberty. El archivo de Liberty se llama liberty-secrets.yaml.

   kubectl apply -f secrets.yaml

Implementa en un clúster de destino con un registro de Docker con autenticación básica

Si usas un registro de Docker para almacenar imágenes de migración, el registro debe admitir la autenticación básica con un nombre de usuario y una contraseña. Debido a que existen muchas formas de configurar una conexión de solo lectura en un registro de Docker, debes usar el método que sea adecuado para tu plataforma de clúster y registro de Docker.

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.

Nota: Active Directory limita los nombres de las computadoras a 15 caracteres, lo que puede causar un conflicto de nombres con tus nodos. Consulta Usa gMSA para obtener más información y soluciones alternativas.

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

• Crea gMSA para contenedores de Windows.
• Crea una cuenta de servicio administrada de grupo
• Usa gMSA (documentación de Google Cloud).
• Configura tu app para que use una gMSA (documentación de Microsoft).

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.

Precaución: No recomendamos almacenar certificados SSL como Secrets de Kubernetes, ya que esto podría causar problemas de seguridad.

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"

   Dónde:

   • 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

   Dónde:

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

Configurar 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
  

  Nota: Solo se permiten los protocolos HTTP y HTTPS en la configuración protocol. Se omiten y no se procesan todos los protocolos que no sean HTTP/HTTPS.

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.

Nota: Los objetos COM de .NET no son compatibles.

¿Qué sigue?

• Aprende a implementar y compilar cargas de trabajo IIS basadas en Windows