Explorar Azure App Service.docx
Document Details
Uploaded by SpellbindingQuatrain
UCM
Full Transcript
**Introducción** Completado100 XP - 3 minutos Su empresa está pensando en trasladar sus aplicaciones web a la nube y le ha pedido que evalúe Azure App Service. **Objetivos de aprendizaje** Después de completar este módulo, podrá: - - - - Examen de Azure App Service ================...
**Introducción** Completado100 XP - 3 minutos Su empresa está pensando en trasladar sus aplicaciones web a la nube y le ha pedido que evalúe Azure App Service. **Objetivos de aprendizaje** Después de completar este módulo, podrá: - - - - Examen de Azure App Service =========================== Completado100 XP - 3 minutos Azure App Service es un servicio basado en HTTP para hospedar aplicaciones web, API de REST y back-ends para dispositivos móviles. Puede desarrollar en su lenguaje o marco de programación favorito. Las aplicaciones se ejecutan y escalan fácilmente en los entornos Windows y Linux. Compatibilidad integrada con el escalado automático --------------------------------------------------- La capacidad de escalar hacia arriba/abajo o de escalar hacia adentro está incorporada en Azure App Service. En función del uso de la aplicación web, puede escalar o reducir verticalmente los recursos de la máquina subyacente en la que se hospeda la aplicación web. Los recursos incluyen el número de núcleos o la cantidad de memoria RAM disponible. El escalado o la reducción horizontal es la capacidad de aumentar o disminuir el número de instancias de máquina que ejecutan la aplicación web. Compatibilidad con los contenedores ----------------------------------- Con Azure App Service, puede implementar y ejecutar aplicaciones web en contenedores en Windows y Linux. Puede extraer imágenes de contenedor de una instancia privada de Azure Container Registry o Docker Hub. Azure App Service también admite aplicaciones de varios contenedores, contenedores de Windows y Docker Compose para orquestar instancias de contenedor. Compatibilidad con la integración e implementación continuas ------------------------------------------------------------ Azure Portal proporciona integración e implementación continuas integradas con Azure DevOps Services, GitHub, Bitbucket, FTP o un repositorio de Git local en la máquina de desarrollo. Conecte su aplicación web con cualquiera de los orígenes anteriores y App Service se encargará del resto mediante la sincronización automática del código y los futuros cambios en el código en la aplicación web. También se admite la integración e implementación continuas para aplicaciones web en contenedores mediante Azure Container Registry o Docker Hub. Ranuras de implementación/ Deployment slots ------------------------------------------- Cuando implemente la aplicación web, puede usar una ranura de implementación distinta en lugar del espacio de producción predeterminado si su nivel de servicio del plan de App Service es estándar o mejor. Las ranuras de implementación son aplicaciones activas con sus propios nombres de host. Los elementos de contenido y configuraciones de aplicaciones se pueden intercambiar entre dos ranuras de implementación, incluida la ranura de producción. App Service en Linux -------------------- App Service también puede hospedar las aplicaciones Web de forma nativa en Linux para las pilas de aplicaciones admitidas. Además, puede ejecutar contenedores de Linux personalizados (también conocidos como Web App for Containers). App Service en Linux admite muchas imágenes integradas específicas del lenguaje. Solo implemente el código. Entre los lenguajes y marcos admitidos se incluyen: Node.js, Java (JRE 8 y JRE 11), PHP, Python,.NET y Ruby. Si el tiempo de ejecución que requiere la aplicación no se admite en las imágenes integradas, puede implementarlo con un contenedor personalizado. Los lenguajes y sus versiones admitidas se actualizan de forma periódica. Puede recuperar la lista actual mediante el comando siguiente en Cloud Shell. BashCopiar az webapp list-runtimes \--os-type linux ### Limitaciones App Service en Linux tiene algunas limitaciones: - - - **Examen de los planes de Azure App Service** Completado100 XP - 4 minutos En App Service, cada aplicación se ejecuta siempre en un *plan de App Service*. Un plan de App Service define un conjunto de recursos de proceso para que una aplicación web se ejecute. Pueden configurarse una o varias aplicaciones para que se ejecuten en los mismos recursos informáticos (o en el mismo plan de App Service). Cuando se crea un plan de App Service en una región determinada (por ejemplo, Oeste de Europa), se crea un conjunto de recursos de proceso para ese plan en dicha región. Todas las aplicaciones que coloque en este plan de App Service se ejecutan en estos recursos de proceso según lo definido por el plan de App Service. Cada plan de App Service define: - - - - - El *plan de tarifa* de un plan de App Service determina qué características de App Service obtendrá y cuánto paga por el plan. Existen algunas categorías de planes de tarifa: - - - ** Nota** Los planes de hospedaje Gratis y Compartido de App Service (versión preliminar) corresponden a niveles básicos que se ejecutan en la misma máquina virtual de Azure que otras aplicaciones de App Service. Es posible que algunas aplicaciones pertenezcan a otros clientes. Estos niveles están pensados para su uso exclusivo con fines de desarrollo y pruebas. **¿Cómo se ejecuta y escala mi aplicación?** En los planes **Gratis** y **Compartido**, una aplicación recibe minutos de CPU en una instancia de máquina virtual compartida y no se puede escalar horizontalmente. En otros planes, una aplicación se ejecuta y escala de la siguiente manera: - - - - De esta manera, el plan de App Service es la **unidad de escalado** de las aplicaciones de App Service. Si el plan está configurado para ejecutar cinco instancias de VM, todas las aplicaciones del plan se ejecutan en las cinco instancias. Si el plan está configurado para el escalado automático, todas las aplicaciones del plan se escalan horizontalmente juntas según la configuración de escalado automático. **¿Qué ocurre si mi aplicación necesita más funcionalidades o características?** El plan de App Service se puede escalar o reducir verticalmente en cualquier momento. Basta con cambiar el plan de tarifa del plan. Si la aplicación está en el mismo plan de App Service con otras aplicaciones, puede que desee mejorar el rendimiento de la aplicación aislando los recursos de proceso. Para hacerlo, puede mover la aplicación a otro plan de App Service. Puede ahorrar dinero incluyendo varias aplicaciones en un plan de App Service. Sin embargo, dado que todas las aplicaciones del mismo plan de App Service comparten los mismos recursos de proceso, debe conocer la capacidad del plan de App Service existente y la carga prevista para la nueva aplicación. Aísle la aplicación en un nuevo plan de App Service en los siguientes casos: - - - De esta forma, puede asignar un nuevo conjunto de recursos para la aplicación y tener un mayor control de las aplicaciones. Implementación en App Service ============================= Completado100 XP - 3 minutos Cada equipo de desarrollo tiene requisitos únicos que pueden dificultar la implementación de una canalización de implementación eficaz en cualquier servicio en la nube. App Service admite la implementación automatizada y manual. Implementación automatizada --------------------------- La implementación automatizada, o la implementación continua, es un proceso que se usa para insertar nuevas características y correcciones de errores en un patrón repetitivo y rápido con un efecto mínimo en los usuarios finales. Azure admite la implementación automatizada directamente desde varios orígenes. Están disponibles las opciones siguientes: - - - Implementación manual --------------------- Hay algunas opciones que puede usar para insertar el código en Azure de forma manual: - - - - Uso de ranuras de implementación -------------------------------- Siempre que sea posible, use ranuras de implementación al implementar una nueva compilación de producción. Cuando se usa un nivel de plan de App Service Estándar o superior, puede implementar la aplicación en un entorno de ensayo y, a continuación, intercambiar los espacios de ensayo y producción. La operación de intercambio prepara las instancias de trabajo necesarias para que coincidan con la escala de producción, lo que elimina el tiempo de inactividad. ### Código de implementación continua Si el proyecto tiene ramas designadas para pruebas, control de calidad y ensayo, cada una de esas ramas debe implementarse continuamente en un espacio de ensayo. De esta manera, las partes interesadas pueden evaluar y probar fácilmente la rama implementada. ### Contenedores de implementación continua Para contenedores personalizados de Azure Container Registry u otros registros de contenedor, implemente la imagen en un espacio de ensayo y cámbielo a producción para evitar tiempos de inactividad. La automatización es más compleja que la implementación de código porque debe introducir la imagen en un registro de contenedor y actualizar la etiqueta de imagen en la aplicación web. - - - Exploración de la autenticación y autorización en App Service ============================================================= Completado100 XP - 6 minutos Azure App Service incluye compatibilidad con la autenticación y la autorización, así que puede iniciar la sesión de los usuarios y acceder a los datos escribiendo una cantidad mínima de código o directamente sin código en la aplicación web, la API RESTful, el back-end móvil y Azure Functions. ¿Por qué usar la autenticación integrada? ----------------------------------------- No es necesario usar App Service para la autenticación y autorización. Muchos marcos web están incluidos en las características de seguridad y puede usarlos si lo desea. Si necesita más flexibilidad de la que App Service proporciona, también puede escribir sus propias utilidades. La característica de autenticación integrada para App Service y Azure Functions puede ahorrar tiempo y esfuerzo, ya que proporciona autenticación integrada con proveedores de identidades federados, lo que le permite centrarse en el resto de la aplicación. - - - Proveedores de identidades -------------------------- App Service usa la identidad federada, en la cual un proveedor de identidades de terceros almacena las identidades de usuario y el flujo de autenticación para usted. De forma predeterminada, están disponibles los siguientes proveedores de identidades: Expandir tabla **Proveedor** **Punto de conexión de inicio de sesión** **Guía de procedimientos** -------------------------------------- ------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Plataforma de identidad de Microsoft /.auth/login/aad [[Inicio de sesión de la plataforma de identidad de Microsoft de App Service]](https://learn.microsoft.com/es-es/azure/app-service/configure-authentication-provider-aad) Facebook /.auth/login/facebook [[Inicio de sesión con Facebook para App Service]](https://learn.microsoft.com/es-es/azure/app-service/configure-authentication-provider-facebook) Google /.auth/login/google [[Inicio de sesión con Google para App Service]](https://learn.microsoft.com/es-es/azure/app-service/configure-authentication-provider-google) X /.auth/login/twitter [[Inicio de sesión de X de App Service]](https://learn.microsoft.com/es-es/azure/app-service/configure-authentication-provider-twitter) Nuevo proveedor de OpenID Connect /.auth/login/\ [[Inicio de sesión con OpenID Connect para App Service]](https://learn.microsoft.com/es-es/azure/app-service/configure-authentication-provider-openid-connect) GitHub /.auth/login/github [[Inicio de sesión de GitHub de App Service]](https://learn.microsoft.com/es-es/azure/app-service/configure-authentication-provider-github) Cuando habilita la autenticación y autorización con uno de estos proveedores, su punto de conexión de inicio de sesión está disponible para la autenticación de usuarios y para la validación de tokens de autenticación del proveedor. Se puede proporcionar a los usuarios cualquier número de estas opciones de inicio de sesión. Funcionamiento -------------- El módulo de autenticación y autorización se ejecuta en el mismo espacio aislado que el código de aplicación. Cuando está habilitado, cada solicitud HTTP entrante pasa a través de él antes de que el código de aplicación lo controle. Este módulo controla varios aspectos de la aplicación: - - - - El módulo se ejecuta por separado del código de la aplicación y se puede configurar mediante Azure Resource Manager o mediante un archivo de configuración. No se necesitan SDK, lenguajes de programación específicos ni cambios en el código de la aplicación. ** Nota** En Linux y los contenedores, el módulo de autenticación y autorización se ejecuta en un contenedor independiente, aislado del código de la aplicación. Puesto que no se ejecuta en proceso, no es posible la integración directa con plataformas de lenguaje específicas. ### Flujo de autenticación El flujo de autenticación es el mismo para todos los proveedores, pero varía en función de si desea iniciar sesión con el SDK del proveedor. - - En la tabla siguiente se muestran los pasos del flujo de autenticación. Expandir tabla **Paso** **Sin el SDK del proveedor** **Con el SDK del proveedor** ---------------------------------- ---------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Inicio de sesión del usuario Redirige el cliente a /.auth/login/\. El código de cliente proporciona inicio de sesión al usuario directamente con el SDK del proveedor y recibe un token de autenticación. Para información, consulte la documentación del proveedor. Autenticación posterior El proveedor redirige el cliente a /.auth/login/\/callback. El código de cliente publica el token del proveedor en /.auth/login/\ para la validación. Establecer la sesión autenticada App Service agrega una cookie autenticada a la respuesta. App Service devuelve su propio token de autenticación al código de cliente. Servir contenido autenticado El cliente incluye la cookie de autenticación en las solicitudes posteriores (controladas automáticamente por explorador). El código de cliente presenta el token de autenticación en el encabezado X-ZUMO-AUTH (controlado automáticamente por SDK de cliente de Mobile Apps). Para los exploradores del cliente, App Service puede dirigir automáticamente todos los usuarios no autenticados a /.auth/login/\. También se pueden presentar a los usuarios uno o varios vínculos /.auth/login/\ para iniciar sesión en la aplicación con sus proveedores preferidos. ### Comportamiento de la autorización En Azure Portal, puede configurar App Service con varios comportamientos cuando una solicitud entrante no esté autenticada. - - ### Almacén de tokens App Service proporciona un almacén de tokens integrado, que es un repositorio de tokens que están asociados a los usuarios de las aplicaciones web, API o aplicaciones móviles nativas. Al habilitar la autenticación con cualquier proveedor, este almacén de tokens pasa a estar inmediatamente disponible para la aplicación, ### Registro y seguimiento Si habilita el registro de aplicaciones, los seguimientos de autenticación y autorización se recopilan directamente en los archivos de registro. Si ve un error de autenticación que no esperaba, puede encontrar cómodamente todos los detalles examinando los registros de aplicaciones existentes. Detección de características de redes de App Service ==================================================== Completado100 XP - 4 minutos De manera predeterminada, puede acceder a las aplicaciones hospedadas en App Service directamente a través de la Internet, y estas solo pueden acceder a los puntos de conexión hospedados en Internet. No obstante, en el caso de muchas aplicaciones, debe controlar el tráfico de red entrante y saliente. Hay dos tipos de implementación principales para Azure App Service. El servicio público multiinquilino hospeda planes de App Service en las SKU de precios Gratis, Compartido, Básico, Estándar, Premium, PremiumV2 y PremiumV3. También se encuentra disponible App Service Environment (ASE) de un único inquilino, que hospeda planes de App Service de SKU aislada directamente en su red virtual de Azure. Características de redes de App Service multiinquilino ------------------------------------------------------ Azure App Service es un sistema distribuido. Los roles que controlan las solicitudes HTTP o HTTPS entrantes se denominan *servidores front-end*. Los roles que hospedan la carga de trabajo del cliente se denominan *roles de trabajo*. Todos los roles de una implementación de App Service existen en una red de varios inquilinos. Puesto que hay muchos clientes diferentes en la misma unidad de escalado de App Service, no puede conectar la red de App Service directamente a su red. En lugar de conectarse a redes, necesita características para administrar los diversos aspectos de la comunicación de aplicaciones. Las características que controlan las solicitudes a la aplicación no se pueden usar para solucionar problemas al realizar llamadas desde la aplicación. Del mismo modo, las características que resuelven problemas para las llamadas desde la aplicación no se pueden usar para solucionar problemas de llamadas a la aplicación. Expandir tabla **Características de entrada** **Características de salida** --------------------------------------- -------------------------------------------------------------- Dirección asignada a las aplicaciones conexiones híbridas Restricciones de acceso Integración de red virtual con requisito de puerta de enlace Puntos de conexión del servicio Integración de la red virtual Puntos de conexión privados Puede combinar las características para solucionar los problemas con algunas excepciones. Los siguientes casos de uso de entrada son ejemplos de cómo usar características de redes de App Service para controlar el tráfico de entrada a la aplicación. Expandir tabla **Caso de uso de entrada** **Característica** ---------------------------------------------------------------------------------------- --------------------------------------- Compatibilidad con las necesidades de SSL basado en IP de la aplicación Dirección asignada a las aplicaciones Compatibilidad con la dirección entrante dedicada no compartida para la aplicación Dirección asignada a las aplicaciones Restricción del acceso a la aplicación desde un conjunto de direcciones bien definidas Restricciones de acceso Comportamiento predeterminado de la redes ----------------------------------------- Las unidades de escalado de Azure App Service admiten muchos clientes en cada implementación. Los planes de SKU Gratis y Compartido hospedan cargas de trabajo de clientes en roles de trabajo multiinquilino. El plan Básico y los planes superiores hospedan cargas de trabajo dedicadas a un único plan de App Service. Si tiene un plan de App Service Estándar, todas las aplicaciones de ese plan se ejecutan en el mismo rol de trabajo. Si escala horizontalmente el rol de trabajo, todas las aplicaciones de ese plan de App Service se replican en un rol de trabajo nuevo para cada instancia del plan de App Service. ### Direcciones de salida Las máquinas virtuales de trabajo se desglosan en gran medida a través de los planes de App Service. Los planes Gratis, Compartido, Básico, Estándar y Premium usan el mismo tipo de máquina virtual de trabajo. El plan PremiumV2 usa otro tipo de máquina virtual. PremiumV3 también usa otro tipo de máquina virtual. Cuando se cambia la familia de máquinas virtuales, obtiene un conjunto diferente de direcciones de salida. Hay muchas direcciones que se usan para las llamadas salientes. Las direcciones de salida que usa la aplicación para realizar llamadas salientes se muestran en las propiedades de la aplicación. Todas las aplicaciones que se ejecutan en la misma familia de máquinas virtuales de trabajo de la implementación de App Service comparten estas direcciones. Si quiere ver todas las direcciones que puede usar la aplicación en una unidad de escalado, existe una propiedad denominada possibleOutboundIpAddresses que las enumera. ### Búsqueda de las direcciones IP de salida Para buscar las direcciones IP de salida que usa actualmente su aplicación en Azure Portal, seleccione **Propiedades** en el panel de navegación izquierdo de la aplicación. Puede encontrar la misma información si ejecuta el comando siguiente de la CLI de Azure en Cloud Shell. Se enumeran en el campo **Direcciones IP salientes adicionales**. BashCopiar az webapp show \\ \--resource-group \ \\ \--name \ \\ \--query outboundIpAddresses \\ \--output tsv Para buscar todas las posibles direcciones IP de salida para la aplicación, con independencia de los planes de tarifa, ejecute el siguiente comando en Cloud Shell. BashCopiar az webapp show \\ \--resource-group \ \\ \--name \ \\ \--query possibleOutboundIpAddresses \\ \--output tsv **Ejercicio: Creación de una aplicación web HTML estática mediante Azure Cloud Shell** Completado100 XP - 15 minutos Microsoft Learn necesita su permiso para crear recursos de Azure. Para obtener más información, consulte la [**[página de la guía de solución de problemas]**](https://learn.microsoft.com/en-us/training/support/troubleshooting). [**[Revisar permisos]**](https://login.microsoftonline.com/redeem?rd=https%3a%2f%2finvitations.microsoft.com%2fredeem%2f%3ftenant%3d604c1504-c6a3-4080-81aa-b33091104187%26user%3d1f3fed61-51ad-4462-b782-4f20981a62b4%26ticket%3da9vXxVaN13lSRDT3JgEFGo7HfshPLAW7uN1is%25252bjsPQ8%25253d%26ver%3d2.0) El espacio aislado gratuito permite crear recursos en un subconjunto de las regiones globales de Azure. Seleccione una región de la lista siguiente al crear los recursos: - - - - - - - - - - En este ejercicio, implementará un sitio de HTML y CSS básico en Azure App Service mediante el comando az webapp up de la CLI de Azure. Después, actualizará el código y lo volverá a implementar con el mismo comando. El comando az webapp up facilita la creación y actualización de aplicaciones web. Cuando se ejecuta, realiza las siguientes acciones: - - - - **Descarga de la aplicación de ejemplo** En esta sección, usará el espacio aislado para descargar la aplicación de ejemplo y establecer variables para que algunos de los comandos sean más fáciles de escribir. 1. 2. 3. **Creación de la aplicación web** 1. 2. **Actualización de la aplicación y nueva implementación** 1. 2. 3. 4. **Comprobación de conocimiento** 200 XP - 3 minutos **Comprobación de conocimientos** Principio del formulario **1. ** **¿Cuál de las siguientes categorías de plan de App Service proporciona las capacidades máximas de escalabilidad horizontal?** ** ** Proceso dedicado Aislado Proceso compartido **2. ** **¿Cuál de las siguientes características de red de App Service puede usarse para controlar el tráfico de red saliente?** ** ** Dirección asignada a las aplicaciones conexiones híbridas Puntos de conexión del servicio Final del formulario