En SUSE se ha hablado de lo fácil que es adaptarse a OpenSUSE Leap cuando se viene de CentOS . En esta publicación de blog, se brindara orientación sobre cómo planificar y prepararse para una migración real y qué consideraciones debemos tener en cuenta.
Comencemos a sumergirnos en más detalles, la migración a un nuevo sistema operativo generalmente plantea varias preguntas. Aquí hay algunos a considerar para la eficiencia:
¿Puedo realizar las mismas tareas en OpenSUSE Leap que en CentOS?
Sí, hay más similitudes que diferencias en términos de funcionamiento y disponibilidad del software. Esta no es una migración drástica de sistemas operativos completamente diferentes, como migrar de Linux a Windows. Ya destacamos muchas similitudes en nuestro blog anterior “ Cómo sentirse como en casa ”, una lectura recomendada para comprender que no requiere un gran esfuerzo para comenzar a usar OpenSUSE Leap cuando ya está familiarizado con CentOS.
¿Qué pasos debo seguir para migrar mis cargas de trabajo?
Identificar las aplicaciones a migrar y sus versiones.
Aquí no me refiero a todas las aplicaciones instaladas, sino a aquellas que brindan un servicio o son necesarias para nuestras herramientas operativas y de automatización.
En el caso de que las mismas versiones no estén disponibles en ambas plataformas, podemos probar si la versión existente en la nueva plataforma es suficiente. En la mayoría de los casos, lo será. Las distribuciones como RHEL o SLES se esfuerzan por garantizar que las actualizaciones sean perfectas y no afecten a las aplicaciones existentes, y se esfuerzan mucho por respaldar las correcciones de errores para que la seguridad no sea una preocupación, incluso si parece una versión anterior.
Una vez identificadas las aplicaciones que necesitamos, ¿qué paquetes las proporcionan en OpenSUSE Leap?
Proporcionaremos todos los detalles técnicos necesarios en publicaciones posteriores. Aunque, en muchos casos, los nombres de los paquetes serán los mismos en ambas plataformas, por lo que puede que ni siquiera sea necesario.
Podemos usar una tabla similar a la siguiente para preparar nuestra migración.
| aplicación. Nombre | Paquete/s + Versión | N. Servidores | Otros requisitos y notas |
| myApp – interfaz | apache2, python3-3.6.15, myapp-1.0, mybackupclient | 1 | Requerirá un balanceador de carga para minimizar la interrupción del servicio |
| mi aplicación – back-end | postgresql15-servidor, mybackupclient | 1 | Será necesario configurar la replicación para minimizar la interrupción del servicio |
Prepare la migración en sí, ¿podemos ejecutar la migración sin tiempo de inactividad?
La respuesta depende de la aplicación, pero siempre hay métodos para minimizar el tiempo de inactividad utilizando una configuración temporal (o permanente si desea tener más resiliencia y una configuración sin preocupaciones), activa-activa o activa-pasiva.
Dependiendo de la importancia del servicio, puedes decidir si vale la pena invertir en estos mecanismos. Examinaremos algunos ejemplos de esto en próximos blogs.
Tenga en cuenta que las migraciones pueden ser tediosas y propensas a errores humanos. Esta es la oportunidad perfecta para automatizar.
Automatice la implementación de la aplicación en nuestro nuevo sistema operativo y, quizás, el proceso de migración en sí mismo para minimizar el tiempo de inactividad, especialmente si el esfuerzo es razonable y podemos reutilizarlo para otros casos de uso.
Por último, pero no menos importante, no olvide incluir una tarea para hacer una copia de seguridad.
Prepare el plan de reversión, ¿podemos usar la configuración anterior si nuestra migración no tiene éxito en el primer intento?
Siempre se recomienda tener un plan de reversión en caso de que la migración no salga como se esperaba, para eso es importante identificar qué hacer para mantener nuestros servicios funcionando en caso de que algo no salga como se esperaba. ¿Cómo podemos mantener los datos sincronizados para que puedan usarse en nuestro sistema anterior? etc… también es muy importante tratar de no mezclar las actualizaciones de la aplicación con la migración, para evitar complicarlo e introducir más variables.
En algunos casos, avanzar puede ser el camino, si pensamos que llevará más tiempo que retroceder, y no es necesario hacer nada irreversible.
En cualquier caso, no queremos problemas y la mejor forma de evitarlos es probando la migración, y el plan de rollback, en un entorno de desarrollo lo más parecido posible al productivo.
Bonificación: Pruebas automatizadas
Para garantizar que nuestra aplicación funcione como se espera, este proceso de migración ofrece una gran oportunidad para comenzar a construir nuestras pruebas automatizadas. Aunque es posible que no migremos a un nuevo sistema operativo en un futuro cercano, estas pruebas pueden ser beneficiosas al actualizar o implementar nuevas instancias de aplicaciones. Son una buena práctica para adoptar, especialmente si planeamos mover estos servicios a un entorno de Kubernetes en el futuro.
Conclusión
Esta publicación de blog describe brevemente algunos de los pasos necesarios para migrar de CentOS a OpenSUSE Leap desde una perspectiva más práctica.
Migrar de CentOS a openSUSE brinda numerosos beneficios, incluida la estabilidad, el soporte de SUSE a la comunidad , potentes herramientas de administración del sistema, funciones de distribución avanzadas y acceso a un rico repositorio de paquetes. La comunidad activa de openSUSE y las sencillas herramientas de migración mejoran aún más el proceso de transición. Si está buscando una distribución de Linux robusta y confiable para sus cargas de trabajo, debería considerar openSUSE.
¿Busca más información sobre lo que puede lograr al migrar a SUSE y openSUSE? Consulte otros blogs de esta serie:
¿Listo para experimentar el poder y la flexibilidad de openSUSE Leap?
Linware Argentina ⯈