Partekatu honen bidez:

Configuración de un contenedor de Linux personalizado para Azure App Service

En este artículo, se explica cómo configurar un contenedor personalizado para que se ejecute en Azure App Service.

Esta guía contiene conceptos clave e instrucciones para la contenedorización de aplicaciones de Windows en App Service. Los nuevos usuarios de Azure App Service deben seguir primero el inicio rápido del contenedor personalizado y el tutorial.

Esta guía incluye conceptos clave e instrucciones para la creación de contenedores de aplicaciones de Linux en App Service. Si no está familiarizado con Azure App Service, siga primero el inicio rápido del contenedor personalizado y el tutorial. Para los contenedores sidecar, consulte Tutorial: Configuración de un contenedor sidecar para un contenedor personalizado en Azure App Service.

Nota:

La entidad de servicio ya no se admite para la autenticación de extracción de imágenes de contenedor de Windows. Se recomienda usar la identidad administrada para contenedores de Windows y Linux.

Imágenes principales admitidas

Para la imagen personalizada de Windows, elija la imagen primaria adecuada (imagen base) para el marco que desee:

  • Para implementar aplicaciones de .NET Framework, use una imagen primaria basada en la versión del Canal de mantenimiento a largo plazo (LTSC) de Windows Server 2019 Core.
  • Para implementar aplicaciones de .NET Core, use una imagen primaria basada en la versión de canal anual (AC) Windows Server 2019 Nano.

La descarga de una imagen principal tarda un tiempo en completarse durante el inicio de la aplicación. Puede reducir el tiempo de inicio mediante una de las siguientes imágenes primarias que ya están almacenadas en caché en Azure App Service:

Cambio de la imagen de Docker de un contenedor personalizado

Para sustituir la imagen actual de contenedor personalizada en Docker por otra imagen, utilice el siguiente comando:

az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name <docker-hub-repo>/<image>

Uso de una imagen de un registro privado

Para utilizar una imagen de un registro privado, como Azure Container Registry, ejecute el siguiente comando:

az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name <image-name> --docker-registry-server-url <private-repo-url> --docker-registry-server-user <username> --docker-registry-server-password <password>

Para <el nombre de usuario> y <la contraseña>, proporcione las credenciales de inicio de sesión para su cuenta de registro privada.

Uso de la identidad administrada para extraer la imagen de Azure Container Registry

Siga estos pasos para configurar la aplicación web para extraer de Azure Container Registry (ACR) mediante la identidad administrada. Los pasos usan la identidad administrada asignada por el sistema. En su lugar, puede usar la identidad administrada asignada por el usuario.

  1. Habilite la identidad administrada asignada por el sistema para la aplicación web mediante el comando az webapp identity assign :

    az webapp identity assign --resource-group <group-name> --name <app-name> --query principalId --output tsv

    Reemplace <app-name> por el nombre que usó en el paso anterior. La salida del comando, filtrada por los argumentos --query y --output, es el ID principal de servicio de la identidad que se ha asignado.

  2. Obtenga el identificador de recurso de su instancia de Azure Container Registry:

    az acr show --resource-group <group-name> --name <registry-name> --query id --output tsv

    Reemplace <registry-name> por el nombre del registro. La salida del comando, filtrada por los --query argumentos y --output , es el identificador de recurso de Azure Container Registry.

  3. Conceda permiso a la identidad administrada para acceder al registro de contenedor:

    az role assignment create --assignee <principal-id> --scope <registry-resource-id> --role "AcrPull"

    Reemplace los siguientes valores:

    • <principal-id> con el identificador de entidad de servicio del comando az webapp identity assign
    • <registry-resource-id> con el identificador del registro de contenedor desde el comando az acr show

    Para más información acerca de estos permisos, consulte ¿Qué es el control de acceso basado en rol de Azure?.

  4. Configure la aplicación para que use la identidad administrada para la extracción de Azure Container Registry.

    az webapp config set --resource-group <group-name> --name <app-name> --generic-configurations '{"acrUseManagedIdentityCreds": true}'

    Reemplace los siguientes valores:

    • <app-name> con el nombre de tu aplicación web.

    Sugerencia

    Si usa la consola de PowerShell para ejecutar los comandos, escape las cadenas del argumento --generic-configurations en este paso y en el siguiente paso. Por ejemplo: --generic-configurations '{\"acrUseManagedIdentityCreds\": true'

  5. (Opcional) Si la aplicación usa una identidad administrada asignada por el usuario, asegúrese de que la identidad está configurada en la aplicación web y, a continuación, establezca la propiedad acrUserManagedIdentityID para especificar su identificador de cliente:

    az identity show --resource-group <group-name> --name <identity-name> --query clientId --output tsv

    Reemplace el valor <identity-name> de la identidad administrada asignada por el usuario y use la salida <client-id> para configurar el identificador de la identidad administrada asignada por el usuario.

    az  webapp config set --resource-group <group-name> --name <app-name> --generic-configurations '{"acrUserManagedIdentityID": "<client-id>"}'

¡Ya está a punto! La aplicación web ahora usa la identidad administrada para extraer de Azure Container Registry.

Uso de una imagen de un registro protegido por red

Para conectarse y extraer de un registro dentro de una red virtual o local, la aplicación debe integrarse con una red virtual. Es necesario la integración de la red virtual para Azure Container Registry con punto de conexión privado. Después de configurar la red y la resolución DNS, habilite el enrutamiento de la extracción de imágenes a través de la red virtual mediante la configuración del ajuste vnetImagePullEnabled del sitio:

az resource update --resource-group <group-name> --name <app-name> --resource-type "Microsoft.Web/sites" --set properties.vnetImagePullEnabled [true|false]

No veo el contenedor actualizado

Si cambia la configuración del contenedor de Docker para que apunte a un nuevo contenedor, la aplicación puede tardar unos minutos antes de que atienda las solicitudes HTTP desde el nuevo contenedor. Mientras se extrae y se inicia el nuevo contenedor, App Service sigue atendiendo solicitudes desde el contenedor antiguo. Solo cuando se inicia el nuevo contenedor y está preparado para recibir solicitudes, App Service comienza a enviarle solicitudes.

Cómo se almacenan las imágenes de contenedor

La primera vez que se ejecuta una imagen de Docker personalizada en App Service, esta aplicación ejecuta una operación docker pull y extrae todas las capas de la imagen. Estas capas se almacenan en el disco, como si Docker se estuviera utilizando en el entorno local. Cada vez que se reinicia la aplicación, App Service realiza una docker pull. Solo extrae capas modificadas. Si no hay ningún cambio, App Service usa las capas existentes en el disco local.

Si la aplicación cambia las instancias de cómputo por algún motivo, como escalar hacia arriba o hacia abajo los niveles de precios, App Service debe extraer de nuevo todas las capas. Lo mismo sucede si se escala horizontalmente para agregar más instancias. También hay casos poco frecuentes en los que las instancias de la aplicación pueden cambiar sin que se deba a una operación de escalado.

Configuración del número de puerto

De forma predeterminada, App Service asume que el contenedor personalizado escucha en el puerto 80. Si el contenedor escucha a otro puerto, establezca la opción WEBSITES_PORT de la aplicación en App Service. Puede establecerlo mediante Cloud Shell. En Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_PORT=8000

En PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_PORT"="8000"}

Actualmente, App Service permite que el contenedor exponga solo un puerto para las solicitudes HTTP.

Configuración de las variables de entorno

El contenedor personalizado puede usar variables de entorno que se deben proporcionar de forma externa. Se pueden pasar mediante Cloud Shell. En Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings DB_HOST="myownserver.mysql.database.azure.com"

En PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"DB_HOST"="myownserver.mysql.database.azure.com"}

Cuando se ejecuta la aplicación, la configuración de la aplicación App Service se inserta automáticamente en el proceso como variables de entorno. Puede comprobar las variables de entorno de contenedor con la dirección URL https://<app-name>.scm.azurewebsites.net/Env.

Si la aplicación usa imágenes de un registro privado o de Docker Hub, las credenciales para acceder al repositorio se guardan en variables de entorno: DOCKER_REGISTRY_SERVER_URL, DOCKER_REGISTRY_SERVER_USERNAMEy DOCKER_REGISTRY_SERVER_PASSWORD. Debido a los riesgos de seguridad, ninguno de estos nombres de variable reservados se expone a la aplicación.

En el caso de los contenedores basados en IIS o .NET Framework (4.0 o posterior), las credenciales se insertan en System.ConfigurationManager como configuración de la aplicación .NET y las cadenas de conexión automáticamente mediante App Service. Para el resto del lenguaje o marco de trabajo, se proporcionan como variables de entorno para el proceso, con uno de los siguientes prefijos:

  • APPSETTING_
  • SQLCONTR_
  • MYSQLCONTR_
  • SQLAZURECOSTR_
  • POSTGRESQLCONTR_
  • CUSTOMCONNSTR_

Este método funciona tanto para aplicaciones de contenedor único o de varios contenedores, en los que las variables de entorno se especifican en el archivo docker-compose.yml.

Uso de almacenamiento compartido persistente

Puede usar el directorio C:\home del sistema de archivos del contenedor personalizado para conservar los archivos entre reinicios y compartirlos en diferentes instancias. El directorio C:\home se proporciona para permitir que el contenedor personalizado acceda al almacenamiento persistente.

Cuando el almacenamiento persistente está deshabilitado, las escrituras en el directorio C:\home no se conservan en los reinicios de la aplicación ni en varias instancias. Cuando el almacenamiento persistente está habilitado, todas las escrituras en el directorio C:\home se conservan. Todas las instancias de una aplicación escalada pueden acceder a ellas. Los archivos existentes ya presentes en el almacenamiento persistente cuando el contenedor comienza a sobrescribir cualquier contenido en el directorio C:\home del contenedor.

La única excepción es el directorio C:\home\LogFiles . Este directorio almacena los registros de contenedor y aplicación. Esta carpeta siempre se conserva tras el reinicio de la aplicación si el registro de aplicaciones está habilitado con la opción Sistema de archivos, tanto si el almacenamiento persistente está habilitado como si no. En otras palabras, habilitar o deshabilitar el almacenamiento persistente no afecta al comportamiento del registro de aplicaciones.

De manera predeterminada, el almacenamiento persistente está habilitado en contenedores personalizados de Windows. Para deshabilitarla, establezca el valor de configuración de la aplicación WEBSITES_ENABLE_APP_SERVICE_STORAGE en false mediante el uso de Cloud Shell. En Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=false

En PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_ENABLE_APP_SERVICE_STORAGE"=false}

Puede usar el directorio /home del sistema de archivos del contenedor personalizado para conservar los archivos entre reinicios y compartirlos en diferentes instancias. El directorio /home se proporciona para permitir que el contenedor personalizado acceda al almacenamiento persistente. El almacenamiento de datos en /home contribuye a la cuota de espacio de almacenamiento incluida en el plan de App Service.

Cuando el almacenamiento persistente está deshabilitado, las escrituras en el directorio /home no se conservan en los reinicios de la aplicación ni en varias instancias. Cuando el almacenamiento persistente está habilitado, todas las escrituras en el directorio /home se conservan. Todas las instancias de una aplicación escalada pueden acceder a ellas. Los archivos existentes ya presentes en el almacenamiento persistente cuando el contenedor comienza a sobrescribir cualquier contenido en el directorio /home del contenedor.

La única excepción es el directorio /home/LogFiles . Este directorio almacena los registros de contenedor y aplicación. Esta carpeta siempre se conserva tras el reinicio de la aplicación si el registro de aplicaciones está habilitado con la opción Sistema de archivos, tanto si el almacenamiento persistente está habilitado como si no. En otras palabras, habilitar o deshabilitar el almacenamiento persistente no afecta al comportamiento del registro de aplicaciones.

Se recomienda escribir datos en /home o en una ruta de acceso de Azure Storage montada. Los datos escritos fuera de estas rutas de acceso no son persistentes durante los reinicios. Los datos se guardan en el espacio en disco del host administrado por la plataforma, separado de la cuota de almacenamiento de archivos de los planes de App Service.

De manera predeterminada, el almacenamiento persistente está deshabilitado en contenedores personalizados de Linux. Para habilitarlo, establezca el valor de la configuración de la aplicación WEBSITES_ENABLE_APP_SERVICE_STORAGE a true utilizando Cloud Shell. En Bash:

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

En PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_ENABLE_APP_SERVICE_STORAGE"=true}

Nota:

También puede configurar su propio almacenamiento persistente.

Detección de sesión de HTTPS

App Service finaliza TLS en los servidores front-end. Esto significa que las solicitudes TLS nunca llegan a tu aplicación. No es necesario implementar ninguna compatibilidad con TLS en la aplicación y no debe hacerlo.

Los servidores front-end se encuentran en centros de datos de Azure. Si usa TLS con la aplicación, el tráfico a través de Internet siempre se cifra de forma segura.

Personalización de la inserción de clave de máquina ASP.NET

Durante el inicio del contenedor, las claves que se generan automáticamente se insertan en el contenedor como claves de máquina de las rutinas criptográficas de ASP.NET. Para encontrar estas claves en el contenedor, busque las siguientes variables de entorno: MACHINEKEY_Decryption, MACHINEKEY_DecryptionKey, MACHINEKEY_ValidationKey y MACHINEKEY_Validation.

En cada reinicio, las nuevas claves pueden restablecer la autenticación de formularios de ASP.NET y el estado de vista, si la aplicación depende de ellos. Para evitar la generación automática de claves, establézcalas manualmente como la configuración de la aplicación de App Service.

Conexión al contenedor

Para conectarse directamente al contenedor de Windows para tareas de diagnóstico, vaya a https://<app-name>.scm.azurewebsites.net/ y elija la opción SSH. Esta opción establece la sesión SSH directa en la que puede ejecutar comandos dentro del contenedor.

  • Funciona de forma diferente al explorador gráfico anterior, en el que solo aparecen los archivos del almacenamiento compartido.
  • En una aplicación escalada horizontalmente, la sesión SSH está conectada a una de las instancias de contenedor. Puede seleccionar una instancia diferente en la lista desplegable Instancia del menú superior de Kudu.
  • A excepción de los cambios en el almacenamiento compartido, cualquier cambio que realice en el contenedor desde dentro de la sesión SSH no se conserva cuando se reinicia la aplicación. Estos cambios no forman parte de la imagen de Docker. Para conservar los cambios, como la configuración del Registro y la instalación del software, haga que formen parte de Dockerfile.

Acceso a los registros de diagnóstico

App Service registra las acciones del host y las actividades de Docker desde el contenedor. Los registros del host de Docker (registros de plataforma) están habilitados de forma predeterminada. Debe habilitar manualmente los registros de aplicaciones o los registros del servidor web desde el contenedor. Para más información, consulte Habilitación del registro de aplicaciones y Habilitar el registro de servidor web.

Existen varias formas de acceder a los registros de Docker:

En el Azure Portal

Los registros de Docker se muestran en Azure Portal, en la página Configuración del contenedor de la aplicación. Los registros están truncados. Para descargar todos los registros, seleccione Descargar.

Desde Kudu

Para ver los archivos de registro individuales, vaya a https://<app-name>.scm.azurewebsites.net/DebugConsole y seleccione la carpeta LogFiles . Para descargar todo el directorio LogFiles , seleccione el icono Descargar situado a la izquierda del nombre del directorio. También puede acceder a esta carpeta utilizando un cliente FTP.

En el terminal SSH, no se puede acceder a la carpeta C:\home\LogFiles de forma predeterminada porque el almacenamiento compartido persistente no está habilitado. Para habilitar este comportamiento en el terminal de la consola, habilite el almacenamiento compartido persistente.

Si intenta descargar el registro de Docker que está actualmente en uso mediante un cliente FTP, es posible que reciba un error debido a un bloqueo de archivo.

Con la API de Kudu

Acceda directamente a https://<app-name>.scm.azurewebsites.net/api/logs/docker para ver los metadatos de los registros de Docker. Es posible que vea más de un archivo de registro en la lista. La href propiedad le permite descargar el archivo de registro directamente.

Para descargar todos los registros juntos en un archivo ZIP, acceda a https://<app-name>.scm.azurewebsites.net/api/logs/docker/zip.

Personalización de la memoria del contenedor

De forma predeterminada, todos los contenedores de Windows implementados en Azure App Service tienen configurado un límite de memoria. En la tabla siguiente se enumeran las opciones de configuración predeterminadas por SKU del plan de App Service.

SKU del plan de servicio de aplicaciones Límite de memoria predeterminado por aplicación en MB
P1v3 1024
P1Mv3 1024
P2v3 1536
P2Mv3 1536
P3v3 2048
P3Mv3 2048
P4Mv3 2560
P5Mv3 3072

Para cambiar este valor, proporcione la configuración de la WEBSITE_MEMORY_LIMIT_MB aplicación mediante Cloud Shell. En Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITE_MEMORY_LIMIT_MB=2000

En PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITE_MEMORY_LIMIT_MB"=2000}

El valor se define en MB y debe ser menor y igual que la memoria física total del host. Por ejemplo, en un plan de App Service con 8 GB de RAM, el total acumulado de WEBSITE_MEMORY_LIMIT_MB para todas las aplicaciones no debe superar los 8 GB. Para obtener más información sobre la cantidad de memoria disponible, consulte la sección Plan de servicio Premium v3 de precios de App Service.

Personalización del número de núcleos de proceso

De forma predeterminada, un contenedor de Windows se ejecuta con todos los núcleos disponibles del plan de tarifa elegido. Es posible que deba reducir el número de núcleos que se usa en el espacio de ensayo. Para reducir el número de núcleos que usa un contenedor, establezca la opción WEBSITE_CPU_CORES_LIMIT de la aplicación en el número de núcleos que desee. Puede establecerlo mediante Cloud Shell. En Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --slot staging --settings WEBSITE_CPU_CORES_LIMIT=1

En PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITE_CPU_CORES_LIMIT"=1}

Sugerencia

La actualización de la configuración de la aplicación desencadena el reinicio automático, lo que provoca un tiempo de inactividad mínimo. En el caso de las aplicaciones de producción, considere la posibilidad de cambiar a un espacio de ensayo para modificarlas allí y volver después a producción.

Para comprobar el número ajustado, abra una sesión SSH desde Azure Portal o use el portal de Kudu (https://<app-name>.scm.azurewebsites.net/webssh/host). Escriba los siguientes comandos mediante PowerShell. Cada comando devuelve un número.

Get-ComputerInfo | ft CsNumberOfLogicalProcessors # Total number of enabled logical processors. Disabled processors are excluded.
Get-ComputerInfo | ft CsNumberOfProcessors # Number of physical processors.

Los procesadores pueden ser multinúcleo o con hiperprocesamiento. Información sobre cuántos núcleos están disponibles, consulte la sección Plan de servicio Premium v3 de precios de App Service.

Personalización del comportamiento del ping de estado

App Service considera que un contenedor ha iniciado correctamente cuando empieza a funcionar y responde a un ping HTTP. La solicitud de ping de estado contiene el encabezado User-Agent= "App Service Hyper-V Container Availability Check". Si el contenedor se inicia pero no responde a pings después de una determinada cantidad de tiempo, App Service registra un evento en el registro de Docker.

Si la aplicación consume muchos recursos, es posible que el contenedor no responda a tiempo al ping HTTP. Para controlar las acciones cuando se produce un error en el ping HTTP, establezca la opción CONTAINER_AVAILABILITY_CHECK_MODE de la aplicación. Puede establecerlo mediante Cloud Shell. En Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings CONTAINER_AVAILABILITY_CHECK_MODE="ReportOnly"

En PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"CONTAINER_AVAILABILITY_CHECK_MODE"="ReportOnly"}

En la tabla siguiente, se muestran los valores posibles:

Valor Descripciones
Reparar Reinicie el contenedor después de tres comprobaciones de disponibilidad consecutivas.
ReportOnly Valor predeterminado. No reinicia el contenedor, pero incluye información sobre el contenedor en los registros de Docker después de tres comprobaciones de disponibilidad consecutivas.
Desactivado No comprobar la disponibilidad.

Compatibilidad con las cuentas de servicio administradas de grupo

Actualmente, no se admiten cuentas de servicio administradas por grupos (gMSA) en los contenedores de Windows de App Service.

Habilite SSH

Secure Shell (SSH) se usa normalmente para ejecutar comandos administrativos de forma remota desde un terminal de línea de comandos. Para habilitar la característica de consola SSH de Azure Portal con contenedores personalizados, siga estos pasos:

  1. Cree un archivo sshd_config estándar con el siguiente contenido de ejemplo y colóquelo en el directorio raíz del proyecto de aplicación:

    Port 			2222
ListenAddress 		0.0.0.0
LoginGraceTime 		180
X11Forwarding 		yes
Ciphers aes128-cbc,3des-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr
MACs hmac-sha1,hmac-sha1-96
StrictModes 		yes
SyslogFacility 		DAEMON
PasswordAuthentication 	yes
PermitEmptyPasswords 	no
PermitRootLogin 	yes
Subsystem sftp internal-sftp

    Nota:

    Este archivo configura OpenSSH y debe incluir los siguientes elementos para cumplir con la característica SSH de Azure Portal:

    • Port se debe establecer en 2222.
    • Ciphers debe incluir al menos un elemento de esta lista: aes128-cbc,3des-cbc,aes256-cbc.
    • MACs debe incluir al menos un elemento de esta lista: hmac-sha1,hmac-sha1-96.

  2. Cree un script de punto de entrada con el nombre entrypoint.sh o cambie cualquier archivo de punto de entrada existente. Agregue el comando para iniciar el servicio SSH, junto con el comando de inicio de la aplicación. En el ejemplo siguiente se muestra cómo iniciar una aplicación de Python. Reemplace el último comando según el lenguaje o pila del proyecto:

    #!/bin/sh
set -e
service ssh start
exec gunicorn -w 4 -b 0.0.0.0:8000 app:app

  3. Agregue al Dockerfile las instrucciones siguientes según la distribución de la imagen base. Estas instrucciones copian los nuevos archivos, instalan el servidor OpenSSH, establecen los permisos adecuados y configuran el punto de entrada personalizado y exponen los puertos necesarios para la aplicación y el servidor SSH, respectivamente:

    COPY entrypoint.sh ./

# Start and enable SSH
RUN apt-get update \
    && apt-get install -y --no-install-recommends dialog \
    && apt-get install -y --no-install-recommends openssh-server \
    && echo "root:Docker!" | chpasswd \
    && chmod u+x ./entrypoint.sh
COPY sshd_config /etc/ssh/

EXPOSE 8000 2222

ENTRYPOINT [ "./entrypoint.sh" ]

    Nota:

    La contraseña raíz debe ser exactamente Docker! porque App Service la usa para permitirle acceder a la sesión ssh con el contenedor. Esta configuración no permite realizar conexiones externas al contenedor. El puerto 2222 del contenedor solo es accesible dentro de la red de puente de una red virtual privada y no es accesible para un atacante en Internet.

  4. Recompile e inserte la imagen de Docker en el registro y, a continuación, pruebe la característica SSH de aplicación web en Azure Portal.

Para más información sobre la solución de problemas, consulte el blog de Azure App Service: Habilitación de SSH en Linux Web App for Containers.

Acceso a los registros de diagnóstico

Puede acceder a los registros de consola generados desde dentro del contenedor.

Para activar el registro de contenedores, ejecute el siguiente comando:

az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

Reemplace <app-name> y <resource-group-name> por los nombres adecuados para la aplicación web.

Después de activar el registro de contenedores, ejecute el siguiente comando para ver la secuencia de registro:

az webapp log tail --name <app-name> --resource-group <resource-group-name>

Si los registros de consola no aparecen inmediatamente, vuelva a comprobar en 30 segundos.

Para detener el streaming de registros en cualquier momento, seleccione Ctrl+C.

Configura aplicaciones con múltiples contenedores

Nota:

La característica Docker Compose se retirará el 31 de marzo de 2027. Los contenedores sidecar reemplazan a las aplicaciones de varios contenedores en App Service. Para nuevos servicios, consulte Tutorial: Configuración de un contenedor sidecar para un contenedor personalizado en Azure App Service. Para las aplicaciones de varios contenedores existentes en App Service, consulte Migración de las aplicaciones de Docker Compose a la característica Sidecar.

Uso del almacenamiento persistente en Docker Compose

Las aplicaciones de varios contenedores como WordPress necesitan almacenamiento persistente para funcionar correctamente. Para habilitarla, la configuración de Docker Compose debe apuntar a una ubicación de almacenamiento fuera del contenedor. Las ubicaciones de almacenamiento dentro del contenedor no conservan los cambios más allá del reinicio de la aplicación.

Para habilitar el almacenamiento persistente, establezca la configuración de la WEBSITES_ENABLE_APP_SERVICE_STORAGE aplicación. Use el comando az webapp config appsettings set en Cloud Shell.

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=TRUE

En el archivo docker-compose.yml, asigne la opción volumes a ${WEBAPP_STORAGE_HOME}.

WEBAPP_STORAGE_HOME es una variable de entorno en App Service que se asigna al almacenamiento persistente para la aplicación. Por ejemplo:

wordpress:
  image: <image name:tag>
  volumes:
  - "${WEBAPP_STORAGE_HOME}/site/wwwroot:/var/www/html"
  - "${WEBAPP_STORAGE_HOME}/phpmyadmin:/var/www/phpmyadmin"
  - "${WEBAPP_STORAGE_HOME}/LogFiles:/var/log"

Limitaciones de vista previa

La aplicación de varios contenedores está actualmente en versión preliminar. No se admiten las siguientes características de la plataforma de App Service:

  • Autenticación/autorización
  • Identidades administradas
  • CORS
  • La integración de red virtual no se admite en escenarios de Docker Compose.
  • En este momento, Docker Compose en Azure App Services tiene un límite de 4.000 caracteres.

Opciones de Docker Compose

Las listas siguientes muestran opciones de configuración admitidas y no admitidas de Docker Compose:

Opciones admitidas

Opciones no admitidas

  • construir (no permitido)
  • depends_on (omitido)
  • redes (omitido)
  • secretos (omitido)
  • puertos que no sean el 80 y 8080 (omitido)
  • variables de entorno predeterminadas, como $variable and ${variable} a diferencia de docker

Limitaciones de la sintaxis

  • "version x.x" siempre debe ser la primera instrucción YAML del archivo
  • la sección de puertos debe usar números entre comillas
  • la sección del volumen de imágenes > debe estar entre comillas y no puede tener definiciones de permisos
  • la sección de volúmenes no debe tener una llave vacía después del nombre del volumen

Nota:

Cualquier otra opción que no se mencione de forma explícita, se omitirá en la versión preliminar pública.

Omitir el mensaje robots933456 en los registros

Es posible que vea el mensaje siguiente en los registros de contenedor:

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

Puede omitir este mensaje sin problemas. /robots933456.txt es una ruta URL ficticia que utiliza App Service para comprobar si el contenedor es capaz de procesar solicitudes. Una respuesta 404 indica que la ruta de acceso no existe y indica a App Service que el contenedor está en buen estado y listo para responder a las solicitudes.

Contenido relacionado

Tutorial: Migración de software personalizado a Azure App Service mediante un contenedor personalizado

Tutorial: Configurar un contenedor sidecar para un contenedor personalizado en Azure App Service

O bien, consulte más recursos: