Configurer un conteneur personnalisé pour Azure App Service

  • Article

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

Ce guide fournit les principaux concepts et instructions pour la conteneurisation d’applications Windows dans App Service. Les nouveaux utilisateurs d’Azure App Service doivent d’abord suivre le démarrage rapide et le didacticiel sur les conteneurs personnalisés.

Ce guide fournit les principaux concepts et des instructions pour la mise en conteneur d’applications Linux dans App Service. Si vous êtes nouveau sur Azure App Service, commencez par suivre le démarrage rapide et le didacticiel sur les conteneurs personnalisés. Pour les conteneurs sidecar (préversion), consultez Didacticiel : Configurer un conteneur sidecar pour un conteneur personnalisé dans Azure App Service (préversion).

Remarque

Le principal de service n’est plus pris en charge pour l’authentification par extraction d’images conteneur Windows. La méthode recommandée consiste à utiliser l’identité managée pour les conteneurs Windows et Linux

Images parentes prises en charge

Pour votre image Windows personnalisée, vous devez choisir l’image parente (image de base) appropriée pour l’infrastructure souhaitée :

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

Modifier l’image Docker d’un conteneur personnalisé

Pour modifier un conteneur personnalisé existant de l’image Docker actuelle par une nouvelle image, utilisez la commande suivante :

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>

Pour <nom d’utilisateur> et <mot de passe>, fournissez les informations d’identification de connexion pour votre compte de registre privé.

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

Suivez la procédure suivante pour configurer votre application web pour une extraction à partir d’Azure Container Registry (ACR) à l’aide d’une identité managée. La procédure utilise une identité managée affectée par le système, mais vous pouvez également utiliser une identité managée affectée par l’utilisateur.

  1. Activez l'identité gérée attribuée par le système pour l'application Web en utilisant la commandeaz webapp identity assign :

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

    Remplacez <app-name> 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. Récupérez l’ID de ressource de votre Azure Container Registry :

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

    Remplacez <registry-name> par le nom de votre registre. La sortie de la commande (filtrée par les arguments --query et --output) est l’ID de ressource d’Azure Container Registry.

  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> par l’ID de principal du 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 commande az acr show

    Pour plus d’informations sur ces autorisations, consultez Présentation du 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 :

    • <app-name> avec le nom de votre application web.

    Conseil

    Si vous utilisez la console PowerShell pour exécuter les commandes, vous devrez placer 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>"}'

Vous êtes prêt, et l’application web utilise désormais l’identité managée pour effectuer une extraction à partir d’Azure Container Registry.

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

Pour vous connecter et effectuer une extraction à partir d’un registre à l’intérieur d’un réseau virtuel ou d’un réseau local, votre application doit s’intégrer à un réseau virtuel (VNet). Cette intégration est nécessaire pour Azure Container Registry avec un point de terminaison privé. Une fois votre réseau et la résolution DNS configurés, vous activez le routage de l’extraction de l’image à travers le réseau virtuel en configurant le paramètre de site vnetImagePullEnabled :

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

Je ne vois 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. Pendant l’extraction et le démarrage du nouveau conteneur, App Service continue de servir les requêtes de l’ancien conteneur. Ce n’est qu’une fois le nouveau conteneur démarré et prêt à recevoir des requêtes qu’App Service commence à lui envoyer des requêtes.

Stockage d’images de conteneur

La première fois que vous exécutez une image Docker personnalisée dans App Service, App Service effectue une opération docker pull et extrait toutes les couches d’image. Ces couches sont stockées sur disque, comme si vous utilisiez Docker localement. À chaque redémarrage de l’application, App Service effectue une opération docker pull, mais extrait uniquement les couches qui ont changé. Si aucune modification n’a été apportée, App Service utilise les couches existantes sur le disque local.

Si l’application modifie des instances de calcul pour une raison quelconque, telle que la mise à l’échelle des niveaux tarifaires, App Service doit de nouveau extraire toutes les couches. Il en va de même si vous effectuez un scale-out pour ajouter davantage d’instances. Il existe également de rares cas où 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 via le Cloud Shell. Dans Bash :

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

Dans PowerShell :

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 qui doivent être fournies en externe. Vous pouvez les transmettre via le Cloud Shell. Dans Bash :

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

Dans PowerShell :

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 d’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.

Si votre application utilise des images à partir d’un registre privé ou d’un Docker Hub, les informations d’identification permettant d’accéder au référentiel sont enregistrées dans les variables d’environnement : DOCKER_REGISTRY_SERVER_URL, DOCKER_REGISTRY_SERVER_USERNAME et 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 des conteneurs basés sur IIS ou .NET Framework (version 4.0 ou ultérieure), ils sont automatiquement injectés par App Service dans System.ConfigurationManager en tant que paramètres d’application .NET et chaînes de connexion. Pour toute autre langage ou infrastructure, ils sont fournis en tant que variables d’environnement pour le processus, avec l’un des préfixes correspondants suivants :

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

Cette méthode fonctionne à la fois pour les applications à conteneur unique et à plusieurs conteneurs, où les variables d’environnement sont spécifiées dans le fichier docker-compose.yml.

Utiliser le stockage partagé persistant

Vous pouvez utiliser le répertoire C:\home dans le système de fichiers de votre conteneur personnalisé pour conserver les fichiers au fil des redémarrages, et les partager entre des instances. Le répertoire C:\home est fourni pour permettre à votre conteneur personnalisé d’accéder au stockage persistant.

Lorsque le stockage persistant est désactivé, les écritures dans le répertoire C:\home ne sont pas rendues persistantes entre les redémarrages d’applications ou entre plusieurs instances. Lorsque le stockage persistant est activé, toutes les écritures dans le répertoire C:\home sont rendues persistantes et sont accessibles par toutes les instances d’une application avec scale-out. En outre, tout contenu à l’intérieur du répertoire C:\home du conteneur est remplacé par tout fichier existant déjà présent dans le stockage persistant au démarrage du conteneur.

La seule exception concerne le répertoire C:\home\LogFiles, qui est utilisé pour stocker le conteneur et les journaux des applications. Ce dossier est toujours conservé lors des redémarrages 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 désactivé. En d’autres termes, l’activation ou la désactivation du stockage persistant 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 de paramètre d’application WEBSITES_ENABLE_APP_SERVICE_STORAGE sur false via le Cloud Shell. Dans Bash :

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

Dans PowerShell :

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

Vous pouvez utiliser le répertoire /home dans le système de fichiers de votre conteneur personnalisé pour conserver les fichiers au fil des redémarrages, et les partager entre des instances. Le répertoire /home est fourni pour permettre à votre conteneur personnalisé d’accéder au stockage persistant. L’enregistrement de données dans /home contribue au quota d’espace de stockage compris dans votre plan App Service.

Lorsque le stockage persistant est désactivé, les écritures dans le répertoire /home ne sont pas rendues persistantes entre les redémarrages d’applications ou entre plusieurs instances. Lorsque le stockage persistant est activé, toutes les écritures dans le répertoire /home sont rendues persistantes et sont accessibles par toutes les instances d’une application avec scale-out. En outre, tout contenu à l’intérieur du répertoire /home du conteneur est remplacé par tout fichier existant déjà présent dans le stockage persistant au démarrage du conteneur.

La seule exception concerne le répertoire /home/LogFiles, qui est utilisé pour stocker le conteneur et les journaux des applications. Ce dossier est toujours conservé lors des redémarrages 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 désactivé. En d’autres termes, l’activation ou la désactivation du stockage persistant n’affecte pas le comportement de journalisation des applications.

Il est recommandé d’écrire des données dans /home ou un chemin de stockage Azure monté. Les données écrites en dehors de ces chemins ne sont pas persistantes lors des redémarrages et sont enregistrées dans l’espace disque de l’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, définissez la valeur de paramètre d’application WEBSITES_ENABLE_APP_SERVICE_STORAGE sur true via le Cloud Shell. Dans Bash :

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

Dans PowerShell :

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

Notes

Vous pouvez également configurer votre propre stockage persistant.

Détecter une session HTTPS

App Service termine les requêtes TLS/SSL au niveau des serveurs frontaux. Cela signifie que les requêtes TLS/SSL n’atteignent jamais votre application. Vous n’avez pas besoin et devez vous abstenir d’implémenter la prise en charge des protocoles TLS/SSL dans votre application.

Les serveurs frontaux se trouvent dans des centres de données Azure. Si vous utilisez les protocoles TLS/SSL pour 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, des clés générées automatiquement sont injectées dans le conteneur en tant que clés machine pour les routines de chiffrement ASP.NET. Vous pouvez rechercher ces clés dans votre conteneur en recherchant les variables d’environnement suivantes : MACHINEKEY_Decryption, MACHINEKEY_DecryptionKey, MACHINEKEY_ValidationKey, 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

Vous pouvez vous connecter directement à votre conteneur Windows pour les tâches de diagnostic en accédant à https://<app-name>.scm.azurewebsites.net/ et en choisissant l’option SSH. Une session SSH directe avec votre conteneur est établie dans laquelle vous pouvez exécuter des commandes au sein 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 ayant fait l’objet d’une montée en charge parallèle, la session SSH est connectée à l’une des instances de conteneur. Vous pouvez sélectionner une autre instance dans la liste déroulante Instance dans le menu Kudu supérieur.
  • Les modifications apportées au conteneur à partir de la session SSH ne sont pas conservée lors du redémarrage de votre application (à l’exception des modifications apportées dans le stockage partagé), car elles ne font pas partie de l’image Docker. Pour conserver vos modifications, telles que des paramètres du Registre et l’installation de logiciels, intégrez-les dans le 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 de l’hôte Docker (journaux de plateforme) sont livrés par défaut, mais les journaux d’application ou de serveur web en provenance du conteneur doivent être activés manuellement. Pour plus d’informations, consultez Activer la journalisation des applications et Activer la journalisation du serveur web.

Il existe plusieurs moyens d’accéder aux journaux du Docker :

Dans le portail Azure

Les journaux du Docker sont affichés sur le portail, dans la page Paramètres du conteneur de votre application. Les journaux sont tronqués, mais vous pouvez tous les télécharger en cliquant sur Télécharger.

De Kudu

Accédez à https://<app-name>.scm.azurewebsites.net/DebugConsole, puis sélectionnez le dossier LogFiles pour afficher les fichiers journaux individuels. Pour télécharger l’intégralité du répertoire LogFiles, 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.

Dans le terminal SSH, vous ne pouvez pas accéder au dossier C:\home\LogFiles par défaut, 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 tentez de télécharger le journal de Docker actuellement utilisé à l’aide d’un client FTP, vous risquez d’obtenir une erreur en raison d’un verrou de fichier.

Avec l’API Kudu

Accédez directement à https://<app-name>.scm.azurewebsites.net/api/logs/docker pour afficher les métadonnées des journaux de Docker. Il se peut que plusieurs fichiers journaux soient répertoriés. La propriété href vous permet de télécharger le fichier journal directement.

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

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

Plan App Service/SKU Limite de mémoire en Mo par défaut et par application
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 paramètre d’application WEBSITE_MEMORY_LIMIT_MB à l’aide du Cloud Shell. Dans Bash :

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

Dans PowerShell :

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

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

Personnaliser le nombre de cœurs de calcul

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

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

Dans PowerShell :

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

Notes

La mise à jour du paramètre d’application déclenche un redémarrage automatique qui entraîne un temps d’arrêt minimal. Pour une application de production, envisagez de la permuter dans un emplacement de préproduction, modifiez le paramètre d’application dans l’emplacement de préproduction, puis re-permutez-la en production.

Vérifiez votre numéro ajusté en ouvrant une session SSH à partir du portail ou via le portail Kudu (https://<app-name>.scm.azurewebsites.net/webssh/host) et en tapant les commandes suivantes à l’aide de PowerShell. Chaque commande génère 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 de type multicœur ou hyperthreading. Pour plus d’informations sur le nombre de cœurs disponibles pour chaque niveau tarifaire, consultez Tarification d’App Service, dans la section Plan de service Premium v3.

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 tests Ping après un certain temps, App Service journalise un événement dans le journal de Docker, indiquant que le conteneur n’a pas démarré.

Si votre application est gourmande en ressources, il se peut que le conteneur ne réponde à temps pas à la requête Ping HTTP. Pour contrôler les actions en cas d’échec des tests Ping HTTP, définissez le paramètre d’application CONTAINER_AVAILABILITY_CHECK_MODE. Vous pouvez le définir via le Cloud Shell. Dans Bash :

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

Dans PowerShell :

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

Le tableau suivant présente les valeurs possibles :

Valeur Descriptions
Repair Redémarrer le conteneur après trois vérifications de disponibilité consécutives
ReportOnly Valeur par défaut. Ne pas redémarrer le conteneur mais signaler dans les journaux de Docker du conteneur après trois vérifications de disponibilité consécutives.
Désactivé Ne pas vérifier la disponibilité.

Prise en charge des comptes de service géré par un groupe

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

Activation de SSH

Secure Shell (SSH) est couramment utilisé pour exécuter des commandes d’administration à distance à partir d’un terminal de ligne de commande. Pour activer la fonctionnalité de console SSH Portail Azure avec des conteneurs personnalisés, les étapes suivantes sont requises :

  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 être conforme à la fonctionnalité SSH Portail Azure :

    • Port être défini sur 2222.
    • Ciphers doit inclure au moins un élément dans cette liste : aes128-cbc,3des-cbc,aes256-cbc.
    • MACs doit inclure au moins un élément dans cette liste : hmac-sha1,hmac-sha1-96.

  2. Créez un script de point d’entrée avec le nom entrypoint.sh (ou modifiez tout fichier de point d’entrée existant) et 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 en fonction de la langue/pile du projet :

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

  3. Ajoutez au fichier Dockerfile les instructions suivantes 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!, car il est utilisé par App Service pour vous permettre d’accéder à 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é et n’est pas accessible à un attaquant sur Internet.

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

Vous trouverez davantage d’informations sur la résolution des problèmes sur le blog Azure App Service : Activation de SSH sur Linux Web App pour conteneurs.

Accéder aux journaux de diagnostic

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

Activez d’abord la journalisation du conteneur en exécutant la commande suivante :

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

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

Une fois la journalisation du conteneur activée, exécutez la commande suivante pour voir le flux de journal :

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

Si vous ne voyez pas les journaux d’activité de la console, attendez 30 secondes et vérifiez à nouveau.

Pour arrêter le streaming de journaux à tout moment, appuyez sur Ctrl+C.

Vous pouvez également inspecter les fichiers journaux dans un navigateur sur https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Configurer des applications à plusieurs conteneurs

Remarque

Les conteneurs sidecar (préversion) remplaceront les applications multiconteneur dans App Service. Pour commencer, consultez Didacticiel : Configurer un conteneur sidecar pour un conteneur personnalisé dans Azure App Service (préversion).

Utiliser le stockage persistant dans Docker Compose

Les applications multiconteneurs telles que WordPress nécessitent un stockage persistant pour fonctionner correctement. Pour l’activer, votre configuration Docker Compose doit pointer vers un emplacement de stockage à l’extérieur 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.

Activez le stockage persistant en définissant le paramètre d’application WEBSITES_ENABLE_APP_SERVICE_STORAGE, à l’aide de la commande az webapp config appsettings set dans le Cloud Shell.

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

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

WEBAPP_STORAGE_HOME est une variable d’environnement d’App Service mappée sur le stockage persistant de votre application. Par 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 / Autorisation
  • Identités managées
  • CORS
  • L’intégration au réseau virtuel n’est pas prise en charge pour les scénarios Docker Compose.
  • Docker Compose sur Azure App Services a actuellement une limite de 4000 caractères.

Options Docker Compose

Les listes suivantes présentent des 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ée)
  • depends_on (ignorée)
  • networks (ignorée)
  • secrets (ignorée)
  • ports autres que 80 et 8080 (ignorées)
  • variables d’environnement par défaut comme $variable and ${variable} ou différente dans Docker

Limitations de syntaxe

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

Notes

Les autres options qui ne sont pas explicitement appelées sont ignorées dans la préversion publique.

robots933456 dans les journaux

Le message suivant peut s'afficher dans les journaux 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 utilisé par App Service pour vérifier si le conteneur est capable de traiter des requêtes. Une réponse 404 indique que le chemin d’accès n’existe pas, mais informe App Service que le conteneur est intègre et prêt à répondre aux requêtes.

Étapes suivantes

Tutoriel : Migrer des logiciels personnalisés vers Azure App Service à l’aide d’un conteneur personnalisé

Didacticiel : Configurer un conteneur sidecar pour un conteneur personnalisé dans Azure App Service (préversion)

Ou vous pouvez également consulter d’autres ressources :