Procedimientos recomendados de implementación
Nota:
A partir del 1 de junio de 2024, las aplicaciones de App Service recién creadas pueden generar un nombre de host predeterminado único que use la convención de nomenclatura <app-name>-<random-hash>.<region>.azurewebsites.net. Los nombres de aplicación existentes permanecen sin cambios. Por ejemplo:
myapp-ds27dh7271aah175.westus-01.azurewebsites.net
Para obtener más información, consulte Nombre de host predeterminado único para el recurso de App Service.
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. En este artículo, se presentan los tres componentes principales de la implementación en Azure App Service: orígenes de implementación, canalizaciones de compilación y mecanismos de implementación. En este artículo también se tratan algunos procedimientos recomendados y sugerencias para pilas de idiomas específicos.
Componentes de implementación
En esta sección, se describen los tres componentes principales para la implementación en App Service.
Origen de implementación
Un origen de implementación es la ubicación del código de la aplicación. En el caso de las aplicaciones de producción, el origen de implementación suele ser un repositorio hospedado por software de control de versiones como GitHub, BitBucket o Azure Repos. En escenarios de desarrollo y pruebas, el origen de implementación puede ser un proyecto en la máquina local.
Canalización de compilación
Una vez que decida qué origen de implementación usará, el paso siguiente consistirá en elegir una canalización de compilación. Una canalización de compilación lee el código fuente del origen de la implementación y ejecuta una serie de pasos para obtener la aplicación en un estado ejecutable.
Los pasos pueden incluir la compilación de código, la minificación de HTML y JavaScript, la ejecución de pruebas y los componentes de empaquetado. Los comandos específicos que la canalización de compilación ejecuta dependen de la pila de lenguaje. Puede ejecutar estas operaciones en un servidor de compilación, como Azure Pipelines, o localmente.
Mecanismo de implementación
El mecanismo de implementación es la acción que se usa para colocar la aplicación en el directorio /home/site/wwwroot de la aplicación web. El directorio /wwwroot es una ubicación de almacenamiento montada que todas las instancias de la aplicación Web comparten. Cuando el mecanismo de implementación coloca la aplicación en este directorio, las instancias reciben una notificación para sincronizar los nuevos archivos.
App Service admite los siguientes mecanismos de implementación:
- Puntos de conexión de Kudu: Kudu es la herramienta de productividad de código abierto para desarrolladores, que se ejecuta como un proceso independiente en Windows App Service. Se ejecuta como un segundo contenedor en Linux App Service. Kudu controla las implementaciones continuas y proporciona puntos de conexión HTTP para la implementación, como zipdeploy/.
- FTP y WebDeploy: Con las credenciales de usuario o de sitio, puede cargar archivos a través de FTP o WebDeploy. Estos mecanismos no pasan a través de Kudu.
Las herramientas de implementación como Azure Pipelines, Jenkins y los complementos de editor usan uno de estos mecanismos de implementación.
Uso de ranuras de implementación
Siempre que sea posible, al implementar una nueva compilación de producción, use ranuras de implementación. Con el nivel de plan de App Service Estándar o superior, puede implementar la aplicación en un entorno de ensayo, validar los cambios y realizar pruebas de humo. Cuando esté listo, intercambie las ranuras de ensayo y de 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 una ranura de ensayo. Este enfoque se conoce como diseño de Gitflow. Este diseño permite a las partes interesadas evaluar y probar fácilmente la rama implementada.
La implementación continua nunca debe estar habilitada para el espacio de producción. En su lugar, la rama de producción (a menudo la principal) se debe implementar en un espacio que no sea de producción. Cuando esté listo para liberar la rama base, cámbiela al espacio de producción. El intercambio a producción, en lugar de la implementación en producción, evita tiempos de inactividad y permite revertir los cambios intercambiando de nuevo.
Contenedores de implementación continua
Para contenedores personalizados de Docker 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. Debe enviar la imagen a un registro de contenedor y actualizar la etiqueta de imagen en la aplicación web.
Para cada rama que quiera implementar en una ranura, configure la automatización para que realice estas tareas en cada confirmación en la rama.
- Compilar y etiquetar la imagen. Como parte de la canalización de compilación, etiquete la imagen con el identificador de confirmación de Git, la marca de tiempo u otra información de identificación. Es mejor no usar la etiqueta predeterminada latest. De lo contrario, será difícil realizar un seguimiento del código que se implementa actualmente, lo que dificultará más la depuración.
- Insertar la imagen etiquetada. Una vez que la imagen se compila y etiqueta, la canalización la envía al registro de contenedor. En el paso siguiente, la ranura de implementación extraerá la imagen etiquetada del registro de contenedor.
- Actualizar el espacio de implementación con la nueva etiqueta de imagen. Cuando se actualiza esta propiedad, el sitio se reinicia automáticamente y se extrae la nueva imagen de contenedor.
Este artículo contiene ejemplos de marcos de automatización comunes.
Uso de Azure DevOps
App Service dispone de entrega continua integrada para los contenedores mediante el Centro de implementación. Vaya a la aplicación en Azure Portal. En Implementación, seleccione Centro de implementación. Siga las instrucciones para seleccionar el repositorio y la rama. Este enfoque configura una canalización de compilación y versión de DevOps para compilar, etiquetar e implementar automáticamente el contenedor cuando se insertan nuevas confirmaciones en la rama seleccionada.
Uso de acciones de GitHub
También puede automatizar la implementación del contenedor con acciones de GitHub. El archivo de flujo de trabajo compila y etiqueta el contenedor con el id. de confirmación, lo inserta en un registro de contenedor y actualiza la aplicación web especificada con la nueva etiqueta de imagen.
on:
push:
branches:
- <your-branch-name>
name: Linux_Container_Node_Workflow
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
# checkout the repo
- name: 'Checkout GitHub Action'
uses: actions/checkout@main
- uses: azure/docker-login@v1
with:
login-server: contoso.azurecr.io
username: ${{ secrets.REGISTRY_USERNAME }}
password: ${{ secrets.REGISTRY_PASSWORD }}
- run: |
docker build . -t contoso.azurecr.io/nodejssampleapp:${{ github.sha }}
docker push contoso.azurecr.io/nodejssampleapp:${{ github.sha }}
- uses: azure/webapps-deploy@v2
with:
app-name: 'node-rnc'
publish-profile: ${{ secrets.azureWebAppPublishProfile }}
images: 'contoso.azurecr.io/nodejssampleapp:${{ github.sha }}'
Uso de otros proveedores de automatización
Los pasos enumerados anteriormente se aplican a otras utilidades de automatización como CircleCI o Travis CI. Sin embargo, debe usar la CLI de Azure para actualizar los espacios de implementación con nuevas etiquetas de imagen en el paso final. Para usar la CLI de Azure en el script de automatización, genere una entidad de servicio con el siguiente comando.
az ad sp create-for-rbac --name "myServicePrincipal" --role contributor \
--scopes /subscriptions/{subscription}/resourceGroups/{resource-group} \
--sdk-auth
En el script, inicie sesión con az login --service-principal, proporcionando la información de la entidad de seguridad. Después, puede usar az webapp config container set para establecer el nombre del contenedor, la etiqueta, la dirección URL del registro y la contraseña del registro. Para obtener más información, consulte Cómo iniciar sesión en la CLI de Azure en Circle CI.
Consideraciones específicas sobre el lenguaje
Tenga en cuenta las siguientes consideraciones para las implementaciones de Java, Node y .NET.
Java
Use la API de zipdeploy de Kudu para implementar aplicaciones JAR. Use wardeploy para aplicaciones WAR. Si usa Jenkins, puede usar esas API directamente en su fase de implementación. Para obtener más información, consulte Implementación en Azure App Service con Jenkins.
Nodo
De manera predeterminada, Kudu ejecuta los pasos de compilación para la aplicación Node (npm install). Si usa un servicio de compilación como Azure DevOps, la compilación de Kudu no es necesaria. Para deshabilitarla, cree una opción de aplicación, SCM_DO_BUILD_DURING_DEPLOYMENT, con el valor false.
.NET
De manera predeterminada, Kudu ejecuta los pasos de compilación para la aplicación .NET (dotnet build). Si usa un servicio de compilación como Azure DevOps, la compilación de Kudu no es necesaria. Para deshabilitarla, cree una opción de aplicación, SCM_DO_BUILD_DURING_DEPLOYMENT, con el valor false.
Otras consideraciones de implementación
Otras consideraciones incluyen la memoria caché local y una CPU o memoria elevadas.
Caché local
El contenido de Azure App Service se almacena en Azure Storage y surge de manera duradera como un recurso compartido de contenido. Sin embargo, algunas aplicaciones solo necesitan un almacén de contenido de solo lectura y de gran rendimiento que puedan ejecutar con alta disponibilidad. Estas aplicaciones pueden beneficiarse del uso de la memoria caché local. Para obtener más información, consulte Información general de caché local de Azure App Service.
Nota:
No se recomienda la memoria caché local para los sitios de administración de contenido como WordPress.
Para evitar el tiempo de inactividad, use siempre la caché local con ranuras de implementación. Para obtener más información sobre cómo usar estas características conjuntamente, consulte Procedimientos recomendados.
CPU o memoria elevadas
Si el plan de App Service usa más del 90 % de la CPU o la memoria disponibles, es posible que la máquina virtual subyacente tenga problemas para procesar la implementación. Cuando esto suceda, escale verticalmente y de forma temporal el número de instancias para realizar la implementación. Una vez finalizada la implementación, podrá volver a configurar el recuento de instancias en su valor anterior.
Para obtener más información, consulte Diagnósticos de App Service para conocer los procedimientos recomendados accionables específicos para el recurso.
Vaya a la aplicación web en Azure Portal.
Seleccione Diagnosticar y solucionar problemas en el panel de navegación izquierdo, que abre Diagnósticos de App Service.
Elija Disponibilidad y rendimiento o explore otras opciones, como Análisis de uso elevado de CPU.
Vea el estado actual de la aplicación con respecto a estos procedimientos recomendados.
También puede usar este vínculo para abrir directamente Diagnósticos de App Service para el recurso: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.