Questions fréquentes (FAQ) sur Azure App Service sur Linux

Ces commandes ou scripts sont exécutés après le démarrage du conteneur Docker intégré, mais avant le démarrage de votre code d’application.

Cette action revient à redémarrer Docker.

Oui, vous pouvez le faire via le site de gestion de contrôle de code source (SCM).

Définissez le champ reserved du service d’application sur true.

Oui. Pour configurer l’intégration/le déploiement continu(e) pour Azure Container Registry ou DockerHub, consultez Déploiement continu avec Web App pour conteneurs. Pour les registres privés, vous pouvez actualiser le conteneur en arrêtant puis démarrant votre application web. Vous pouvez également modifier ou ajouter un paramètre d’application factice pour forcer une actualisation de votre conteneur.

Oui.

Oui, vous devez définir le paramètre d’application WEBSITE_WEBDEPLOY_USE_SCM sur false.

Si le déploiement Git sur votre application web Linux échoue, choisissez l’une des options suivantes pour déployer le code de votre application :

• Utilisez la fonctionnalité Livraison continue (préversion) : vous pouvez stocker le code source de votre application dans un dépôt Git Azure DevOps ou un dépôt GitHub pour utiliser La livraison continue Azure. Pour plus d’informations, consultez Configurer la livraison continue pour une application web Linux.

• Utilisez l’API de déploiement ZIP : pour utiliser cette API, connectez-vous via SSH à votre application web et accédez au dossier où vous souhaitez déployer votre code. Exécutez le code ci-dessous :

  curl -X POST -u <user> --data-binary @<zipfile> https://{your-sitename}.scm.azurewebsites.net/api/zipdeploy
  

  Si vous obtenez une erreur stipulant que la commande curl est introuvable, veillez à installer curl à l’aide de apt-get install curl avant d’exécuter la commande curl précédente.

Oui, vous devez désactiver perMessageDeflate dans votre code Node.js côté serveur. Par exemple, si vous utilisez socket.io, utilisez le code suivant :

const io = require('socket.io')(server,{
  perMessageDeflate :false
});

Oui.

Oui. Lors d’un déploiement Git, Kudu doit détecter que vous déployez une application PHP (grâce à la présence d’un fichier composer.lock) et déclenchera une installation Composer.

Oui, cette fonctionnalité est disponible dans l’interface Azure CLI. Vous pouvez utiliser des identités attribuées par le système ou attribuées par l’utilisateur. Actuellement, cette fonctionnalité n’est pas prise en charge dans le portail Azure.

Si le paramètre WEBSITES_ENABLE_APP_SERVICE_STORAGE est non spécifié ou est défini sur false, le répertoire /home/ n’est pas partagé par les instances de mise à l’échelle, et les fichiers écrits ne sont pas conservés après chaque redémarrage. La définition explicite de WEBSITES_ENABLE_APP_SERVICE_STORAGE sur true active le montage. Une fois que cette valeur est fixée à true, si vous souhaitez désactiver le montage, vous devez explicitement la fixer WEBSITES_ENABLE_APP_SERVICE_STORAGE à false.

App Service sur Linux utilise deux types de stockage différents :

• Stockage du système de fichiers : le stockage du système de fichiers est inclus dans le quota du plan App Service. Il est utilisé lorsque les fichiers sont enregistrés dans le stockage persistant rooté dans le /home répertoire.
• Espace disque hôte : l’espace disque hôte est utilisé pour stocker des images conteneur. Elle est gérée par la plateforme via le pilote de stockage Docker.

L’espace disque hôte est distinct du quota de stockage du système de fichiers. Il n’est pas extensible et il existe une limite de 15 Go pour chaque instance. Il est utilisé pour stocker toutes les images personnalisées sur le worker. Vous pouvez peut-être utiliser plus de 15 Go en fonction de la disponibilité exacte de l’espace disque hôte, mais cela n’est pas garanti.

Si la couche accessible en écriture du conteneur enregistre les données en dehors du répertoire ou d’un chemin de /home stockage Azure monté, l’espace disque hôte est également consommé.

La plateforme nettoie régulièrement l’espace disque hôte pour supprimer les conteneurs inutilisés. Si le conteneur écrit une grande quantité de données en dehors du /home répertoire ou byOS (Bring Your Own Storage), il génère des échecs de démarrage ou des exceptions d’exécution une fois la limite d’espace disque hôte dépassée.

Nous vous recommandons de conserver vos images conteneur aussi petites que possible et d’écrire des données dans le stockage persistant ou BYOS lors de l’exécution sur Linux App Service. Si ce n’est pas possible, vous devez fractionner le plan App Service, car l’espace disque hôte est fixe et partagé entre tous les conteneurs du plan App Service.

Vous pouvez configurer le temps que la plateforme doit attendre avant qu’elle redémarre votre conteneur. Pour ce faire, définissez le paramètre d’application WEBSITES_CONTAINER_START_TIME_LIMIT sur la valeur souhaitée. La valeur par défaut est de 230 secondes, la valeur maximale de 1800 secondes.

Vous devez fournir l’URL de registre complète, y compris http:// ou https://.

Ajoutez le nom complet de l’image, comprenant l’URL de registre privé (par exemple, myacr.azurecr.io/dotnet:latest). Les noms d’image qui utilisent un port personnalisé ne peuvent pas être entrés par le biais du portail. Pour définir docker-custom-image-name, utilisez l’outil en ligne de commande az.

Nous ne prenons pas en charge l’exposition de plusieurs ports.

Oui, le mode Bring Your Own Storage est disponible en préversion.

Le site SCM s’exécute dans un conteneur distinct. Vous ne pouvez pas vérifier le système de fichiers ou les processus en cours d’exécution du conteneur d’application.

Non, la plateforme gère l’annulation HTTPS au niveau des serveurs frontaux partagés.

Oui, c’est obligatoire pour les conteneurs personnalisés. Pour configurer manuellement un port personnalisé, utilisez l’instruction EXPOSE dans le Dockerfile et le paramètre de l’application, WEBSITES_PORT, avec une valeur de port pour la liaison sur le conteneur.

Oui, remplacez la variable d’environnement avant le démarrage de l’application .NET Core. P. ex. : dans le script init.sh : export ASPNETCORE_URLS={Votre valeur}

Pour utiliser ACR avec plusieurs conteneurs, toutes les images de conteneur doivent être hébergées sur le même serveur de Registre ACR. Une fois qu’elles se trouvent sur le même serveur de Registre, vous devez créer des paramètres d’application, puis mettre à jour le fichier config Docker Compose en y ajoutant le nom de l’image ACR.

Créez les paramètres d’application suivants :

• DOCKER_REGISTRY_SERVER_USERNAME
• DOCKER_REGISTRY_SERVER_URL (URL complète, p. ex. : https://<server-name>.azurecr.io)
• DOCKER_REGISTRY_SERVER_PASSWORD (activez l’accès administrateur dans les paramètres ACR)

Dans le fichier de configuration, référencez votre image ACR comme dans l’exemple suivant :

image: <server-name>.azurecr.io/<image-name>:<tag>

• Un seul conteneur peut être ouvert en vue d’y accéder
• Seuls les ports 80 et 8080 sont accessibles (ports exposés)

Voici les règles pour déterminer quel conteneur est accessible, par ordre d’importance :

• Le paramètre d’application WEBSITES_WEB_CONTAINER_NAME doit être défini sur le nom du conteneur.
• Le premier conteneur doit définir le port 80 ou 8080.
• Si aucune de ces règles n’est appliquée, le premier conteneur défini dans le fichier sera accessible (exposé).

L' depends_on option n’est pas prise en charge sur app service et sera ignorée. À l'instar de la recommandation de Docker concernant le contrôle du démarrage et de l'arrêt, les applications App Service Multi-container doivent vérifier les dépendances par le biais du code de l'application, tant au démarrage qu'à la déconnexion. L'exemple de code ci-dessous montre une application Python vérifiant si un conteneur Redis est en cours d'exécution.

import time
import redis
from flask import Flask
app = Flask(__name__)
cache = redis.Redis(host='redis', port=6379)
def get_hit_count():
    retries = 5
    while True:
        try:
            return cache.incr('hits')
        except redis.exceptions.ConnectionError as exc:
            if retries == 0:
                raise exc
            retries -= 1
            time.sleep(0.5)
@app.route('/')
def hello():
    count = get_hit_count()
    return 'Hello from Azure App Service team! I have been seen {} times.\n'.format(count)
if __name__ == "__main__":
    app.run(host="0.0.0.0", port=80, debug=True)

Web Sockets

Les Web Sockets sont pris en charge sur les applications Linux. Le webSocketsEnabled paramètre ARM ne s’applique pas aux applications Linux, car les sockets Web sont toujours activés pour Linux.

La tarification varie en fonction de la référence SKU et de la région, mais vous pouvez voir plus de détails dans notre page de tarification : Tarification d’App Service.

Lorsqu’Azure App Services démarre votre conteneur, la demande de préparation envoie une requête HTTP au point de terminaison robots933456.txt de votre application. Il s’agit simplement d’un point de terminaison factice, mais votre application doit répondre avec n’importe quel code d’état autre que 5XX. Si votre logique d’application ne répond pas avec un code d’état HTTP à des points de terminaison inexistants, la demande de préparation ne peut pas recevoir de réponse et elle redémarre perpétuellement votre conteneur. La demande de préparation peut également échouer en raison d’une configuration incorrecte du port.

Pour vous assurer que le port est correctement configuré sur Azure App Services, consultez la question Comment faire spécifier le port dans mon conteneur Linux ?

La demande de préparation par défaut échoue après une attente de 240 secondes d’une réponse du conteneur. Vous pouvez augmenter le délai d’expiration de la demande de préparation de conteneur en ajoutant le paramètre d’application WEBSITES_CONTAINER_START_TIME_LIMIT avec une valeur comprise entre 240 et 1 800 secondes.

Le système de fichiers de votre application est un partage réseau monté. Cela rend possibles les scénarios de scale-out dans lesquels votre code doit être exécuté sur plusieurs hôtes. Malheureusement, cela bloque l’utilisation de fournisseurs de bases de données basés sur des fichiers comme SQLite, car il n’est pas possible d’acquérir des verrous exclusifs sur le fichier de base de données. Nous recommandons un service de base de données géré : Azure SQL, Azure Database pour MySQL ou Azure Database pour PostgreSQL

Vous pouvez utiliser uniquement des lettres (A-Z, a-z), des chiffres (0-9) et le trait de soulignement (_) comme paramètres d’application.

Vous pouvez proposer votre idée sur le Forum de commentaires pour Web Apps. Ajoutez « [Linux] » au titre de votre idée.

Prochaines étapes

• Qu’est-ce qu’Azure App Service sur Linux ?
• Configurer des environnements de préproduction dans Azure App Service
• Déploiement continu avec Web App pour conteneurs
• Éléments à connaître : Web Apps et Linux
• Informations de référence sur les variables d’environnement et les paramètres d’application

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.