Refactorización de una aplicación local a una aplicación web de Azure App Service y una instancia de SQL Managed Instance

En este artículo se muestra cómo la compañía ficticia Contoso refactoriza una aplicación de Windows .NET de dos niveles que se ejecuta en máquinas virtuales de VMware como parte de una migración a Azure. El equipo de Contoso migra la máquina virtual de front-end de la aplicación a la aplicación web de Azure App Service. En este artículo también se muestra cómo Contoso migra la base de datos de la aplicación a Azure SQL Managed Instance.

La aplicación SmartHotel360 que se usa en este ejemplo se proporciona como software de código abierto. Si quiere utilizarla para sus propias pruebas, puede descargarla desde GitHub.

Impulsores del negocio

El equipo directivo de TI de Contoso ha trabajado estrechamente con sus socios comerciales para comprender lo quieren lograr con esta migración:

  • Abordar el crecimiento del negocio. Contoso está creciendo y los sistemas y la infraestructura locales están bajo presión.
  • Aumentar la eficacia. Contoso debe quitar procedimientos innecesarios y optimizar los procesos para sus desarrolladores y usuarios. La empresa necesita que el departamento de TI sea rápido y no malgaste tiempo ni dinero a fin de satisfacer más rápidamente los requisitos del cliente.
  • Aumentar la agilidad. el equipo de TI de Contoso necesita más capacidad de respuesta a las necesidades de la empresa. El equipo de TI debe ir por delante de los cambios del mercado para garantizar el éxito en una economía global. El tiempo de reacción no se debe interponer en el camino ni bloquear el negocio.
  • Escala. a medida que el negocio crece satisfactoriamente, el equipo de TI de Contoso debe proporcionar sistemas que puedan crecer al mismo ritmo.
  • Reducir los costos. Contoso quiere minimizar los costos de licencia.

Objetivos de la migración

El equipo de la nube de Contoso ha definido los siguientes objetivos con el fin de determinar el mejor método de migración:

Requisitos Detalles
Aplicación La aplicación de Azure seguirá siendo tan crítica como lo es hoy en día en el entorno local.

Debe tener las mismas funcionalidades de rendimiento que las que tiene actualmente en VMware.

El equipo no quiere invertir en la aplicación. Por ahora, los administradores simplemente moverán la aplicación de forma segura a la nube.

El equipo quiere finalizar el soporte técnico de Windows Server 2008 R2, donde se ejecuta actualmente la aplicación.

El equipo también quiere abandonar SQL Server 2008 R2 y pasar a una base de datos de plataforma como servicio (PaaS), lo que minimizará la necesidad de administración.

Contoso quiere aprovechar su inversión en licencias de SQL Server y Software Assurance, tanto como que sea posible.

Además, Contoso quiere mitigar el único punto de error en el nivel web.
Limitaciones La aplicación está formada por una aplicación de ASP.NET y un servicio Windows Communication Foundation (WCF) que se ejecutan en la misma máquina virtual. Contoso quiere distribuir estos componentes entre dos aplicaciones web con Azure App Service.
Azure Contoso quiere mover la aplicación a Azure, pero no quiere que se ejecute en máquinas virtuales. Quiere usar los servicios de PaaS de Azure para los niveles web y de datos.
DevOps Contoso quiere migrar a un modelo DevOps, con Azure DevOps para las canalizaciones de compilación y de versión.

Diseño de la solución

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

Aplicación actual

  • La aplicación SmartHotel360 local se divide en niveles entre dos máquinas virtuales (WEBVM y SQLVM).
  • Las máquinas virtuales se encuentran en el host de VMware ESXi contosohost1.contoso.com versión 6.5.
  • El entorno de VMware se administra con 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).
  • Las VM locales del centro de datos de Contoso se retirarán después de realizar la migración.

Solución propuesta

  • Para el nivel web de la aplicación, Contoso ha decidido usar Azure App Service. Este servicio PaaS permite implementar la aplicación con tan solo unos cambios en la configuración. Contoso usará Visual Studio para realizar el cambio e implementará dos aplicaciones web, una para el sitio web y otra para el servicio WCF.
  • Para cumplir los requisitos de una canalización de DevOps, Contoso usará Azure DevOps para la administración del código fuente con repositorios de Git. Se usarán compilaciones y versiones automatizadas para compilar el código e implementarlo en Azure App Service.

Consideraciones sobre la base de datos

Como parte del proceso de diseño de la solución, Contoso hizo una comparación de características entre Azure SQL Database y SQL Managed Instance. Contoso ha decidido usar SQL Managed Instance basándose en las siguientes consideraciones:

  • El objetivo de SQL Managed Instance es proporcionar casi un 100 % de compatibilidad con la versión de la instalación local de SQL Server más reciente. Microsoft recomienda SQL Managed Instance para los clientes que ejecutan SQL Server de forma local o en máquinas virtuales de infraestructura como servicio (IaaS), que desean migrar sus aplicaciones a un servicio totalmente administrado con cambios mínimos en el diseño.
  • Contoso planea migrar un gran número de aplicaciones desde el entorno local a máquinas de IaaS. Muchas de estas máquinas virtuales las proporcionan proveedores de software independientes. Contoso se da cuenta de que el uso de SQL Managed Instance le ayudará a garantizar la compatibilidad de las bases de datos con estas aplicaciones. Utilizarán SQL Managed Instance en lugar de utilizar SQL Database, que podría no ser compatible.
  • Contoso simplemente puede realizar una migración mediante lift-and-shift a SQL Managed Instance con Azure Database Migration Service totalmente automatizado. Con este servicio, Contoso puede reutilizarla para las migraciones futuras de la base de datos.
  • SQL Managed Instance admite el Agente SQL Server, un componente importante de la aplicación SmartHotel360. Contoso necesita esta compatibilidad porque, sin ella, tendrá que volver a diseñar los planes de mantenimiento que requiere la aplicación.
  • Con Software Assurance, Contoso puede intercambiar sus licencias existentes para obtener descuentos en una instancia de SQL Managed Instance con la Ventaja híbrida de Azure para SQL Server. Esto permite a Contoso ahorrar hasta un 30 % mediante el uso de SQL Managed Instance.
  • La instancia de SQL Managed Instance está totalmente integrada en la red virtual, por lo que ofrece un mayor nivel de aislamiento y seguridad para los datos de Contoso. Contoso puede obtener las ventajas de la nube pública y, al mismo tiempo, mantener el entorno aislado de la red Internet pública.
  • SQL Managed Instance admite muchas características de seguridad, entre otras, Always Encrypted, enmascaramiento dinámico de datos, seguridad en el nivel de fila y detección de amenazas.

Revisión de la solución

Contoso evalúa el diseño propuesto y crea una lista de ventajas y desventajas como se muestra en la tabla siguiente:

Consideración Detalles
Ventajas No es necesario modificar el código de la aplicación SmartHotel360 para la migración a Azure.

Contoso puede aprovechar su inversión en Software Assurance con la Ventaja híbrida de Azure para SQL Server y Windows Server.

Después de la migración, ya no será necesaria la compatibilidad con Windows Server 2008 R2. Para obtener más información, consulte la directiva de ciclo de vida de Microsoft.

Contoso puede configurar el nivel web de la aplicación con varias instancias, para que el nivel web deje de ser un único punto de error.

La base de datos ya no dependerá de la antigüedad de SQL Server 2008 R2.

Instancia administrada de SQL admite los requisitos técnicos y los objetivos de Contoso.

La instancia de SQL Managed Instance va a proporcionar compatibilidad total con su implementación actual, al tiempo que le permite dejar de usar SQL Server 2008 R2.

Contoso puede aprovechar su inversión en Software Assurance y usar la Ventaja híbrida de Azure para SQL Server y Windows Server.

Puede volver a usar Azure Database Migration Service para futuras migraciones adicionales.

La instancia de SQL Managed Instance tiene tolerancia a errores integrada que Contoso no necesita configurar. Esto garantiza que la capa de datos ya no sea un único punto de conmutación por error.
Desventajas Azure App Service solo admite la implementación de una aplicación por cada aplicación web. Esto significa que deben aprovisionarse dos aplicaciones web (una para el sitio web y otra para el servicio WCF).

Para la capa de datos, es posible que SQL Managed Instance no sea la mejor solución si Contoso desea personalizar el sistema operativo o el servidor de base de datos, o si desea ejecutar aplicaciones de terceros junto con SQL Server. La ejecución de SQL Server en una máquina virtual IaaS puede proporcionar esta flexibilidad.

Arquitectura propuesta

Diagrama de la arquitectura propuesta.

Proceso de migración

  1. Contoso aprovisiona una instancia de Azure SQL Managed Instance a la que migra la base de datos SmartHotel360 mediante Azure Database Migration Service.

  2. Aprovisiona y configura las aplicaciones web e implementa la aplicación SmartHotel360 en ellas.

    Diagrama del proceso de migración.

Servicios de Azure

Servicio Descripción Coste
Azure App Service Migration Assistant Una forma sencilla y gratuita de migrar sin problemas aplicaciones web de .NET desde el entorno local a la nube con cambios mínimos en el código o incluso sin ningún cambio. Es una herramienta que se puede descargar de forma gratuita.
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. Obtenga información sobre las regiones admitidas y los precios de Azure Database Migration Service.
Instancia administrada de Azure SQL SQL Managed Instance es un servicio de base de datos administrada que representa una instancia de SQL Server completamente administrada en Azure. Usa el mismo código que la versión más reciente del motor de base de datos de SQL Server y tiene las características, mejoras de rendimiento y revisiones de seguridad más recientes. El uso de una instancia de SQL Managed Instance que se ejecuta en Azure conlleva cargos en función de la capacidad. Más información acerca de los precios de SQL Managed Instance.
Azure App Service Permite crear aplicaciones en la nube eficaces que usan una plataforma totalmente administrada. Los precios se basan en el tamaño, la ubicación y la duración del uso. Más información.
Azure Pipelines Ofrece una canalización de integración continua e implementación continua (CI/CD) para el desarrollo de aplicaciones. La canalización comienza con un repositorio de Git para administrar código de aplicaciones, un sistema de compilación para producir paquetes y otros artefactos de compilación, y un sistema de administración de versiones para implementar cambios en entornos de desarrollo, prueba y producció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

Contoso ejecutará la migración de la forma siguiente:

  • Paso 1: Evaluar y migrar las aplicaciones web. Contoso usa la herramienta Azure App Service Migration Assistant para ejecutar comprobaciones de compatibilidad previas a la migración y migrar sus aplicaciones web a Azure App Service.
  • Paso 2: Configuración de una instancia de SQL Managed Instance. Contoso necesita una instancia administrada existente a la que se migrará la base de datos de SQL Server local.
  • Paso 3: Migración a través de Azure Database Migration Service. Contoso migra la base de datos de la aplicación a través de Azure Database Migration Service.
  • Paso 4: Configuración de Azure DevOps. Contoso crea un proyecto de Azure DevOps e importa el repositorio de Git.
  • Paso 5: Configuración de cadenas de conexión. Contoso configura las cadenas de conexión para que la instancia de SQL Managed Instance, la aplicación web del servicio WCF y la aplicación web del nivel web puedan comunicarse.
  • Paso 6: Configuración de las canalizaciones de compilación y versión en Azure DevOps. Como último paso, Contoso configura las canalizaciones de compilación y de versión en Azure DevOps para crear la aplicación. A continuación, el equipo implementa las canalizaciones en dos aplicaciones web independientes.

Paso 1: Evaluar y migrar las aplicaciones web

Los administradores de Contoso evalúan y migran su aplicación web mediante la herramienta Azure App Service Migration Assistant. Usan la ruta de aprendizaje sobre migración de aplicaciones de ASP.NET a Azure como guía durante el proceso. En resumen, los administradores realizan las siguientes acciones:

  • Usan la herramienta Azure App Service Migration Assistant para evaluar las dependencias entre sus aplicaciones web y determinar si hay alguna incompatibilidad entre las aplicaciones web locales y aquellas que se admiten en Azure App Service.

  • Descargan Azure App Service Migration Assistant e inician sesión en su cuenta de Azure.

  • Eligen una suscripción, un grupo de recursos y el nombre de dominio del sitio web.

Paso 2: Configuración de una instancia de SQL Managed Instance

Para configurar una instancia de Azure SQL Managed Instance, Contoso necesita una subred que cumpla los requisitos siguientes:

  • La subred debe estar dedicada. Debe estar vacía y no puede contener ningún otro servicio en la nube. La subred no puede ser una subred de puerta de enlace.
  • Una vez creada la instancia administrada, Contoso no debe agregar recursos a la subred.
  • La subred no puede tener asociado un grupo de seguridad de red.
  • La subred debe tener una tabla de rutas definida por el usuario. La única ruta asignada debe ser 0.0.0.0/0, con Internet como próximo salto.
  • Si se especifica un DNS personalizado para la red virtual, es necesario agregar a la lista la dirección IP virtual 168.63.129.16 de las resoluciones recursivas de Azure. Aprenda a configurar un servidor DNS personalizado para una instancia de Azure SQL Managed Instance.
  • La subred no puede tener un punto de conexión de servicio (de almacenamiento o SQL) asociado a ella. Los puntos de conexión de servicio se deben deshabilitar en la red virtual.
  • La subred tiene que tener como mínimo 16 direcciones IP. Aprenda cómo cambiar el tamaño de la subred de la instancia administrada.
  • En el entorno híbrido de Contoso, se requiere la configuración de DNS personalizada. Contoso configura los valores de DNS para usar uno o varios de los servidores de Azure DNS de la empresa. Más información sobre la personalización de DNS.

Configurar una red virtual para la instancia administrada

Los administradores de Contoso configuran la red virtual de la forma siguiente:

  1. Crean una nueva red virtual (VNET-SQLMI-EU2) en la región primaria (East US 2). Agregan la red virtual al grupo de recursos ContosoNetworkingRG.

  2. Asignan el espacio de direcciones 10.235.0.0/24. Garantizan que el intervalo no se solapa con otras redes de su empresa.

  3. Se agregan dos subredes a la red:

    • SQLMI-DS-EUS2 (10.235.0.0/25).

    • SQLMI-SAW-EUS2 (10.235.0.128/29). Esta subred se usa para asociar un directorio a la instancia administrada.

      Captura de pantalla del panel Crear red virtual de la instancia administrada.

  4. Después de implementar la red virtual y las subredes, emparejan las redes como se indica a continuación:

    • Se empareja VNET-SQLMI-EUS2 con VNET-HUB-EUS2 (la red virtual del centro de conectividad de East US 2).

    • Se empareja VNET-SQLMI-EUS2 con VNET-PROD-EUS2 (la red de producción).

      Captura de pantalla de las redes emparejadas.

  5. Establecen una configuración de DNS personalizada. La configuración de DNS primero apunta a los controladores de dominio de Azure de Contoso. Azure DNS es secundario. Los controladores de dominio de Azure de Contoso están ubicados de la manera siguiente:

    • Ubicados en la subred PROD-DC-EUS2, en la red de producción (VNET-PROD-EUS2) en la región East US 2.

    • Dirección de CONTOSODC3: 10.245.42.4

    • Dirección de CONTOSODC4: 10.245.42.5

    • Solucionador de Azure DNS: 168.63.129.16

    Captura de pantalla de la lista de servidores DNS de red.

¿Necesita más ayuda?

Configuración del enrutamiento

La instancia administrada se coloca en una red privada virtual. Contoso necesita una tabla de enrutamiento para que la red virtual se comunique con el servicio de administración de Azure. Si la red virtual no puede comunicarse con el servicio que la administra, se vuelve inaccesible.

Contoso tiene en cuenta estos factores:

  • La tabla de enrutamiento contiene un conjunto de reglas (rutas) que especifican cómo se deben enrutar los paquetes enviados en la red virtual desde la instancia administrada.
  • La tabla de enrutamiento se asocia con subredes en las que se implementan instancias administradas. Cada paquete que sale de una subred se controla en función de la tabla de rutas asociada.
  • Una subred puede asociarse con una sola tabla de rutas.
  • No hay ningún cargo adicional por la creación de tablas de redirección en Microsoft Azure.

Para configurar el enrutamiento, los administradores de Contoso siguen estos pasos:

  1. Se crea una tabla de enrutamiento definida por el usuario en el grupo de recursos ContosoNetworkingRG.

    Captura de pantalla del panel Crear tabla de rutas.

  2. Para cumplir los requisitos de SQL Managed Instance, tras implementar la tabla de rutas (MIRouteTable), los administradores agregan una ruta con un prefijo de dirección 0.0.0.0/0. La opción Tipo de próximo salto está establecida en Internet.

    Captura de pantalla del panel Agregar ruta para agregar un prefijo de dirección.

  3. Se asocia la tabla de enrutamiento con la subred SQLMI-DB-EUS2 (en la red VNET-SQLMI-EUS2).

    Captura de pantalla del panel Asociar subred para enrutar la subred de la tabla.

¿Necesita más ayuda?

Aprenda cómo configurar rutas para una instancia administrada.

Creación de una instancia administrada

Ahora, los administradores de Contoso aprovisionan una instancia de SQL Managed Instance. Para ello:

  1. Como la instancia administrada da servicio a una aplicación empresarial, los administradores implementan la instancia administrada en la región primaria de la empresa (Este de EE. UU. 2). La instancia administrada se agrega al grupo de recursos ContosoRG.

  2. Seleccionan un plan de tarifa y el tamaño de los recursos de tamaño y almacenamiento de la instancia. Más información acerca de los precios de SQL Managed Instance.

    Captura de pantalla del panel SQL Managed Instance.

    Una vez implementada la instancia administrada, aparecen dos nuevos recursos en el grupo de recursos ContosoRG:

    • La instancia de SQL Managed Instance.

    • Un clúster virtual en caso de que Contoso tenga varias instancias administradas.

      Captura de pantalla de los nuevos recursos del grupo de recursos ContosoRG.

¿Necesita más ayuda?

Aprenda cómo aprovisionar una instancia administrada.

Paso 3: Migración a través de Azure Database Migration Service

Los administradores de Contoso siguen las instrucciones del tutorial de migración paso a paso para migrar la instancia administrada con Azure Database Migration Service. Pueden realizar migraciones en línea, sin conexión e híbridas (versión preliminar).

En resumen, los administradores de Contoso hacen lo siguiente:

  • Crean una instancia de Azure Database Migration Service con una SKU Premium que está conectada a la red virtual.
  • Se aseguran de que Database Migration Service pueda acceder a la instancia remota de SQL Server a través de la red virtual. Esto implicaría asegurarse de que todos los puertos de entrada están permitidos desde Azure a SQL Server en el nivel de la red virtual, la VPN de red y la máquina que hospeda SQL Server.
  • Configuran Azure Database Migration Service:
    • Cree un proyecto de migración.
    • Agregue un origen (base de datos local).
    • Seleccione un destino.
    • Seleccione las bases de datos que se van a migrar.
    • Configure las opciones avanzadas.
    • Inicie la replicación.
    • Resuelva posibles errores.
    • Realice la migración final.

Paso 4: Configurar Azure DevOps

Contoso necesita compilar la infraestructura y las canalizaciones de DevOps para la aplicación. Para ello, los administradores de Contoso crean un proyecto de DevOps, importan el código y luego configuran las canalizaciones de compilación y versión.

  1. En la cuenta de Azure DevOps de Contoso, crean un nuevo proyecto, ContosoSmartHotelRefactor, y, a continuación, seleccionan Git como control de versiones.

    Captura de pantalla del panel Nuevo proyecto.

  2. Importan el repositorio de Git que actualmente contiene su código de la aplicación. Lo descargan desde el repositorio público de GitHub.

    Captura de pantalla del panel Importar un repositorio GIT para especificar el tipo de origen y la dirección URL de clonación.

  3. Conectan Visual Studio al repositorio y clonan el código en la máquina de desarrollo mediante Team Explorer.

    Captura de pantalla del panel Conectarse a un proyecto.

  4. Abren el archivo de la solución para la aplicación. La aplicación web y el servicio WCF tienen proyectos separados dentro del archivo.

    Captura de pantalla del Explorador de soluciones, donde se enumeran los proyectos de la aplicación web y el servicio WCF.

Paso 5: Configurar cadenas de conexión

Los administradores de Contoso se aseguran de que las aplicaciones web y la base de datos pueden comunicarse. Para ello, configura las cadenas de conexión en el código y en las aplicaciones web.

  1. En la aplicación web del servicio WCF, SHWCF-EUS2, en Configuración>Configuración de la aplicación, agregan una nueva cadena de conexión llamada DefaultConnection.

  2. Extraen la cadena de conexión de la base de datos SmartHotel-Registration y, a continuación, la actualizan con las credenciales correctas.

    Captura de pantalla del panel Configuración de la cadena de conexión.

  3. En Visual Studio, los administradores abren el proyecto SmartHotel.Registration.wcf desde el archivo de la solución. En el proyecto, actualizan la sección connectionStrings del archivo web.config con la cadena de conexión.

    Captura de pantalla de la sección connectionStrings del archivo web.config en el proyecto SmartHotel.Registration.wcf.

  4. Cambian la sección client del archivo web.config para que SmartHotel.Registration.Web apunte a la nueva ubicación del servicio WCF. Esta es la dirección URL de la aplicación web WCF que hospeda el punto de conexión de servicio.

    Captura de pantalla de la sección Cliente del archivo web.config del proyecto SmartHotel.Registration.wcf.

  5. Una vez realizados los cambios en el código, los administradores los confirman y los sincronizan mediante Team Explorer en Visual Studio.

Paso 6: Configurar canalizaciones de compilación y versión en Azure DevOps

Los administradores de Contoso configuran ahora Azure DevOps para ejecutar el proceso de compilación y creación de versiones.

  1. En Azure DevOps, seleccionan Compilación y versión>Nueva canalización.

    Captura de pantalla del vínculo Nueva canalización en Azure DevOps.

  2. Seleccionan Repositorio GIT de Azure Repos y el repositorio correspondiente.

    Captura de pantalla del botón Repositorio Git de Azure y el repositorio seleccionado.

  3. En Seleccionar una plantilla, selecciona la plantilla de ASP.NET para su compilación.

    Captura de pantalla del panel Seleccionar una plantilla para seleccionar la plantilla de ASP.NET.

  4. Usan el nombre ContosoSmartHotelRefactor-ASP.NET-CI para realizar la compilación y, a continuación, seleccionan Guardar y poner en cola, lo que inicia la primera compilación.

    Captura de pantalla del botón Guardar y poner en cola para la compilación.

  5. Seleccionan el número de compilación para ver el proceso. Cuando termina, los administradores pueden ver los comentarios del proceso y seleccionar Artefactos para revisar los resultados de la compilación.

    Captura de pantalla de la página de compilación y el vínculo Artefactos para revisar los resultados de la compilación.

    Se abre el panel Explorador de artefactos y la carpeta drop muestra los resultados de la compilación.

    • Los dos archivos .zip son los paquetes que contienen las aplicaciones.
    • Estos archivos .zip se usan en la canalización de versión para la implementación en Azure App Service.

    Captura de pantalla del panel Explorador de artefactos.

  6. Seleccionan Versiones>+ Nueva canalización.

    Captura de pantalla del vínculo Nueva canalización.

  7. Seleccionan la plantilla de implementación de Azure App Service.

    Captura de pantalla de la plantilla de implementación de Azure App Service.

  8. Asignan a la canalización de versión el nombre ContosoSmartHotel360Refactor y, en Nombre de la fase, especifican SHWCF-EUS2 como nombre de la aplicación web de WCF.

    Captura de pantalla del nombre de la fase de la aplicación web de WCF.

  9. En las fases, seleccionan 1 phase, 1 task (1 fase, 1 tarea) para configurar la implementación del servicio WCF.

    Captura de pantalla de la opción 1 trabajo, 1 tarea.

  10. Comprueban que la suscripción está seleccionada y autorizada y, a continuación, seleccionan Nombre de App Service.

    Captura de pantalla de la selección del nombre de App Service.

  11. En la canalización, seleccionan Artefactos, + Agregar un artefacto, después, seleccionan Compilación como el tipo de origen y, finalmente, compilan con la canalización ContosoSmarthotel360Refactor.

    Captura de pantalla del botón Compilación del panel Agregar un artefacto.

  12. Los administradores seleccionan el icono de rayo en el artefacto para habilitar el desencadenador de la implementación continua.

    Captura de pantalla del icono de rayo en el artefacto.

  13. Establecen el desencadenador de implementación continua en Habilitado.

    Captura de pantalla que muestra el desencadenador de implementación continua establecido en Habilitado.

  14. Ahora, vuelven a la fase 1 trabajo, 1 tarea y, después, seleccionan Implementación de Azure App Service.

    Captura de pantalla de la opción para seleccionar Implementación de Azure App Service.

  15. En Seleccione un archivo o carpeta, expanden la carpeta drop, seleccionan el archivo SmartHotel.Registration.Wcf.zip que se creó durante la compilación y, a continuación, seleccionan Guardar.

    Captura de pantalla del panel Seleccione un archivo o carpeta para seleccionar el archivo WCF.

  16. Seleccionan Canalización>Fases y, a continuación, seleccionan + Agregar para agregar un entorno para SHWEB-EUS2. Seleccionan otra implementación de Azure App Service.

    Captura de pantalla del vínculo 1 trabajo, 1 tarea para agregar un entorno.

  17. Repiten el proceso para publicar el archivo de aplicación web (SmartHotel.Registration.Web.zip) en la aplicación web correcta y, a continuación, seleccionan Guardar.

    Captura de pantalla del panel Seleccione un archivo o carpeta para seleccionar el archivo web.

    Aparece la canalización de versión, como se muestra aquí:

    Captura de pantalla del resumen de la canalización de versión.

  18. Vuelven a Compilación, seleccionan Desencadenadores y, a continuación, activan la casilla Habilitar la integración continua. Esta acción habilita la canalización para que, cuando se confirmen los cambios en el código, se produzcan la compilación y la creación de versión completas.

    Captura de pantalla en la que se resalta la casilla

  19. Seleccionan Guardar y poner en cola para ejecutar la canalización completa. Se desencadena una nueva compilación que, a su vez, crea la primera versión de la aplicación en Azure App Service.

    Captura de pantalla del botón Guardar y poner en cola.

  20. Los administradores de Contoso pueden seguir el proceso de canalización de compilación y versión en Azure DevOps. Una vez finalizada la compilación, se inicia la creación de versión.

    Captura de pantalla de compilación y versión.

  21. Una vez finalizada la canalización, se han implementado ambos sitios, y la aplicación está funcionamiento en línea.

    Captura de pantalla que muestra que la aplicación está en funcionamiento.

    La aplicación se ha migrado correctamente a Azure.

Limpieza después de la migración

Después de la migración, el equipo de Contoso realiza los siguientes pasos de limpieza:

  • Quita las VM locales del inventario de vCenter.
  • Eliminan las máquinas virtuales de los trabajos de copia de seguridad locales.
  • Actualizan la documentación interna para que muestre las nuevas ubicaciones de la aplicación SmartHotel360. La documentación muestra que la base de datos se ejecuta en SQL Managed Instance y el front-end está en ejecución en dos aplicaciones web.
  • Revisan los recursos que interactúan con las máquinas virtuales retiradas y actualizan los valores de configuración pertinentes y la documentación para reflejar la nueva configuración.

Revisión de la implementación

Con los recursos ya migrados a Azure, Contoso debe proteger la infraestructura nueva y ponerla totalmente en marcha.

Seguridad

  • Contoso tiene que asegurarse de que la nueva base de datos SmartHotel-Registration es segura. Más información.
  • Específicamente, Contoso actualiza las aplicaciones web para usar SSL con certificados.

Copias de seguridad

  • El equipo de Contoso revisa los requisitos de copia de seguridad de la base de datos de Azure SQL Managed Instance. Más información.
  • También aprenden a administrar las copias de seguridad y las restauraciones de SQL Database. Más información sobre las copias de seguridad automáticas.
  • Consideran la implementación de grupos de conmutación por error para proporcionar conmutación por error regional para la base de datos. Más información.
  • Para lograr resistencia, consideran la implementación de la aplicación web en la región principal (East US 2) y la región secundaria (Central US). El equipo podría configurar Traffic Manager para garantizar la conmutación por error durante las interrupciones regionales.

Optimización de los costos y licencias

  • Una vez implementados todos los recursos, Contoso asigna etiquetas de Azure según el planeamiento de la infraestructura.
  • Todas las licencias se integran en el costo de los servicios de PaaS que consume Contoso. Este costo se deduce del Contrato Enterprise.
  • 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.

Conclusión

En este artículo, Contoso refactorizó la aplicación SmartHotel360 en Azure mediante la migración de la VM de front-end de la aplicación a dos aplicaciones web de Azure App Service. La base de datos de la aplicación se migró a una instancia de Azure SQL Managed Instance.