Procedimientos recomendados de implementaciónDeployment Best Practices

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.Every development team has unique requirements that can make implementing an efficient deployment pipeline difficult on any cloud service. 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.This article introduces the three main components of deploying to App Service: deployment sources, build pipelines, and deployment mechanisms. En este artículo también se tratan algunos procedimientos recomendados y sugerencias para pilas de idiomas específicos.This article also covers some best practices and tips for specific language stacks.

Componentes de implementaciónDeployment Components

Origen de implementaciónDeployment Source

Un origen de implementación es la ubicación del código de la aplicación.A deployment source is the location of your application code. 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.For production apps, the deployment source is usually a repository hosted by version control software such as GitHub, BitBucket, or Azure Repos. En escenarios de desarrollo y prueba, el origen de implementación puede ser un proyecto en la máquina local.For development and test scenarios, the deployment source may be a project on your local machine. App Service también admite las carpetas OneDrive y Dropbox como orígenes de implementación.App Service also supports OneDrive and Dropbox folders as deployment sources. A pesar de que las carpetas en la nube pueden facilitar la introducción a App Service, normalmente no se recomienda usar este origen para las aplicaciones de producción de nivel empresarial.While cloud folders can make it easy to get started with App Service, it is not typically recommended to use this source for enterprise-level production applications.

Canalización de compilaciónBuild Pipeline

Una vez que decida un origen de implementación, el paso siguiente consistirá en elegir una canalización de compilación.Once you decide on a deployment source, your next step is to choose a build pipeline. 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.A build pipeline reads your source code from the deployment source and executes a series of steps (such as compiling code, minifying HTML and JavaScript, running tests, and packaging components) to get the application in a runnable state. Los comandos específicos que la canalización de compilación ejecuta dependen de la pila de lenguajes.The specific commands executed by the build pipeline depend on your language stack. Estas operaciones se pueden ejecutar en un servidor de compilación como Azure Pipelines o de forma local.These operations can be executed on a build server such as Azure Pipelines, or executed locally.

Mecanismo de implementaciónDeployment Mechanism

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.The deployment mechanism is the action used to put your built application into the /home/site/wwwroot directory of your web app. El directorio /wwwroot es una ubicación de almacenamiento montada que todas las instancias de la aplicación Web comparten.The /wwwroot directory is a mounted storage location shared by all instances of your web app. Cuando el mecanismo de implementación coloca la aplicación en este directorio, las instancias reciben una notificación para sincronizar los nuevos archivos.When the deployment mechanism puts your application in this directory, your instances receive a notification to sync the new files. App Service admite los siguientes mecanismos de implementación:App Service supports the following deployment mechanisms:

  • 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 endpoints: Kudu is the open-source developer productivity tool that runs as a separate process in Windows App Service, and as a second container in Linux App Service. Kudu controla las implementaciones continuas y proporciona puntos de conexión HTTP para la implementación, como zipdeploy.Kudu handles continuous deployments and provides HTTP endpoints for deployment, such as zipdeploy.
  • FTP y WebDeploy: Con las credenciales de usuario o de sitio, puede cargar archivos a través de FTP o WebDeploy.FTP and WebDeploy: Using your site or user credentials, you can upload files via FTP or WebDeploy. Estos mecanismos no pasan por Kudu.These mechanisms do not go through Kudu.

Las herramientas de implementación como Azure Pipelines, Jenkins y los complementos de editor usan uno de estos mecanismos de implementación.Deployment tools such as Azure Pipelines, Jenkins, and editor plugins use one of these deployment mechanisms.

Uso de ranuras de implementaciónUse deployment slots

Siempre que sea posible, use ranuras de implementación al implementar una nueva compilación de producción.Whenever possible, use deployment slots when deploying a new production build. 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.When using a Standard App Service Plan tier or better, you can deploy your app to a staging environment, validate your changes, and do smoke tests. Cuando esté preparado, puede intercambiar las ranuras de ensayo y de producción.When you are ready, you can swap your staging and production slots. 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.The swap operation warms up the necessary worker instances to match your production scale, thus eliminating downtime.

Código de implementación continuaContinuously deploy code

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.If your project has designated branches for testing, QA, and staging, then each of those branches should be continuously deployed to a staging slot. (Esto se conoce como diseño Gitflow). De esta manera, las partes interesadas pueden evaluar y probar fácilmente la rama implementada.(This is known as the Gitflow design.) This allows your stakeholders to easily assess and test the deployed the branch.

La implementación continua nunca debe estar habilitada para el espacio de producción.Continuous deployment should never be enabled for your production slot. En su lugar, la rama de producción (a menudo la principal) se debe implementar en un espacio que no sea de producción.Instead, your production branch (often main) should be deployed onto a non-production slot. Cuando esté listo para liberar la rama base, cámbiela al espacio de producción.When you are ready to release the base branch, swap it into the production slot. 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.Swapping into production—instead of deploying to production—prevents downtime and allows you to roll back the changes by swapping again.

Diagrama en el que se muestra el flujo entre las ramas de desarrollo, de ensayo y principal, y las ranuras en las que se implementan.

Contenedores de implementación continuaContinuously deploy containers

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.For custom containers from Docker or other container registries, deploy the image into a staging slot and swap into production to prevent downtime. 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.The automation is more complex than code deployment because you must push the image to a container registry and update the image tag on the webapp.

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.For each branch you want to deploy to a slot, set up automation to do the following on each commit to the branch.

  1. Compilar y etiquetar la imagen.Build and tag the image. 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.As part of the build pipeline, tag the image with the git commit ID, timestamp, or other identifiable information. Es mejor no usar la etiqueta predeterminada "latest".It’s best not to use the default “latest” tag. 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.Otherwise, it’s difficult to trace back what code is currently deployed, which makes debugging far more difficult.
  2. Insertar la imagen etiquetada.Push the tagged image. Una vez que la imagen se compila y etiqueta, la canalización la envía a nuestro registro de contenedor.Once the image is built and tagged, the pipeline pushes the image to our container registry. En el paso siguiente, el espacio de implementación extraerá la imagen etiquetada del registro de contenedor.In the next step, the deployment slot will pull the tagged image from the container registry.
  3. Actualizar el espacio de implementación con la nueva etiqueta de imagen.Update the deployment slot with the new image tag. Cuando se actualice esta propiedad, el sitio se reiniciará automáticamente y se extraerá la nueva imagen de contenedor.When this property is updated, the site will automatically restart and pull the new container image.

Objeto visual de uso de espacio

A continuación se muestran ejemplos de marcos de automatización comunes.There are examples below for common automation frameworks.

Uso de Azure DevOpsUse Azure DevOps

App Service dispone de entrega continua integrada para los contenedores mediante el Centro de implementación.App Service has built-in continuous delivery for containers through the Deployment Center. Vaya a la aplicación en Azure Portal y seleccione Deployment Center (Centro de implementación) en Implementación.Navigate to your app in the Azure portal and select Deployment Center under Deployment. Siga las instrucciones para seleccionar el repositorio y la rama.Follow the instructions to select your repository and branch. 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.This will configure a DevOps build and release pipeline to automatically build, tag, and deploy your container when new commits are pushed to your selected branch.

Uso de acciones de GitHubUse GitHub Actions

También puede automatizar la implementación del contenedor con acciones de GitHub.You can also automate your container deployment with GitHub Actions. 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á el espacio del sitio con la nueva etiqueta de imagen.The workflow file below will build and tag the container with the commit ID, push it to a container registry, and update the specified site slot with the new image tag.

name: Build and deploy a container image to Azure Web Apps

on:
  push:
    branches:
    - <your-branch-name>

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@main

    -name: Authenticate using a Service Principal
      uses: azure/actions/login@v1
      with:
        creds: ${{ secrets.AZURE_SP }}

    - uses: azure/container-actions/docker-login@v1
      with:
        username: ${{ secrets.DOCKER_USERNAME }}
        password: ${{ secrets.DOCKER_PASSWORD }}

    - name: Build and push the image tagged with the git commit hash
      run: |
        docker build . -t contoso/demo:${{ github.sha }}
        docker push contoso/demo:${{ github.sha }}

    - name: Update image tag on the Azure Web App
      uses: azure/webapps-container-deploy@v1
      with:
        app-name: '<your-webapp-name>'
        slot-name: '<your-slot-name>'
        images: 'contoso/demo:${{ github.sha }}'

Uso de otros proveedores de automatizaciónUse other automation providers

Los pasos enumerados anteriormente se aplican a otras utilidades de automatización como CircleCI o Travis CI.The steps listed earlier apply to other automation utilities such as CircleCI or 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.However, you need to use the Azure CLI to update the deployment slots with new image tags in the final step. Para usar la CLI de Azure en el script de automatización, genere una entidad de servicio con el siguiente comando.To use the Azure CLI in your automation script, generate a Service Principal using the following command.

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.In your script, log in using az login --service-principal, providing the principal’s information. 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.You can then use az webapp config container set to set the container name, tag, registry URL, and registry password. A continuación se muestran algunos vínculos útiles para crear el proceso de CI del contenedor.Below are some helpful links for you to construct your container CI process.

Consideraciones específicas del idiomaLanguage-Specific Considerations

JavaJava

Use la API zipdeploy/ de Kudu para implementar las aplicaciones JAR y wardeploy/ para las aplicaciones WAR.Use the Kudu zipdeploy/ API for deploying JAR applications, and wardeploy/ for WAR apps. Si usa Jenkins, puede usar esas API directamente en la fase de implementación.If you are using Jenkins, you can use those APIs directly in your deployment phase. Para obtener más información, consulte este artículo.For more information, see this article.

NodoNode

De forma predeterminada, Kudu ejecuta los pasos de compilación para la aplicación Node (npm install).By default, Kudu executes the build steps for your Node application (npm install). Si usa un servicio de compilación como Azure DevOps, la compilación de Kudu es innecesaria.If you are using a build service such as Azure DevOps, then the Kudu build is unnecessary. Para deshabilitarla, cree una opción de aplicación, SCM_DO_BUILD_DURING_DEPLOYMENT, con el valor false.To disable the Kudu build, create an app setting, SCM_DO_BUILD_DURING_DEPLOYMENT, with a value of false.

.NET.NET

De forma predeterminada, Kudu ejecuta los pasos de compilación para la aplicación .NET (dotnet build).By default, Kudu executes the build steps for your .NET application (dotnet build). Si usa un servicio de compilación como Azure DevOps, la compilación de Kudu es innecesaria.If you are using a build service such as Azure DevOps, then the Kudu build is unnecessary. Para deshabilitarla, cree una opción de aplicación, SCM_DO_BUILD_DURING_DEPLOYMENT, con el valor false.To disable the Kudu build, create an app setting, SCM_DO_BUILD_DURING_DEPLOYMENT, with a value of false.

Otras consideraciones de implementaciónOther Deployment Considerations

caché localLocal Cache

El contenido de Azure App Service se almacena en Azure Storage y surge de manera duradera como un recurso compartido de contenido.Azure App Service content is stored on Azure Storage and is surfaced up in a durable manner as a content share. Sin embargo, algunas aplicaciones solo necesitan un almacén de contenido de solo lectura y de gran rendimiento que puedan ejecutar con alta disponibilidad.However, some apps just need a high-performance, read-only content store that they can run with high availability. Estas aplicaciones pueden beneficiarse del uso de la memoria caché local.These apps can benefit from using local cache. No se recomienda la memoria caché local para los sitios de administración de contenido como WordPress.Local cache is not recommended for content management sites such as WordPress.

Use siempre la memoria caché local junto con ranuras de implementación para evitar tiempos de inactividad.Always use local cache in conjunction with deployment slots to prevent downtime. Consulte esta sección para información sobre el uso conjunto de estas características.See this section for information on using these features together.

CPU o memoria elevadasHigh CPU or Memory

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.If your App Service Plan is using over 90% of available CPU or memory, the underlying virtual machine may have trouble processing your deployment. Cuando esto suceda, escale de forma temporal el número de instancias para realizar la implementación.When this happens, temporarily scale up your instance count to perform the deployment. Una vez finalizada la implementación, puede devolver el número de instancias a su valor anterior.Once the deployment has finished, you can return the instance count to its previous value.

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.For more information on best practices, visit App Service Diagnostics to find out actionable best practices specific to your resource.

  • Vaya a la aplicación web en Azure Portal.Navigate to your Web App in the Azure portal.
  • En el panel izquierdo, haga clic en Diagnosticar y solucionar problemas para abrir la página Diagnósticos de App Service.Click on Diagnose and solve problems in the left navigation, which opens App Service Diagnostics.
  • Elija el icono Procedimientos recomendados de la página principal.Choose Best Practices homepage tile.
  • Haga clic en Best Practices for Availability & Performance (Prácticas recomendadas de disponibilidad y rendimiento) o en Best Practices for Optimal Configuration (Procedimientos recomendados para la configuración óptima) para ver el estado actual de la aplicación en lo que respecta a estas prácticas recomendadas.Click Best Practices for Availability & Performance or Best Practices for Optimal Configuration to view the current state of your app in regards to these best practices.

También puede usar este vínculo para abrir directamente Diagnósticos de App Service para el recurso: https://ms.portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.You can also use this link to directly open App Service Diagnostics for your resource: https://ms.portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.