Déployer des fichiers statiques web

  • Article

Remarque

Azure Spring Apps est le nouveau nom du service Azure Spring Cloud. Bien que le service ait un nouveau nom, vous verrez l’ancien nom à divers endroits pendant un certain temps, car nous travaillons à mettre à jour les ressources telles que les captures d’écran, les vidéos et les diagrammes.

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 Enterprise à l’aide du buildpack Tanzu Web Servers. Cette approche est utile si vous avez des applications qui sont purement destinées à contenir des fichiers statiques tels que HTML, 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 la résolution des problèmes spécifiques 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 Enterprise, consultez la section Build service on demand of Use Tanzu Build Service and How to deploy polyglot apps.

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 frontale dans l’infrastructure JavaScript de votre choix, puis déployer votre application frontale dynamique à partir du code source. Azure Spring Apps crée 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 managé Azure Spring Apps.
  • 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.

Créer et déployer votre application frontale en tant que contenu statique

Cet exemple déploie une application frontale 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.
  • À l’aide de Node Gestionnaire de package pour générer une application React dans des fichiers statiques qu’un serveur web peut servir. Procédez comme suit :
    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 du 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 du 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 d’accès du fichier de configuration par défaut Comment personnaliser le chemin du fichier de configuration du serveur
nginx nginx.conf sous le chemin racine de votre code source. Utilisez la variable BP_NGINX_CONF_LOCATION d’environnement 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 du corps accepté de la demande cliente est définie sur 500 m dans la passerelle et la valeur du 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 dans le plan Azure Spring Apps Enterprise 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 Enterprise peut générer les erreurs de génération 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 Enterprise.

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. Ensuite, case activée 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