En entrada anterior, creó una máquina virtual (VM) e instaló paquetes manualmente para ejecutar un servidor web básico. Si estuviera ansioso por empezar, podría compilar una pizzería en línea con esta VM. Uno de los mayores casos de uso de Azure VM es para ejecutar aplicaciones web, normalmente a escala. Las aplicaciones web son una carga de trabajo cómoda para las VM, La comodidad es buena, si también le gusta el mantenimiento que conlleva la administración de todas esas máquinas virtuales. Ya sabe, cosas divertidas como las actualizaciones de software, los parches de seguridad, el registro centralizado y los informes de cumplimiento. ¿Qué pasaría si pudiera obtener toda la potencia de un servidor web seguro para ejecutar sus aplicaciones web, incluida la capacidad de escalado automático para satisfacer las demandas, pero sin la necesidad de crear y administrar todas esas VM? Permítame presentarles el servicio Azure Web Apps.
En este capítulo, vamos a comparar el enfoque de infraestructura como servicio (IaaS) de las VM y los servidores web con el enfoque de plataforma como servicio (PaaS). Aprenderá las ventajas de Azure Web Apps a medida que crea una aplicación web y verá cómo trabajar con sus versiones de desarrollo y producción. A continuación, aprenderá a implementar su aplicación web automáticamente desde un control de código fuente, como GitHub. Este flujo de trabajo se muestra en la siguiente imagen. Azure Web Apps le permite implementar y ejecutar su pizzería en línea en cosa de minutos, sin necesidad de instalar y configurar un VM ni paquetes de servidor web.

Información general y conceptos de Azure Web Apps
Con Azure Web Apps, empezará a sumergir sus dedos en el maravilloso mundo de las soluciones PaaS. Si piensa que la informática en la nube solo se trata de VM, probablemente cambiará de idea. Al comienzo de este libro, hablamos sobre adquirir potencia para el equipo y centrarse en sus aplicaciones y clientes. Cuando se cambia de soluciones IaaS, como VM y se vuelca hacia soluciones PaaS, como aplicaciones web, sus aplicaciones y clientes se convierten en el foco.
Para ejecutar aplicaciones web en IaaS, las VM requieren la administración del SO, actualizaciones de aplicaciones, reglas de seguridad y tráfico, además de la configuración de todo el sistema. Con Web Apps, usted carga su aplicación web y delega todas esas tareas administrativas. Ahora puede enfocarse en mejorar la experiencia de la aplicación para sus clientes o en mejorar la disponibilidad con opciones de escalado y administración de tráfico.
¿Significa eso que nunca debe ejecutar VM para hospedar una aplicación web? Probablemente no. Hay razones válidas para ejecutar toda la pila de aplicaciones y configurarla usted mismo, como por ejemplo si necesita un soporte de aplicaciones muy específico o un tiempo de ejecución de lenguaje. Pero Web Apps puede proporcionar muchos de los casos de uso para ejecutar aplicaciones web.

Lenguajes y entornos compatibles
¿Qué tipo de flexibilidad ofrece Web Apps en términos de lenguajes de programación que puede utilizar para crear su aplicación web? ¡Bastante! Existen dos plataformas principales para ejecutar Web Apps: Windows y Linux. Puede ejecutar aplicaciones web .NET Core, Node.js, Python, Java, Ruby y PHP de forma nativa en instancias de aplicaciones web de Windows y Linux. En Windows, también puede ejecutar .NET Framework completo. Si quiere ser realmente especial y ejecutar su aplicación web en contenedores, también existe Web Apps for Containers que le permite ejecutar contenedores Docker nativos para Linux. Nos adentraremos más en contenedores y Docker en el capítulo 19: Por ahora, es suficiente que entienda que sus opciones están cubiertas con Web Apps.
¿En qué situaciones Web Apps no tiene mucho sentido? No todos los lenguajes de aplicación son compatibles con Web Apps. Digamos que realmente quiere torturarse con una aplicación web escrita en Perl. En ese caso, es probable que vuelva a ejecutar en VM IaaS que administra usted mismo, porque Perl no es compatible con Web Apps. Sin embargo, Web Apps es compatible con los lenguajes de programación web más comunes que podría querer utilizar. Probablemente también debería buscar una versión más reciente de la aplicación que una escrita en Perl.
Web Apps no solo es compatible con varios lenguajes, sino que también con varias versiones de esos lenguajes. Piense en PHP, por ejemplo. Típicamente, hay tres o cuatro versiones de PHP que puede seleccionar para tener una mejor compatibilidad para su aplicación. Y lo mejor de todo, es que no tiene que preocuparse por las dependencias en el servidor web subyacente para que sean compatibles con todo, como lo necesitaría si usted mismo administrara una VM IaaS. Python es otro ejemplo de diferencias entre las versiones estables 2.7 y 3.6 (y posteriores), como se muestra en la siguiente figura.

Web Apps también mantiene actualizadas las correcciones de seguridad. Pero no espere que una versión anterior de PHP o Python siga siendo compatible indefinidamente, en algún momento habrá un corte de versiones anteriores compatibles. Una vez más, ese podría ser un momento en el que deba volver a ejecutar usted mismo VM IaaS si la aplicación necesita una versión anterior de lenguaje. Pero si necesita ejecutar una versión anterior de un lenguaje determinado para que sea compatible con una aplicación heredada, no se quede estancado en un enfoque de mantenimiento constante. Siempre busque cambiar esas aplicaciones heredadas a plataformas compatibles más modernas.

Representación de versiones diferentes mediante ranuras de implementación
Las ranuras de implementación proporcionan un entorno preconfigurado para su aplicación web. Puede insertar nuevas versiones de la aplicación en una ranura de implementación y ejecutarlas con variables de entorno o conexiones a base de datos, sin afectar al sitio en vivo. Cuando esté satisfecho con lo que ve en la ranura de implementación, puede cambiar esta versión al sitio en vivo en un instante. A continuación, el sitio que antes estaba en vivo luego cambia a su propia ranura de implementación, proporcionando una versión archivada o puede llevar la aplicación de vuelta a producción si fuera necesario.
El número de ranuras de implementación disponibles varía en función del nivel de aplicación web que seleccione. Un mayor número de ranuras de implementación permite que diferentes desarrolladores utilicen varias versiones en etapas, a medida que representan y prueban sus propias actualizaciones.

Planes de App Services
Web Apps es parte de la familia más extensa App Services de Azure, que también incluye Mobile Apps, API Apps y Logic Apps. Todas, salvo Logic Apps están disponibles en todas las regiones donde Azure está disponible. Este es un excelente recurso para comprobar la disponibilidad por región: https://azure.microsoft.com/regions/services. Muchos servicios están disponibles en todo el mundo.
Cuando necesite crear un recurso de App Services, como una aplicación web, cree o utilice un plan de App Services existente. El plan de servicio define la cantidad de recursos disponibles para usted, cuánta automatización está disponible para escalar y hacer copias de seguridad de su aplicación web, y cuánta disponibilidad tiene su sitio con espacios de ensayo y Traffic Manager (una forma de dirigir geográficamente el tráfico a la instancia más cercana para un usuario). Así como con cualquier cosa, obtiene lo que paga. Las necesidades de su aplicación y de su negocio deben guiarle en cuanto a la cantidad de recursos requeridos y las características adicionales que se necesitan. Cada nivel de servicio se basa en las funciones de los niveles inferiores, agregando generalmente más almacenamiento y recursos disponibles.
Los cuatro niveles principales del plan de servicios son los siguientes:
– Gratuito/compartido: utiliza una infraestructura compartida, ofrece almacenamiento mínimo y no tiene opciones para implementar versiones diferentes en etapas, enrutar tráfico o hacer copias de respaldo. El nivel compartido le permite utilizar un dominio personalizado y cobra por este dominio.
– Básico: proporciona recursos informáticos dedicados para su aplicación web y le permite utilizar SSL y escalar manualmente el número de instancias de la aplicación web que ejecuta. Los niveles gratuitos/compartidos y básicos ofrecen un buen entorno para probar el servicio de Web Apps, pero no recomendaría ejecutar ninguna carga de trabajo real de producción o desarrollo. El rendimiento no es un factor limitante, pero se echan de menos algunas de las funciones automatizadas, como las copias de seguridad y el escalado.
– Estándar: agrega copias de respaldo diarias, escalado automático de instancias de aplicaciones web y ranuras de implementación, y permite enrutar usuarios con Traffic Manager. Este nivel puede ser adecuado para aplicaciones de baja demanda o entornos de desarrollo en los que no se necesita un gran número de copias de seguridad o ranuras de implementación.
– Premium: proporciona copias de respaldo más frecuentes, mayor capacidad de almacenamiento y un mayor número de ranuras de implementación y opciones de escalado de instancias. Este nivel es ideal para la mayor parte de las cargas de trabajo de producción.

Caso para aislamiento
Con las soluciones PaaS como Web Apps, la infraestructura se abstrae intencionalmente. Como lo indican los nombres de algunos de los niveles de plan de servicio, las aplicaciones web se ejecutan a través de una plataforma compartida de recursos disponibles. Eso no quiere decir para nada que las aplicaciones web no son seguras y que otros pueden ver sus datos privados. Pero el cumplimiento de normas o razones reglamentarias pueden requerir que ejecute sus aplicaciones en un entorno aislado y controlado. Escriba entornos de App Services: entornos aislados que le permiten ejecutar instancias de App Services como Web Apps en una parte segmentada de un centro de datos de Azure. Usted controla el tráfico de red entrante y saliente y puede implementar firewalls y crear conexiones de red privada virtual (VPN) en sus recursos locales.
Todos estos componentes de infraestructura todavía se abstraen en gran medida con los entornos de App Services, pero este enfoque proporciona un gran equilibrio cuando se busca la flexibilidad de las soluciones PaaS, pero a su vez desea conservar algunos controles más específicos del flujo de tráfico de las conexiones de red.

Puede hacer mucho con los niveles Gratuito y Básico, aunque para cargas de trabajo de producción probablemente debería utilizar el nivel Estándar o Premium. El ejemplo de este capítulo utiliza el nivel Estándar para que pueda ver todas las funciones disponibles. Cuando utiliza Web Apps con sus propias aplicaciones, puede decidir cuántas de estas funciones necesita y seleccionar el nivel de plan de App Services más adecuado.

Creación de una aplicación web
Con algo de teoría bajo la manga, echemos un vistazo a una Web App en acción. Hay un par de pasos para poner en marcha una aplicación. En primer lugar, usted crea la aplicación web básica y visualiza el sitio predeterminado en el navegador. Luego, usa la página web de GitHub de ejemplo y la inserta en Azure. Tal vez sus desarrolladores web han empezado a compilar un front-end para su pizzería en línea, así que tiene un sitio web básico listo para cargar.
NOTA: Si nunca ha usado Git antes, no se preocupe. No necesita entender lo que Git está haciendo en este punto, y tendrá la oportunidad al final del capítulo para jugar y explorar un poco. Aprenda Git en un mes de almuerzos, de Rick Umali (https://www.manning.com/books/learn-git-in-a-month-of-lunches), es una excelente introducción al uso de Git si quieres aprender un poco más, y está disponible para leer de forma gratuita en la plataforma liveBook de Manning.

Creación de una aplicación web básica
Al igual que en la entrada anterior, le voy a dar algunas pautas a lo largo del camino, pero observe si puede aplicar algo de la teoría sobre los tiempos de ejecución de la aplicación y los planes de App Service para crear una aplicación web. Si no está seguro de algunas opciones, es seguro aceptar los valores predeterminados por ahora.

PaaS, no IaaS
Esta aplicación web es un nuevo recurso y está separada de las VM como la que creó en el capítulo 2, que es un enfoque de IaaS para crear y ejecutar aplicaciones web. El enfoque de PaaS es Web Apps. No hay una relación real entre los dos tipos. De hecho, si siguió el consejo en el capítulo 2 y eliminó su VM, esta aplicación web se ejecuta sin necesidad alguna de una VM en su suscripción de Azure.

Pruébelo ahora
Complete los siguientes pasos para crear su aplicación web:
1 Abra un navegador web y vaya a https://portal.azure.come inicie sesión en su cuenta de Azure.
2 En el portal, seleccione Crear un recurso en la esquina superior izquierda del panel.
3 Seleccione Web en la lista de recursos que puede crear y, a continuación, seleccione Web App.
4 Para ayudar a mantener las cosas limpias y organizadas como hizo en la entrada anterior, le sugiero que cree un grupo de recursos dedicado para su aplicación web, como azuremolchapter3.

5 Para el nombre de la Web App, escriba un nombre único globalmente. Este nombre debe ser globalmente único, ya que crea la URL a su aplicación web en el formato http://.azurewebsite.net. En el caso que se lo esté preguntando, sí: aquí puede colocar un nombre de dominio personalizado. Por ahora, utilice la dirección azurewebsites.net predeterminada.
6 Va a insertar un código HTML básico, no un contenedor Docker, pero busque en todas las diferentes pilas de tiempo de ejecución disponibles. Puede cambiar esta configuración después de haber creado la aplicación web, pero por ahora, elija un tiempo de ejecución ASP.NET que se ejecute en Windows.
7 Permita que Azure cree un plan de App Service de manera automática, pero cambie el tamaño a estándar S1. Este nivel proporciona todas las funciones básicas sin proporcionar demasiados recursos para su sitio web de demostración básico. En las implementaciones del mundo real, este paso es donde podría crear y configurar manualmente sus propios planes de App Service o seleccionar un plan existente.
8 Cuando esté listo, revise y cree su primera aplicación web.
App Services tarda unos segundos en crearse. Cuando esté listo, busque y seleccione App Services en la barra de navegación de la izquierda de la pantalla; a continuación, elija su aplicación web de la lista. En la ventana Información general de su aplicación web, vea y seleccione la URL de la aplicación web, como https://azuremol.azurewebsites.net.
Al seleccionar la URL de la aplicación web, se abrirá una nueva ventana o pestaña del navegador. Se carga la página de la aplicación web predeterminada, como se muestra en la siguiente figura. Todavía no parece una pizzería. . .

Implementación de un sitio HTML de ejemplo
Tiene una aplicación web en Azure, pero es un sitio web aburrido y predeterminado. ¿Cómo hacer su propio sitio web en Azure? Una de las formas más comunes de hacerlo entre plataformas es usando Git. La mayoría de los desarrolladores y equipos de aplicaciones utilizan un sistema de control de código fuente. En lugar de almacenar archivos en el equipo y guardar los cambios a medida que va avanzando, los sistemas de control de código fuente mantienen un seguimiento de los cambios y le permiten trabajar con otros. Puede crear versiones de prueba que no afecten su código de producción y volver a versiones anteriores si surgen problemas. Git es uno de los sistemas de control de código fuente más comunes; GitHub es un servicio basado en la nube que le permite compartir y contribuir código con el resto del mundo. Microsoft adquirió GitHub en junio de 2018, pero no hay nada que lo obligue a usar GitHub con Azure, o viceversa. Todos los ejemplos de este libro están disponibles en GitHub.
Para este ejemplo, usted crea una copia local del sitio HTML estático de ejemplo y, a continuación, inserta los archivos a la aplicación web de Azure. Este flujo de trabajo se muestra a continuación.

Pruébelo ahora
Complete los siguientes pasos para obtener una copia de la página HTML de ejemplo de GitHub e insertarla a su aplicación web:
1 Abra Cloud Shell en Azure Portal y espere unos segundos para que su sesión se conecte. Para comenzar, necesita el sitio HTML de ejemplo de GitHub.
Para clonar o copiar el sitio HTML de ejemplo de GitHub, ingrese el siguiente comando:

git clone https://github.com/fouldsy/azure-mol-samples-2nd-ed.git

Si esta es su primera vez con Git en Cloud Shell, es necesario definir un par de ajustes para que Git entienda quién es usted. Para la mayoría de los ejercicios en este libro, realmente no importa; pero para utilizar con sus propios proyectos y aplicaciones, es ideal para hacer un seguimiento de quién realiza ciertas acciones en un sistema de control de código fuente. Solo tiene que definir esta configuración una vez. Escriba su propia dirección de correo electrónico y nombre completo en git config de la siguiente manera:

git config –global user.email «iain@azuremol.com»
git config –global user.name «Iain Foulds»

2 Cambie al directorio azure-mol-samples-2nd-ed que se creó al clonar el repositorio Git:
cd azure-mol-samples-2nd-ed/03/prod
3 A fin de estar preparado para cargar la página HTML de ejemplo, inicialice Git y luego agregue y confirme sus archivos. No se preocupe demasiado por los comandos Git en este momento. Debe decirle a Git qué archivos rastrear y agregar, y busque la forma de poder hacer un seguimiento de los cambios más tarde si fuera necesario:
git init && git add . && git commit -m «Pizza»
4 Ahora puede prepararse para insertar este sitio HTML de ejemplo en su aplicación web. Primero, defina las credenciales de implementación. Para proteger Web Apps cuando usa un método de implementación como Git o FTP, tiene que proporcionar un nombre de usuario y una contraseña. Las Web Apps pueden utilizar un conjunto de credenciales válidas en todos los planes de App Service en Azure o credenciales de nivel de aplicación que solo se aplican a una sola aplicación.
En el mundo real, recomiendo utilizar credenciales a nivel de aplicación para minimizar el alcance de un ataque en caso de que una de las credenciales quede expuesta. Azure genera automáticamente las credenciales a nivel de aplicación, pero tiene que recuperar y asignar estas credenciales cada vez. Para simplificar las cosas, utilice una credencial definida que pueda reutilizar en los próximos capítulos.
Cree las credenciales de despliegue y especifique su propio nombre de usuario y contraseña segura. El nombre de usuario tiene que ser único globalmente. Si ayuda, agregue sus iniciales al nombre de usuario o una convención de nombres que tenga sentido para su entorno.

az webapp deployment user set –user-name azuremol –password @azurem0l!

5 A continuación, necesita obtener la URL del repositorio Git de su aplicación web. Escriba el nombre de la aplicación web (no el nombre de usuario que creó en el paso 4) y el grupo de recursos que especificó cuando se creó la aplicación web para ver la URL del repositorio Git.

La barra invertida
En el siguiente ejemplo y los capítulos posteriores, la barra invertida () significa que el comando continúa en la línea siguiente. Es una forma de juntar largas líneas, y este enfoque se utiliza en una gran cantidad de ejemplos en línea donde puede copiar y pegar los comandos. No tiene que escribir las barras invertidas en los ejemplos de este libro si no quiere. Simplemente siga tipeando los parámetros adicionales como parte de una línea grande.
Si está utilizando el sistema de notificaciones de comandos de Windows en lugar de un Bash Shell, no incluya las barras invertidas. Si lo hace, no obtendrá para nada el resultado que desea.

az webapp deployment source config-local-git \
–name azuremol \
–resource-group azuremolchapter3 -o tsv

6 Su aplicación web está configurada para trabajar con repositorios Git, así que debe decirle a Cloud Shell qué repositorio es. En Git, usted define estas ubicaciones como remotas.
Copie su URL de Git clone del paso 5 y, a continuación, defina esta dirección URL como destino para el sitio HTML de ejemplo en Cloud Shell con el siguiente comando:

git remote add azure your-git-clone-url

7 Para cargar o copiar archivos con Git, los debe insertar. ¿A dónde los inserta Git? A un remoto como el que configuró en el paso 6, tal como azure. La parte final del comando es una rama, típicamente maestra. Gracias a las ramas en Git es como podrá hacer un seguimiento de los diferentes modelos de trabajo en curso. Una práctica recomendada en los entornos de producción es insertar para liberar ramas que puede nombrar como desee, tal como dev o staging. Estas ramas adicionales permiten que su código de producción funcione normalmente; a continuación, puede trabajar en nuevas funciones o actualizaciones de forma segura y sin afectar las cargas de trabajo reales que utilizan sus clientes.
Inserte el sitio HTML de ejemplo en su aplicación web:

git push azure master

8 Cuando se le solicite, escriba la contraseña que creó para las credenciales de implementación. Puede copiar y pegar la contraseña para minimizar los errores aquí.
En el resultado puede ver que se elimina la página de sitio web de la aplicación predeterminada existente y que el sitio HTML de ejemplo se carga y configura para ejecutarse. Este es un resultado de ejemplo:

Counting objects: 3, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 510 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Updating branch ‘master’. remote: Updating submodules.
remote: Preparing deployment for commit id ‘dda01e9d86’.
remote: Generating deployment script.
remote: Generating deployment script for Web Site
remote: Running deployment command…
remote: Handling Basic Web Site deployment.
remote: Creating app_offline.htm
remote: KuduSync.NET from: ‘D:\home\site\repository’ to:
‘D:\home\site\wwwroot’
remote: Deleting file: ‘hostingstart.html’
remote: Copying file: ‘index.html’
remote: Deleting app_offline.htm
remote: Finished successfully.
remote: Running post deployment command(s)…
remote: Deployment successful.
To https://azuremolikf@azuremol.scm.azurewebsites.net/azuremol.git

[new branch] master -> master

Para ver la aplicación web actualizada, actualice su sitio en un navegador web o ábralo de nuevo desde la ventana de Información general en Azure Portal. Debería verse como el maravilloso ejemplo de la figura. Sí, el sitio es básico, pero el flujo de trabajo para implementar el sitio HTML estático más básico en una aplicación web compleja de .NET o Node.js, ¡es el mismo!

Visualización de registros de diagnóstico
Ahora que ha visto cómo crear una aplicación web básica e implementar un sitio HTML simple, ¿qué pasa con la administración general? Si tiene problemas, sería útil ver el servidor web o los registros de la aplicación. Para ayudar a solucionar los problemas de sus aplicaciones, puede escribir el resultado de la aplicación en estos archivos de registro, que se pueden ver en tiempo real o escribirse en archivos de registro para revisión posterior.
Su aplicación web se ejecuta en gran medida por sí sola. No hay mucho que pueda hacer desde la perspectiva de mantenimiento en el host web subyacente. Si la aplicación tiene problemas, le recomendamos que mire los registros para ver lo que está pasando y solucionar el asunto. Con Azure Web Apps, puede configurar cosas como el nivel de los mensajes de registro a revisar, dónde almacenar los registros, y cuánto tiempo mantener los registros. La figura siguiente describe cómo se generan y se ven los archivos de registro con Web Apps.

Pruébelo ahora
Complete los siguientes pasos para configurar los registros de diagnóstico para su aplicación web:
1 En Azure Portal, seleccione la aplicación web que creó en el ejercicio anterior.
2 En la ventana Información general, desplácese hacia abajo hasta la sección Monitor y seleccione Registros de App Service.
3 Revise las opciones de registro disponibles, como el contenido y si desea habilitar el seguimiento de solicitudes fallidas. Si se encarga de la infraestructura de Azure, podría tener que trabajar con los desarrolladores de aplicaciones a fin de determinar los registros que necesitan para ayudar a solucionar problemas. A continuación, puede activar el registro correspondiente aquí. Los registros pueden almacenarse en el sistema de archivos local de la aplicación web o enviarse a Azure Storage para su procesamiento con otra aplicación.
4 Por ahora, active el registro de aplicaciones (sistema de archivos). También active el registro del servidor web en el sistema de archivos con un periodo de retención de siete días. El nivel de error predeterminado puede no mostrar nada si todo funciona bien, pero tenga cuidado al cambiar a Depurar o Seguimiento, ya que sus registros pueden llenarse con rapidez y hacer que sea difícil ver realmente lo que está sucediendo. Si tiene un problema, aumente gradualmente el nivel de registro hasta que capture suficiente información para solucionar los problemas sin verse abrumado por los datos de registro.
Si de verdad quiere profundizar en los datos, puede acceder a los registros almacenados en el sistema de archivos mediante FTP. Las direcciones FTP se muestran en la sección Registros de descarga o en la ventana Información general de la aplicación web. Puede estar pensando: «FTP es una forma complicada de obtener registros de diagnóstico. ¿No hay una manera más fácil?» ¡Porque sí la hay! En Azure Portal, justo donde configuró sus registros de diagnóstico, hay una opción de Transmisión de registros. ¿Puede adivinar lo que hace? Déjeme darle una pista: tiene que ver con la transmisión de sus archivos de registro.
Si selecciona este botón en Azure Portal, puede elegir entre Registros de aplicaciones y Registros de servidor web. Estos registros leen de los mismos registros de diagnóstico que se escriben en el archivo. Puede demorar algunos minutos para que aparezcan los datos de registro en la transmisión, y lo que se muestra depende de los niveles de registro que especifique y si la aplicación web genera algún evento de aplicación. Para el sitio HTML básico, la transmisión es bastante aburrida, pero es una función fantástica para tener en el navegador web. La figura muestra registros de transmisión de servidor web de ejemplo en Azure Portal.

A medida que se vaya sintiendo más cómodo con Azure y utilice el módulo CLI de Azure o Azure PowerShell, podrá transmitir registros con estas herramientas. Los desarrolladores también pueden habilitar la depuración remota con Visual Studio o configurar Application Insights para permitir que su aplicación web proporcione telemetría a servicios adicionales para supervisión y diagnóstico. La conclusión clave aquí es que a medida que se mueve hacia soluciones PaaS como Web Apps, todavía puede obtener registros de diagnósticos y datos de las aplicaciones cruciales para solucionar problemas y supervisar el rendimiento de su aplicación web.

Laboratorio: Creación y utilización de una ranura de implementación
Ya vio cómo crear un sitio HTML simple e insertar la página a Azure Web Apps con Git. ¿Qué pasa si ahora desea agregar algunos nuevos estilos de pizzas y verlos antes de poner el sitio en vivo para que los clientes los comiencen a pedir? Revise cómo utilizar una ranura de implementación para proporcionar un lugar para cargar sus cambios, revisarlos y luego llevarlos a producción:
1 En la aplicación web, seleccione Ranuras de implementación. Agregue una ranura de implementación llamada Dev, pero no clone ninguna configuración de la ranura de implementación existente.
2 Cuando esté listo, seleccione el espacio de ensayo de la lista. El portal muestra las mismas opciones de configuración y de registro que la ranura de producción, lo que muestra cómo se puede cambiar la configuración en esta ranura de implementación sin afectar al sitio en vivo.
3 En esta ocasión, explore las opciones en Azure Portal para el Centro de implementación. Desea utilizar Git local para el control de código fuente que usa el servicio de compilación de App Service para el espacio de ensayo. Esto ocurrió en segundo plano cuando utilizó la CLI de Azure en el ejercicio anterior, pero dispone de otras opciones en términos de desde dónde puede implementar su código y qué servicio desarrolla y crea esa implementación.
4 Cuando haya terminado, copie Git Clone Uri, como https://azuremol-dev.scm.azurewebsites.net:443/azuremol.git. Observe cómo el repositorio Git incluye -dev para el espacio de ensayo.
Se incluye un sitio de desarrollo de ejemplo en los ejemplos de GitHub que clonó anteriormente.
5 En Azure Cloud Shell, cámbiese al directorio de desarrollo de la siguiente manera:

cd ~/azure-mol-samples-2nd-ed/03/dev

6 Como lo hizo anteriormente, inicialice, agregue y confirme los cambios en Git con los siguientes comandos:

git init && git add . && git commit -m «Pizza»

7 Cree un vínculo al nuevo repositorio de Git en el espacio de ensayo con git remote add dev, seguido de su URL de implementación del espacio de ensayo de Git.
8 Utilice git push dev master para insertar los cambios en la ranura de implementación.
9 Seleccione la dirección URL que dirige a su espacio de ensayo desde la ventana Información general de Azure Portal. El cambio no es muy grande, seguro, pero el título de la página le permite saber que está viendo la versión de desarrollo.
10 En Azure Portal para la aplicación web, ¿qué cree que ocurre si selecciona el botón Intercambiar. Pruébelo y, a continuación, actualice la página principal, como https://azure-mol.azurewebsites.net, en su navegador web.

Ranuras de implementación, detrás de las escenas
Al intercambiar ranuras, lo que estaba en vivo en la ranura production ahora está en la ranura dev y lo que estaba en dev ahora está en vivo en production. No todos los ajustes se pueden intercambiar, como la configuración SSL y los dominios personalizados; pero en su gran mayoría, las ranuras de implementación son una gran manera de organizar y validar el contenido antes de dejarlo en vivo para sus clientes. También puede realizar un intercambio con vista preliminar, lo que le da la oportunidad de garantizar que el contenido intercambiado funcione de manera correcta antes de que esté públicamente en vivo en producción.
Para usar en producción en los flujos de trabajo DevOps, también puede configurar Intercambio automático. Aquí, cuando se observa una confirmación de código en el control de código fuente como GitHub, puede desencadenar una compilación en una ranura de implementación de Azure Web Apps. Cuando la compilación está completa y la aplicación está lista para servir el contenido, las ranuras de implementación se intercambian automáticamente para que el código se torne en vivo en producción. Usted suele usar este flujo de trabajo con un entorno de prueba para revisar primero los cambios de código, no para publicar en vivo directamente a producción.