Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Migre sus 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
Este patrón proporciona step-by-step instrucciones para migrar cargas de trabajo en contenedores de Azure Red Hat (ARO) a (ROSA). OpenShift Red Hat OpenShift Service en AWS
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 Nube de AWS . Abarca dos métodos para migrar sus cargas de trabajo a clústeres ROSA: CI/CD y el kit de herramientas de migración para contenedores (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 su aplicación y puede garantizar una configuración uniforme a través de una canalización, le recomendamos que utilice este 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 AWS como un servicio nativo. Es fácilmente accesible a través de 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 por parte de Red Hat como por parte de ambos AWS .
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 Nube de AWS servicios y proporciona una integración perfecta con AWS ofertas como los servicios de bases de datos, las soluciones de almacenamiento y los servicios de seguridad.
Requisitos previos y limitaciones
Requisitos previos
Un activo Cuenta de AWS.
Permisos configurados para los Servicios de AWS que ROSA confía para ofrecer 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 para configurar un clúster de ROSA, consulte la guía de orientación AWS prescriptiva sobre las estrategias de implementación de ROSA.
La conectividad de red se establece desde la red local AWS hasta AWS Direct Connect(preferiblemente) 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 clientel cliente OpenShift CLI (oc), el cliente ROSA y el binario de Git.
Requisitos previos adicionales para el CI/CD método:
Acceso al servidor Jenkins local con permisos para crear una nueva canalización, añadir etapas, añadir OpenShift clústeres y realizar 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 todos. Regiones de AWS Para conocer la disponibilidad de las regiones, consulte Servicios de AWS by Region
. Para 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 despliegue de red: pública, privada y AWS PrivateLink. PrivateLinkpermite a los equipos de ingeniería de confiabilidad de sitios (SRE) de Red Hat administrar el clúster mediante una subred privada conectada al PrivateLink punto final del clúster en una VPC existente.
La elección de PrivateLink esta opción 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 OpenShift documentación de Red Hat
importante
Puede crear un PrivateLink clúster solo en el momento de la instalación. No puede cambiar un clúster para usarlo PrivateLink después de la instalación.
El siguiente diagrama ilustra la PrivateLink arquitectura de un clúster ROSA que se utiliza Direct Connect para conectarse a los entornos locales y ARO.
AWS permisos para ROSA
Para obtener AWS permisos para ROSA, le recomendamos que utilice AWS Security Token Service (AWS STS) con tokens dinámicos de corta duración. Este método utiliza funciones y políticas predefinidas con privilegios mínimos para conceder a ROSA permisos mínimos para operar en la instalación Cuenta de AWS, el plano de control y las funciones informáticas de ROSA.
Reimplementación de la canalización de CI/CD
CI/CD pipeline redeployment is the recommended method for users who have a mature CI/CDcanalización. Si elige esta opción, puede utilizar cualquier estrategia de DevOps despliegue para trasladar gradualmente la carga de aplicaciones a los despliegues en ROSA.
nota
Este patrón supone un caso de uso común en el que tienes una canalización local de Git, JFrog Artifactory y Jenkins. Este enfoque requiere que establezcas la conectividad de red desde la red local AWS hasta Direct Connect ella y que configures el clúster 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.
Tools (Herramientas)
Servicios de AWS
AWS DataSynces un servicio de transferencia y descubrimiento de datos en línea que le ayuda a mover archivos u datos de objetos hacia, desde y entre los servicios AWS de almacenamiento.
AWS Direct Connectconecta la red interna a una Direct Connect ubicación a través de un cable Ethernet de fibra óptica estándar. Con esta conexión, puede crear interfaces virtuales directamente con las públicas y, al Servicios de AWS mismo tiempo, omitir a los proveedores de servicios de Internet en su ruta de red.
AWS PrivateLinkle ayuda a crear conexiones unidireccionales y privadas desde sus nubes privadas virtuales (VPCs) a servicios externos a la VPC.
Red Hat OpenShift Service en AWS (ROSA) es un servicio gestionado que ayuda a OpenShift los usuarios de Red Hat a crear, escalar y gestionar aplicaciones en contenedores. AWS
AWS Security Token Service (AWS STS) le ayuda a 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
Para mayor resiliencia y si tiene cargas de trabajo que cumplen con las normas de seguridad, configure un clúster ROSA multizona de disponibilidad 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 OpenShift documentación de Red Hat
. 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 de gestión de costes de Red Hat para OpenShift Container Platform para comprender mejor los costes de las nubes y los contenedores y realizar un seguimiento de los mismos. Para obtener más información, consulte ROSA Workshop
. Supervise y audite los servicios y aplicaciones de infraestructura de clústeres de ROSA mediante el uso de 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, AWS DevOps |
Agregue el cliente |
| Administrador de AWS, administrador de sistemas de AWS, AWS DevOps |
Cree una nueva rama de Git. | Cree una nueva rama en el repositorio de Git para | AWS DevOps |
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, AWS DevOps |
Crear 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, AWS DevOps |
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, 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, administrador de sistemas de AWS |
Comprobar la implementación. | Utilice el comando oc o la consola de ROSA | Administrador de AWS DevOps, 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 clúster de destino mediante AWS DataSync utilidades de código abierto como rsync, o puede utilizar el método MTC. Para obtener más información, consulte la Documentación de AWS DataSync. | Administrador de AWS DevOps, administrador de sistemas de AWS |
Pruebe su aplicación. |
| Administrador de AWS DevOps, 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, 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, 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, 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, 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, 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, administrador de sistemas de AWS |
Resolució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 | ARO y ROSA pueden tener 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. Reconfigure las aplicaciones que se basan en nombres DNS estáticos IPs o específicos. |
Acceso a servicios externos | Si su aplicación depende de servicios externos, como bases de datos APIs, es posible que tenga que actualizar su configuración de conexión para asegurarse de que pueda 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. |
Site-to-Site VPN o Direct Connect configuración | Si ya Site-to-Site VPN existen Direct Connect conexiones entre su red local y ARO, necesitará establecer conexiones similares con ROSA para una comunicación ininterrumpida 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. |
Supervisión 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
AWSreferencias
¿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 estrategias de implementación (orientación AWS prescriptiva)
Red Hat OpenShift Service en AWS Now GA
(AWS entrada de blog)
OpenShift Documentación de Red Hat
Información adicional
Elegir entre las opciones de reimplementación de MTC y de CI/CD canalización
La migración de aplicaciones de un OpenShift clúster a otro requiere una cuidadosa consideración. Lo ideal sería que la transición fuera fluida mediante una CI/CD canalización para volver a implementar 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 CI/CD canalización es el enfoque recomendado si la aplicación se puede volver a implementar 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 le ayuda a cambiar el tráfico gradualmente mediante una estrategia. 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 el uso de AWS DataSync 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 DevOps equipo necesita formación para utilizar la herramienta MTC y realizar migraciones.
