FAQ sur Azure App Service sur Linux

Vous trouverez tous les fichiers Docker sur GitHub.

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

Cette action est identique à un redémarrage Docker.

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

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

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

Oui.

Oui, vous devez définir un paramètre d’application appelé WEBSITE_WEBDEPLOY_USE_SCMsur false.

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

• Utiliser 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 Guide pratique pour configurer la livraison continue pour l’application web Linux.

• Utiliser l’API de déploiement ZIP : pour utiliser cette API, connectez-vous ssh à votre application web et accédez au dossier dans lequel vous souhaitez déployer votre code. Exécutez le code suivant :

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

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

Oui, désactivez-la perMessageDeflate dans votre code de 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, pendant 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 Kudu déclenche ensuite une installation de compositeur.

Oui, cette fonctionnalité est disponible à partir d’Azure CLI. Vous pouvez utiliser des identités affectées par le système ou par l’utilisateur . Cette fonctionnalité n’est actuellement pas prise en charge dans le Portail Azure.

Si WEBSITES_ENABLE_APP_SERVICE_STORAGE le paramètre n’est pas spécifié ou défini sur false, le /home/ répertoire n’est pas partagé entre les instances d’échelle et les fichiers écrits ne sont pas conservés pendant les redémarrages. La définition WEBSITES_ENABLE_APP_SERVICE_STORAGE explicite de la valeur true active le montage. Une fois que cette valeur est définie sur true, si vous souhaitez désactiver le montage, vous devez explicitement définir sur WEBSITES_ENABLE_APP_SERVICE_STORAGEfalse.

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. Il est géré 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 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 des données en dehors du /home répertoire ou d’un chemin de 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 répertoire ou byOS /home (Bring Your Own Storage), cela entraîne des échecs de démarrage ou des exceptions d’exécution une fois la limite d’espace disque de l’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 de App Service, car l’espace disque hôte est fixe et partagé entre tous les conteneurs du plan App Service.

Vous pouvez configurer la durée d’attente de la plateforme avant de redémarrer votre conteneur. Pour ce faire, définissez le WEBSITES_CONTAINER_START_TIME_LIMIT paramètre d’application sur la valeur souhaitée. La valeur par défaut est 230 secondes et la valeur maximale est 1800 secondes.

Fournissez l’URL complète du Registre, y compris http:// ou https://.

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

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

Oui, apportez votre propre stockage en préversion.

Le site SCM s’exécute dans un conteneur distinct. Vous ne pouvez pas case activée le système de fichiers ou exécuter des processus du conteneur d’application.

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

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

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

Pour utiliser ACR avec plusieurs conteneurs, toutes les images conteneur doivent être hébergées sur le même serveur de registre ACR. Une fois qu’ils se trouvent sur le même serveur de Registre, vous devez créer des paramètres d’application, puis mettre à jour le fichier de configuration Docker Compose pour inclure 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, par exemple : https://<server-name>.azurecr.io)
• DOCKER_REGISTRY_SERVER_PASSWORD (activer 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 pour l’accès
• Seuls les ports 80 et 8080 sont accessibles (ports exposés)

Voici les règles permettant de déterminer quel conteneur est accessible, dans l’ordre de priorité :

• WEBSITES_WEB_CONTAINER_NAME Paramètre d’application défini sur le nom du conteneur
• Premier conteneur à définir le port 80 ou 8080
• Si aucune des valeurs ci-dessus n’est vraie, le premier conteneur défini dans le fichier est accessible (exposé)

L’option depends_onn’est pas prise en charge sur App Service et elle sera ignorée. Tout comme la recommandation de contrôle de démarrage et d’arrêt de Docker, App Service applications multiconteneur doit case activée dépendances via le code de l’application, à la fois au démarrage et à la déconnexion. L’exemple de code ci-dessous montre une application Python qui vérifie 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 web sockets sont toujours activés pour Linux.

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

Lorsque Azure App Services démarre votre conteneur, la demande de préchauffement 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 tout code de status non-5XX. Si votre logique d’application ne répond pas avec du code de status HTTP à des points de terminaison inexistants, la demande de préchauffement ne peut pas recevoir de réponse et redémarre perpétuellement votre conteneur. La demande de préchauffement 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échauffement par défaut échoue après 240 secondes d’attente d’une réponse du conteneur. Vous pouvez augmenter le délai d’expiration de la demande de préchauffement du conteneur en ajoutant le paramètre WEBSITES_CONTAINER_START_TIME_LIMIT d’application 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 permet des scénarios de scale-out où votre code doit être exécuté sur plusieurs hôtes. Malheureusement, cela bloque l’utilisation de fournisseurs de base 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 managé : 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 (_) pour les paramètres de l’application.

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

Étapes suivantes

• Qu’est-ce que Azure App Service sur Linux ?
• Configurer des environnements intermédiaires dans Azure App Service
• Déploiement continu avec Web App pour conteneurs
• Ce que vous devez savoir : 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.