Migración de cargas de trabajo de contenedores de Azure Red Hat OpenShift (ARO) a Red Hat OpenShift Service en AWS (ROSA)
Naveen Ramasamy, Srikanth Rangavajhala y Gireesh Sreekantan, Amazon Web Services
Resumen
En este patrón se proporcionan instrucciones paso a paso para migrar cargas de trabajo de contenedores de Azure Red Hat OpenShift (ARO) a Red Hat OpenShift Service en AWS (ROSA)
La migración de cargas de trabajo de contenedores desde ARO, otras nubes o entornos en las instalaciones a ROSA implica la transferencia de aplicaciones, configuraciones y datos de una plataforma a otra. Este patrón ayuda a garantizar una transición fluida y, al mismo tiempo, optimiza los servicios, la seguridad y la rentabilidad de la Nube de AWS. Cubre dos métodos para migrar cargas de trabajo a clústeres de ROSA: CI/CD y Migration Toolkit for Containers (MTC).
En este patrón se tratan ambos métodos. El método que elija depende de la complejidad y la certeza del proceso de migración. Si tiene el control total sobre el estado de la aplicación y puede garantizar una configuración coherente a través de una canalización, le recomendamos que utilice el método CI/CD. Sin embargo, si el estado de la aplicación implica incertidumbres, cambios imprevistos o un ecosistema complejo, le recomendamos que utilice MTC como una ruta fiable y controlada para migrar la aplicación y sus datos a un nuevo clúster. Para obtener una comparación detallada de los dos métodos, consulte la sección Información adicional.
Beneficios de la migración a ROSA:
ROSA se integra perfectamente con AWS como un servicio nativo. Es fácilmente accesible a través de la Consola de administración de AWS y se factura a través de una sola Cuenta de AWS. Ofrece total compatibilidad con otros Servicios de AWS y proporciona soporte colaborativo tanto de AWS como de Red Hat.
ROSA admite implementaciones híbridas y multinube. Permite que las aplicaciones se ejecuten de manera coherente en los centros de datos en las instalaciones y en varios entornos en la nube.
ROSA se beneficia del enfoque de seguridad de Red Hat y ofrece características como el control de acceso basado en roles (RBAC), el escaneo de imágenes y las evaluaciones de vulnerabilidades para garantizar un entorno de contenedores seguro.
ROSA se ha diseñado para escalar aplicaciones con facilidad y ofrece opciones de alta disponibilidad. Permite que las aplicaciones crezcan según sea necesario y, al mismo tiempo, mantiene la fiabilidad.
ROSA automatiza y simplifica la implementación de un clúster de Kubernetes en comparación con los métodos de administración y configuración manuales. Esto acelera el proceso de desarrollo e implementación.
ROSA se beneficia de los servicios en la Nube de AWS y proporciona una integración perfecta con ofertas AWS como los servicios de bases de datos, las soluciones de almacenamiento y los servicios de seguridad.
Requisitos previos y limitaciones
Requisitos previos
Una Cuenta de AWS activa.
Permisos configurados para los Servicios de AWS en los que se basa ROSA para entregar la funcionalidad. Para obtener más información, consulte Prerequisites en la documentación de ROSA.
ROSA activado en la consola de ROSA
. Para obtener instrucciones, consulte la documentación de ROSA. El clúster de ROSA instalado y configurado. Para obtener más información, consulte Get started with ROSA en la documentación de ROSA. Para comprender los diferentes métodos de configuración de un clúster de ROSA, consulte las Recomendaciones de AWS sobre estrategias de implementación de ROSA.
Conectividad de red establecida desde la red en las instalaciones a AWS a través de AWS Direct Connect (opción preferida) o AWS Virtual Private Network (Site-to-Site VPN).
Una instancia de Amazon Elastic Compute Cloud (Amazon EC2) u otro servidor virtual para instalar herramientas como
aws client, el cliente de la CLI de OpenShift (oc), el cliente de ROSA y el objeto binario de Git.
Requisitos previos adicionales para el método de CI/CD:
Acceso al servidor de Jenkins en las instalaciones con permisos para crear una nueva canalización, agregar etapas, agregar clústeres de OpenShift y llevar a cabo compilaciones.
Acceso al repositorio de Git en el que se mantiene el código fuente de la aplicación, con permisos para crear una nueva rama de Git y llevar a cabo confirmaciones en la nueva rama.
Requisitos previos adicionales para el método de MTC:
Un bucket de Amazon Simple Storage Service (Amazon S3) que se utilizará como repositorio de replicación.
Acceso administrativo al clúster de ARO de origen. Es necesario para configurar la conexión de MTC.
Limitaciones
Algunos Servicios de AWS no están disponibles en todas las Regiones de AWS. Para obtener información sobre la disponibilidad en regiones, consulte Servicios de AWS by Region
. Para ver los puntos de conexión específicos, consulte la página Service endpoints and quotas y elija el enlace del servicio.
Arquitectura
ROSA proporciona tres patrones de implementación de red: pública, privada y AWS PrivateLink. PrivateLink permite a los equipos de ingeniería de confiabilidad del sitio (SRE) de Red Hat administrar el clúster mediante una subred privada conectada al punto de conexión de PrivateLink del clúster en una VPC existente.
La elección de la opción de PrivateLink proporciona la configuración más segura. Por ese motivo, la recomendamos para cargas de trabajo confidenciales o para requisitos de cumplimiento estrictos. Para obtener información sobre las opciones de implementación de redes públicas y privadas, consulte la documentación de Red Hat OpenShift
importante
Solo puede crear un clúster de PrivateLink en el momento de la instalación. No puede cambiar un clúster para que use PrivateLink después de la instalación.
En el siguiente diagrama se ilustra la arquitectura de PrivateLink de un clúster de ROSA que utiliza Direct Connect para conectarse a entornos en las instalaciones y de ARO.
Permisos de AWS para ROSA
Para los permisos de AWS para ROSA, le recomendamos que utilice AWS Security Token Service (AWS STS) con tokens dinámicos de corta duración. Este método utiliza roles y políticas predefinidos con privilegios mínimos a fin de conceder a ROSA los permisos mínimos para operar en la Cuenta de AWS, y admite la instalación de ROSA, el plano de control y la funcionalidad de computación.
Reimplementación de la canalización de CI/CD
La reimplementación de la canalización de CI/CD es el método recomendado para los usuarios que tengan una canalización de CI/CD madura. Si elige esta opción, puede utilizar cualquier estrategia de implementación de DevOps para trasladar gradualmente la carga de aplicaciones a implementaciones en ROSA.
nota
En este patrón se supone un caso de uso común en el que tenga una canalización en las instalaciones de Git, JFrog Artifactory y Jenkins. Este enfoque requiere que establezca la conectividad de red desde la red en las instalaciones a AWS a través de Direct Connect y que configure el clúster de ROSA antes de seguir las instrucciones de la sección Epics. Consulte la sección Requisitos previos para obtener los detalles.
En el siguiente diagrama se muestra el flujo de trabajo para este método.
Método MTC
Puede usar Migration Toolkit for Containers (MTC)
En el siguiente diagrama se muestra el flujo de trabajo para este método.
Herramientas
Servicios de AWS
AWS DataSync es un servicio de transferencia y detección de datos en línea que lo ayuda a trasladar archivos o datos de objetos hacia, desde y entre los servicios de almacenamiento de AWS.
AWS Direct Connect vincula su red interna con una ubicación de Direct Connect a través de cable estándar Ethernet de fibra óptica. Con esta conexión, puede crear interfaces virtuales directamente en Servicios de AWS públicos a la vez que omite a los proveedores de servicios de Internet en su ruta de acceso a la red.
AWS PrivateLink ayuda a crear conexiones unidireccionales y privadas desde sus nubes privadas virtuales (VPC) hacia los servicios externos a la VPC.
Red Hat OpenShift Service en AWS (ROSA) es un servicio administrado que ayuda a los usuarios de Red Hat OpenShift a crear, escalar y administrar aplicaciones en contenedores en AWS.
AWS Security Token Service (AWS STS) permite solicitar credenciales temporales con privilegios limitados para los usuarios.
Otras herramientas
Migration Toolkit for Containers (MTC)
proporciona una consola y una API para migrar aplicaciones en contenedores de ARO a ROSA.
Prácticas recomendadas
Por cuestiones de resiliencia y si tiene cargas de trabajo de cumplimiento de seguridad, configure un clúster multi-AZ de ROSA que utilice PrivateLink. Para obtener más información, consulte la documentación de ROSA.
nota
PrivateLink no se puede configurar después de la instalación.
El bucket de S3 que utiliza como repositorio de replicación no debe ser público. Utilice las políticas de bucket de S3 adecuadas para restringir el acceso.
Si elige el método MTC, utilice la opción de migración por etapas para reducir el tiempo de inactividad durante la transición.
Revise las cuotas de servicio antes y después de aprovisionar el clúster de ROSA. Si es necesario, solicite un aumento de la cuota de acuerdo con sus requisitos. Para obtener más información, consulte la documentación de Service Quotas.
Consulte ROSA security guidelines e implemente las prácticas recomendadas de seguridad.
Le recomendamos eliminar el administrador de clústeres predeterminado después de la instalación. Para obtener más información, consulte la documentación de Red Hat OpenShift
. Utilice el escalado automático del grupo de máquinas para reducir verticalmente los nodos de trabajo no utilizados en el clúster de ROSA a fin de optimizar los costos. Para obtener más información, consulte ROSA Workshop
. Utilice el servicio Red Hat Cost Management para OpenShift Container Platform para comprender mejor los costos de la nube y los contenedores y hacer un seguimiento de ellos. Para obtener más información, consulte ROSA Workshop
. Supervise y audite las aplicaciones y los servicios de infraestructura de clústeres de ROSA mediante los Servicios de AWS. Para obtener más información, consulte ROSA Workshop
.
Epics
| Tarea | Descripción | Habilidades requeridas |
|---|---|---|
Agregue el nuevo clúster de ROSA a Jenkins. |
| Administrador de AWS, administrador de sistemas de AWS, DevOps de AWS |
Agregue el cliente |
| Administrador de AWS, administrador de sistemas de AWS, DevOps de AWS |
Cree una nueva rama de Git. | Cree una nueva rama en el repositorio de Git para | DevOps de AWS |
Etiquete las imágenes para ROSA. | En la etapa de compilación, utilice una etiqueta diferente para identificar las imágenes que se crearon a partir de la canalización de ROSA. | Administrador de AWS, administrador de sistemas de AWS, DevOps de AWS |
Cree una canalización. | Cree una nueva canalización de Jenkins que sea similar a la canalización existente. Para esta canalización, utilice la rama de Git | Administrador de AWS, administrador de sistemas de AWS, DevOps de AWS |
Agregue una etapa de implementación de ROSA. | En la nueva canalización, agregue una etapa de implementación en el clúster de ROSA y haga referencia al clúster de ROSA que agregó a la configuración global de Jenkins. | Administrador de AWS, DevOps de AWS, administrador de sistemas de AWS |
Inicie una nueva compilación. | En Jenkins, seleccione la canalización y elija Build now, o confirme un cambio en la rama | Administrador de AWS, DevOps de AWS, administrador de sistemas de AWS |
Comprobar la implementación. | Utilice el comando oc o la consola de ROSA | Administrador de AWS, DevOps de AWS, administrador de sistemas de AWS |
Copie los datos en el clúster de destino. | Para cargas de trabajo con estado, copie los datos del clúster de origen al de destino mediante AWS DataSync o utilidades de código abierto como rsync. También puede utilizar el método MTC. Para obtener más información, consulte la Documentación de AWS DataSync. | Administrador de AWS, DevOps de AWS, administrador de sistemas de AWS |
Pruebe su aplicación. |
| Administrador de AWS, DevOps de AWS, administrador de sistemas de AWS |
Lleve a cabo la transición. | Si las pruebas se llevan a cabo correctamente, utilice la política de Amazon Route 53 adecuada para trasladar el tráfico de la aplicación alojada en ARO a la aplicación alojada en ROSA. Cuando complete este paso, la carga de trabajo de la aplicación pasará por completo al clúster de ROSA. | Administrador AWS, administrador de sistemas AWS |
| Tarea | Descripción | Habilidades requeridas |
|---|---|---|
Instale el operador de MTC. | Instale el operador de MTC en los clústeres de ARO y ROSA:
| Administrador de AWS, DevOps de AWS, administrador de sistemas de AWS |
Configure el tráfico de red al repositorio de replicación. | Si utiliza un servidor proxy, configúrelo para permitir el tráfico de red entre el repositorio de replicación y los clústeres. El repositorio de replicación es un objeto de almacenamiento intermedio que MTC utiliza para migrar datos. Los clústeres de origen y destino deben tener acceso de red al repositorio de replicación durante la migración. | Administrador de AWS, DevOps de AWS, administrador de sistemas de AWS |
Agregue el clúster de origen a MTC. | En la consola web de MTC, agregue el clúster de origen de ARO. | Administrador de AWS, DevOps de AWS, administrador de sistemas de AWS |
Agregue Amazon S3 como repositorio de replicación. | En la consola web de MTC, agregue el bucket de Amazon S3 (consulte Requisitos previos) como repositorio de replicación. | Administrador de AWS, DevOps de AWS, administrador de sistemas de AWS |
Cree un plan de migración. | En la consola web de MTC, cree un plan de migración y especifique el tipo de transferencia de datos como Copy. Esto indicará a MTC que copie los datos del clúster de origen (ARO) al bucket de S3 y del bucket al clúster de destino (ROSA). | Administrador de AWS, DevOps de AWS, administrador de sistemas de AWS |
Ejecute el plan de migración. | Ejecute el plan de migración mediante la opción Stage o Cutover:
| Administrador de AWS, DevOps de AWS, administrador de sistemas de AWS |
Solución de problemas
| Problema | Solución |
|---|---|
Problemas de conectividad | Al migrar las cargas de trabajo de contenedores de ARO a ROSA, es posible que se produzcan problemas de conectividad que deban resolverse para garantizar una migración satisfactoria. Para corregir estos problemas de conectividad (enumerados en esta tabla) durante la migración, es fundamental contar con una planificación meticulosa, coordinarse con los equipos de red y seguridad y llevar a cabo pruebas exhaustivas. La implementación de una estrategia de migración gradual y la verificación de la conectividad en cada paso ayudarán a minimizar las posibles interrupciones y a garantizar una transición fluida de ARO a ROSA. |
Diferencias de configuración de la red | Es posible que ARO y ROSA tengan variaciones en sus configuraciones de red, como la configuración de la red virtual (VNet), las subredes y las políticas de red. Para que la comunicación entre los servicios sea adecuada, asegúrese de que la configuración de red esté alineada entre las dos plataformas. |
Reglas de firewall y grupo de seguridad | ROSA y ARO pueden tener una configuración predeterminada de firewall y grupo de seguridad diferente. Asegúrese de ajustar y actualizar estas reglas para permitir el tráfico necesario a fin de mantener la conectividad entre los contenedores y los servicios durante la migración. |
Cambios de dirección IP y DNS | Al migrar las cargas de trabajo, los nombres de DNS y las direcciones IP pueden cambiar. Vuelva a configurar las aplicaciones que se basan en direcciones IP estáticas o nombres de DNS específicos. |
Acceso a servicios externos | Si la aplicación depende de servicios externos, como bases de datos o API, es posible que deba actualizar la configuración de conexión para asegurarse de que puedan comunicarse con los nuevos servicios de ROSA. |
Configuración de Azure Private Link | Si utiliza Azure Private Link o servicios de puntos de conexión privados en ARO, necesitará configurar la funcionalidad equivalente en ROSA para garantizar la conectividad privada entre los recursos. |
Configuración de Site-to-Site VPN o Direct Connect | Si ya existen conexiones de Site-to-Site VPN o Direct Connect entre la red en las instalaciones y ARO, necesitará establecer conexiones similares con ROSA para que no se interrumpa la comunicación con sus recursos locales. |
Configuración del equilibrador de carga y entrada | Las configuraciones de los controladores de entrada y los equilibradores de carga pueden diferir entre ARO y ROSA. Vuelva a configurar estos ajustes para mantener el acceso externo a los servicios. |
Gestión de TLS y certificados | Si las aplicaciones utilizan certificados SSL o TLS, asegúrese de que sean válidos y estén configurados correctamente en ROSA. |
Acceso al registro de contenedores | Si los contenedores están alojados en un registro de contenedores externo, configure los permisos de acceso y autenticación adecuados para ROSA. |
Monitoreo y registro | Actualice las configuraciones de supervisión y registro para que reflejen la nueva infraestructura de ROSA para que pueda continuar supervisando el estado y el rendimiento de los contenedores de manera eficaz. |
Recursos relacionados
AWS Referencias de
Qué es Red Hat OpenShift Service en AWS? (documentación de ROSA)
Get started with ROSA (documentación de ROSA)
Red Hat OpenShift Service en AWS implementation strategies (Recomendaciones de AWS)
Red Hat OpenShift Service en AWS Now GA
(entrada en el blog de AWS)
Documentación de Red Hat OpenShift
Información adicional
Cómo elegir entre las opciones de reimplementación de la canalización de CI/CD y MTC
La migración de aplicaciones de un clúster de OpenShift a otro requiere una consideración cuidadosa. Lo ideal sería que la transición fuera fluida mediante una canalización de CI/CD para reimplementar la aplicación y gestionar la migración de los volúmenes de datos persistentes. Sin embargo, en la práctica, una aplicación en ejecución en un clúster es susceptible a cambios imprevistos con el tiempo. Estos cambios pueden hacer que la aplicación se desvíe gradualmente de su estado de implementación original. MTC ofrece una solución para casos en los que el contenido exacto de un espacio de nombres es incierto y es importante migrar sin problemas todos los componentes de la aplicación a un nuevo clúster.
Para tomar la decisión correcta, es necesario evaluar el caso específico y sopesar los beneficios de cada enfoque. De este modo, puede garantizar una migración exitosa y fluida que se ajuste a sus necesidades y prioridades. A continuación, se comparan las directrices adicionales para elegir entre las dos opciones.
Reimplementación de la canalización de CI/CD
El método de canalización de CI/CD es el enfoque recomendado si la aplicación se puede reimplementar con confianza mediante una canalización. De este modo, se garantiza que la migración sea controlada, predecible y alineada con sus prácticas de implementación actuales. Si elige este método, puede utilizar estrategias de implementación azul/verde o implementación canario para trasladar la carga a implementaciones en ROSA. En este caso, este patrón supone que Jenkins orquesta las implementaciones de aplicaciones desde el entorno en las instalaciones.
Ventajas:
No necesita acceso administrativo al clúster de ARO de origen ni implementar ningún operador en el clúster de origen o destino.
Este enfoque lo ayuda a cambiar el tráfico gradualmente mediante una estrategia de DevOps.
Desventajas:
Probar la funcionalidad de la aplicación requiere más esfuerzo.
Si la aplicación contiene datos persistentes, se requieren pasos adicionales para copiar los datos mediante AWS DataSync u otras herramientas.
Migración de MTC
En un entorno real, las aplicaciones en ejecución pueden sufrir cambios imprevistos que hacen que se alejen de la implementación inicial. Elija la opción de MTC cuando no conozca el estado actual de la aplicación en el clúster de origen. Por ejemplo, si el ecosistema de aplicaciones abarca varios componentes, configuraciones y volúmenes de almacenamiento de datos, le recomendamos que elija MTC para garantizar una migración completa que abarque la aplicación y todo su entorno.
Ventajas:
MTC proporciona una copia de seguridad y restauración completas de la carga de trabajo.
Copiará los datos persistentes del origen al destino mientras migra la carga de trabajo.
No requiere acceso al repositorio de código fuente.
Desventajas:
Necesita privilegios administrativos para instalar el operador de MTC en los clústeres de origen y destino.
El equipo de DevOps necesita formación para utilizar la herramienta de MTC y llevar a cabo migraciones.
