Compartir a través de


Configuración de contenedores sidecar en Azure App Service

En este artículo se proporcionan pasos prácticos para habilitar y configurar contenedores sidecar en la aplicación de App Service.

Crear un sidecar en el portal de Azure

  1. Vaya al recurso de App Service en Azure Portal.
  2. Seleccione Centro de implementación y vaya a la pestaña Contenedores .
  3. Haga clic en Agregar contenedor para agregar un sidecar.
  4. Rellene el nombre de la imagen, la autenticación del Registro (si es necesario) y las variables de entorno.
  5. Guarde los cambios. El sidecar se implementará junto con el contenedor de aplicaciones principal.

Habilitar compatibilidad con sidecar para contenedores personalizados de Linux

Para un contenedor personalizado, debe habilitar explícitamente la compatibilidad con un contenedor sidecar. En el portal, puede realizar la selección en el Asistente para crear la instancia de App Service. También puede habilitarla para una aplicación existente en la páginaContenedores del Centro > de implementaciónde una aplicación existente, como se muestra en la captura de pantalla siguiente:

Captura de pantalla que muestra la configuración del contenedor de una aplicación contenedora personalizada con el botón Iniciar actualización resaltado.

Con la CLI de Azure, convierte la aplicación web para que use la configuración de sitecontainers. Por ejemplo:

az webapp sitecontainers convert --mode sitecontainers --name <YourWebAppName> --resource-group <YourResourceGroup>

Esto actualiza el LinuxFxVersion a sitecontainers y habilita la compatibilidad con el patrón sidecar.

Volver al modo de contenedor personalizado clásico (Docker)

Si necesita volver de la configuración con sidecar habilitado a la configuración clásica basada en Docker, ejecute el siguiente comando:

az webapp sitecontainers convert \
  --mode docker \
  --name <app-name> \
  --resource-group <resource-group>

Este comando quita todos los contenedores sidecar y restablece tu aplicación para que utilice la configuración de estilo clásico DOCKER|<image>. Para más información, consulte la documentación de la CLI de Azure para az webapp sitecontainers convert.

Para obtener más información, consulte ¿Cuáles son las diferencias de los contenedores personalizados con compatibilidad con sidecar?

¿Cuáles son las diferencias de los contenedores personalizados con compatibilidad con sidecar?

Las aplicaciones habilitadas para Sidecar se configuran de forma diferente a las aplicaciones que no están habilitadas para sidecar.

  • Las aplicaciones habilitadas para Sidecar se designan mediante LinuxFxVersion=sitecontainers y se configuran con sitecontainers recursos.
  • Las aplicaciones que no están habilitadas para sidecar configuran directamente el nombre y el tipo del contenedor con LinuxFxVersion=DOCKER|<image-details>.

Para obtener más información, consulte az webapp config set --linux-fx-version.

Las aplicaciones que no están habilitadas para integrarse con sidecar configuran al contenedor principal con configuraciones de la aplicación como:

  • DOCKER_REGISTRY_SERVER_URL
  • DOCKER_REGISTRY_SERVER_USERNAME
  • DOCKER_REGISTRY_SERVER_PASSWORD
  • WEBSITES_PORT

Esta configuración no se aplica a las aplicaciones con compatibilidad con sidecar.

Definir un sidecar con una plantilla de ARM

Agregue el tipo de Microsoft.Web/sites/sitecontainers recurso a una aplicación. Para extraer una imagen de contenedor sidecar de ACR mediante una identidad administrada asignada por el usuario, especifique authType como UserAssigned y proporcione userManagedIdentityClientId:

{
  "type": "Microsoft.Web/sites/sitecontainers",
  "apiVersion": "2024-04-01",
  "name": "<app-name>/<sidecar-name>",
  "properties": {
    "image": "<acr-name>.azurecr.io/<image-name>:<version>",
    "isMain": false,
    "authType": "UserAssigned",
    "userManagedIdentityClientId": "<client-id>",
    "environmentVariables": [
      { "name": "MY_ENV_VAR", "value": "my-value" }
    ]
  }
}

Importante

Solo el contenedor principal ("isMain": true) recibe tráfico externo. En una aplicación de contenedor personalizada de Linux con compatibilidad con el contenedor sidecar habilitada, el contenedor principal tiene isMain establecido en true. Todos los contenedores tipo sidecar deberían tener "isMain": false.

Para obtener más información, vea Microsoft.Web sites/sitecontainers.

Creación de contenedores sidecar con la CLI de Azure

Cree una aplicación compatible con sidecar con az webapp create. Por ejemplo:

az webapp create --name <app-name> --resource-group <group-name> --sitecontainers-app

Cree un contenedor sidecar con az webapp sitecontainers create. Por ejemplo:

az webapp sitecontainers create --name <app-name> --resource-group <group-name> --container-name <container> --image <image> --target-port <port>

Cree un contenedor sidecar con un archivo JSON:

az webapp sitecontainers create --name <app-name> --resource-group <group-name> --sitecontainers-spec-file <file-path>

Para todos los comandos de contenedor sidecar, consulte az webapp sitecontainers.

Establecimiento de variables de entorno

En una aplicación linux, todos los contenedores (main y sidecars) comparten variables de entorno. Para invalidar una variable específica para un sidecar, agréguela en la configuración del sidecar.

  • En las plantillas de ARM, use la matriz environmentVariables en las propiedades del contenedor sidecar.
  • En el portal, agregue variables de entorno en la interfaz de usuario de configuración del contenedor.
  • Las variables de entorno pueden hacer referencia a la configuración de la aplicación por nombre; el valor se resolverá en tiempo de ejecución.

Adición de la extensión del contenedor sidecar de Redis

En Azure Portal, puede agregar una extensión sidecar de Redis a la aplicación para el almacenamiento en caché. El sidecar de Redis es solo para el almacenamiento en caché ligero, no un reemplazo de Azure Cache for Redis.

Para usar el sidecar de Redis:

  • En el código de la aplicación, establezca la cadena de conexión de Redis en localhost:6379.
  • Configure Redis en el código de inicio de la aplicación.
  • Use patrones de almacenamiento en caché para almacenar y recuperar datos.
  • Pruebe accediendo a la aplicación y comprobando los registros para confirmar el uso de la memoria caché.

Agrega la extensión sidecar de Datadog

En Azure Portal, puede agregar una extensión sidecar de Datadog para recopilar registros, métricas y seguimientos para la observabilidad sin modificar el código de la aplicación. Al agregar la extensión, especifique la información de la cuenta de Datadog para que la extensión sidecar pueda enviar datos de telemetría directamente a Datadog.

Para aplicaciones basadas en código:

  1. Cree un startup.sh script para descargar e inicializar el seguimiento de Datadog. El script siguiente es un ejemplo de una aplicación .NET:

    #!/bin/bash
    
    # Create log directory. This should correspond to the "Datadog Trace Log Directory" extension setting
    mkdir -p /home/LogFiles/dotnet
    
    # Download the Datadog tracer tarball
    wget -O /datadog/tracer/datadog-dotnet-apm-2.49.0.tar.gz https://github.com/DataDog/dd-trace-dotnet/releases/download/v2.49.0/datadog-dotnet-apm-2.49.0.tar.gz
    
    # Navigate to the tracer directory, extract the tarball, and return to the original directory
    mkdir -p /datadog/tracer
    pushd /datadog/tracer
    tar -zxf datadog-dotnet-apm-2.49.0.tar.gz
    popd
    
    dotnet /home/site/wwwroot/<yourapp>.dll
    
  2. Establezca el comando de inicio en App Service para ejecutar este script.

  3. Ejecute la aplicación y confirme que la telemetría se envía iniciando sesión en el panel de Datadog.

Para aplicaciones basadas en contenedores:

Antes de agregar la extensión del contenedor sidecar de Datadog, agregue la configuración del seguimiento de Datadog en el Dockerfile, similar al ejemplo de script para las aplicaciones basadas en código.

Adición de la extensión del contenedor sidecar Phi-3 o Phi-4

Desde Azure Portal, puede agregar una extensión del contenedor sidecar Phi-3 o Phi-4 a la aplicación para proporcionar un modelo de inferencia local para cargas de trabajo de IA. La aplicación debe estar en un plan de tarifa que admita las necesidades de inferencia. En el caso de los niveles no admitidos, no verá las opciones de las extensiones del contenedor sidecar Phi-3 o Phi-4.

  • El contenedor sidecar Phi-3 o Phi-4 expone una API de finalización de chat en http://localhost:11434/v1/chat/completions.
  • Después de agregar el contenedor sidecar, el arranque inicial puede ser lento debido a la carga del modelo.
  • Para invocar la API, envíe solicitudes POST a este punto de conexión, con el mismo estilo de la API de finalización del chat de OpenAPI.

Para ver tutoriales de un extremo a otro, consulte:

Acceso a un contenedor sidecar desde el contenedor principal o desde otro contenedor sidecar

Los contenedores de Sidecar comparten el mismo host de red que el contenedor principal. El contenedor principal y otros contenedores sidecar pueden llegar a cualquier puerto en un contenedor sidecar mediante localhost:<port>. Por ejemplo, si un contenedor sidecar escucha en el puerto 4318, la aplicación principal puede acceder a ella en localhost:4318.

El campo Puerto del portal es solo metadatos y no lo usa App Service para el enrutamiento.

Adición de montajes de volumen

De forma predeterminada, el volumen predeterminado /home se monta en todos los contenedores a menos que esté deshabilitado. Puede configurar montajes de volumen adicionales para los contenedores sidecar.

Los montajes de volúmenes permiten compartir archivos y directorios no persistentes entre contenedores dentro de la aplicación web.

  • Subruta de volumen: ruta de acceso lógica al directorio creada por App Service. Contenedores con la misma subruta comparten archivos.
  • Ruta de acceso del montaje del contenedor: ruta de acceso del directorio dentro del contenedor asignado a la subruta de volumen.

Configuración de ejemplo:

Nombre de Sidecar Subruta de volumen Ruta de acceso de montaje del contenedor Solo lectura
Contenedor1 /directory1/directory2 /container1Vol Falso
Container2 /directory1/directory2 /container2Vol Cierto
Contenedor3 /directory1/directory2/directory3 /container3Vol Falso
Container4 /directory4 /container1Vol Falso
  • Si Container1 crea /container1Vol/myfile.txt, Container2 puede leerlo a través de /container2Vol/myfile.txt.
  • Si Container1 crea /container1Vol/directory3/myfile.txt, Container2 puede leerlo a través /container2Vol/directory3/myfile.txtde y Container3 puede leer y escribir a través /container3Vol/myfile.txtde .
  • Container4 no comparte un volumen con los demás.

Nota:

El contenedor de Linux integrado no puede usar montaje de volúmenes para las aplicaciones de Linux basadas en código.

Más recursos