Niveau de journal
Ce document expliquera comment vous pouvez exploiter la puissance des variables dans le serveur web Apache et dans les fichiers de configuration du module du dispatcher.
??Précédent Présentation du cache
Variables
Les variables sont prises en charge par Apache et à compter de la version 4.1.9 du module du répartiteur.
Nous pouvons les utiliser pour accomplir de nombreuses tâches comme :
- S’assurer que tout ce qui est spécifique à l’environnement n’est pas en ligne dans les configurations, mais extrait afin que les fichiers de configuration du développement fonctionnent en production avec le même résultat fonctionnel.
- Basculer les fonctions et modifier les niveaux de journal des fichiers immuables qu’AMS fournit et ne vous laissera pas modifier.
- Modifier les inclusions à utiliser en fonction de variables comme RUNMODE et ENV_TYPE.
- Faire correspondre les noms DNS DocumentRoot et VirtualHost entre les configurations Apache et celles du module.
Utilisation des variables de la ligne de base
Comme les fichiers de la ligne de base AMS sont en lecture seule et immuables, certaines fonctions peuvent être activées, désactivées et configurées en modifiant les variables qu’elles utilisent.
Variables de référence prêtes à l’emploi et configurables
Toutes les variables prêtes à l’emploi sont définies dans /etc/httpd/conf.d/variables/ootb.vars et assurez-vous qu’une valeur par défaut est définie pour toutes les variables de référence. Une fois les valeurs par défaut chargées, les autres fichiers .vars remplacent les valeurs définies dans le fichier ootb.vars.
L’une des variables du fichier ootb.vars que vous souhaitez modifier et ajuster dans le fichier modifiable /etc/httpd/conf.d/variables/ams_default.vars.
Voici un exemple de certaines variables :
Define DISP_LOG_LEVEL info Define AUTHOR_WHITELIST_ENABLED 0 Define PUBLISH_WHITELIST_ENABLED 0 Define AUTHOR_FORCE_SSL 1 Define PUBLISH_FORCE_SSL 1
Exemple 1 - Forcer le SSL
Les variables affichées ci-dessus AUTHOR_FORCE_SSL ou PUBLISH_FORCE_SSL peuvent être définies sur 1 pour activer les règles de réécriture qui forcent les utilisateurs finaux à être redirigés vers du HTTPS lorsqu’ils entrent une requête HTTP
Voici la syntaxe du fichier de configuration qui permet à cette activation de fonctionner :
</VirtualHost *:80> <IfModule mod_rewrite.c> ReWriteEngine on <If "${PUBLISH_FORCE_SSL} == 1"> Include /etc/httpd/conf.d/rewrites/forcessl_rewrite.rules </If> </IfModule> </VirtualHost>
Comme vous pouvez le constater, l’inclusion des règles de réécriture correspond au contenu du code permettant de rediriger le navigateur des utilisateurs finaux, mais la variable définie sur 1 est ce qui permet ou non l’utilisation du fichier
Exemple 2 - Niveau de journalisation
Les variables DISP_LOG_LEVEL peuvent être utilisées pour définir ce que vous souhaitez avoir concernant le niveau de journal réellement utilisé dans la configuration en cours.
Voici l’exemple de syntaxe qui existe dans les fichiers de configuration de la ligne de base AMS :
<IfModule disp_apache2.c> DispatcherLog logs/dispatcher.log DispatcherLogLevel ${DISP_LOG_LEVEL} </IfModule>
Si vous avez besoin d’augmenter le niveau de journalisation du répartiteur, mettez à jour la variable ams_default.vars DISP_LOG_LEVEL au niveau souhaité.
Les valeurs d’exemple peuvent être un entier ou un mot :
|
Valeur - Nombre entier |
Valeur - Mot |
---|---|---|
Vectoriser |
4 |
trace |
Déboguer |
3 |
debug |
Informations |
2 |
info |
Avertissement |
1 |
warn |
Erreur |
0 |
error |
Exemple 3 - Listes blanches
Les variables AUTHOR_WHITELIST_ENABLED et PUBLISH_WHITELIST_ENABLED peuvent être définies sur 1 pour activer des règles de réécriture qui incluent des règles permettant d’autoriser ou non le trafic de l’utilisateur final en fonction de son adresse IP. L’activation de cette fonction doit être associée à la création et à l’inclusion d’un fichier de règles de liste blanche.
Voici quelques exemples de syntaxe illustrant comment la variable active l’inclusion des fichiers de la liste blanche et un exemple de fichier de la liste blanche.
sample.vhost :
<VirtualHost *:80> <Directory /> <If "${AUTHOR_WHITELIST_ENABLED} == 1"> Include /etc/httpd/conf.d/whitelists/*_whitelist.rules </If> </Directory> </VirtualHost>
sample_whitelist.rules :
<RequireAny> Require ip 10.43.0.10/24 </RequireAny>
Comme vous pouvez le constater, le fichier sample_whitelist.rules applique la restriction sur les adresses IP. Par contre, l’activation de la variable lui permet d’être incluse dans le fichier sample.vhost
Exemple 4 - niveau du fichier Stat
La variable DEFAULT_STAT_LEVEL peut être définie sur un nombre qui permettra à chaque ferme qui utilise cette variable de connaître le nombre de répertoires à créer en profondeur.fichiers stat lors du vidage du cache
ams_defaults.vars :
Define DEFAULT_STAT_LEVEL 7
Chaque ferme qui utilise cette variable définit désormais son niveau de fichier stat sur 7. C’est vraiment bien que ce paramètre de configuration globale s’applique facilement à plusieurs fermes. Voici un exemple de section d’un fichier de ferme dans laquelle il utilise la variable.
002_ams_publish_farm.any :
/publishfarm { /cache { /statfileslevel "${DEFAULT_STAT_LEVEL}" } }
Où placer les variables
Arguments de démarrage du serveur web
AMS intégrera des variables globales aux arguments de démarrage du processus Apache dans le fichier /etc/sysconfig/httpd.
Ce fichier contient des variables prédéfinies comme celles illustrées ci-dessous :
AUTHOR_IP="10.43.0.59" AUTHOR_PORT="4502" AUTHOR_DOCROOT='/mnt/var/www/author' PUBLISH_IP="10.43.0.20" PUBLISH_PORT="4503" PUBLISH_DOCROOT='/mnt/var/www/html' ENV_TYPE='dev' RUNMODE='dev'
Elles ne peuvent pas être modifiées, mais vous pouvez les utiliser dans vos fichiers de configuration
Comme ce fichier est inclus uniquement lorsque le service démarre, un redémarrage du service est nécessaire pour récupérer les modifications. Ce qui veut dire qu’une recharge n’est pas suffisante comparée à un redémarrage
Fichiers de variables (.vars)
Les variables personnalisées fournies par votre code doivent se trouver dans des fichiers .vars dans le répertoire /etc/httpd/conf.d/variables/.
Ces fichiers peuvent avoir toutes les variables personnalisées que vous souhaitez. Vous trouverez quelques modèles de syntaxe dans les exemples de fichiers suivants :
/etc/httpd/conf.d/variables/weretail_domains_dev.vars:
Define WERETAIL_DOMAIN dev.weretail.com Define WERETAIL_ALT_DOMAIN dev.weretail.net
/etc/httpd/conf.d/variables/weretail_domains_stage.vars:
Define WERETAIL_DOMAIN stage.weretail.com Define WERETAIL_ALT_DOMAIN stage.weretail.net
/etc/httpd/conf.d/variables/weretail_domains_prod.vars:
Define WERETAIL_DOMAIN www.weretail.com Define WERETAIL_ALT_DOMAIN www..weretail.net
Lors de la création de vos propres fichiers de variables, nommez-les en fonction de leur contenu et en suivant les normes d’appellation fournies dans le manuel ici. Dans l’exemple ci-dessus, le fichier de variables contient les différentes entrées DNS en tant que variables à utiliser dans les fichiers de configuration.
Utilisation des variables
Maintenant que vous avez défini vos variables dans vos fichiers de variables, il est important de savoir comment les utiliser correctement dans vos autres fichiers de configuration.
Nous utiliserons les fichiers .vars d’exemple ci-dessus pour illustrer un cas d’utilisation conforme.
Nous voulons inclure toutes les variables basées sur l’environnement de façon globale. Nous allons créer le fichier /etc/httpd/conf.d/000_load_env_vars.conf
Include /etc/httpd/conf.d/variables/*_${ENV_TYPE}.vars Include /etc/httpd/conf.d/variables/*_${RUNMODE}.vars
Lorsque le service httpd démarre, il extrait les variables définies par AMS dans /etc/sysconfig/httpd et possède les jeux de variables ENV_TYPE et RUNMODE.
Ce fichier .conf global sera importé rapidement car l’ordre d’inclusion des fichiers dans conf.d est un ordre de chargement alphanumérique, où 000 dans le nom du fichier assure qu’il se charge avant les autres fichiers du répertoire.
L’instruction d’inclusion utilise également une variable dans le nom du fichier.Cela peut modifier le fichier qu’il chargera réellement en fonction de la valeur des variables ENV_TYPE et RUNMODE.
Si la valeur ENV_TYPE est dev, alors le fichier utilisé est :
/etc/httpd/conf.d/variables/weretail_domains_dev.vars
Si la valeur ENV_TYPE est stage, alors le fichier utilisé est :
/etc/httpd/conf.d/variables/weretail_domains_stage.vars
Si la valeur RUNMODE est prévisualisation, alors le fichier utilisé est :
/etc/httpd/conf.d/variables/weretail_domains_preview.vars
Lorsque ce fichier sera inclus, il nous permettra d’utiliser les noms de variables qui ont été enregistrés à l’intérieur.
Dans notre fichier /etc/httpd/conf.d/available_vhosts/weretail.vhost, nous pouvons remplacer la syntaxe normale qui ne fonctionnait que pour dev :
<VirtualHost *:80> ServerName dev.weretail.com ServerAlias dev.weretail.net
Avec une syntaxe plus récente qui utilise la puissance des variables pour dev, évaluation et prod :
<VirtualHost *:80> ServerName ${WERETAIL_DOMAIN} ServerAlias ${WERETAIL_ALT_DOMAIN}
Dans notre fichier /etc/httpd/conf.dispatcher.d/vhosts/weretail_vhosts.any, nous pouvons remplacer la syntaxe normale qui ne fonctionnait que pour dev :
"dev.weretail.com" "dev.weretail.net"
Avec une syntaxe plus récente qui utilise la puissance des variables pour dev, évaluation et prod :
"${WERETAIL_DOMAIN}" "${WERETAIL_ALT_DOMAIN}"
Ces variables peuvent être réutilisées massivement pour personnaliser les paramètres d’exécution sans avoir à déployer des fichiers différents par environnement. Vous pouvez simplement créer des modèles pour vos fichiers de configuration à l’aide de variables et inclure des fichiers basés sur des variables.
Suivant ➡ Purge
Adobe
Recevez de l’aide plus rapidement et plus facilement
Nouvel utilisateur ?