Déployer des fichiers statiques web

  • Article

Remarque

Les plans Essentiel, Standard et Entreprise seront déconseillés à compter de la mi-mars 2025, avec une période de mise hors service de trois ans. Nous vous recommandons de passer à Azure Container Apps. Pour plus d’informations, consultez l’annonce concernant la mise hors service d’Azure Spring Apps.

La consommation Standard et le plan dédié seront déconseillés à compter du 30 septembre 2024, avec un arrêt complet six mois après. Nous vous recommandons de passer à Azure Container Apps. Pour plus d’informations, consultez Migrer la consommation Standard et le plan dédié Azure Spring Apps vers Azure Container Apps.

Cet article s’applique à :❌ De base/Standard ✔️ Entreprise

Cet article explique comment déployer vos fichiers statiques sur une instance de plan Azure Spring Apps Entreprise à l’aide du buildpack Tanzu Web Servers. Cette approche est utile si vous avez des applications qui sont strictement destinées à contenir des fichiers statiques tels que HTML ou CSS, ou des applications front-end créées avec l’infrastructure JavaScript de votre choix. Vous pouvez déployer directement ces applications avec un serveur web configuré automatiquement (HTTPD et NGINX) pour servir ces ressources.

Prérequis

Déployer vos fichiers statiques

Remarque

Cet article se concentre sur la description des configurations de déploiement et sur la résolution des problèmes propres au déploiement de fichiers statiques web. Pour comprendre les scénarios généraux de génération et de déploiement pour le plan Azure Springs Apps Entreprise, consultez la section Créer un service à la demande de l’article Utiliser Tanzu Build Service et le Guide pratique pour déployer des applications polyglottes.

Vous pouvez déployer des fichiers statiques sur Azure Spring Apps en utilisant des serveurs web NGINX ou HTTPD des manières suivantes :

  • Vous pouvez déployer des fichiers statiques directement. Azure Spring Apps configure automatiquement le serveur web spécifié pour servir les fichiers statiques.
  • Vous pouvez créer votre application front-end dans l’infrastructure JavaScript de votre choix, puis déployer votre application front-end dynamique à partir du code source. Azure Spring Apps génère votre application en contenu statique, et utilise votre serveur web configuré pour servir les fichiers statiques.

Vous pouvez également créer un fichier de configuration de serveur pour personnaliser le serveur web.

Exemples de déploiement

Les exemples Azure CLI de cette section montrent la génération et le déploiement de fichiers statiques pour deux scénarios de registre de conteneurs :

  • Registre de conteneurs Azure Spring Apps géré.
  • Registre de conteneurs géré par l’utilisateur.

Générer et déployer des fichiers statiques directement

Cet exemple déploie des fichiers statiques directement à l’aide d’un fichier de configuration de serveur par défaut généré automatiquement.

La commande suivante déploie un fichier statique :

az spring app deploy
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <app-name> \
    --source-path <path-to-source-code> \
    --build-env BP_WEB_SERVER=nginx

Pour plus d’informations sur l’utilisation de variables d’environnement, consultez la section Configurer un fichier de configuration de serveur généré automatiquement.

Générer et déployer votre application front-end en tant que contenu statique

Cet exemple déploie une application front-end dynamique à partir du code source.

La commande suivante déploie une application :

az spring app deploy \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <app-name> \
    --source-path <path-to-source-code> \
    --build-env BP_WEB_SERVER=nginx BP_NODE_RUN_SCRIPTS=build BP_WEB_SERVER_ROOT=build

Générer et déployer des fichiers statiques à l’aide d’un fichier de configuration personnalisé

Cet exemple déploie des fichiers statiques à l’aide d’un fichier de configuration de serveur personnalisé.

La commande suivante déploie une application :

az spring app deploy \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <app-name> \
    --source-path <path-to-source-code>

Pour plus d’informations, consultez la section Utiliser un fichier de configuration de serveur personnalisé de cet article.

Exemple de code

Remarque

L’exemple de code est géré par la communauté open source Paketo.

Les exemples de buildpacks Paketo illustrent des cas d’usage courants pour plusieurs types d’applications différents, notamment les cas d’usage suivants :

  • Servir les fichiers statiques avec un fichier de configuration de serveur par défaut avec BP_WEB_SERVER pour sélectionner HTTPD ou NGINX.
  • Utilisation de Node Package Manager (NPM) pour générer une application React en fichiers statiques qui peuvent être servis par un serveur web. Utiliser les étapes suivantes :
    1. Définissez un script sous la propriété scripts du fichier package.json qui génère vos ressources statiques prêtes pour la production. Pour React, il s’agit de build.
    2. Découvrez où les ressources statiques sont stockées après l’exécution du script de build. Pour React, les ressources statiques sont stockées dans ./build par défaut.
    3. Définissez BP_NODE_RUN_SCRIPTS sur le nom du script de build.
    4. Définissez BP_WEB_SERVER_ROOT sur le répertoire de sortie de build.
  • Servir les fichiers statiques avec votre propre fichier de configuration de serveur en utilisant HTTPD ou NGINX.

Configurer un fichier de configuration de serveur généré automatiquement

Vous pouvez utiliser des variables d’environnement pour modifier le fichier de configuration de serveur généré automatiquement. Le tableau suivant montre les variables d’environnement prises en charge.

Variable d’environnement Valeur prise en charge Description
BP_WEB_SERVER nginx ou httpd Spécifie le type de serveur web, nginx pour Nginx ou httpd pour Apache HTTP Server. Obligatoire lors de l’utilisation du fichier de configuration de serveur généré automatiquement.
BP_WEB_SERVER_ROOT Chemin de fichier absolu ou chemin de fichier relatif à /workspace. Définit le répertoire racine des fichiers statiques. Par défaut, il s’agit de public.
BP_WEB_SERVER_ENABLE_PUSH_STATE true ou false Active le routage d’état push pour votre application. Quelle que soit la route demandée, index.html est toujours servi. Utile pour les applications web monopages.
BP_WEB_SERVER_FORCE_HTTPS true ou false Applique HTTPS pour les connexions de serveur en redirigeant toutes les demandes d’utilisation du protocole HTTPS.

Les variables d’environnement suivantes ne sont pas prises en charge.

  • BP_LIVE_RELOAD_ENABLED
  • BP_NGINX_VERSION
  • BP_HTTPD_VERSION

Utiliser un fichier de configuration de serveur personnalisé

Vous pouvez configurer un serveur web à l’aide d’un fichier de configuration de serveur personnalisé. Le tableau suivant montre le chemin du fichier de configuration :

Serveur web Chemin du fichier de configuration par défaut Comment personnaliser le chemin du fichier de configuration de serveur
nginx nginx.conf sous le chemin racine de votre code source. Utilisez la variable d’environnement BP_NGINX_CONF_LOCATION pour spécifier le nom du fichier de configuration. Placez le fichier sous le chemin racine de votre code source.
httpd httpd.conf sous le chemin racine de votre code source. Non pris en charge.

Votre fichier de configuration doit être conforme aux restrictions décrites dans le tableau suivant.

Configuration Description Configuration de Nginx Configuration de Httpd
Port d’écoute Le serveur web doit écouter sur le port 8080. Le service vérifie la disponibilité et l’activité du port TCP. Vous devez utiliser la variable modèle PORT dans le fichier de configuration. Le numéro de port approprié est injecté lors du lancement du serveur web. listen {{PORT}} Listen "${PORT}"
chemin du journal Chemin du journal de configuration de la console. access_log /dev/stdout, error_log stderr ErrorLog /proc/self/fd/2
Chemin du fichier avec autorisation en écriture Le serveur web reçoit l’autorisation en écriture sur le répertoire /tmp. La configuration du chemin complet demande une autorisation en écriture sous le répertoire /tmp. Par exemple : client_body_temp_path /tmp/client_body_temp
Taille maximale acceptée du corps de la demande cliente Le serveur web se trouve derrière la passerelle. La taille maximale acceptée du corps de la requête cliente est définie sur 500 m dans la passerelle, tandis que la valeur pour le serveur web doit être inférieure à 500 m. client_max_body_size doit être inférieur à 500 m. LimitRequestBody doit être inférieur à 500 m.

Liaisons des Buildpacks

Le déploiement de fichiers statiques sur le plan Azure Spring Apps Entreprise prend en charge la liaison de buildpack Dynatrace. La liaison de buildpack htpasswd n’est pas prise en charge.

Pour plus d’informations, consultez Comment configurer l’intégration APM et les certificats d’autorité de certification.

Erreurs courantes de génération et de déploiement

Votre déploiement de fichiers statiques sur une instance Azure Spring Apps Entreprise peut générer les erreurs de build courantes suivantes :

  • ERROR: No buildpack groups passed detection.
  • ERROR: Please check that you're running against the correct path.
  • ERROR: failed to detect: no buildpacks participating

La cause racine de ces erreurs est que le type de serveur web n’est pas spécifié. Pour résoudre ces erreurs, définissez la variable d’environnement BP_WEB_SERVER sur nginx ou httpd.

Le tableau suivant décrit les erreurs de déploiement courantes lorsque vous déployez des fichiers statiques sur Azure Spring Apps Entreprise.

Message d’erreur Origine Solution
112404: Exit code 0: purposely stopped, please refer to https://aka.ms/exitcode Le serveur web n’a pas pu démarrer. Validez votre fichier de configuration de serveur pour voir s’il existe une erreur de configuration. Vérifiez ensuite si votre fichier de configuration est conforme aux restrictions décrites dans la section Utiliser un fichier de configuration de serveur personnalisé.
mkdir() "/var/client_body_temp" failed (13: Permission denied) Le serveur web n’a pas d’autorisation en écriture sur le chemin spécifié. Configurez le chemin sous le répertoire /tmp ; par exemple : /tmp/client_body_temp.

Étapes suivantes