Procedimientos recomendados de implementación

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 de 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

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 prueba, el origen de implementación puede ser un proyecto en la máquina local.

Canalización de compilación

Una vez que decida un origen de implementación, 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 implementación y ejecuta una serie de pasos (por ejemplo, compilar el código, compactar el código HTML y JavaScript, ejecutar pruebas o empaquetar componentes) para hacer que la aplicación pueda ejecutarse. Los comandos específicos que la canalización de compilación ejecuta dependen de la pila de lenguajes. Estas operaciones se pueden ejecutar en un servidor de compilación como Azure Pipelines o de forma local.

Mecanismo de implementación

El mecanismo de implementación es la acción que se usa para colocar la aplicación compilada 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 para desarrolladores de código abierto que se ejecuta como un proceso independiente en Windows App Service y 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, use ranuras de implementación al implementar una nueva compilación de producción. Al usar un 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, puede intercambiar las ranuras 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. (Se denomina Diseño Gitflow.) De esta manera, las partes interesadas pueden 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 cambio 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 porque debe introducir la imagen en un registro de contenedor y actualizar la etiqueta de imagen en la aplicación web.

Para cada rama que quiera implementar en un espacio, configure la automatización para que haga lo siguiente en cada confirmación en la rama.

1. 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, es difícil realizar un seguimiento del código que se implementa actualmente, lo que dificulta mucho más la depuración.
2. Insertar la imagen etiquetada. Una vez que la imagen se compila y etiqueta, la canalización la envía a nuestro registro de contenedor. En el paso siguiente, el espacio de implementación extraerá la imagen etiquetada del registro de contenedor.
3. Actualizar el espacio de implementación con la nueva etiqueta de imagen. Cuando se actualice esta propiedad, el sitio se reiniciará automáticamente y se extraerá la nueva imagen de contenedor.

A continuación se muestran 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 y seleccione Deployment Center (Centro de implementación) en Implementación. Siga las instrucciones para seleccionar el repositorio y la rama. De esta manera se configurará una canalización de versión y compilación de DevOps para compilar, etiquetar e implementar automáticamente el contenedor cuando se inserten 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 siguiente compilará y etiquetará el contenedor con el identificador de confirmación, lo insertará en un registro de contenedor y actualizará 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 y proporcione 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. A continuación se muestran algunos vínculos útiles para crear el proceso de CI del contenedor.

• Cómo iniciar sesión en Azure CLI en Circle CI

Consideraciones específicas del idioma

Java

Use la API zipdeploy/ de Kudu para implementar las aplicaciones JAR y wardeploy/ para las aplicaciones WAR. Si usa Jenkins, puede usar esas API directamente en su fase de implementación. Para obtener más información, consulte este artículo.

Nodo

De forma 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 es innecesaria. Para deshabilitarla, cree una opción de aplicación, SCM_DO_BUILD_DURING_DEPLOYMENT, con el valor false.

.NET

De forma 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 es innecesaria. Para deshabilitarla, cree una opción de aplicación, SCM_DO_BUILD_DURING_DEPLOYMENT, con el valor false.

Otras consideraciones de implementación

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. No se recomienda la memoria caché local para los sitios de administración de contenido como WordPress.

Use siempre la memoria caché local junto con ranuras de implementación para evitar tiempos de inactividad. Consulte esta sección para información sobre el uso conjunto de estas características.

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 de forma temporal el número de instancias para realizar la implementación. Una vez finalizada la implementación, puede devolver el número de instancias a su valor anterior.

Para obtener más información sobre los procedimientos recomendados, visite Diagnósticos de App Service para obtener información sobre los procedimientos recomendados viables específicos para el recurso.

• Vaya a la aplicación web en Azure Portal.
• Seleccione en Diagnosticar y resolver problemas en el panel izquierdo, que abre el Diagnóstico de App Service.
• Elija el icono Procedimientos recomendados de la página principal.
• Seleccione Procedimientos recomendados para la disponibilidad y el rendimiento o Procedimientos recomendados para una configuración óptima para ver el estado actual de su 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.

Más recursos

Referencia de variables de entorno y configuración de la aplicación