Refactorización de una aplicación de Linux mediante Azure App Service, Traffic Manager y Azure Database for MySQL

En este artículo se muestra cómo la empresa ficticia Contoso refactoriza una aplicación basada en LAMP de dos niveles y la migra del entorno local a Azure mediante Azure App Service con integración de GitHub y Azure Database for MySQL.

osTicket, la aplicación de consola de servicio que se usa en este ejemplo, se proporciona como software de código abierto. Si quiere utilizarla para sus propias pruebas, puede descargarla desde el repositorio de osTicket de GitHub.

Impulsores del negocio

El equipo directivo de TI ha trabajado estrechamente con sus socios comerciales para comprender sus objetivos:

  • Abordar el crecimiento del negocio. Contoso crece y se mueve a mercados nuevos. Se necesitan más agentes de servicio al cliente.
  • Escala. se debe compilar la solución para que Contoso pueda agregar más agentes de servicio al cliente al escalar el negocio.
  • Mejora de la resistencia. En el pasado, los problemas del sistema afectaban solo a los usuarios internos. Con su nuevo modelo de negocio, se verán afectados los usuarios externos, y Contoso necesita que la aplicación esté siempre en funcionamiento.

Objetivos de la migración

El equipo de la nube de Contoso ha definido los objetivos de esta migración con el fin de determinar el mejor método para llevarla a cabo:

  • La aplicación debe escalar más allá de la capacidad y el rendimiento local actual. Contoso va a mover la aplicación para aprovechar las ventajas del escalado a petición de Azure.
  • Contoso quiere mover el código base de la aplicación a una canalización de entrega continua. Cuando los cambios de la aplicación se inserten en GitHub, Contoso quiere implementar dichos cambios sin tareas para el personal de operaciones.
  • La aplicación debe ser resistente, con funcionalidades para el crecimiento y la conmutación por error. Contoso quiere implementar la aplicación en dos regiones de Azure diferentes y configurarla para el escalado automático.
  • Quiere minimizar las tareas de administración de la base de datos tras mover la aplicación a la nube.

Diseño de la solución

Después de fijar sus objetivos y requisitos, Contoso diseña y revisa una solución de implementación e identifica el proceso de migración, incluidos los servicios de Azure que usará para la migración.

Arquitectura actual

  • La aplicación se divide en niveles entre dos máquinas virtuales (OSTICKETWEB y OSTICKETMYSQL).
  • Las máquinas virtuales se encuentran en el host de VMware ESXi contosohost1.contoso.com (versión 6.5).
  • El entorno de VMware lo administra vCenter Server 6.5 (vcenter.contoso.com) que se ejecuta en una máquina virtual.
  • Contoso tiene un centro de datos local (contoso-datacenter), con un controlador de dominio local (contosodc1).

Diagrama de la arquitectura actual.

Arquitectura propuesta

Esta es la arquitectura propuesta:

  • La aplicación de nivel web en OSTICKETWEB se migrará mediante la compilación de una aplicación web de Azure App Service en dos regiones de Azure. El equipo de Contoso implementará Azure App Service para Linux mediante el contenedor Docker de PHP 7.0.
  • El código de la aplicación se moverá a GitHub y Azure App Service Web App se configurará para la entrega continua con GitHub.
  • Azure App Service se implementará tanto en la región primaria (East US 2) como en la región secundaria (Central US).
  • Azure Traffic Manager se configurará delante de las dos aplicaciones web en ambas regiones.
  • Traffic Manager se configurará en modo de prioridad para forzar el tráfico a través de East US 2.
  • Si Azure App Server en East US 2 se queda sin conexión, los usuarios pueden obtener acceso a la aplicación de conmutación por error en la Central US.
  • La base de datos de la aplicación se migrará al servicio Azure Database for MySQL mediante Azure Database Migration Service. La copia de seguridad de la base de datos local se realizará localmente y se restaurará de forma directa en Azure Database for MySQL.
  • La base de datos residirá en la región primaria (East US 2) de la subred de la base de datos (PROD-DB-EUS2) de la red de producción (VNET-PROD-EUS2).
  • Dado que se migra una carga de trabajo de producción, los recursos de Azure para la aplicación residirán en el grupo de recursos de producción ContosoRG.
  • El recurso Traffic Manager se implementará en el grupo de recursos de la infraestructura de Contoso, ContosoInfraRG.
  • Las VM locales del centro de datos de Contoso se retirarán después de realizar la migración.

Diagrama de la arquitectura del escenario

Proceso de migración

Contoso completa el proceso de migración como se indica a continuación:

  1. Como primer paso, los administradores de Contoso configuran la infraestructura de Azure, incluido el aprovisionamiento de Azure App Service, la configuración de Traffic Manager y el aprovisionamiento de una instancia de Azure Database for MySQL.
  2. Después de preparar la infraestructura de Azure, migran la base de datos mediante Azure Database Migration Service.
  3. Cuando la base de datos se ejecuta en Azure, configuran un repositorio privado de GitHub para Azure App Service con entrega continua y lo cargan con la aplicación osTicket.
  4. En Azure Portal, se carga la aplicación desde GitHub en el contenedor Docker que ejecuta Azure App Service.
  5. Se modifica la configuración de DNS y se configura el escalado automático para la aplicación.

Diagrama del proceso de migración de Contoso.

Servicios de Azure

Servicio Descripción Coste
Azure App Service El servicio ejecuta y escala aplicaciones mediante el servicio PaaS de Azure para sitios web. Los precios se basan en el tamaño de las instancias y en las características que se necesiten. Más información.
Azure Traffic Manager Un equilibrador de carga que usa un Sistema de nombres de dominio (DNS) para dirigir los usuarios a Azure o a sitios web y servicios externos. Los precios se basan en el número de consultas de DNS recibidas y el número de puntos de conexión supervisados. Más información.
Azure Database Migration Service Azure Database Migration Service permite migraciones completas de varios orígenes de base de datos a plataformas de datos de Azure, con un tiempo de inactividad mínimo. Información acerca de las regiones admitidas y los precios de Database Migration Service.
Azure Database for MySQL La base de datos se basa en el motor de base de datos MySQL de código abierto. Proporciona una base de datos MySQL de la comunidad completamente administrada y lista para la empresa para el desarrollo y la implementación de aplicaciones. Los precios se basan en los requisitos de proceso, almacenamiento y copia de seguridad. Más información.

Requisitos previos

Contoso debe cumplir los siguientes requisitos previos para ejecutar este escenario:

Requisitos Detalles
Suscripción de Azure Suscripciones creadas por Contoso anteriormente en esta serie de artículos. Si no tiene una suscripción a Azure, cree una cuenta gratuita.

Si crea una cuenta gratuita, será el administrador de su suscripción y podrá realizar todas las acciones.

Si usa una suscripción existente y no es el administrador, tendrá que solicitar al administrador que le asigne permisos de propietario o colaborador.
Infraestructura de Azure Contoso configura la infraestructura de Azure según se describe en Infraestructura de Azure para la migración.

Pasos del escenario

Este es el plan de Contoso para realizar la migración:

  • Paso 1: Aprovisionamiento de Azure App Service. Los administradores de Contoso aprovisionarán aplicaciones web en las regiones primarias y secundarias.
  • Paso 2: Configuración de Traffic Manager. Configurarán Traffic Manager delante de las aplicaciones web para el enrutamiento y el equilibrio de carga del tráfico.
  • Paso 3: Aprovisionamiento de Azure Database for MySQL. En Azure, aprovisionarán una instancia de Azure Database for MySQL.
  • Paso 4: Migración de la base de datos. Contoso migra la base de datos mediante Azure Database Migration Service.
  • Paso 5: Configuración de GitHub. Se configura un repositorio de GitHub local para los sitios web y el código de la aplicación.
  • Paso 6: Configuración de las aplicaciones web. Se configuran las aplicaciones web con los sitios web de osTicket.

Paso 1: Aprovisionamiento de Azure App Service.

Los administradores de Contoso aprovisionan dos aplicaciones web (una en cada región) con Azure App Service.

  1. Crean un recurso de aplicación web (osticket-eus2) en la región primaria (East US 2) desde Azure Marketplace.

  2. Colocan el recurso en el grupo de recursos de producción ContosoRG.

    Captura de pantalla del panel de aplicación web para crear una aplicación web en Linux.

  3. Se crea un plan de App Service (APP-SVP-EUS2) en la región primaria y se usa el tamaño estándar.

    Captura de pantalla del panel de nuevo plan de App Service para crear un plan de App Service.

  4. Seleccionan un sistema operativo Linux con la pila en tiempo de ejecución PHP 7.0, que es un contenedor de Docker.

    Captura de pantalla del panel de aplicación web, con el sistema operativo Linux, la ubicación Este de EE. UU. 2 y PHP 7.0 seleccionados.

  5. Crean una segunda aplicación web (osticket-cus) y un plan de Azure App Service para la región Centro de EE. UU.

    Captura de pantalla del panel de aplicación web, con el sistema operativo Linux, la ubicación Centro de EE. UU. y PHP 7.0 seleccionados.

¿Necesita más ayuda?

Paso 2: Configuración de Traffic Manager

Los administradores de Contoso configuran Traffic Manager para dirigir las solicitudes web entrantes a las aplicaciones web que se ejecutan en nivel web de osTicket.

  1. Crean un recurso de Traffic Manager (osticket.trafficmanager.net) en Azure Marketplace. Usan el enrutamiento de prioridad para que la región Este de EE. UU. 2 sea el sitio primario. Colocan el recurso en el grupo de recursos de la infraestructura existente (ContosoInfraRG). Tenga en cuenta que Traffic Manager es global y no está enlazado a una ubicación específica.

    Captura de pantalla del panel Crear perfil de Traffic Manager.

  2. Configuran Traffic Manager con puntos de conexión. Agregan la aplicación web de la región Este de EE. UU. 2 como sitio primario (osticket-eus2) y la aplicación web del Centro de EE. UU. como secundario (osticket-cus).

    Captura de pantalla del panel Agregar punto de conexión de Traffic Manager.

  3. Después de agregar los puntos de conexión, los administradores pueden supervisarlos.

    Captura de pantalla del panel Puntos de conexión para supervisar los puntos de conexión en Traffic Manager.

¿Necesita más ayuda?

Paso 3: Aprovisionamiento de Azure Database for MySQL

Los administradores de Contoso aprovisionan una instancia de base de datos MySQL en la región primaria (Este de EE. UU. 2).

  1. En Azure Portal, crea un recurso de Azure Database for MySQL.

    Captura de pantalla del vínculo Azure Database for MySQL en Azure Portal.

  2. Agrega el nombre contosoosticket para la base de datos de Azure. Agregan la base de datos al grupo de recursos de producción ContosoRG y, después, especifican las credenciales.

  3. La base de datos MySQL local es de la versión 5.7, por lo que selecciona esta versión por cuestiones de compatibilidad. Utiliza los tamaños predeterminados, que coinciden con los requisitos de la base de datos.

    Captura de pantalla del panel Servidor MySQL, con la versión 5.7 seleccionada.

  4. Para las opciones de redundancia de copia de seguridad, seleccionan Redundancia geográfica. Esta opción permite restaurar la base de datos de su región secundaria (Centro de EE. UU.) si se produce una interrupción. Solo pueden configurar esta opción al aprovisionar la base de datos.

    Captura de pantalla del panel Opciones de redundancia de copia de seguridad con la opción Redundancia geográfica seleccionada.

  5. Configuran la seguridad de conexión. En la base de datos, seleccionan Seguridad de la conexión y configuran las reglas de firewall para permitir que la base de datos acceda a los servicios de Azure.

  6. Se agrega la dirección IP del cliente de la estación de trabajo local a las direcciones IP inicial y final. Esto permite que las aplicaciones web tengan acceso a la base de datos MySQL, junto con el cliente de base de datos que realiza la migración.

    Captura de pantalla del panel Seguridad de la conexión que muestra el acceso a los servicios de Azure activado y a la dirección IP del cliente seleccionada.

Paso 4: Migración de la base de datos

Hay varias maneras de mover la base de datos MySQL. Cada opción requiere que los administradores de Contoso creen una instancia de Azure Database for MySQL para el destino. Después de crear la instancia, pueden migrar la base de datos mediante cualquiera de las dos rutas de acceso:

  • Paso 4a: Azure Database Migration Service
  • Paso 4b: Copia de seguridad y restauración de MySQL Workbench

Paso 4a: Migración de la base de datos mediante Azure Database Migration Service

Los administradores de Contoso siguen el tutorial de migración paso a paso para migrar la base de datos con Azure Database Migration Service. Pueden realizar migraciones en línea, sin conexión e híbridas (versión preliminar) mediante MySQL 5.6 o 5.7.

Nota:

MySQL 8.0 se admite en Azure Database for MySQL, pero la herramienta Azure Database Migration Service todavía no es compatible con esta versión.

En Resumen, Contoso hace lo siguiente:

  • Garantizan que se cumplen todos los requisitos previos:

    • El origen del servidor de bases de datos MySQL debe coincidir con la versión que admite Azure Database for MySQL. Azure Database for MySQL admite MySQL Community Edition, el motor de almacenamiento InnoDB y la migración entre origen y destino con las mismas versiones.

    • Habilitan el registro binario en my.ini (Windows) o my.cnf (Unix). Si no lo hacen, se producirá el siguiente error en el Asistente para migración:

      Error in binary logging. Variable binlog_row_image has value 'minimal'. Please change it to 'full'.

      Para obtener más información, consulte Opciones y variables del registro binario en la documentación de MySQL.

    • El usuario debe tener el rol ReplicationAdmin.

    • Migre los esquemas de base de datos sin claves externas ni desencadenadores.

  • Crean una red virtual que se conecta a través de ExpressRoute o VPN a la red local.

  • Crean una instancia de Azure Database Migration Service con una SKU Premium que está conectada a la red virtual.

  • Garantizan que Azure Database Migration Service pueda acceder a la base de datos MySQL a través de la red virtual. Esto implica asegurarse de que todos los puertos de entrada están permitidos desde Azure a MySQL en el nivel de la red virtual, la VPN de red y la máquina que hospeda MySQL.

  • Ejecutan la herramienta Database Migration Service y, a continuación, hacen lo siguiente:

    1. Crean un proyecto de migración basado en la SKU Premium.

      Captura de pantalla del panel de información general de MySQL con un mensaje que indica que el servicio de migración se ha creado correctamente.

      Captura de pantalla del panel Nuevo proyecto de migración de MySQL.

    2. Agregue un origen (base de datos local).

      Captura de pantalla del panel Agregar detalles de origen del Asistente para migración.

    3. Seleccione un destino.

      Captura de pantalla del panel Detalles de destino del Asistente para migración.

    4. Seleccione las bases de datos que se van a migrar.

      Captura de pantalla del panel Asignar a las bases de datos de destino del Asistente para migración.

    5. Configure las opciones avanzadas.

      Captura de pantalla del panel Configuración de migración del Asistente para migración.

    6. Inicie la replicación y resuelva los posibles errores.

      Captura de pantalla del panel de detalles del servidor.

    7. Realice la migración final.

      Captura de pantalla del panel de detalles de osTicket.

      Captura de pantalla del panel Migración total completa.

      Captura de pantalla de la tabla de estados de las actividades de migración.

    8. Restablezca las claves externas y los desencadenadores.

    9. Modifique las aplicaciones para que usen la nueva base de datos.

      Captura de pantalla de la tabla Actividades de migración.

Paso 4b: Migración de la base de datos (MySQL Workbench)

  1. Los administradores de Contoso comprueban los requisitos previos y las descargas de MySQL Workbench.

  2. Instala MySQL Workbench para Windows de acuerdo con las instrucciones de instalación. La máquina en la que instalen MySQL Workbench debe ser accesible para la máquina virtual osticketmysql y para Azure a través de Internet.

  3. En MySQL Workbench, se crea una conexión de MySQL a osticketmysql.

    Captura de pantalla del panel de detalles de la conexión de MySQL Workbench.

  4. Exportan la base de datos como osticket a un archivo independiente local.

    Captura de pantalla del panel Exportación de datos de MySQL Workbench.

  5. Después de realizar la copia de seguridad de la base de datos localmente, los administradores crean una conexión a la instancia de Azure Database for MySQL.

    Panel Configurar conexión nueva de MySQL Workbench.

  6. Ahora, pueden importar (restaurar) la base de datos en la instancia de Azure Database for MySQL desde el archivo independiente. Se crea un nuevo esquema (osticket) para la instancia.

    Captura de pantalla del panel Importación de datos de MySQL Workbench.

  7. Una vez que hayan restaurado los datos, los administradores podrán consultarlos mediante MySQL Workbench. Los datos se muestran en Azure Portal.

    Captura de pantalla de Azure Portal que muestra los datos restaurados.

    Captura de pantalla de la hoja de bases de datos de MySQL con una flecha que apunta a la base de datos osTicket.

  8. Los administradores actualizan la información de la base de datos en las aplicaciones web. En la instancia de MySQL, se abre Cadenas de conexión.

    Captura de pantalla del vínculo Cadenas de conexión en la instancia de MySQL.

  9. En la lista cadenas de conexión, seleccionan la configuración de la aplicación web y, a continuación, la copian seleccionando Haga clic para copiar.

    Captura de pantalla de la configuración de la aplicación web en la instancia de MySQL.

  10. Abren una nueva ventana del Bloc de notas, pegan la cadena allí y la actualizan para que coincida con la base de datos de osTicket, la instancia de MySQL y la configuración de credenciales.

    Captura de pantalla de la cadena de conexión pegada en un archivo de Notepad.

  11. Pueden comprobar el nombre del servidor y el inicio de sesión en el panel de información general de la instancia de MySQL en Azure Portal.

    Captura de pantalla del panel Grupo de recursos, que muestra el nombre del servidor y nombre de la cuenta de administrador del servidor.

Paso 5: Configuración de GitHub

Los administradores de Contoso crean un repositorio de GitHub privado y configuran una conexión a la base de datos osTicket en Azure Database for MySQL. Después, cargan la aplicación web en Azure App Service.

  1. Van al repositorio de GitHub público de software de osTicket y lo bifurcan a la cuenta de GitHub de Contoso.

    Captura de pantalla de la página del repositorio de GitHub con el botón Bifurcar resaltado.

  2. Después de bifurcar el repositorio, van a la carpeta include y seleccionan el archivo ost-config.php.

    Captura de pantalla del archivo PHP en GitHub.

  3. Se abre el archivo en el explorador y se edita.

    Captura de pantalla del icono de edición de archivo (un lápiz) en GitHub.

  4. En el editor, los administradores actualizan los detalles de la base de datos, específicamente para DBHOST y DBUSER.

    Captura de pantalla del panel de edición del archivo en GitHub.

  5. Los administradores confirman los cambios.

    Captura de pantalla en la que se resalta el botón Confirmar cambios en el panel de edición.

  6. Para cada aplicación web (osticket-eus2 y osticket-cus), en Azure Portal, seleccionan Configuración de la aplicación en el panel izquierdo y, a continuación, modifican la configuración.

    Captura de pantalla en la que se resalta el vínculo Configuración de la aplicación en Azure Portal.

  7. Se especifica la cadena de conexión con el nombre osticket y se copia la cadena desde el Bloc de notas en el área de valores. Se selecciona MySQL en la lista desplegable junto a la cadena y se guarda la configuración.

    Captura de pantalla del panel Cadenas de conexión que resalta la cadena de conexión de osTicket.

Paso 6: Configuración de las aplicaciones web

Como último paso del proceso de migración, los administradores de Contoso configuran las aplicaciones web con los sitios web de osTicket.

  1. En la aplicación web principal (osticket-eus2), abren Opción de implementación y establecen el origen en GitHub.

    Captura de pantalla del panel Opción de implementación, con GitHub seleccionado como origen.

  2. Se seleccionan las opciones de implementación.

    Captura de pantalla de los detalles de la opción en el panel Opción de implementación.

  3. Después de establecer las opciones, la configuración aparece como pendiente en Azure Portal.

    Captura de pantalla del panel Opciones de implementación que muestra un estado de sitio pendiente.

  4. Después de actualizar la configuración y cargar la instancia de la aplicación web de osTicket desde GitHub en el contenedor de Docker que ejecuta Azure App Service, el sitio se muestra como activo.

    Captura de pantalla del panel Opciones de implementación.

  5. Repiten los pasos anteriores para la aplicación web secundaria, osticket-cus.

  6. Tras configurar el sitio, es accesible a través del perfil de Traffic Manager. El nombre DNS es la nueva ubicación de la aplicación osTicket. Más información.

    Captura de pantalla del panel Perfil de Traffic Manager que muestra el nombre DNS.

  7. Contoso quiere usar un nombre DNS que sea fácil de recordar. En el panel Nuevo registro de recursos, crean un alias (CNAME) y un nombre de dominio completo (osticket.contoso.com) que apunta al nombre de Traffic Manager en el DNS de sus controladores de dominio.

    Captura de pantalla del panel Nuevo registro de recursos en el que se muestra el nombre de alias y un puntero a Traffic Manager.

  8. Se configuran ambas aplicaciones web, osticket-eus2 yosticket-cus, para permitir los nombres de host personalizados.

    Captura de pantalla del panel Agregar nombre de host que resalta el botón Validar.

Configurar el escalado automático

Por último, los administradores de Contoso configuran el escalado automático de la aplicación. El escalado automático garantiza que, a medida que los agentes usan la aplicación, las instancias de aplicación aumentan y disminuyen en función de las necesidades empresariales.

  1. En App Service APP-SVP-EUS2, abren Unidad de escalado.

  2. Se configura una nueva opción de escalado automático con una única regla que aumenta el recuento de instancias en uno cuando el uso de CPU para la instancia actual es superior al 70 % durante 10 minutos.

    Captura de pantalla de la página Configuración de escalabilidad automática de la primera región.

  3. Se configura la misma opción en APP-SVP-CUS para asegurarse de que se aplica el mismo comportamiento si la aplicación conmuta por error a la región secundaria. La única diferencia es que se establece la instancia predeterminada en 1, ya que solo es para las conmutaciones por error.

    Captura de pantalla de la página Configuración de escalabilidad automática de la segunda región.

Limpiar después de la migración

Al completar la migración, se refactoriza la aplicación osTicket para que se ejecute en una aplicación web de Azure App Service con entrega continua mediante un repositorio de GitHub privado. La aplicación se ejecuta en dos regiones para aumentar la resistencia. La base de datos de osTicket se ejecuta en Azure Database for MySQL después de la migración a la plataforma PaaS.

Para realizar una limpieza después de la migración, Contoso hace lo siguiente:

  • Eliminan las máquinas virtuales de VMware del inventario de vCenter.
  • Quita las VM locales de los trabajos de copia de seguridad locales.
  • Actualizan la documentación interna para que muestre las nuevas ubicaciones y direcciones IP.
  • Revisan los recursos que interactúan con las máquinas virtuales locales y actualizan los valores de configuración pertinentes o la documentación para reflejar la nueva configuración.
  • Vuelven a configurar la supervisión para que apunte a la dirección URL osticket.trafficmanager.net, para realizar un seguimiento de que la aplicación está en funcionamiento.

Revisión de la implementación

Con la aplicación en ejecución, Contoso debe proteger y poner plenamente en funcionamiento la infraestructura nueva.

Seguridad

El equipo de seguridad de Contoso revisa la aplicación para determinar si existe algún problema de seguridad. Identifican que la comunicación entre la aplicación osTicket y la instancia de base de datos MySQL no está configurada para SSL. Hacen todo esto para garantizar que el tráfico de la base de datos no pueda piratearse. Más información.

Copias de seguridad

  • Las aplicaciones web de osTicket no contienen datos de estado y, por tanto, no es necesario hacer copias de seguridad.
  • El equipo de Contoso no tiene que configurar la copia de seguridad de la base de datos. Azure Database for MySQL crea automáticamente copias de seguridad del servidor y las almacena. El equipo optó por utilizar la redundancia geográfica para la base de datos para que sea resistente y esté lista para la producción. Las copias de seguridad pueden utilizarse para restaurar el servidor a un momento dado. Más información.

Optimización de los costos y licencias

  • No hay ningún problema relacionado con las licencias para la implementación de PaaS.
  • Contoso usará Azure Cost Management + Billing para asegurarse de que la compañía permanece dentro de los presupuestos establecidos por la dirección de TI.