Compartir vía

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.

Obtenga información sobre los conceptos clave y obtenga instrucciones para la contenedorización de aplicaciones de Windows en App Service. Los nuevos usuarios deben seguir primero el inicio rápido y el tutorial del contenedor personalizado.

Obtenga información sobre los conceptos clave y obtenga instrucciones para la contenedorización de aplicaciones Linux en App Service. Los nuevos usuarios deben seguir primero el inicio rápido y el tutorial del contenedor personalizado. Para los contenedores sidecar, consulte Tutorial: Configuración de un contenedor sidecar para un contenedor personalizado en Azure App Service.

Nota:

Ya no se admite el uso de una entidad de servicio para la autenticación al extraer imágenes de contenedor de Windows. Se recomienda usar la identidad administrada para contenedores de Windows y Linux.

Imágenes principales admitidas

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

  • Para implementar aplicaciones de .NET Framework, use una imagen principal basada en la versión de lanzamiento del Canal de Servicio a Largo Plazo de Windows Server 2019 Core.
  • Para implementar aplicaciones de .NET Core, use una imagen primaria basada en la versión de canal anual 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

Use el comando siguiente para cambiar la imagen de Docker actual a una nueva imagen en un contenedor personalizado existente:

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>

Proporcione las credenciales de inicio de sesión para la cuenta de registro privada en los campos \<username> y \<password>.

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

Siga estos pasos para configurar su aplicación web para obtener contenido de Azure Container Registry mediante su 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 az webapp identity assign comando :

    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. Obtén el identificador de recurso del registro de contenedores:

    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 argumentos --query y --output, es el ID de recurso del registro de contenedor.

  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 sobre estos permisos, vea ¿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>"}'

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. También necesita integración de una red virtual en Azure Container Registry con un punto de conexión privado. Después de configurar la red y la resolución DNS, habilite el enrutamiento de la imagen mediante la red virtual. Configura los ajustes del sitio vnetImagePullEnabled.

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

Solucionar problemas sobre qué hacer si no ve 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 e inicia el nuevo contenedor, App Service sigue atendiendo solicitudes del contenedor anterior. App Service solo envía solicitudes al nuevo contenedor después de iniciarse y está lista para recibir solicitudes.

Obtenga información sobre cómo se almacenan las imágenes de contenedor

La primera vez que ejecute una imagen personalizada de Docker en App Service, App Service realiza el docker pull comando y extrae todas las capas de imagen. Las capas se almacenan en el disco, igual que cuando se usa Docker localmente. Cada vez que se reinicia la aplicación, App Service realiza el docker pull comando . 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 proceso por cualquier motivo (como cambiar los planes de tarifa), App Service debe volver a extraer todas las capas. Lo mismo sucede si se escala horizontalmente para agregar más instancias. Además, en raras ocasiones, las instancias de la aplicación pueden cambiar sin 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 Azure Cloud Shell. En Bash, use el siguiente comando:

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

En PowerShell, use el siguiente comando:

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 necesita proporcionar externamente. Puede pasarlos mediante Cloud Shell. En Bash, use el siguiente comando:

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

En PowerShell, use el siguiente comando:

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

Cuando se usa SSH en un contenedor con imágenes personalizadas de Docker, es posible que solo vea algunas variables de entorno si intenta usar comandos como env o printenv. Para ver todas las variables de entorno dentro del contenedor, como las que se pasan a la aplicación para el uso en tiempo de ejecución, agregue esta línea al script de punto de entrada:

eval $(printenv | sed -n "s/^\([^=]\+\)=\(.*\)$/export \1=\2/p" | sed 's/"/\\\"/g' | sed '/=/s//="/' | sed 's/$/"/' >> /etc/profile)

Vea un ejemplo completo.

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 de Internet Information Services (IIS) o .NET Framework (4.0 o posterior), las credenciales se insertan automáticamente en System.ConfigurationManager como configuraciones de aplicaciones .NET y cadenas de conexión mediante App Service. Para todos los demás lenguajes o marcos, se proporcionan como variables de entorno para el proceso, con uno de los siguientes prefijos:

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

Puede usar este método para aplicaciones de contenedor único o de varios contenedores, donde se especifican las variables de entorno en el docker-compose.yml archivo.

Uso de almacenamiento compartido persistente

Puede usar el C:\home directorio del sistema de archivos de contenedor personalizado para conservar los archivos entre reinicios y compartirlos entre instancias. Cuando usas el directorio C:\home, tu contenedor personalizado puede acceder al almacenamiento persistente.

Cuando el almacenamiento persistente está deshabilitado, las escrituras en el C:\home directorio 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 C:\home directorio se conservan. Todas las instancias de una aplicación escalada pueden acceder a ellas. Cuando se inicia el contenedor, si hay archivos presentes en el almacenamiento persistente, sobrescriben cualquier contenido del C:\home directorio del contenedor.

La única excepción es el C:\home\LogFiles directorio . Este directorio almacena los registros de contenedor y aplicación. La 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, al 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 desactivar, establezca el valor de configuración de la aplicación WEBSITES_ENABLE_APP_SERVICE_STORAGE a false mediante Cloud Shell. En Bash, use el siguiente comando:

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

En PowerShell, use el siguiente comando:

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

Puede usar el /home directorio del sistema de archivos de contenedor personalizado para conservar los archivos entre reinicios y compartirlos entre instancias. Al utilizar el directorio C:\home, su contenedor personalizado puede acceder al almacenamiento persistente. Tenga en cuenta que los datos que guarde dentro /home contribuyen a la cuota de espacio de almacenamiento incluida en el plan de App Service.

Cuando el almacenamiento persistente está deshabilitado, las escrituras en el C:\home directorio 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 C:\home directorio se conservan. Todas las instancias de una aplicación escalada pueden acceder a ellas. Cuando se inicia el contenedor, si hay archivos presentes en el almacenamiento persistente, sobrescriben cualquier contenido del C:\home directorio del contenedor.

La única excepción es el C:\home\LogFiles directorio . Este directorio almacena los registros de contenedor y aplicación. La 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, al 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 montada de Azure Storage. Los datos que escribe fuera de estas rutas de acceso no son persistentes durante los reinicios. Los datos se guardan en un espacio en disco del host gestionado 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 configuración de la aplicación WEBSITES_ENABLE_APP_SERVICE_STORAGE a true mediante Cloud Shell. En Bash, use el siguiente comando:

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

En PowerShell, use el siguiente comando:

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 dentro de los 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 se generan e insertan automáticamente en el contenedor como claves de máquina para ASP.NET rutinas criptográficas. Puede encontrar estas claves en el contenedor buscando las siguientes variables de entorno: MACHINEKEY_Decryption, MACHINEKEY_DecryptionKey, MACHINEKEY_ValidationKeyy 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 seleccione la opción SSH. Esta opción establece una 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.
  • Excepto en el caso de los cambios en el almacenamiento compartido, los cambios realizados en el contenedor desde dentro de la sesión SSH no se conservan 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 de software, consíguelos como parte del 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.

Puede acceder a los registros de Docker de varias maneras:

Portal de Azure

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

Kudu

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

De forma predeterminada, no puede acceder a la C:\home\LogFiles carpeta en el terminal SSH 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.

Kudu API

Vaya 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. Puede usar la href propiedad para descargar directamente el archivo de registro.

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 configuraciones predeterminadas por SKU del plan de App Service.

SKU o 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 WEBSITE_MEMORY_LIMIT_MB aplicación en Cloud Shell. En Bash, use el siguiente comando:

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

En PowerShell, use el siguiente comando:

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

El valor se define en megabytes (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 puede superar los 8 GB. Para más información sobre la cantidad de memoria disponible, consulte el plan de servicio Premium v3 en 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 para el plan de tarifa. 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 configuración de la WEBSITE_CPU_CORES_LIMIT aplicación en el número preferido de núcleos. Puede establecerlo mediante Cloud Shell. En Bash, use el siguiente comando:

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

En PowerShell, use el siguiente comando:

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. Para una aplicación de producción, considere la posibilidad de intercambiarla en un espacio de ensayo. Cambie la configuración de la aplicación en el espacio de ensayo y luego súbala nuevamente al espacio de producción.

Para comprobar el número ajustado, abra una sesión SSH mediante Azure Portal o 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 procesadores multicore o hyper-threading. Para averiguar cuántos núcleos están disponibles, consulte el plan de servicio Premium v3 en 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 al ping HTTP en el tiempo. Para controlar lo que sucede cuando se produce un error en los pings HTTP, establezca la configuración de la CONTAINER_AVAILABILITY_CHECK_MODE aplicación. Puede establecerlo mediante Cloud Shell. En Bash, use el siguiente comando:

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

En PowerShell, use el siguiente comando:

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

En la tabla siguiente, se muestran los valores posibles:

Valor Description
Repair Reinicie el contenedor después de tres comprobaciones de disponibilidad consecutivas.
ReportOnly Valor predeterminado. Informe del contenedor en los registros de Docker después de tres comprobaciones de disponibilidad consecutivas, pero no lo reinicie.
Off No comprobar la disponibilidad.

Compatibilidad con cuentas de servicio administradas de grupo

Las cuentas de servicio administradas de grupo no se admiten en contenedores de Windows en App Service.

Habilite SSH

Puede usar Secure Shell (SSH) 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:

    • El Port valor debe establecerse en 2222.
    • Los Ciphers valores deben incluir al menos un elemento de esta lista: aes128-cbc, 3des-cbco aes256-cbc.
    • Los MACs valores deben incluir al menos un elemento de esta lista: hmac-sha1 o hmac-sha1-96.

  2. Cree un script de punto de entrada denominado 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 las instrucciones siguientes al Dockerfile 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 concederle 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. Un atacante en Internet no puede acceder a él.

  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 una aplicación web Linux para contenedores.

Acceso a los registros de diagnóstico

Puede acceder a los registros de consola que se generan 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 los <app-name> valores 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, use el método abreviado de teclado 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 funcionalidad sidecar.

Uso del almacenamiento persistente en Docker Compose

Las aplicaciones de varios contenedores como WordPress necesitan almacenamiento persistente para funcionar correctamente. Para habilitar el almacenamiento persistente, 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 az webapp config appsettings set comando en Cloud Shell.

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

En su 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 de 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 o autorización.
  • Identidades administradas.
  • Uso compartido de recursos entre orígenes (CORS).
  • Integración de red virtual con escenarios de Docker Compose.

Docker Compose en Azure App Service tiene actualmente un límite de 4000 caracteres.

Opciones de Docker Compose

En las secciones siguientes se muestran las 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 distintos de 80 y 8080 (omitido)
  • Variables de entorno predeterminadas como $variable y ${variable} (a diferencia de En Docker)

Limitaciones de sintaxis

  • La primera instrucción YAML del archivo siempre debe ser version x.x.
  • La sección de puertos debe usar números entre comillas.
  • La image > volume sección debe citarse y no puede tener definiciones de permisos.
  • La sección de volúmenes no puede incluir una llave "{}" vacía después del nombre del volumen.

Nota:

Cualquier otra opción que no se mencione explícitamente se omite en la versión preliminar.

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 de URL ficticia. App Service lo usa para comprobar si el contenedor es capaz de atender solicitudes. Una respuesta de error "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

  • Last updated on