Partager via

Configurer un conteneur personnalisé pour Azure App Service

Cet article montre comment configurer un conteneur personnalisé à exécuter sur Azure App Service.

Découvrez les concepts clés et obtenez des instructions pour la conteneurisation d’applications Windows dans App Service. Les nouveaux utilisateurs doivent d’abord suivre le guide de démarrage rapide et le didacticiel personnalisés du conteneur.

Découvrez les concepts clés et obtenez des instructions pour la conteneurisation d’applications Linux dans App Service. Les nouveaux utilisateurs doivent d’abord suivre le guide de démarrage rapide et le didacticiel personnalisés du conteneur. Pour les conteneurs sidecar, consultez Tutoriel : Configurer un conteneur sidecar pour un conteneur personnalisé dans Azure App Service.

Remarque

L'utilisation d'un principal de service pour l'authentification par extraction d'images de conteneurs Windows n'est plus prise en charge. Nous vous recommandons d’utiliser l’identité managée pour les conteneurs Windows et Linux.

Images parentes prises en charge

Sélectionnez l’image parente appropriée (image de base) pour l’infrastructure souhaitée pour votre image Windows personnalisée :

  • Pour déployer des applications .NET Framework, utilisez une image parente basée sur la version Long-Term Servicing Channel de Windows Server 2019 Core.
  • Pour déployer des applications .NET Core, utilisez une image parente basée sur la version Windows Server 2019 Nano Annual Channel.

Le téléchargement d’une image parente lors du démarrage de l’application peut prendre un certain temps. Vous pouvez réduire le temps de démarrage à l’aide de l’une des images parentes suivantes qui sont déjà mises en cache dans Azure App Service :

Modifier l’image Docker d’un conteneur personnalisé

Utilisez la commande suivante pour modifier l’image Docker actuelle en une nouvelle image dans un conteneur personnalisé existant :

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

Utiliser une image à partir d’un registre privé

Pour utiliser une image à partir d’un registre privé, comme Azure Container Registry, exécutez la commande suivante :

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>

Fournissez les informations d’identification de connexion pour votre compte de registre privé dans les champs \<username> et \<password>.

Utiliser l’identité managée pour extraire une image d’Azure Container Registry

Suivez les étapes ci-dessous pour configurer votre application web afin qu'elle extraie des données d'Azure Container Registry à l'aide d'une identité managée. Les étapes utilisent l’identité managée affectée par le système, mais vous pouvez également utiliser l’identité managée affectée par l’utilisateur.

  1. Activez l’identité managée affectée par le système pour l’application web à l’aide de la az webapp identity assign commande :

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

    Remplacez <le nom> de l’application par le nom que vous avez utilisé à l’étape précédente. La sortie de la commande, filtrée par les arguments --query et --output, est l’ID du principal de service de l’identité affectée.

  2. Obtenez l’ID de ressource de votre registre de conteneurs :

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

    Remplacez <le nom> du registre par le nom de votre registre. La sortie de la commande, filtrée par les arguments --query et --output, est l’ID de ressource du registre de conteneurs.

  3. Accordez à l’identité managée l’autorisation d’accéder au registre de conteneurs :

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

    Remplacez les valeurs suivantes :

    • <principal-id> avec l’ID de principal de service récupéré à partir de la commande az webapp identity assign
    • <registry-resource-id> avec l’ID de votre registre de conteneurs à partir de la az acr show commande

    Pour plus d’informations sur ces autorisations, consultez Qu’est-ce que le contrôle d’accès en fonction du rôle Azure ?.

  4. Configurez votre application pour qu’elle utilise l’identité managée pour effectuer une extraction à partir d’Azure Container Registry.

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

    Remplacez les valeurs suivantes :

    • <nom> de l’application avec le nom de votre application web.

    Conseil

    Si vous utilisez la console PowerShell pour exécuter les commandes, placez les chaînes dans une séquence d’échappement dans l’argument --generic-configurations dans cette étape et la suivante. Par exemple : --generic-configurations '{\"acrUseManagedIdentityCreds\": true'.

  5. (Facultatif) Si votre application utilise une identité managée affectée par l’utilisateur, assurez-vous qu’elle est configurée sur l’application web, puis définissez la propriété acrUserManagedIdentityID pour spécifier son ID client :

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

    Remplacez l’<identity-name> de votre identité managée affectée par l’utilisateur et utilisez la sortie <client-id> pour configurer l’ID de l’identité managée affectée par l’utilisateur.

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

L’application web utilise désormais l’identité managée pour récupérer des données depuis le registre de conteneurs Azure.

Utiliser une image à partir d’un registre protégé par le réseau

Pour vous connecter et extraire à partir d’un registre à l’intérieur d’un réseau virtuel ou local, votre application doit s’intégrer à un réseau virtuel. Vous avez également besoin d’une intégration de réseau virtuel pour Azure Container Registry avec un point de terminaison privé. Après avoir configuré votre réseau et votre résolution DNS, activez le routage du pull d'image via le réseau virtuel. Configurez le paramètre du site vnetImagePullEnabled :

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

Dépannage : que faire si vous ne voyez pas le conteneur mis à jour

Si vous modifiez vos paramètres de conteneur Docker pour qu’ils pointent vers un nouveau conteneur, l’application peut prendre quelques minutes avant de servir les requêtes HTTP du nouveau conteneur. Bien que le nouveau conteneur soit extrait et démarré, App Service continue de traiter les demandes de l’ancien conteneur. App Service envoie uniquement des demandes au nouveau conteneur après son démarrage et est prêt à recevoir des demandes.

Découvrez comment les images conteneur sont stockées

La première fois que vous exécutez une image Docker personnalisée dans App Service, App Service exécute la docker pull commande et extrait toutes les couches d’image. Les couches sont stockées sur le disque, comme lorsque vous utilisez Docker localement. Chaque fois que l’application redémarre, App Service exécute la docker pull commande. Il extrait uniquement les couches modifiées. Si aucune modification n’a été apportée, App Service utilise les couches existantes sur le disque local.

Si l’application modifie les instances de calcul pour une raison quelconque (comme la modification des niveaux tarifaires), App Service doit à nouveau extraire toutes les couches. Il en va de même si vous effectuez un scale-out pour ajouter davantage d’instances. En outre, dans de rares cas, les instances d’application peuvent changer sans opération de mise à l’échelle.

Configurer le numéro de port

Par défaut, App Service suppose que votre conteneur personnalisé écoute sur le port 80. Si votre conteneur écoute un port différent, définissez le paramètre d’application WEBSITES_PORT dans votre application App Service. Vous pouvez le définir à l’aide d’Azure Cloud Shell. Dans Bash, utilisez la commande suivante :

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

Dans PowerShell, utilisez la commande suivante :

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

App Service autorise actuellement votre conteneur à exposer un seul port pour les requêtes HTTP.

Configuration des variables d’environnement

Votre conteneur personnalisé peut utiliser des variables d’environnement que vous devez fournir en externe. Vous pouvez les transmettre à l’aide de Cloud Shell. Dans Bash, utilisez la commande suivante :

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

Dans PowerShell, utilisez la commande suivante :

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

Lorsque votre application s’exécute, les paramètres de l’application App Service sont automatiquement injectés dans le processus en tant que variables d’environnement. Vous pouvez vérifier les variables d’environnement de conteneur avec l’URL https://<app-name>.scm.azurewebsites.net/Env.

Lorsque vous effectuez une connexion SSH dans un conteneur avec des images Docker personnalisées, vous pouvez voir seulement quelques variables d’environnement si vous essayez d’utiliser des commandes comme env ou printenv. Pour afficher toutes les variables d’environnement dans le conteneur, comme celles que vous transmettez à votre application pour l’utilisation de l’exécution, ajoutez cette ligne à votre script de point d’entrée :

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

Consultez un exemple complet.

Si votre application utilise des images à partir d’un registre privé ou de Docker Hub, les informations d’identification d’accès au référentiel sont enregistrées dans des variables d’environnement : DOCKER_REGISTRY_SERVER_URL, DOCKER_REGISTRY_SERVER_USERNAMEet DOCKER_REGISTRY_SERVER_PASSWORD. En raison des risques de sécurité, aucun de ces noms de variables réservés n’est exposé à l’application.

Pour les conteneurs IIS (Internet Information Services) ou .NET Framework (4.0 ou version ultérieure), les informations d’identification sont automatiquement injectées en System.ConfigurationManager tant que paramètres d’application .NET et chaînes de connexion par App Service. Pour tous les autres langages ou infrastructures, ils sont fournis en tant que variables d’environnement pour le processus, avec l’un des préfixes suivants :

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

Vous pouvez utiliser cette méthode pour les applications à conteneur unique ou à plusieurs conteneurs, où les variables d’environnement sont spécifiées dans le docker-compose.yml fichier.

Utiliser le stockage partagé persistant

Vous pouvez utiliser le C:\home répertoire de votre système de fichiers conteneur personnalisé pour conserver les fichiers entre les redémarrages et les partager entre les instances. Lorsque vous utilisez le C:\home répertoire, votre conteneur personnalisé peut accéder au stockage persistant.

Lorsque le stockage persistant est désactivé, les écritures dans le répertoire ne sont pas conservées entre les redémarrages de l’application C:\home ou sur plusieurs instances. Lorsque le stockage persistant est activé, toutes les écritures dans le C:\home répertoire persistent. Toutes les instances d’une application mise à l’échelle horizontalement ont accès à celles-ci. Au démarrage du conteneur, si des fichiers sont présents sur le stockage persistant, ils remplacent tout contenu dans le C:\home répertoire du conteneur.

La seule exception est le C:\home\LogFiles répertoire. Ce répertoire stocke les journaux du conteneur et de l’application. Le dossier persiste toujours lors du redémarrage de l’application si la journalisation des applications est activée avec l’option Système de fichiers, que le stockage persistant soit activé ou non. En d’autres termes, lorsque vous activez ou désactivez le stockage persistant, cela n’affecte pas le comportement de journalisation des applications.

Par défaut, le stockage persistant est activé sur les conteneurs personnalisés Windows. Pour le désactiver, définissez la valeur du WEBSITES_ENABLE_APP_SERVICE_STORAGE paramètre d’application à false l’aide de Cloud Shell. Dans Bash, utilisez la commande suivante :

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

Dans PowerShell, utilisez la commande suivante :

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

Vous pouvez utiliser le /home répertoire de votre système de fichiers conteneur personnalisé pour conserver les fichiers entre les redémarrages et les partager entre les instances. Lorsque vous utilisez le C:\home répertoire, votre conteneur personnalisé peut accéder au stockage persistant. Gardez à l’esprit que les données que vous enregistrez contribuent /home au quota d’espace de stockage inclus dans votre plan App Service.

Lorsque le stockage persistant est désactivé, les écritures dans le répertoire ne sont pas conservées entre les redémarrages de l’application C:\home ou sur plusieurs instances. Lorsque le stockage persistant est activé, toutes les écritures dans le C:\home répertoire persistent. Toutes les instances d’une application mise à l’échelle horizontalement ont accès à celles-ci. Au démarrage du conteneur, si des fichiers sont présents sur le stockage persistant, ils remplacent tout contenu dans le C:\home répertoire du conteneur.

La seule exception est le C:\home\LogFiles répertoire. Ce répertoire stocke les journaux du conteneur et de l’application. Le dossier persiste toujours lors du redémarrage de l’application si la journalisation des applications est activée avec l’option Système de fichiers, que le stockage persistant soit activé ou non. En d’autres termes, lorsque vous activez ou désactivez le stockage persistant, cela n’affecte pas le comportement de journalisation des applications.

Nous vous recommandons d’écrire des données dans /home ou un chemin de stockage Azure monté. Les données que vous écrivez en dehors de ces chemins d’accès ne sont pas persistantes pendant les redémarrages. Les données sont enregistrées dans l’espace disque hôte géré par la plateforme distinct du quota de stockage de fichiers des plans App Service.

Par défaut, le stockage persistant est désactivé sur les conteneurs Linux personnalisés. Pour l'activer, réglez le WEBSITES_ENABLE_APP_SERVICE_STORAGE paramètre d'application sur la valeur true en utilisant Cloud Shell. Dans Bash, utilisez la commande suivante :

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

Dans PowerShell, utilisez la commande suivante :

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

Remarque

Vous pouvez également configurer votre propre stockage persistant.

Détecter une session HTTPS

App Service met fin au protocole TLS aux serveurs frontaux. Cela signifie que les requêtes TLS n’arrivent jamais à votre application. Vous n’avez pas besoin et ne devez pas implémenter de prise en charge de TLS dans votre application.

Les interfaces utilisateur se trouvent dans les centres de données Azure. Si vous utilisez TLS avec votre application, votre trafic sur Internet est toujours chiffré en toute sécurité.

Personnaliser l’injection de clé machine ASP.NET

Pendant le démarrage du conteneur, les clés sont générées et injectées automatiquement dans le conteneur en tant que clés de machine pour ASP.NET routines de chiffrement. Vous pouvez trouver ces clés dans votre conteneur en recherchant les variables d’environnement suivantes : MACHINEKEY_Decryption, , MACHINEKEY_DecryptionKeyMACHINEKEY_ValidationKey, et MACHINEKEY_Validation.

Les nouvelles clés générées à chaque redémarrage peuvent réinitialiser l’authentification par formulaires ASP.NET et l’état d’affichage, si votre application en dépend. Pour empêcher la régénération automatique des clés, définissez-les manuellement en tant que paramètres d’application App Service.

Connexion au conteneur

Pour vous connecter directement à votre conteneur Windows pour les tâches de diagnostic, accédez à https://<app-name>.scm.azurewebsites.net/ et sélectionnez l’option SSH. Cette option établit une session SSH directe dans laquelle vous pouvez exécuter des commandes à l’intérieur de votre conteneur.

  • Elle fonctionne séparément du navigateur graphique, au-dessus de celui-ci, et n’affiche que les fichiers de votre stockage partagé.
  • Dans une application étendue, la session SSH se connecte à l’une des instances de conteneurs. Vous pouvez sélectionner une autre instance dans la liste déroulante Instance dans le menu supérieur de Kudu.
  • À l’exception des modifications apportées au stockage partagé, toute modification apportée au conteneur à partir de la session SSH ne persiste pas lorsque votre application redémarre. Ces modifications ne font pas partie de l’image Docker. Pour conserver les modifications telles que les paramètres du Registre et l’installation logicielle, faites-les partie du fichier Dockerfile.

Accéder aux journaux de diagnostic

App Service journalise les actions de l’hôte Docker, ainsi que les activités provenant du conteneur. Les journaux d’activité de l’hôte Docker (journaux de plateforme) sont activés par défaut. Vous devez activer manuellement les journaux des applications ou les journaux de serveur web à partir du conteneur. Pour plus d’informations, consultez Activer la journalisation des applications et Activer la journalisation du serveur web.

Vous pouvez accéder aux journaux Docker de plusieurs façons :

Portail Azure

Les journaux Docker s’affichent dans le portail Azure dans le volet Paramètres du conteneur de votre application. Les logs sont tronqués. Pour télécharger tous les journaux de logs, sélectionnez Télécharger.

Kudu

Pour afficher les fichiers journaux individuels, accédez à https://<app-name>.scm.azurewebsites.net/DebugConsole et sélectionnez le LogFiles dossier. Pour télécharger l’intégralité LogFiles du répertoire, sélectionnez l’icône Télécharger à gauche du nom du répertoire. Vous pouvez également accéder à ce dossier à l’aide d’un client FTP.

Par défaut, vous ne pouvez pas accéder au C:\home\LogFiles dossier dans le terminal SSH, car le stockage partagé persistant n’est pas activé. Pour activer ce comportement dans le terminal de la console, vous devez activer le stockage partagé persistant.

Si vous essayez de télécharger le journal Docker actuellement utilisé à l’aide d’un client FTP, vous risquez d’obtenir une erreur en raison d’un verrou de fichier.

Kudu API

Accédez directement à https://<app-name>.scm.azurewebsites.net/api/logs/docker pour voir les métadonnées des journaux de Docker. Vous pouvez voir plus d'un fichier journal répertorié. Vous pouvez utiliser la href propriété pour télécharger directement le fichier journal.

Pour télécharger tous les journaux dans un fichier ZIP, accédez à https://<app-name>.scm.azurewebsites.net/api/logs/docker/zip.

Personnaliser la mémoire du conteneur

Par défaut, tous les conteneurs Windows déployés dans Azure App Service ont une limite de mémoire configurée. Le tableau suivant répertorie les paramètres par défaut par référence SKU de plan App Service.

plan de service d'application SKU Limite de mémoire par défaut par application (en Mo)
P1v3 1 024
P1Mv3 1 024
P2v3 1536
P2Mv3 1536
P3v3 2 048
P3Mv3 2 048
P4Mv3 2560
P5Mv3 3 072

Vous pouvez modifier cette valeur en fournissant le WEBSITE_MEMORY_LIMIT_MB paramètre d’application dans Cloud Shell. Dans Bash, utilisez la commande suivante :

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

Dans PowerShell, utilisez la commande suivante :

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

La valeur est définie en mégaoctets (Mo) et doit être inférieure et égale à la mémoire physique totale de l’hôte. Par exemple, dans un plan App Service avec 8 Go de RAM, le total cumulé de WEBSITE_MEMORY_LIMIT_MB toutes les applications ne peut pas dépasser 8 Go. Pour plus d’informations sur la quantité de mémoire disponible, consultez le plan de service Premium v3 dans la tarification App Service.

Personnaliser le nombre de cœurs de calcul

Par défaut, un conteneur Windows s’exécute avec tous les cœurs disponibles pour votre niveau tarifaire. Vous pouvez réduire le nombre de cœurs qu’utilise votre emplacement de préproduction. Pour réduire le nombre de cœurs qu’un conteneur utilise, définissez le WEBSITE_CPU_CORES_LIMIT paramètre d’application sur le nombre de cœurs préféré. Vous pouvez le définir à l’aide de Cloud Shell. Dans Bash, utilisez la commande suivante :

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

Dans PowerShell, utilisez la commande suivante :

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

Conseil

La mise à jour du paramètre d’application déclenche le redémarrage automatique, ce qui entraîne un temps d’arrêt minimal. Pour une application en production, envisagez de la déplacer vers un environnement de test. Modifiez les paramètres de l'application dans l'environnement de test, puis remettez-la en production.

Pour vérifier votre numéro ajusté, ouvrez une session SSH à l’aide du portail Azure ou du portail Kudu (https://<app-name>.scm.azurewebsites.net/webssh/host). Entrez les commandes suivantes à l’aide de PowerShell. Chaque commande retourne un nombre.

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

Les processeurs peuvent être des processeurs multicœurs ou hyperthreading. Pour savoir combien de cœurs sont disponibles, consultez le plan de service Premium v3 dans la tarification App Service.

Personnaliser le comportement de test Ping d’intégrité

App Service considère que le démarrage d’un conteneur est correct quand le conteneur démarre et répond à un test Ping HTTP. La requête Ping d’intégrité contient l’en-tête User-Agent= "App Service Hyper-V Container Availability Check". Si le conteneur démarre mais ne répond pas aux pings après un certain temps, App Service journalise un événement dans le journal Docker.

Si votre application est gourmande en ressources, le conteneur peut ne pas répondre au test ping HTTP à temps. Pour contrôler ce qui se passe quand les pings HTTP échouent, définissez le paramètre d’application CONTAINER_AVAILABILITY_CHECK_MODE . Vous pouvez le définir à l’aide de Cloud Shell. Dans Bash, utilisez la commande suivante :

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

Dans PowerShell, utilisez la commande suivante :

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

Le tableau suivant présente les valeurs possibles :

Valeur Descriptif
Repair Redémarrez le conteneur après trois vérifications de disponibilité consécutives.
ReportOnly Valeur par défaut. Signalez le conteneur dans les journaux Docker après trois vérifications de disponibilité consécutives, mais ne le redémarrez pas.
Off Ne pas vérifier la disponibilité.

Prise en charge des comptes de services gérés par groupe

Les comptes de service géré de groupe ne sont pas pris en charge dans les conteneurs Windows dans App Service.

Activation de SSH

Vous pouvez utiliser Secure Shell (SSH) pour exécuter à distance des commandes d’administration à partir d’un terminal de ligne de commande. Pour activer la fonctionnalité de console SSH du portail Azure avec des conteneurs personnalisés, procédez comme suit :

  1. Créez un fichier sshd_config standard avec l’exemple de contenu suivant et placez-le dans le répertoire racine du projet d’application :

    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

    Remarque

    Ce fichier configure OpenSSH et doit inclure les éléments suivants pour se conformer à la fonctionnalité SSH du portail Azure :

    • La Port valeur doit être définie sur 2222.
    • Les Ciphers valeurs doivent inclure au moins un élément dans cette liste : aes128-cbc, 3des-cbcou aes256-cbc.
    • Les MACs valeurs doivent inclure au moins un élément dans cette liste : hmac-sha1 ou hmac-sha1-96.

  2. Créez un script de point d’entrée nommé entrypoint.sh ou modifiez un fichier de point d’entrée existant. Ajoutez la commande pour démarrer le service SSH, ainsi que la commande de démarrage de l’application. L’exemple suivant illustre le démarrage d’une application Python. Remplacez la dernière commande selon la langue ou le stack du projet :

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

  3. Ajoutez les instructions suivantes au fichier Dockerfile en fonction de la distribution d’images de base. Ces instructions copient les nouveaux fichiers, installent le serveur OpenSSH, définissent les autorisations appropriées et configurent le point d’entrée personnalisé et exposent les ports requis par l’application et le serveur SSH, respectivement :

    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" ]

    Remarque

    Le mot de passe racine doit être exactement Docker! dû au fait qu’App Service l’utilise pour vous accorder l’accès à la session SSH avec le conteneur. Cette configuration n’autorise pas les connexions externes avec le conteneur. Le port 2222 du conteneur est accessible uniquement au sein du réseau de pont d’un réseau virtuel privé. Un attaquant sur Internet ne peut pas y accéder.

  4. Régénérez et envoyez (push) l’image Docker au Registre, puis testez la fonctionnalité SSH d’application web dans le portail Azure.

Pour plus d’informations sur la résolution des problèmes, consultez le blog Azure App Service : Activer SSH sur une application web Linux pour conteneurs.

Accéder aux journaux de diagnostic

Vous pouvez accéder aux journaux de la console qui sont générés à partir du conteneur.

Pour activer la journalisation des conteneurs, exécutez la commande suivante :

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

Remplacez les valeurs <app-name> et <resource-group-name> par des noms appropriés pour votre application web.

Après avoir activé la journalisation des conteneurs, exécutez la commande suivante pour afficher le flux de journaux :

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

Si les logs de console ne s’affichent pas immédiatement, revérifiez dans 30 secondes.

Pour arrêter le streaming des logs (journaux) à tout moment, utilisez le raccourci clavier Ctrl+C.

Configurer des applications à plusieurs conteneurs

Remarque

La fonctionnalité Docker Compose sera mise hors service le 31 mars 2027. Les conteneurs Sidecar succèdent aux applications multi-conteneurs dans App Service. Pour les nouveaux services, consultez Tutoriel : Configurer un conteneur sidecar pour un conteneur personnalisé dans Azure App Service. Pour les applications multiconteneurs existantes dans App Service, consultez Migrer vos applications Docker Compose vers la fonctionnalité side-car.

Utiliser le stockage persistant dans Docker Compose

Les applications multiconteneurs telles que WordPress nécessitent un stockage persistant pour fonctionner correctement. Pour activer le stockage persistant, votre configuration Docker Compose doit pointer vers un emplacement de stockage en dehors de votre conteneur. Les emplacements de stockage à l’intérieur de votre conteneur ne rendent pas les modifications persistantes au-delà du redémarrage de l’application.

Pour activer le stockage persistant, définissez le paramètre d’application WEBSITES_ENABLE_APP_SERVICE_STORAGE . Utilisez la az webapp config appsettings set commande dans Cloud Shell.

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

Dans votre docker-compose.yml fichier, mappez l’option volumes sur ${WEBAPP_STORAGE_HOME}.

WEBAPP_STORAGE_HOME est une variable d’environnement dans le service App qui correspond au stockage persistant de votre application. Exemple :

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"

Limitations de la version préliminaire

La fonctionnalité multiconteneurs est actuellement en préversion. Les fonctionnalités suivantes de la plateforme App Service ne sont pas prises en charge :

  • Authentification ou autorisation.
  • Identités gérées.
  • Partage de ressources inter-origines (CORS).
  • Intégration de réseau virtuel à des scénarios Docker Compose.

Docker Compose sur Azure App Service a actuellement une limite de 4 000 caractères.

Options Docker Compose

Les sections suivantes montrent les options de configuration Docker Compose prises en charge et non prises en charge.

Options prises en charge

Options non prises en charge

  • build (non autorisé)
  • depends_on (ignoré)
  • networks (ignoré)
  • secrets (ignoré)
  • Ports autres que 80 et 8080 (ignorés)
  • Variables d’environnement par défaut comme $variable et ${variable} (contrairement à Docker)

Limitations de syntaxe

  • La première instruction YAML dans le fichier doit toujours être version x.x.
  • La section ports doit utiliser des nombres entre guillemets.
  • La image > volume section doit être entre guillemets et ne peut pas avoir de définitions d’autorisations.
  • La section des volumes ne peut pas inclure d'accolade ouvrante vide après le nom du volume.

Remarque

Toutes les autres options non mentionnées explicitement sont ignorées en préversion.

Ignorer le message robots933456 dans les logs informatiques

Le message suivant peut s’afficher dans les journaux d’activité du conteneur :

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

Vous pouvez sans risque ignorer ce message. /robots933456.txt est un chemin d’URL factice. App Service l’utilise pour vérifier si le conteneur est capable de traiter les demandes. Une réponse d’erreur « 404 » indique que le chemin d’accès n’existe pas et signale à App Service que le conteneur est sain et prêt à répondre aux demandes.

Contenu connexe

  • Last updated on