Partager via


Configurer des sidecars dans Azure App Service

Cet article fournit des étapes pratiques pour activer et configurer des sidecars dans votre application App Service.

Créer un side-car dans le portail Azure

  1. Accédez à votre ressource App Service dans le portail Azure.
  2. Sélectionnez Le Centre de déploiement et accédez à l’onglet Conteneurs .
  3. Cliquez sur Ajouter un conteneur pour ajouter un side-car.
  4. Renseignez le nom de l’image, l’authentification du Registre (si nécessaire) et les variables d’environnement.
  5. Enregistrez vos modifications. Le side-car sera déployé en même temps que votre conteneur d’application principal.

Activer la prise en charge du sidecar pour les conteneurs personnalisés sous Linux

Pour un conteneur personnalisé, vous devez activer explicitement la prise en charge du sidecar. Dans le portail, vous pouvez effectuer la sélection dans l’Assistant Création d’App Service. Vous pouvez également l’activer pour une application existante dans la pageConteneurs> de déploiement d’une application existante, comme illustré dans la capture d’écran suivante :

Capture d’écran montrant les paramètres de conteneur d’une application conteneur personnalisée avec le bouton Démarrer la mise à jour mise en surbrillance.

Avec Azure CLI, convertissez votre application web pour utiliser la sitecontainers configuration. Par exemple:

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

Cela met à jour la LinuxFxVersion prise sitecontainers en charge et la prise en charge du modèle side-car.

Rétablir le mode de conteneur personnalisé classique (Docker)

Si vous devez revenir de la configuration sidecar à l’installation classique de Docker, exécutez la commande suivante :

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

Cette commande supprime tous les conteneurs sidecar et réinitialise votre application pour utiliser la configuration de style classique DOCKER|<image> . Pour plus d’informations, consultez la documentation Azure CLI pour az webapp sitecontainers convert.

Pour plus d’informations, consultez Quelles sont les différences entre les conteneurs personnalisés avec sidecar ?

Quelles sont les différences pour les conteneurs personnalisés avec sidecar ?

Les applications compatibles avec Sidecar sont configurées différemment des applications qui ne le sont pas.

  • Les applications sidecar sont désignées par LinuxFxVersion=sitecontainers et configurées avec des ressources sitecontainers.
  • Les applications qui ne sont pas activées pour le sidecar configurent le nom et le type du conteneur directement avec LinuxFxVersion=DOCKER|<image-details>.

Pour plus d’informations, consultez az webapp config set --linux-fx-version.

Les applications qui ne sont pas compatibles sidecar configurent le conteneur principal avec des paramètres d’application tels que :

  • DOCKER_REGISTRY_SERVER_URL
  • DOCKER_REGISTRY_SERVER_USERNAME
  • DOCKER_REGISTRY_SERVER_PASSWORD
  • WEBSITES_PORT

Ces paramètres ne s’appliquent pas aux applications compatibles sidecar.

Définir un sidecar avec un modèle ARM

Ajoutez le Microsoft.Web/sites/sitecontainers type de ressource à une application. Pour extraire une image sidecar à partir d’ACR à l’aide d’une identité managée affectée par l’utilisateur, spécifiez authType comme UserAssigned et fournissez les éléments suivants 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" }
    ]
  }
}

Important

Seul le conteneur principal ("isMain": true) reçoit le trafic externe. Dans une application conteneur personnalisée Linux avec prise en charge side-car activée, votre conteneur principal a la valeur isMain sur true. Tous les conteneurs auxiliaires doivent avoir "isMain": false.

Pour plus d'informations, consultez Microsoft.Web sites/sitecontainers.

Créer des sidecars avec Azure CLI

Créez une application sidecar avec az webapp create. Par exemple:

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

Créez un conteneur sidecar avec az webapp sitecontainers create. Par exemple:

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

Créez un conteneur sidecar avec un fichier JSON :

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

Pour toutes les commandes sidecar, consultez az webapp sitecontainers.

Définir des variables d’environnement

Dans une application Linux, tous les conteneurs (principaux et sidecars) partagent des variables d’environnement. Pour remplacer une variable spécifique pour une side-car, ajoutez-la dans la configuration du sidecar.

  • Dans les modèles ARM, utilisez l'array environmentVariables dans les propriétés du sidecar.
  • Dans le portail, ajoutez des variables d’environnement dans l’interface utilisateur de configuration du conteneur.
  • Les variables d’environnement peuvent référencer les paramètres d’application par nom ; la valeur sera résolue au moment de l’exécution.

Ajouter l’extension side-car Redis

À partir du portail Azure, vous pouvez ajouter une extension side-car Redis à votre application pour la mise en cache. Le side-car Redis est destiné uniquement à la mise en cache légère, et non à un remplacement du Cache Azure pour Redis.

Pour utiliser le side-car Redis :

  • Dans votre code d’application, définissez la chaîne de connexion Redis sur localhost:6379.
  • Configurez Redis dans le code de démarrage de votre application.
  • Utilisez des modèles de mise en cache pour stocker et récupérer des données.
  • Testez en accédant à votre application et en vérifiant les journaux pour confirmer l’utilisation du cache.

Ajouter l’extension sidecar Datadog

À partir du portail Azure, vous pouvez ajouter une extension de side-car Datadog pour collecter des journaux, des métriques et des traces pour l’observabilité sans modifier le code de l’application. Lorsque vous ajoutez l’extension, vous spécifiez vos informations de compte Datadog afin que l’extension sidecar puisse expédier des données de télémétrie directement à Datadog.

Pour les applications basées sur du code :

  1. Créez un startup.sh script pour télécharger et initialiser le traceur Datadog. Le script suivant est un exemple pour une application .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. Définissez la commande de démarrage dans App Service pour exécuter ce script.

  3. Exécutez l'application et confirmez que la télémétrie est envoyée en vous connectant à votre tableau de bord Datadog.

Pour les applications basées sur des conteneurs :

Avant d’ajouter l’extension sidecar Datadog, ajoutez la configuration du traceur Datadog dans votre fichier Dockerfile, similaire à l’exemple de script pour les applications basées sur du code.

Ajouter l’extension side-car Phi-3/Phi-4

À partir du portail Azure, vous pouvez ajouter une extension side-car Phi-3 ou Phi-4 à votre application pour fournir un modèle d’inférence local pour les charges de travail IA. Votre application doit se trouver dans un niveau tarifaire qui prend en charge les besoins d’inférence. Pour les niveaux non pris en charge, vous ne voyez pas les options des extensions side-car Phi-3/Phi-4.

  • Le side-car Phi-3/Phi-4 expose une API d’achèvement de conversation à l’adresse http://localhost:11434/v1/chat/completions.
  • Une fois le side-car ajouté, le démarrage initial peut être lent en raison du chargement du modèle.
  • Pour appeler l’API, envoyez des requêtes POST à ce point de terminaison, dans le même style que l’API d’achèvement de conversation OpenAPI.

Pour connaître les procédures pas à pas de bout en bout, consultez :

Accéder à un side-car à partir du conteneur principal ou d’un autre side-car

Les conteneurs sidecar partagent le même hôte réseau que le conteneur principal. Le conteneur principal et d’autres sidecars peuvent atteindre n’importe quel port sur un side-car à l’aide de localhost:<port>. Par exemple, si un side-car écoute sur le port 4318, l’application principale peut y accéder localhost:4318.

Le champ Port dans le portail est uniquement des métadonnées et n’est pas utilisé par App Service pour le routage.

Ajouter des montages de volume

Par défaut, le volume par défaut /home est monté sur tous les conteneurs, sauf si désactivé. Vous pouvez configurer des montages de volume supplémentaires pour vos side-cars.

Les montages de volumes vous permettent de partager des fichiers et répertoires non persistants entre des conteneurs au sein de votre application web.

  • Sous-chemin d’accès du volume : Chemin d’accès de répertoire logique créé par App Service. Les conteneurs ayant le même sous-chemin partagent des fichiers.
  • Chemin de montage du conteneur : Chemin d’accès du répertoire à l’intérieur du conteneur qui est mappé au chemin sous-jacent du volume.

Exemple de configuration :

Nom du sidecar Sous-chemin d’accès du volume Chemin de montage du conteneur Lecture seule
Conteneur1 /directory1/directory2 /container1Vol Faux
Container2 /directory1/directory2 /container2Vol Vrai
Conteneur3 /directory1/directory2/directory3 /container3Vol Faux
Conteneur4 /directory4 /container1Vol Faux
  • Si Container1 crée /container1Vol/myfile.txt, Container2 peut le lire via /container2Vol/myfile.txt.
  • Si Container1 crée /container1Vol/directory3/myfile.txt, Container2 peut le lire via /container2Vol/directory3/myfile.txt, et Container3 peut lire/écrire via /container3Vol/myfile.txt.
  • Container4 ne partage pas de volume avec les autres.

Remarque

Pour les applications Linux basées sur du code, le conteneur Linux intégré ne peut pas utiliser de montages de volumes.

Plus de ressources