Compartir vía

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

  • Artículo

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 de contenedores personalizados 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 es la primera vez que utiliza Azure App Service, siga primero el inicio rápido y el tutorial del contenedor personalizado. Para contenedores sidecar (versión preliminar), consulte Tutorial: Configurar un contenedor sidecar para contenedor personalizado en Azure App Service (versión preliminar).

Nota:

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

Imágenes principales admitidas

Si desea utilizar una imagen de Windows personalizada, debe elegir la imagen principal (imagen base) adecuada para la plataforma que desee:

La descarga de una imagen primaria tarda un tiempo en completarse durante el inicio de la aplicación. Sin embargo, 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, pero también 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 valor que usó en el paso anterior. La salida del comando (filtrado por los argumentos --query y --output ) es el identificador de entidad de servicio de la identidad asignada.

  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 (filtrado por los argumentos --query 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> por el identificador de entidad de servicio del comando az webapp identity assign
    • <registry-resource-id> por 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> por el nombre de la aplicación web.

    Sugerencia

    Si usa la consola de PowerShell para ejecutar los comandos, debe escapar las cadenas del argumento --generic-configurations en este y el paso siguiente. 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á configurado y 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 (VNET). La integración con VNET también es necesaria para Azure Container Registry con punto de conexión privado. Cuando la red y la resolución DNS están configuradas, se habilita el enrutamiento de la extracción de imágenes a través de la red virtual mediante el ajuste de la configuración del sitio vnetImagePullEnabled:

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.

Almacenamiento de 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 vuelve a ejecutar la operación docker pull, pero solo extrae las capas que han cambiado. Si no hay ningún cambio, App Service usa las capas existentes en el disco local.

Si la aplicación cambia las instancias de proceso por algún motivo (por ejemplo, porque se amplíen o reduzcan verticalmente los planes de tarifa), 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 da por hecho que el contenedor personalizado escucha en el puerto 80. Si el contenedor escucha otro puerto, establezca la opción WEBSITES_PORT de la aplicación en App Service. Puede hacerlo 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_URLDOCKER_REGISTRY_SERVER_USERNAME y 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 superior), App Service la inserta automáticamente en System.ConfigurationManager como cadenas de conexión y opciones de la aplicación .NET. En todos los demás lenguajes o plataformas, se proporcionan como variables de entorno del proceso, con uno de los siguientes prefijos correspondientes:

  • 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 al contenedor personalizado el acceso al almacenamiento persistente.

Si se deshabilita el almacenamiento persistente, no se conservarán las escrituras en el directorio C:\home entre reinicios de aplicación ni entre varias instancias. Cuando se habilita el almacenamiento persistente, se conservan todas las escrituras en el directorio C:\home y todas las instancias de una aplicación escalada horizontalmente podrán acceder a ellas. Además, todo el contenido dentro del directorio C:\home del contenedor se sobrescribe mediante los archivos existentes que ya están presentes en el almacenamiento persistente cuando se inicia el contenedor.

La única excepción es el directorio C:\home\LogFiles, que se usa para almacenar los registros del contenedor y de la aplicación. Esta carpeta siempre se conserva cuando se reinicia la aplicación si el registro de aplicaciones está habilitado con la opción Sistema de archivos, independientemente del almacenamiento persistente que se está habilitando o deshabilitando. 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 deshabilitarlo, defina el valor de la opción WEBSITES_ENABLE_APP_SERVICE_STORAGE de la aplicación en false mediante 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 al contenedor personalizado el acceso al almacenamiento persistente. El almacenamiento de datos en /home contribuye a la cuota de espacio de almacenamiento incluida en el plan de App Service.

Si se deshabilita el almacenamiento persistente, no se conservarán las escrituras en el directorio /home entre reinicios de aplicación ni entre varias instancias. Cuando se habilita el almacenamiento persistente, se conservan todas las escrituras en el directorio /home y todas las instancias de una aplicación escalada horizontalmente podrán acceder a ellas. Además, todo el contenido dentro del directorio /home del contenedor se sobrescribe mediante los archivos existentes que ya están presentes en el almacenamiento persistente cuando se inicia el contenedor.

La única excepción es el directorio /home/LogFiles, que se usa para almacenar los registros del contenedor y de la aplicación. Esta carpeta siempre se conserva cuando se reinicia la aplicación si el registro de aplicaciones está habilitado con la opción Sistema de archivos, independientemente del almacenamiento persistente que se está habilitando o deshabilitando. 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 y se guardan en el espacio en disco del host administrado por la plataforma independiente de la cuota de almacenamiento de archivos de Planes de App Service.

De manera predeterminada, el almacenamiento persistente está deshabilitado en contenedores personalizados de Linux. Para habilitarlo, defina el valor de la opción WEBSITES_ENABLE_APP_SERVICE_STORAGE de la aplicación en true mediante 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 las solicitudes TLS/SSL en los servidores front-end. Esto significa que las solicitudes TLS/SSL nunca van a llegar a la aplicación. No es necesario ni debe implementarse ninguna compatibilidad con TLS/SSL en la aplicación.

Los servidores front-end se encuentran en centros de datos de Azure. Si usa TLS/SSL 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 claves 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

Puede conectarse directamente al contenedor de Windows para realizar tareas de diagnóstico desde https://<app-name>.scm.azurewebsites.net/ y elija la opción SSH. Se establece una sesión SSH directa con el contenedor 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.
  • Cualquier cambio que realice en el contenedor desde la sesión SSH no se conserva cuando se reinicie la aplicación (excepto los cambios en el almacenamiento compartido), ya que no forma 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 la plataforma) se envían de forma predeterminada, pero los registros de la aplicación o los registros del servidor web que están dentro del contenedor deben habilitarse manualmente. 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 Azure Portal

Los registros de Docker aparecen en el portal, en la página Configuración del contenedor de la aplicación. Los registros están truncados, pero se pueden descargar seleccionando Descargar.

Desde Kudu

Vaya a https://<app-name>.scm.azurewebsites.net/DebugConsole y seleccione la carpeta LogFiles para ver los archivos de registro individuales. 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 manera 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 aparezcan varios archivos de registro. La propiedad href 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 App Service 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

Puede cambiar este valor proporcionando la configuración de la aplicación WEBSITE_MEMORY_LIMIT_MB 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 ser superior a 8 GB. Encontrará más información sobre la cantidad de memoria disponible en cada plan de tarifa en Precios de App Service, en la sección Plan de servicio Premium v3.

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, por ejemplo, que desee 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 hacerlo 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}

Nota

Al actualizar la configuración de la aplicación, se desencadena el reinicio automático, lo que hace que el tiempo de inactividad sea 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.

Compruebe el número ajustado abriendo una sesión SSH desde el portal o mediante el portal de Kudu (https://<app-name>.scm.azurewebsites.net/webssh/host) y escribiendo los comandos siguientes mediante PowerShell. Cada comando da como resultado 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 de varios núcleos o hyperthreading. Encontrará más información sobre el número de núcleos disponibles en cada plan de tarifa en Precios de App Service, en la sección Plan de servicio Premium v3.

Personalización del comportamiento del ping de estado

App Service considera que un contenedor se ha iniciado correctamente cuando se inicia 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 al ping tras un período de tiempo determinado, App Service agrega un evento al registro de Docker, lo que indica que el contenedor no se inició.

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 hacerlo 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:

Value Descripciones
Repair Reinicia 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 comprueba 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 suele utilizar 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, se requieren los pasos siguientes:

  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) y 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!, ya que App Service la usa para permitir el acceso 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. Vuelva a generar la imagen de Docker e insértela en el Registro y, a continuación, pruebe la característica SSH de aplicación web en Azure Portal.

Encontrará más información sobre la solución de problemas en 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.

En primer lugar, active el registro de contenedores mediante la ejecución del 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 su aplicación web.

Una vez que se active el registro de contenedor, ejecute el siguiente comando para ver el flujo del registro:

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

Si no ve los registros de la consola de inmediato, vuelve a comprobarlo en 30 segundos.

Para detener el streaming de registro en cualquier momento, escriba Ctrl+C.

Los archivos de registro también se pueden inspeccionar en un explorador en https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Configuración de aplicaciones de varios contenedores

Nota:

Los contenedores sidecar (versión preliminar) se realizarán correctamente en aplicaciones de varios contenedores en App Service. Para empezar, consulte Tutorial: Configuración de un contenedor sidecar para un contenedor personalizado en Azure App Service (versión preliminar).

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 opción WEBSITES_ENABLE_APP_SERVICE_STORAGE de la aplicación utilizando 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
  • No se admite la integración con la red virtual 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

  • build (no permitido)
  • depends_on (omitido)
  • networks (omitido)
  • secrets (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.

robots933456 en registros

Puede ver el mensaje siguiente en los registros del 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 de acceso de la dirección URL ficticia que utiliza App Service para comprobar si el contenedor es capaz de atender las solicitudes. Una respuesta 404 simplemente indica que la ruta de acceso no existe, pero permite a App Service saber que el contenedor está en buen estado y listo para responder a las solicitudes.

Pasos siguientes

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

Tutorial: Configuración de un contenedor sidecar para un contenedor personalizado en Azure App Service (versión preliminar)

O bien, consulte más recursos: