Implementación de archivos en App Service

En este artículo, se muestra cómo implementar el código como un paquete ZIP, WAR, JAR o EAR en Azure App Service. También se muestra cómo implementar archivos individuales en App Service, de forma independiente del paquete de aplicación.

Requisitos previos

Para completar los pasos en este artículo, cree una aplicación de App Service o use alguna aplicación que haya creado para otro tutorial.

Si no tiene una suscripción a Azure, cree una cuenta gratuita de Azure antes de empezar.

Creación de un paquete ZIP de proyecto

Nota

Si ha descargado los archivos en un paquete ZIP, extráigalos primero. Por ejemplo, si ha descargado un paquete ZIP de GitHub, no puede implementar ese archivo tal cual. GitHub agrega directorios anidados adicionales que no funcionan con App Service.

En la ventana de un terminal local, navegue hasta el directorio raíz del proyecto de la aplicación.

Este directorio debería contener el archivo de entrada para la aplicación web como, por ejemplo, index.html, index.php y app.js. También puede contener archivos de administración de paquetes como project.json, composer.json, package.json, bower.json y requirements.txt.

A menos que desee que App Service ejecute la automatización de implementación automáticamente, ejecute todas las tareas de compilación (por ejemplo, npm, bower, gulp, composer y pip) y asegúrese de que tiene todos los archivos que necesita para ejecutar la aplicación. Este paso es necesario si desea ejecutar su paquete directamente.

Cree un archivo ZIP con todo el contenido del proyecto. En el caso de los proyectos de dotnet, esta carpeta es la carpeta de salida del comando dotnet publish. El siguiente comando usa la herramienta predeterminada de su terminal:

# Bash
zip -r <file-name>.zip .

# PowerShell
Compress-Archive -Path * -DestinationPath <file-name>.zip

Implementación de un paquete ZIP

Al implementar un paquete ZIP, App Service desempaqueta su contenido en la ruta de acceso predeterminada de la aplicación (D:\home\site\wwwroot para Windows y /home/site/wwwroot para Linux).

Esta implementación del paquete ZIP usa el mismo servicio de Kudu que permite realizar implementaciones basadas en la integración continua. Kudu admite la siguientes funcionalidades para implementar el paquete ZIP:

  • La eliminación de archivos restantes de una implementación anterior.
  • La opción de activar el proceso de compilación predeterminado, en el que se incluye la restauración del paquete.
  • La personalización de la implementación, incluyendo la ejecución de scripts de implementación.
  • Registros de implementación.
  • Un límite de tamaño de paquete de 2048 MB.

Para obtener más información, consulte la documentación de Kudu.

Nota

Los archivos del paquete ZIP solo se copian si sus marcas de tiempo no coinciden con lo que ya está implementado. La generación de un archivo ZIP mediante un proceso de compilación que almacena en memoria caché los resultados puede dar lugar a implementaciones más rápidas. Consulte el tema sobre la implementación desde un archivo ZIP o una dirección URL para obtener más información.

Implemente un paquete ZIP en la aplicación web mediante el comando az webapp deploy. El comando de la CLI usa la API de publicación de Kudu para implementar los archivos y se puede personalizar completamente.

En el ejemplo siguiente, se inserta un paquete ZIP en el sitio. Especifique la ruta de acceso al paquete ZIP local para --src-path.

az webapp deploy --resource-group <group-name> --name <app-name> --src-path <zip-package-path>

Este comando reinicia la aplicación después de implementar el paquete ZIP.

En función de la configuración de redes de las aplicaciones web, puede que se bloquee el acceso directo al sitio desde el entorno local. Para implementar el código en este escenario, puede publicar el paquete ZIP en un sistema de almacenamiento al que se pueda acceder desde la aplicación web y desencadenar la aplicación para extraer el paquete ZIP de la ubicación de almacenamiento, en lugar de insertarlo en la aplicación web. Consulte este artículo sobre la implementación en aplicaciones web protegidas por red para obtener más información.

El ejemplo siguiente usa el parámetro --src-url para especificar la dirección URL de una cuenta de Azure Storage de la que el sitio debe extraer el archivo ZIP.

az webapp deploy --resource-group <group-name> --name <app-name> --src-url "https://storagesample.blob.core.windows.net/sample-container/myapp.zip?sv=2021-10-01&sb&sig=slk22f3UrS823n4kSh8Skjpa7Naj4CG3

Habilitación de la automatización de compilación para la implementación mediante ZIP

De manera predeterminada, el motor de implementación da por supuesto que un paquete ZIP está listo para ejecutarse tal cual y no ejecuta ninguna automatización de la compilación. Para habilitar la misma automatización de la compilación que en una implementación de Git, establezca la configuración de la aplicación SCM_DO_BUILD_DURING_DEPLOYMENT ejecutando el siguiente comando en Cloud Shell:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings SCM_DO_BUILD_DURING_DEPLOYMENT=true

Para obtener más información, consulte la documentación de Kudu.

¿Qué ocurre con mi aplicación durante la implementación?

Todos los métodos de implementación admitidos oficialmente realizan cambios en los archivos de la carpeta /home/site/wwwroot de la aplicación. Estos archivos se usan para ejecutar la aplicación. Por tanto, se puede producir un error en la implementación debido a archivos bloqueados. Es posible que la aplicación también se comporte de forma impredecible durante la implementación porque no todos los archivos se hayan actualizado al mismo tiempo. Este comportamiento no es deseable en una aplicación orientada al cliente. Hay varias formas de evitar estos problemas:

Implementación de paquetes WAR, JAR y EAR

Puede implementar su paquete WAR, JAR o EAR en App Service para ejecutar la aplicación web de Java mediante la CLI de Azure, PowerShell o la API de publicación de Kudu.

El proceso de implementación coloca el paquete correctamente en la unidad de archivos compartidos (consulte Referencia de la API de publicación de Kudu). Por ese motivo, no se recomienda implementar paquetes WAR, JAR o EAR mediante FTP o WebDeploy.

Implemente un paquete WAR en Tomcat o JBoss EAP mediante el comando az webapp deploy. Especifique la ruta de acceso al paquete de Java local para --src-path.

az webapp deploy --resource-group <group-name> --name <app-name> --src-path ./<package-name>.war

En función de la configuración de redes de las aplicaciones web, puede que se bloquee el acceso directo al sitio desde el entorno local. Para implementar el código en este escenario, puede publicar el paquete ZIP en un sistema de almacenamiento al que se pueda acceder desde la aplicación web y desencadenar la aplicación para extraer el paquete ZIP de la ubicación de almacenamiento, en lugar de insertarlo en la aplicación web. Consulte este artículo sobre la implementación en aplicaciones web protegidas por red para obtener más información.

El ejemplo siguiente usa el parámetro --src-url para especificar la dirección URL de una cuenta de Azure Storage de la que la aplicación web debe extraer el archivo WAR.

az webapp deploy --resource-group <group-name> --name <app-name> --src-url "https://storagesample.blob.core.windows.net/sample-container/myapp.war?sv=2021-10-01&sb&sig=slk22f3UrS823n4kSh8Skjpa7Naj4CG3 --type war

El comando de la CLI usa la API de publicación de Kudu para implementar el paquete y se puede personalizar completamente.

Implementación de archivos individuales

Implemente un script de inicio, una biblioteca y un archivo estático en la aplicación web mediante el comando az webapp deploy con el parámetro --type.

Si implementa un script de inicio de esta manera, App Service utiliza automáticamente el script para iniciar la aplicación.

El comando de la CLI usa la API de publicación de Kudu para implementar los archivos y se puede personalizar completamente.

Implementación de un script de inicio

az webapp deploy --resource-group <group-name> --name <app-name> --src-path scripts/startup.sh --type=startup

Implementación de un archivo de biblioteca

az webapp deploy --resource-group <group-name> --name <app-name> --src-path driver.jar --type=lib

Implementación de un archivo estático

az webapp deploy --resource-group <group-name> --name <app-name> --src-path config.json --type=static

Referencia de la API de publicación de Kudu

La API publish de Kudu le permite especificar los mismos parámetros del comando de la CLI como parámetros de consulta URL. Para autenticarse con la API de Kudu, puede usar la autenticación básica con las credenciales de implementación de la aplicación.

En la tabla siguiente, se muestran los parámetros de consulta disponibles, sus valores permitidos y sus descripciones.

Key Valores permitidos Descripción Obligatorio Tipo
type war|jar|ear|lib|startup|static|zip Tipo de artefacto que se va a implementar; establece la ruta de acceso de destino predeterminada e informa a la aplicación web de cómo se debe controlar la implementación.
- type=zip: implementar un paquete ZIP descomprimiendo el contenido en /home/site/wwwroot. El parámetro path es opcional.
- type=war: implementar un paquete WAR. De manera predeterminada, el paquete WAR se implementa en /home/site/wwwroot/app.war. La ruta de acceso de destino se puede especificar con path.
- type=jar: implementar un paquete JAR en /home/site/wwwroot/app.jar. El parámetro path no se tiene en cuenta.
- type=ear: implementar un paquete EAR en /home/site/wwwroot/app.ear. El parámetro path no se tiene en cuenta.
- type=lib: implementar un archivo de biblioteca JAR. De manera predeterminada, el archivo se implementa en /home/site/libs. La ruta de acceso de destino se puede especificar con path.
- type=static: implementar un archivo estático (por ejemplo, un script). De manera predeterminada, el archivo se implementa en /home/site/wwwroot.
- type=startup: implementar un script que App Service utiliza automáticamente como script de inicio para la aplicación. De manera predeterminada, el script se implementa en D:\home\site\scripts\<name-of-source> para Windows y en home/site/wwwroot/startup.sh para Linux. La ruta de acceso de destino se puede especificar con path.
String
restart true|false De manera predeterminada, la API reinicia la aplicación después de la operación de implementación (restart=true). Para implementar varios artefactos, evite reinicios en todos ellos menos en la implementación final; para ello, establezca restart=false. No Boolean
clean true|false Especifica si se debe limpiar (eliminar) la implementación de destino antes de implementar allí el artefacto. No Boolean
ignorestack true|false La API de publicación usa la variable de entorno WEBSITE_STACK para elegir valores predeterminados seguros en función de la pila del lenguaje del sitio. Si se establece este parámetro en false, se deshabilitan los valores predeterminados específicos del lenguaje. No Boolean
path "<absolute-path>" Ruta de acceso absoluta en la que se implementará el artefacto. Por ejemplo: "/home/site/deployments/tools/driver.jar", "/home/site/scripts/helper.sh". No String

Pasos siguientes

Para ver escenarios de implementación más avanzados, pruebe Implementación en Azure con Git. La implementación basada en Git en Azure permite el control de versiones, la restauración de paquetes, MSBuild y mucho más.

Más recursos