# 2. Configuration de HAProxy > Syntaxe des fichiers, guillemets, variables, conditions, formats horaires et de taille, adresses et exemples --- Index LLMS : [llms.txt](/fr/llms.txt) --- ## 2.1. Format du fichier de configuration {#section-2-1} Le processus de configuration d'HAProxy repose sur 3 sources majeures de paramètres : - les arguments en ligne de commande, qui ont toujours la priorité - le(s) fichier(s) de configuration, dont le format est décrit ici - l'environnement du processus en cours d'exécution, en cas de référence explicite à certaines variables d'environnement Le fichier de configuration suit un format hiérarchique assez simple qui obéit à quelques règles fondamentales : ```text 1. a configuration file is an ordered sequence of statements 2. a statement is a single non-empty line before any unprotected "#" (hash) 3. a line is a series of tokens or "words" delimited by unprotected spaces or tab characters 4. the first word or sequence of words of a line is one of the keywords or keyword sequences listed in this document 5. all other words are all arguments of the first one, some being well-known keywords listed in this document, others being values, references to other parts of the configuration, or expressions 6. certain keywords delimit a section inside which only a subset of keywords are supported 7. a section ends at the end of a file or on a special keyword starting a new section ``` C’est tout ce qu’il faut savoir pour écrire un générateur de configuration simple mais fiable, mais cela ne suffit pas à analyser de manière fiable n’importe quelle configuration ni à déterminer comment traiter certains cas limites. Tout d'abord, plusieurs conséquences découlent des règles ci-dessus. La règle 6 et la règle 7 impliquent que les mots-clés utilisés pour définir une nouvelle section sont valables partout et ne peuvent avoir une signification différente dans une section spécifique. Ces mots-clés sont toujours un seul mot (contrairement à une suite de mots), et la section qui suit traditionnellement porte le même nom. Par exemple, lorsqu'on parle de la « section global », cela désigne la section de configuration qui suit le mot-clé « global ». Cette convention est fréquemment utilisée dans les messages d'erreur afin d'aider à localiser les parties à corriger. Plusieurs sections créent un objet interne ou un espace de configuration, qui doit être distingué des autres. Dans ce cas, elles incluent un mot supplémentaire définissant le nom de cette section particulière. Pour certaines d'entre elles, le nom de section est obligatoire. Par exemple, « frontend foo » crée une nouvelle section de type « frontend » nommée « foo ». En général, un nom est spécifique à sa section, et deux sections de types différents peuvent utiliser le même nom, mais cela n'est pas recommandé car cela complique la gestion de la configuration. Une conséquence directe de la règle 7 est que, lorsqu’un nombre de fichiers est lu simultanément, chacun d’eux doit commencer par une nouvelle section, et la fin de chaque fichier marque la fin d’une section. Un fichier ne peut pas contenir de sous-sections ni terminer une section existante tout en en commençant une nouvelle. Règle 1 indique que l'ordre a de l'importance. En effet, certains mots-clés créent des directives pouvant être répétées plusieurs fois afin de former des séquences ordonnées de règles à appliquer dans un ordre précis. Par exemple, « tcp-request » peut être utilisé pour alterner des règles « accept » et « reject » selon des critères variés. En conséquence, un processeur de fichier de configuration doit toujours conserver l'ordre d'une section lors de l'édition d'un fichier. L'ordre des sections ne compte généralement pas, sauf pour la section globale, qui doit être placée avant les autres sections, bien qu'elle puisse être répétée si nécessaire. En outre, certains identifiants automatiques peuvent être attribués automatiquement à certains objets créés (par exemple, des proxies), et en réorganisant les sections, leurs identifiants changeront. Ces identifiants apparaissent par exemple dans les statistiques. Ainsi, la configuration ci-dessous attribuera à « foo » un numéro d'identifiant inférieur à celui de son homologue « bar ». Cet ordre sera inversé si les deux sections sont échangées : ```text listen foo bind:80 listen bar bind:81 ``` Un autre point important est que, conformément aux règles 2 et 3 ci-dessus, les lignes vides, espaces, tabulations et commentaires suivant le caractère non protégé "#" ne font pas partie de la configuration, car ils ne servent qu’à délimiter les éléments. Cela implique que les configurations suivantes sont strictement équivalentes : ```text global#this is the global section daemon#daemonize frontend foo mode http # or tcp ``` et : ```shell global daemon # this is the public web frontend frontend foo mode http ``` La pratique courante consiste à aligner à gauche uniquement le mot-clé qui introduit une nouvelle section, et à insérer des espaces (c’est-à-dire préfixer un caractère de tabulation ou quelques espaces) pour les autres mots-clés afin qu’il soit immédiatement visible qu’ils appartiennent à la même section (comme dans l’exemple ci-dessus). Placer des commentaires avant une nouvelle section aide le lecteur à déterminer s’il s’agit de la section souhaitée. Laisser une ligne vide à la fin d’une section aide également visuellement à repérer sa fin lors de son édition. Les tabulations sont très pratiques pour la mise en retrait, mais elles ne se copient pas bien. Si l’on utilise des espaces à la place, il est recommandé d’en éviter un trop grand nombre (de 2 à 4) afin que l’édition dans le champ ne devienne pas une contrainte avec les éditeurs limités ne prenant pas en charge l’indentation automatique. Dans les premiers temps, il était courant de voir les arguments séparés à des positions de tabulation fixes, car la plupart des mots-clés ne prenaient pas plus de deux arguments. Avec les versions modernes, qui intègrent des expressions complexes, cette pratique n’est plus valable et n’est pas recommandée. ## 2.2. Citation et échappement {#section-2-2} Dans les configurations modernes, certains arguments exigent l'utilisation de caractères qui étaient auparavant considérés comme des délimiteurs purs. Afin de rendre cela possible, HAProxy prend en charge l'échappement des caractères en préfixant le caractère à échapper d'une barre oblique inverse ('\'), la citation faible en entourant un morceau de texte de guillemets doubles ("") et la citation forte en entourant un morceau de texte de guillemets simples (''). Cela ressemble fortement à ce qui est fait dans plusieurs langages de programmation et est très proche de ce qu’on rencontre couramment dans le shell Bourne. Le principe est le suivant : pendant que le parseur de configuration découpe les lignes en mots, il prend également en compte les guillemets et les barres obliques inversées pour déterminer si un caractère est un séparateur ou la représentation brute de ce caractère dans le mot courant. Lorsque cela est fait, le caractère d’échappement est supprimé, les guillemets sont supprimés, et le mot restant est utilisé tel quel comme mot-clé ou argument, par exemple. Si une barre oblique inverse est nécessaire dans un mot, elle doit soit être échappée en utilisant elle-même (c’est-à-dire une barre oblique inverse en double), soit être fortement citée. La sortie des guillemets est obtenue en précédant un caractère spécial d'un backslash (\): ```text \ to mark a space and differentiate it from a delimiter \# to mark a hash and differentiate it from a comment \\ to use a backslash \' to use a single quote and differentiate it from strong quoting \" to use a double quote and differentiate it from weak quoting ``` En outre, quelques caractères non imprimables peuvent être émis en utilisant leur représentation habituelle en langage C : ```text \n to insert a line feed (LF, character \x0a or ASCII 10 decimal) \r to insert a carriage return (CR, character \x0d or ASCII 13 decimal) \t to insert a tab (character \x09 or ASCII 9 decimal) \xNN to insert character having ASCII code hex NN (e.g \x0a for LF). ``` La citation faible est obtenue en entourant de guillemets doubles ("") le caractère ou la séquence de caractères à protéger. La citation faible empêche l'interprétation de : ```text space or tab as a word separator ' single quote as a strong quoting delimiter ``` ```haproxy # hash as a comment start ``` La citation faible permet l'interprétation des variables d'environnement (qui ne sont pas évaluées en dehors des guillemets) en les précédant d'un signe dollar ('\$'). Si un caractère dollar est nécessaire à l'intérieur de guillemets doubles, il doit être échappé à l'aide d'une barre oblique inverse. Une citation forte est obtenue en entourant les caractères ou la séquence de caractères à protéger de guillemets simples (''). À l'intérieur des guillemets simples, aucun caractère n'est interprété ; il s'agit de la méthode la plus efficace pour citer des expressions régulières. En conséquence, voici la matrice indiquant comment les caractères spéciaux peuvent être saisis dans différents contextes (les caractères non imprimables sont remplacés par leur nom entre chevrons). Notez que certains caractères qui ne peuvent être représentés qu’avec une échappement n’ont aucune représentation possible entre guillemets simples, d’où leur absence dans ce cas : ```text Character | Unquoted | Weakly quoted | Strongly quoted -----------+---------------+-----------------------------+----------------- | \, \x09 | "", "\", "\x09" | '' -----------+---------------+-----------------------------+----------------- | \n, \x0a | "\n", "\x0a" | -----------+---------------+-----------------------------+----------------- | \r, \x0d | "\r", "\x0d" | -----------+---------------+-----------------------------+----------------- | \, \x20 | "", "\", "\x20" | '' -----------+---------------+-----------------------------+----------------- " | \", \x22 | "\"", "\x22" | '"' -----------+---------------+-----------------------------+----------------- # | \#, \x23 | "#", "\#", "\x23" | '#' -----------+---------------+-----------------------------+----------------- $ | $, \$, \x24 | "\$", "\x24" | '$' -----------+---------------+-----------------------------+----------------- ' | \', \x27 | "'", "\'", "\x27" | -----------+---------------+-----------------------------+----------------- \ | \\, \x5c | "\\", "\x5c" | '\' -----------+---------------+-----------------------------+----------------- ``` Exemple : ```shell # those are all strictly equivalent: log-format %{+Q}o\ %t\ %s\ %{-Q}r log-format "%{+Q}o %t %s %{-Q}r" log-format '%{+Q}o %t %s %{-Q}r' log-format "%{+Q}o %t"' %s %{-Q}r' log-format "%{+Q}o %t"' %s'\ %{-Q}r ``` Il existe un cas particulier où une deuxième niveau de citation ou d’échappement peut être nécessaire. Certains mots-clés prennent des arguments entre parenthèses, parfois séparés par des virgules. Ces arguments sont généralement des entiers ou des mots prédéfinis, mais lorsqu’ils sont des chaînes arbitraires, il peut être nécessaire d’effectuer un niveau d’échappement supplémentaire afin de distinguer les caractères appartenant à l’argument de ceux utilisés pour délimiter les arguments eux-mêmes. Un cas assez courant est le convertisseur « regsub ». Il prend une expression régulière en argument, et si une parenthèse fermante est nécessaire à l’intérieur, celle-ci devra être elle-même citée. L'analyseur d'arguments en mot-clé est identique à celui du niveau supérieur en ce qui concerne les guillemets, à ceci près que les séquences d'échappement \#, \\$, et \xNN ne sont pas traitées. Mais ce qui n'est pas toujours évident, c'est que les délimiteurs utilisés à l'intérieur doivent d'abord être échappés ou mis entre guillemets afin qu'ils ne soient pas résolus au niveau supérieur. Prenons cet exemple utilisant le convertisseur « regsub », qui prend trois arguments : une expression régulière, une chaîne de remplacement et un ensemble d'indicateurs : ```shell # replace all occurrences of "foo" with "blah" in the path: http-request set-path %[path,regsub(foo,blah,g)] ``` Ici, aucune citation particulière n'était nécessaire. Mais si nous voulons maintenant remplacer soit « foo » soit « bar » par « blah », nous devrons utiliser l'expression régulière « (foo\|bar) ». Nous ne pouvons pas écrire : ```text http-request set-path %[path,regsub((foo|bar),blah,g)] ``` car nous souhaitons que la chaîne soit coupée de cette manière : ```text http-request set-path %[path,regsub((foo|bar),blah,g)] |---------|----|-| arg1 _/ / / arg2 __________/ / arg3 ______________/ ``` mais en réalité ce qui est transmis est une chaîne entre les parenthèses d'ouverture et de fermeture, suivie de déchets : ```text http-request set-path %[path,regsub((foo|bar),blah,g)] |--------|--------| arg1=(foo|bar _/ / trailing garbage _________/ ``` La solution évidente semble ici être de citer le parenthèse fermante, mais cela ne fonctionnera pas seul, car, comme mentionné ci-dessus, les guillemets sont traités par l'analyseur de niveau supérieur, qui les résout avant le traitement de ce mot : ```text http-request set-path %[path,regsub("(foo|bar)",blah,g)] ------------ -------- ---------------------------------- word1 word2 word3=%[path,regsub((foo|bar),blah,g)] ``` Ainsi, nous n'avons apporté aucune modification au parseur d'arguments au second niveau, qui continue de voir une expression régulière tronquée comme seul argument, ainsi que des données aléatoires à la fin de la chaîne. En échappant les guillemets, ceux-ci seront transmis inchangés au second niveau : ```text http-request set-path %[path,regsub(\"(foo|bar)\",blah,g)] ------------ -------- ------------------------------------ word1 word2 word3=%[path,regsub("(foo|bar)",blah,g)] |---------||----|-| arg1=(foo|bar) _/ / / arg2=blah ___________/ / arg3=g _______________/ ``` Une autre approche consiste à utiliser des guillemets simples à l’extérieur de toute la chaîne et des guillemets doubles à l’intérieur (afin que les guillemets doubles ne soient pas supprimés à nouveau) : ```text http-request set-path '%[path,regsub("(foo|bar)",blah,g)]' ------------ -------- ---------------------------------- word1 word2 word3=%[path,regsub("(foo|bar)",blah,g)] |---------||----|-| arg1=(foo|bar) _/ / / arg2 ___________/ / arg3 _______________/ ``` Mais dans ce cas, il est important de noter que les délimiteurs intégrés dans la chaîne de niveau supérieur restent des caractères purs et ne sont plus des délimiteurs. Cela signifie notamment que les espaces et tabulations autour des virgules font partie de la chaîne. L'exemple ci-dessous est erroné pour plusieurs raisons : ```text http-request set-path '%[path, regsub("(foo|bar)", blah, g)]' ------------ -------- -------------------------------------- word1 word2 word3=%[path, regsub("(foo|bar)", blah, g)] |--------|---------||-----|--| converter=" regsub" _/ / / / arg1=(foo|bar) _/ / / arg2=" blah" ___________/ / arg3=" g" ______________/ ``` Le simple fait d'entourer les virgules d'espaces a fait que ces espaces faisaient partie du champ lui-même, d'où la conversion « regsub » (commençant par un espace), qui ne sera pas trouvée et déclenchera une erreur, mais de manière plus subtile, la chaîne de remplacement « blah » insérera un espace dans la sortie. Une bonne règle générale consiste à ne jamais insérer d'espaces inutiles à l'intérieur des expressions. Lorsque l'on utilise des expressions régulières, il peut arriver que le caractère dollar ('\$') apparaisse dans l'expression ou qu'une barre oblique inverse ('\') soit utilisée dans la chaîne de remplacement. Dans ce cas, celles-ci seront également traitées à l'intérieur des guillemets doubles, d'où la préférence pour les guillemets simples (ou l'échappement double). Exemple : ```text http-request set-path '%[path,regsub("^/(here)(/|$)","my/\1",g)]' ------------ -------- ----------------------------------------- word1 word2 word3=%[path,regsub("^/(here)(/|$)","my/\1",g)] |-------------| |-----||-| arg1=(here)(/|$) _/ / / arg2=my/\1 ________________/ / arg3 ______________________/ ``` Souvenez-vous que les barres obliques inverses ne sont pas des caractères d'échappement entre guillemets simples, et que tout le mot ci-dessus est déjà protégé contre elles grâce aux guillemets simples. À l'inverse, si des guillemets doubles avaient été utilisés autour de l'expression entière, le caractère dollar et les barres obliques auraient été résolus au niveau supérieur, rompant ainsi le contenu de l'argument au second niveau. Malheureusement, comme les guillemets simples ne peuvent pas être échappés à l’intérieur d’une citation forte, si vous devez inclure des guillemets simples dans votre argument, vous devrez les échapper ou les citer deux fois. Il existe plusieurs façons de procéder : ```text http-request set-var(txn.foo) str("\\'foo\\'") http-request set-var(txn.foo) str(\"\'foo\'\") http-request set-var(txn.foo) str(\\\'foo\\\') ``` En cas de doute, il est préférable de ne jamais utiliser de guillemets, puis d’ajouter des guillemets simples ou doubles autour des arguments nécessitant une virgule ou une parenthèse fermante, en envisageant d’échapper ces guillemets à l’aide d’un backslash si la chaîne contient un dollar ou un backslash. Encore une fois, cela ressemble fortement à ce qui est utilisé sous un shell Bourne lorsqu’on échappe deux fois une commande passée à « eval ». Pour les auteurs d’API, la meilleure approche consiste probablement à entourer chaque argument d’un guillemet échappé, quelle que soit sa teneur. Les utilisateurs constateront probablement que l’utilisation de guillemets simples autour de l’expression entière et de guillemets doubles autour de chaque argument rend les configurations plus lisibles. ## 2.3. Variables d'environnement {#section-2-3} La configuration d'HAProxy prend en charge les variables d'environnement. Ces variables ne sont interprétées qu'à l'intérieur de guillemets doubles. Les variables sont étendues pendant l'analyse de la configuration. Les noms de variables doivent être précédés du signe dollar ("\$") et éventuellement entourés d'accolades ("{}"), de manière similaire à ce qui est fait dans le shell Bourne. Les noms de variables peuvent contenir des caractères alphanumériques ou le caractère souligné ("\_"), mais ne doivent pas commencer par un chiffre. Si la variable contient une liste de plusieurs valeurs séparées par des espaces, elle peut être étendue en arguments individuels en entourant la variable d'accolades et en ajoutant le suffixe '[\*]' avant la fermeture de l'accolade. Il est également possible de spécifier une valeur par défaut à utiliser lorsque la variable n'est pas définie, en ajoutant cette valeur après un trait de soulignement '-' à côté du nom de la variable. Notez que la valeur par défaut ne remplace que les variables non définies, pas les variables vides. Exemple : ```text bind "fd@${FD_APP1}" log "${LOCAL_SYSLOG-127.0.0.1}:514" local0 notice # send to local server user "$HAPROXY_USER" ``` Certains variables sont définis par HAProxy, ils peuvent être utilisés dans le fichier de configuration. Ces variables sont listées dans le tableau ci-dessous et sont classées selon quatre catégories : - utilisable : la variable est accessible à partir de la configuration, soit pour être résolue telle quelle, soit utilisée dans des blocs conditionnels ou des prédicats afin d’activer ou de désactiver certains fragments de configuration, comme décrit dans [section 2.4](/fr/docs/haproxy/configuration-basics/#section-2-4) « Blocs conditionnels ». - modifiable : la variable peut être redéfinie ou supprimée dans la configuration via les mots-clés "setenv"/"unsetenv". - répertorié : la variable est répertoriée dans la sortie de la commande CLI "show env", décrite dans la [section 9.3](/fr/docs/haproxy/filters/#section-9-3) "Commandes sockets Unix" du guide de gestion. Il existe également deux sous-catégories, « master » et « worker », marquées respectivement par « M » et « W » dans le tableau ci-dessous, illustrant les différences entre les deux processus lorsque HAProxy est lancé en mode master-worker. - master : la variable est définie et accessible depuis le processus principal. Elle apparaît donc dans la sortie de la commande CLI du processus principal « show env » et peut être utilisée dans des blocs conditionnels ou des directives afin d'activer certaines configurations spéciales pour le processus principal (voir les exemples dans la [section 2.4](/fr/docs/haproxy/configuration-basics/#section-2-4) « Blocs conditionnels »). - worker : la variable est définie et accessible depuis le processus worker. Elle apparaît dans la commande "show env" de l'interface CLI du worker (ou de l'interface CLI principale avec "@1 show env"), et peut également conditionner certains paramètres du processus worker (voir les exemples dans la [section 2.4](/fr/docs/haproxy/configuration-basics/#section-2-4) "Blocs conditionnels"). En mode autonome (sans l'option "-W" ni le mot-clé "master-worker"), le processus se comporte comme un worker, à l'exception des variables "HAPROXY_MASTER_CLI" et "HAPROXY_MWORKER" qui ne sont pas définies. Certains variables sont marqués comme non utilisables et non modifiables : - FICHIERS_DE_CONFIG_HAPROXY - TRAVAILLEUR_M_HAPROXY - CLI_HAPROXY - CLI_PRIMAIRE_HAPROXY - PAIR_LOCAL_HAPROXY Leurs valeurs sont indéfinies pendant l'analyse de la configuration ; elles sont définies ultérieurement lors de l'initialisation. Il est donc recommandé de ne pas utiliser ces variables au sein de blocs conditionnels, ni de les référencer dans les mots-clés "setenv"/"resetenv"/"unsetenv" de la section globale. Le tableau ci-dessous résume l'état de chaque variable pour les différents modes de fonctionnement : ```text +---------------------------+---------+------------+-----------+ | variable | usable | modifiable | listed | | +---------+------------+-----------+ | | M | W | M | W | M | W | +---------------------------+----+----+------+-----+-----+-----+ | HAPROXY_STARTUP_VERSION | X | X | | | X | X | | HAPROXY_BRANCH | X | X | | | X | X | | HAPROXY_CFGFILES | | | | | X | X | | HAPROXY_MWORKER | | | | | X | X | | HAPROXY_CLI | | | | | | X | | HAPROXY_MASTER_CLI | | | | | X | | | HAPROXY_LOCALPEER | | X | | | | X | | HAPROXY_HTTP_LOG_FMT | | X | | X | | | | HAPROXY_HTTP_CLF_LOG_FMT | | X | | X | | | | HAPROXY_HTTPS_LOG_FMT | | X | | X | | | | HAPROXY_TCP_LOG_FMT | | X | | X | | | | HAPROXY_TCP_CLF_LOG_FMT | | X | | X | | | | HAPROXY_KEYLOG_FC_LOG_FMT | | X | | X | | | | HAPROXY_KEYLOG_BC_LOG_FMT | | X | | X | | | +---------------------------+----+----+------+-----+-----+-----+ ``` Les variables en question sont les suivantes : - HAPROXY_LOCALPEER : défini au démarrage du processus et contient le nom de l'homologue local. (Voir "-L" dans le guide d'administration.) - HAPROXY_CFGFILES : liste des fichiers de configuration chargés par HAProxy, séparés par des points-virgules. Peut être utile dans le cas où vous avez spécifié un répertoire. - HAPROXY_HTTP_LOG_FMT : contient la valeur du format de journalisation HTTP par défaut tel qu défini dans la [section 8.2.3](/fr/docs/haproxy/configuration-logging/#section-8-2-3) « Format de journalisation HTTP ». Il peut être utilisé pour remplacer le format de journalisation par défaut sans avoir à copier l'ensemble de la définition originale. - HAPROXY_HTTP_CLF_LOG_FMT : contient la valeur du format de journalisation HTTP CLF par défaut, tel qu défini dans [la section 8.2.3](/fr/docs/haproxy/configuration-logging/#section-8-2-3) « Format de journalisation HTTP ». Il peut être utilisé pour remplacer le format de journalisation par défaut sans avoir à copier toute la définition originale. Exemple : ```shell # Add the rule that gave the final verdict to the log log-format "${HAPROXY_TCP_LOG_FMT} lr=%[last_rule_file]:%[last_rule_line]" ``` - HAPROXY_HTTPS_LOG_FMT : similaire à HAPROXY_HTTP_LOG_FMT mais pour le format des journaux HTTPS tel qu'il est défini dans [section 8.2.4](/fr/docs/haproxy/configuration-logging/#section-8-2-4) "Format des journaux HTTPS". - HAPROXY_TCP_LOG_FMT : similaire à HAPROXY_HTTP_LOG_FMT mais pour le format des journaux TCP tel qu défini dans la [section 8.2.2](/fr/docs/haproxy/configuration-logging/#section-8-2-2) « Format des journaux TCP ». - HAPROXY_TCP_CLF_LOG_FMT : similaire à HAPROXY_HTTP_CLF_LOG_FMT mais pour le format de journalisation TCP CLF tel qu défini dans la [section 8.2.2](/fr/docs/haproxy/configuration-logging/#section-8-2-2) « Format de journalisation TCP ». - HAPROXY_KEYLOG_FC_LOG_FMT : contient le format de journalisation des clés pour la connexion TLS du frontend (face client), avec les entrées de clés séparées par des sauts de ligne, ce qui peut entraîner une incompatibilité avec votre serveur syslog. "tune.ssl.keylog on" est obligatoire. - HAPROXY_KEYLOG_BC_LOG_FMT : similaire à HAPROXY_KEYLOG_FC_LOG_FMT mais destiné à la connexion TLS côté backend (vers le serveur). Les entrées clés sont séparées par des sauts de ligne, ce qui peut entraîner une incompatibilité avec votre serveur syslog. "tune.ssl.keylog on" est obligatoire. - HAPROXY_MWORKER : En mode master-worker, cette variable est définie à 1. - HAPROXY_CLI : adresses des écouteurs configurés pour le socket de statistiques de chaque processus, séparées par des points-virgules. - HAPROXY_MASTER_CLI : En mode master-worker, les adresses des écouteurs de l'interface CLI principale, séparées par des points-virgules. - HAPROXY_STARTUP_VERSION : contient la version utilisée au démarrage, en mode master-worker, il s'agit de la version utilisée pour démarrer le master, même après mise à jour du binaire et rechargement. - HAPROXY_BRANCH : contient la version de branche d'HAProxy (par exemple "2.8"). Il ne contient pas le numéro de version complet. Il peut être utile en cas de migration si les ressources (par exemple des cartes ou des certificats) sont situées dans un chemin contenant le numéro de branche. En outre, certaines variables pseudo sont résolues internement et peuvent être utilisées comme des variables régulières. Les variables pseudo commencent toujours par un point ('.'), et ce sont les seules où l'utilisation du point est autorisée. La liste actuelle des variables pseudo est : - .FICHIER : le nom du fichier de configuration actuellement en cours d'analyse. - .LINE : le numéro de ligne du fichier de configuration actuellement analysé, commençant à un. - .SECTION : le nom de la section actuellement analysée, ou son type si la section n'a pas de nom (par exemple « global »), ou une chaîne vide avant la première section. Ces variables sont résolues à l'emplacement où elles sont analysées. Par exemple, si une variable ".LINE" est utilisée dans une directive « log-format » située dans une section « defaults », son numéro de ligne sera résolu avant l'analyse et la compilation de la directive « log-format », de sorte que ce même numéro de ligne sera réutilisé par les proxies ultérieurs. Ainsi, il est possible d'émettre des informations afin d'aider à localiser une règle dans des variables, des journaux, des états d'erreur, des contrôles d'état, des valeurs d'en-tête, voire d'utiliser des numéros de ligne pour nommer certains objets de configuration, comme des serveurs par exemple. ## 2.4. Blocs conditionnels {#section-2-4} Il peut parfois être pratique de pouvoir activer ou désactiver conditionnellement certaines parties arbitraires de la configuration, par exemple pour activer/désactiver le SSL ou les chiffres, activer ou désactiver certains écouteurs en pré-production sans modifier la configuration, ou ajuster la syntaxe de la configuration pour prendre en charge deux versions distinctes d’HAProxy pendant une migration. HAProxy fournit un ensemble de directives imbriquables du type préprocesseur, permettant d’intégrer ou d’ignorer certains blocs de texte. Ces directives doivent être placées sur une ligne à part et agissent sur les lignes qui les suivent. Deux d’entre elles prennent une expression, les autres ne font que basculer vers un bloc alternatif ou terminer un niveau actuel. Les 4 directives suivantes sont définies pour former des blocs conditionnels : - .si `` - .sinon_si `` - .sinon - .fin_si La directive ".if" introduit un nouveau niveau, ".elif" reste au même niveau, ".else" également, et ".endif" ferme un niveau. Chaque ".if" doit être terminée par une directive ".endif" correspondante. La directive ".elif" ne peut être placée qu'après ".if" ou ".elif", et il n'y a pas de limite au nombre de ".elif" pouvant être enchaînés. Il ne peut y avoir qu'une seule ".else" par ".if" et elle doit toujours être placée après ".if" ou après le dernier ".elif" d'un bloc. Les commentaires peuvent être placés sur la même ligne si nécessaire, après un '#', ils seront ignorés. Les directives sont tokenisées comme les autres directives de configuration, et il est donc possible d'utiliser des variables d'environnement dans les conditions. Les conditions peuvent également être évaluées au démarrage grâce au paramètre -cc. Voir « 3. Démarrage de HAProxy » dans la documentation de gestion. Les conditions sont soit une chaîne vide (qui renvoie alors false), soit une expression composée de toute combinaison de : - l'entier zéro ('0'), retourne toujours « false » - un entier non nul (par exemple '1'), retourne toujours « true ». - une prédicat suivie éventuellement de paramètre(s) entre parenthèses. - une condition placée entre une paire de parenthèses '(' et ')' - un point d'exclamation ('!') placé avant l'un quelconque des éléments ci-dessus non vides, qui inverse son état. - des expressions combinées par une opération ET logique ('&&'), évaluées de gauche à droite jusqu'à ce qu'une retourne « false » - des expressions combinées par une opération OU logique ('\|\|'), évaluées de droite à gauche jusqu'à ce qu'une retourne « true » Le même analyseur de lignes et parseur d'arguments est utilisé que pour le reste du langage de configuration. Les mots sont séparés autour de séries consécutives d'un ou plusieurs espaces ou tabulations non entre guillemets, puis réassemblés en utilisant un seul espace pour les séparer avant évaluation, afin de simplifier la tâche de l'utilisateur qui n'a pas à entourer toute la ligne de guillemets. Toutefois, cela signifie également que les espaces entourant les virgules ou les parenthèses font bien partie de la valeur, ce qui n'est pas toujours attendu. Par exemple, l'expression suivante : ```text .if defined( HAPROXY_MWORKER ) ``` testera l'existence de la variable « HAPROXY_MWORKER » (avec des espaces), et celle-ci : ```text .if streq("$ENABLE_SSL", 1) ``` comparera la variable d'environnement "ENABLE_SSL" à la valeur « 1 » (avec un seul espace initial). La raison est que la ligne est d'abord divisée en mots de cette manière : ```text .if streq("$ENABLE_SSL", 1) |---|--------------------| |--| 1 2 3 ``` puis la citation faible est appliquée et la variable d’environnement "\$ENABLE_SSL" est résolue (par exemple, supposons que ENABLE_SSL=0), avant que les mots ne soient finalement réassemblés en une chaîne unique en insérant un seul espace entre les mots : ```text .if streq(0, 1) |---|-------|--| 1 2 3 ``` et uniquement alors est-il analysé comme une expression unique. L'espace inséré entre la virgule et « 1 » fait toujours partie de la valeur de l'argument, rendant cet argument « 1 » : ```text .if streq(0, 1) |---|-----|-|--| \ \ \ \_ argument2: " 1" \ \ \___ argument1: "0" \ \_______ function: "streq" \___________ directive: ".if" ``` On constate ici que, même si ENABLE_SSL avait été égal à « 1 », il n'aurait pas correspondu à « 1 » car la chaîne aurait différé d'un espace. Note : comme expliqué dans la section « 2.2. Citation et échappement », une bonne règle de base consiste à ne jamais insérer d'espaces inutiles à l'intérieur des expressions. Notez que, comme dans d'autres langages, l'opérateur ET a une priorité supérieure à celle de l'opérateur OU, de sorte que « A && B || C && D » est évalué comme « (A && B) || (C && D) ». La liste des prédicats actuellement pris en charge est la suivante : - awslc_api_atleast(``): retourne true si le numéro actuel de l'API awslc est au moins aussi récent que `` sinon false. Exemple : awslc_api_atleast(35) - awslc_api_before(``): renvoie true si le numéro actuel de l'API awslc est strictement inférieur à `` sinon false. Exemple : awslc_api_before(26) - defined(``) : renvoie true si une variable d'environnement `` existe, quelle que soit sa valeur - feature(``) : renvoie true si la fonction `` est indiquée comme présente dans la liste des fonctions signalées par "haproxy -vv" (ce qui signifie qu'un `` apparaît après un '+') - openssl_version_atleast(``): retourne true si la version actuelle d'OpenSSL est au moins aussi récente que ``, sinon false. Des bibliothèques comme LibreSSL, AWS-LC et WolfSSL fournissent également une version pseudo-OpenSSL. Exemple : ```text ssllib_name_startswith(OpenSSL) && openssl_version_atleast(1.1.1) ``` - openssl_version_before(``): renvoie true si la version OpenSSL actuelle est strictement antérieure à ``, sinon false. Des bibliothèques comme LibreSSL, AWS-LC et WolfSSL fournissent également une version pseudo-OpenSSL. Exemple : openssl_version_before(3.5.0) - ssllib_name_startswith(``) : renvoie true si le nom de la bibliothèque SSL avec laquelle HAProxy a été lié commence par ``. Exemple : ssllib_name_startswith(wolfSSL) - streq(``,``) : renvoie true uniquement si les deux chaînes sont égales - strneq(``,``): renvoie true uniquement si les deux chaînes diffèrent - strstr(``,``): renvoie true uniquement si la deuxième chaîne est trouvée dans la première. - version_atleast(``): renvoie true si la version actuelle de HAProxy est au moins aussi récente que ``, sinon false. La syntaxe des versions est la même que celle affichée par la commande "haproxy -v", et les composantes manquantes sont supposées valoir zéro. - version_before(``): renvoie true si la version actuelle de HAProxy est strictement antérieure à `` sinon false. La syntaxe des versions est identique à celle affichée par la commande "haproxy -v" et les composantes manquantes sont supposées valoir zéro. - enabled(``) : retourne true si l'option `` est activée en cours d'exécution. Seul un sous-ensemble d'options est pris en charge : ```text POLL, EPOLL, KQUEUE, EVPORTS, SPLICE, GETADDRINFO, REUSEPORT, FAST-FORWARD, SERVER-SSL-VERIFY-NONE ``` Exemple : ```haproxy # 1. HAPROXY_MWORKER variable is set automatically by HAProxy in master and # in worker process environments (see HAProxy variables matrix from # 2.3. Environment variables). Its presence enables an additional listener. global master-worker ``` .if defined(HAPROXY_MWORKER) listen mwcli_px bind:1111 ... .endif ```haproxy # 2. HAPROXY_BRANCH is set automatically by HAProxy in master and in worker # process environments (see HAProxy variables matrix from 2.3. Environment # variables). We check HAPROXY_BRANCH value and conditionally enable # mworker-max-reloads parameter. global master-worker ``` .if streq("\$HAPROXY_BRANCH",3.1) mworker-max-reloads 5 .endif ```haproxy # 3. Some arbitrary environment variables are set by user in the global # section. If HAProxy is started in master-worker mode, they are presented in # master and in worker process environments. We check values of these # variables and conditionally enable ports 80 and 443. Environment variables # checks can be mixed with features and version checks. global setenv WITH_SSL yes unsetenv SSL_ONLY ``` .if strneq("\$SSL_ONLY",yes) bind:80 .endif .if streq("\$WITH_SSL",yes) .if feature(OPENSSL) bind:443 ssl crt ... .endif .endif .if feature(OPENSSL) && (streq("$`WITH_SSL",yes) || streq("`$SSL_ONLY",yes)) bind:443 ssl crt ... .endif .if version_atleast(2.4-dev19) profiling.memory on .endif .if !feature(OPENSSL) .alert "SSL support is mandatory" .endif Quatre autres directives sont fournies pour signaler certains états : - .diag "message" : émettre ce message uniquement en mode diagnostic (-dD) - .notice "message" : émettre ce message au niveau NOTICE - .warning "message" : émettre ce message au niveau WARNING - .alert "message" : émettre ce message au niveau ALERT Les messages émis au niveau WARNING peuvent empêcher le démarrage du processus si l'option « zero-warning » est activée. Les messages émis au niveau ALERT provoquent toujours une erreur fatale. Ces messages peuvent être utilisés pour détecter certaines conditions inappropriées et fournir des conseils à l'utilisateur. Exemple : ```text .if "${A}" .if "${B}" .notice "A=1, B=1" .elif "${C}" .notice "A=1, B=0, C=1" .elif "${D}" .warning "A=1, B=0, C=0, D=1" .else .alert "A=1, B=0, C=0, D=0" .endif .else .notice "A=0" .endif .diag "WTA/2021-05-07: replace 'redirect' with 'return' after switch to 2.4" http-request redirect location /goaway if ABUSE ``` ## 2.5. Format d'horodatage {#section-2-5} Certains paramètres comportent des valeurs représentant une durée, telles que les délais d'expiration. Ces valeurs sont généralement exprimées en millisecondes (sauf indication contraire explicite), mais peuvent être exprimées dans toute autre unité en ajoutant l'unité à la valeur numérique. Il est important de le prendre en compte, car cela ne sera pas rappelé pour chaque mot-clé. Les unités prises en charge sont : - us : microsecondes. 1us = 1/1000000s - ms : millisecondes. 1ms = 1/1000s. Il s'agit de l'unité par défaut. - s : secondes. 1s = 1000ms - m : minutes. 1m = 60s = 60000ms - h : heures. 1h = 60m = 3600s = 3600000ms - d : jours. 1d = 24h = 1440m = 86400s = 86400000ms ## 2.6. Format de taille {#section-2-6} Certains paramètres impliquent des valeurs représentant une taille, telles que les limites de débit. Ces valeurs sont généralement exprimées en octets (sauf indication contraire explicite), mais peuvent être exprimées dans n'importe quelle autre unité en ajoutant l'unité à la valeur numérique. Il est important de le prendre en compte, car cela ne sera pas rappelé pour chaque mot-clé. Les unités prises en charge sont insensibles à la casse : - k : kilo-octets. 1 kilo-octet = 1024 octets - m : méga-octets. 1 méga-octet = 1048576 octets - g : giga-octets. 1 giga-octet = 1073741824 octets Les formats de temps et de taille exigent des entiers ; la notation décimale n'est pas autorisée. ## 2.7. Format de nom pour les cartes et les listes ACL {#section-2-7} Il est possible d'utiliser une liste de modèles pour les cartes ou les ACL. Une liste de modèles est identifiée par son nom et peut être utilisée à différents endroits dans la configuration. Les listes de modèles sont divisées en trois catégories selon le format du nom : - Listes de motifs basées sur des fichiers réguliers : c'est le cas par défaut. Le nom du fichier, absolu ou relatif, est utilisé comme nom. Le fichier doit exister, sinon une erreur est déclenchée. Toutefois, il peut être vide. Le préfixe « file@ » peut également être spécifié, mais il ne fait pas partie du nom identifiant la liste. Un nom de fichier, avec ou sans préfixe, référence la même liste de motifs. - Listes de motifs basées sur des fichiers facultatifs : le nom de fichier doit être précédé du préfixe "opt@". L'existence du fichier est facultative. Si le fichier existe, son contenu est chargé, mais aucune erreur n'est signalée s'il est absent. Le préfixe ne fait pas partie du nom identifiant la liste. Cela signifie qu'un fichier facultatif et un fichier régulier portant le même nom référencent la même liste de motifs. - Listes de motifs basées sur des fichiers virtuels : le nom n'est qu'un identifiant. Il ne fait pas référence à aucun fichier. Le préfixe « virt@ » doit être utilisé. Il fait partie du nom. Il ne peut donc pas être combiné avec d'autres types de listes. Les fichiers virtuels sont utiles lorsque les modèles sont entièrement gérés de manière dynamique, sans modèles présents au démarrage ni lors d’un rechargement. Les fichiers facultatifs peuvent être utilisés dans les mêmes conditions. Toutefois, les modèles peuvent être sauvegardés dans le fichier, par le biais d’un script externe basé, par exemple, sur la commande CLI « show map ». Ainsi, il devient possible de conserver les modèles lors d’un rechargement. Note : Même si cela est peu probable, cela signifie qu'aucun fichier régulier commençant par « file@ », « opt@ » ou « virt@ » ne peut être chargé, sauf en ajoutant explicitement « ./ » devant le nom de fichier (par exemple « file@./virt@map »). ## 2.8. Variables {#section-2-8} Dans la configuration HAProxy, les variables peuvent être utilisées dans les fonctions d'extraction d'échantillon, les convertisseurs, les chaînes de format de journalisation ou les actions TCP/HTTP. Des variables propres au processus peuvent être définies, accessibles globalement pendant toute la durée de vie du processus. D'autres ont une durée de vie plus courte. Les variables sont similaires à celles utilisées dans les scripts shell. Il s'agit d'un nom symbolique pour une zone de mémoire. La taille des variables n'est pas limitée et est allouée dynamiquement. Elles doivent donc être utilisées avec précaution, notamment en cas d'utilisation intensive. Toutefois, il est possible de limiter la quantité maximale de mémoire utilisée par les variables en configurant les paramètres globaux "tune.vars". Les variables doivent être désignées en utilisant le format "``.``". Le `` est un mot unique indiquant la durée de vie de la variable. La partie ``, à l'intérieur d'une portée, ne peut contenir que des caractères 'a-z', 'A-Z', '0-9' et '\_'. Elle est unique dans cette portée, mais le même nom utilisé dans des portées différentes peut faire référence à des variables différentes. Les portées prises en charge sont : - proc : pour les variables connues pendant toute la durée de vie du processus et accessibles globalement. Les variables « proc » peuvent être manipulées depuis la ligne de commande à l’aide des commandes « get var » et « set var ». Elles peuvent également être définies depuis les sections « global » à l’aide des directives « set-var » et « set-var-fmt ». - sess : pour les variables connues pendant toute la durée de vie d'une session. Les variables « sess » sont privées à une session, non visibles depuis l'extérieur et non partagées avec d'autres sessions. - txn : pour les variables connues pendant toute la durée de vie d'une transaction. Les variables « txn » sont privées à un flux, non visibles depuis l'extérieur et non partagées avec d'autres flux. - req : pour les variables connues pendant le traitement d'une requête sur un flux spécifique. Les variables « req » sont visibles depuis la création du flux jusqu'à la première tentative de connexion au serveur. Elles sont privées à un flux, non visibles depuis l'extérieur et non partagées avec d'autres flux. Il n'y a aucune superposition entre les variables « req » et « res ». - res : pour les variables connues pendant le traitement de la réponse pour un flux spécifique. Les variables « res » sont visibles à partir de la première tentative de connexion au serveur jusqu'à la destruction du flux. Elles sont privées à un flux, non visibles depuis l'extérieur et non partagées avec d'autres flux. Il n'y a aucune superposition entre les variables « req » et « res ». - check : pour les variables connues pendant l'exécution d'une vérification de santé. Les variables « check » sont privées à une vérification de santé, non visibles depuis l'extérieur de celle-ci et non partagées avec d'autres vérifications de santé. Elles peuvent être définies à l'aide des directives dédiées « tcp-check » ou « http-check ». En fonction du contexte, des portées supplémentaires faisant référence au parent d'un flux actuel peuvent être utilisées : - psess : identique à « sess » mais utilise la session du flux parent, le cas échéant. - ptxn : identique à « txn » mais utilise la transaction du flux parent, le cas échéant. - preq : identique à "req" mais utilise le flux parent, le cas échéant. Les variables "preq" ne sont accessibles que pendant le traitement de la requête du flux parent. - pres : identique à « res » mais utilise le flux parent, le cas échéant. Les variables « pres » ne sont accessibles que pendant le traitement de la réponse du flux parent. Les portées faisant référence au flux parent sont utilisables dès la définition de ce dernier. Dans la plupart des cas, aucun flux parent n’existe. Toutefois, s’il est applicable, cela sera explicitement précisé. Pour l’instant, il est uniquement possible de récupérer la valeur des variables définies dans une portée du flux parent. Il n’est pas possible de définir ni d’annuler de telles variables. En général, un flux enfant effectue un traitement pour le parent à un moment précis et empêche celui-ci de progresser jusqu’à la fin de l’opération qu’il effectue. Cela signifie que le parent peut être arrêté au milieu du traitement d’une requête ou d’une réponse, par exemple. En conséquence, certaines portées ne seront pas disponibles depuis le flux enfant. Par exemple, si une requête fait l’objet d’une analyse effectuée par un flux enfant, ce dernier ne trouvera aucune variable dans la portée « pres » car le parent n’est pas en train de traiter une réponse, et donc ne possède aucune variable dans sa portée « res ». Le contenu d'une variable est le résultat d'une expression d'extraction d'échantillon et hérite du type de sortie de cette expression. Il est important de le prendre en compte lors de l'utilisation de la variable, car son type doit être compatible avec son usage. Par exemple, une variable contenant une chaîne utilisée dans le convertisseur « add() » doit être convertible en entier valide pour réussir. Cela est particulièrement vrai lorsque les variables sont comparées à des valeurs statiques. La méthode de correspondance appropriée doit être utilisée. ## 2.9. Formats d'adresses {#section-2-9} Plusieurs instructions telles que « bind », « server », « nameserver » et « log » nécessitent une adresse. Cette adresse peut être un nom d'hôte, une adresse IPv4, une adresse IPv6 ou '*'. Le '*' est égal à l'adresse spéciale "0.0.0.0" et peut être utilisé, dans le cas de « bind » ou « dgram-bind », pour écouter sur toutes les adresses IPv4 du système. L'équivalent IPv6 est '::'. Selon l'instruction, un port ou une plage de ports suit l'adresse IP. Cela est obligatoire dans l'instruction « bind », facultatif dans l'instruction « server ». Cette adresse peut également commencer par une barre oblique « / ». Elle est considérée comme appartenant à la famille « unix », et les caractères « / » et suivants doivent obligatoirement être présents dans le chemin. Le type de socket ou la méthode de transport par défaut, « datagram » ou « stream », dépend de l'instruction de configuration indiquant l'adresse. En effet, les directives « bind » et « server » utilisent par défaut un type de socket « stream », tandis que les directives « log », « nameserver » ou « dgram-bind » utilisent un type de socket « datagram ». Optionnellement, un préfixe peut être utilisé pour forcer le type de famille d'adresses et/ou le type de socket et la méthode de transport. ### 2.9.1. Préfixes de famille d'adresses {#section-2-9-1} 'abns@``' suivant `` est un espace de noms abstrait (Linux uniquement). 'abnsz@``' suivant `` est un espace de noms abstrait terminé par un octet nul (Linux uniquement). 'fd@``' suivant est un descripteur de fichier `` hérité du processus parent. Ce descripteur doit être lié et peut ou non déjà être en écoute. L'adresse 'ip@`
`[:port1[-port2]]' suivant `
` est considérée comme une adresse IPv4 ou IPv6 selon la syntaxe. Selon l'instruction utilisant cette adresse, un port ou une plage de ports peut être spécifié, ou doit l'être. 'ipv4@`
`[:port1[-port2]]' suivant `
` est toujours considéré comme une adresse IPv4. Selon l'instruction utilisant cette adresse, un port ou une plage de ports peut être spécifié, ou doit l'être. 'ipv6@`
`[:port1[-port2]]' suivant `
` est toujours considéré comme une adresse IPv6. Selon l'instruction utilisant cette adresse, un port ou une plage de ports peut ou doit être spécifié. 'sockpair@``' : l'adresse qui suit est le descripteur de fichier d'un socket Unix connecté ou d'une paire de sockets. Lors d'une connexion, l'initiateur crée une paire de sockets connectés et transmet l'un d'eux à l'autre extrémité via le descripteur. L'écouteur attend de recevoir ce descripteur depuis le socket Unix et l'utilise comme celui renvoyé par accept(). Cette option doit être utilisée avec précaution. Bugs : Ce protocole est connu pour être peu fiable sous macOS en raison d'un problème dans l'implémentation de sendmsg(2) de macOS. La connexion pourrait ne pas être acceptée correctement. 'unix@``' : la chaîne qui suit est considérée comme le chemin `` d'un socket Unix. Ce préfixe permet de déclarer un chemin de socket Unix qui ne commence pas par une barre oblique '/'. ### 2.9.2. Préfixes de type de socket {#section-2-9-2} Les préfixes de famille d'adresses précédents peuvent également être utilisés pour forcer le type de socket et la méthode de transport. La valeur par défaut dépend de l'instruction utilisant cette adresse, mais dans certains cas, l'utilisateur peut la forcer à une autre valeur. C'est notamment le cas de l'instruction « log », dont la valeur par défaut est syslog via UDP, mais où l'on peut forcer l'utilisation de syslog via TCP. Ces préfixes ont été conçus à usage interne ; les utilisateurs doivent préférer les alias de la section suivante « 2.9.3 Préfixes de protocole ». Toutefois, ils peuvent parfois s'avérer pratiques, par exemple en combinaison avec des sockets héritées identifiées par leur numéro de descripteur de fichier, auquel cas le domaine d'adresse est « fd » et le type de socket doit être déclaré. Si les utilisateurs ont besoin de l'un de ces préfixes pour obtenir le comportement attendu, car ils ne peuvent pas configurer la même fonctionnalité à l'aide des préfixes de protocole, ils doivent en informer les responsables du maintien. 'stream+``@`
`' impose le type de socket et la méthode de transport à « stream » 'dgram+``@`
`' impose le type de socket et la méthode de transport par "datagramme". 'quic+``@`
`' impose le type de socket à « datagram » et la méthode de transport à « stream ». ### 2.9.3. Préfixes de protocole {#section-2-9-3} 'quic4@`
`[:port1[-port2]]' suivant `
` est toujours considéré comme une adresse IPv4, mais le type de socket est forcé à « datagram » et la méthode de transport est forcé à « stream ». Selon l'instruction utilisant cette adresse, un port UDP ou une plage de ports peut ou doit être spécifié. Cela équivaut à « quic+ipv4@ ». 'quic6@`
`[:port1[-port2]]' suivant `
` est toujours considéré comme une adresse IPv6, mais le type de socket est forcé à « datagram » et la méthode de transport est forcé à « stream ». Selon l'instruction utilisant cette adresse, un port UDP ou une plage de ports peut ou doit être spécifié. Cela équivaut à « quic+ipv6@ ». 'tcp@`
`[:port1[-port2]]' suivant `
` est considéré comme une adresse IPv4 ou IPv6 selon la syntaxe, mais le type de socket et la méthode de transport sont forcés à « stream ». Selon l'instruction utilisant cette adresse, un port ou une plage de ports peut ou doit être spécifié. Il est considéré comme un alias de « stream+ip@ ». 'tcp4@`
`[:port1[-port2]]' suivant `
` est toujours considéré comme une adresse IPv4, mais le type de socket et la méthode de transport sont forcés à « stream ». Selon l'instruction utilisant cette adresse, un port ou une plage de ports peut ou doit être spécifié. Il est considéré comme un alias de 'stream+ipv4@'. 'tcp6@`
`[:port1[-port2]]' suivant `
` est toujours considéré comme une adresse IPv6, mais le type de socket et la méthode de transport sont forcés à « stream ». Selon l'instruction utilisant cette adresse, un port ou une plage de ports peut ou doit être spécifié. Il est considéré comme un alias de « stream+ipv4@ ». 'mptcp@`
`[:port1[-port2]]' suivant `
` est considéré comme une adresse IPv4 ou IPv6 selon la syntaxe, mais le type de socket et la méthode de transport sont forcés à « stream », avec le protocole MPTCP. Selon l'instruction utilisant cette adresse, un port ou une plage de ports peut ou doit être spécifié. 'mptcp4@`
`[:port1[-port2]]' suivant `
` est toujours considéré comme une adresse IPv4, mais le type de socket et la méthode de transport sont forcés à « stream », avec le protocole MPTCP. En fonction de l'instruction utilisant cette adresse, un port ou une plage de ports peut ou doit être spécifié. 'mptcp6@`
`[:port1[-port2]]' suivant `
` est toujours considéré comme une adresse IPv6, mais le type de socket et la méthode de transport sont forcés à « stream », avec le protocole MPTCP. En fonction de l'instruction utilisant cette adresse, un port ou une plage de ports peut ou doit être spécifié. 'udp@`
`[:port1[-port2]]' suivant `
` est considéré comme une adresse IPv4 ou IPv6 selon la syntaxe, mais le type de socket et la méthode de transport sont forcés à « datagram ». Selon l'instruction utilisant cette adresse, un port ou une plage de ports peut ou doit être spécifié. Il est considéré comme un alias de « dgram+ip@ ». 'udp4@`
`[:port1[-port2]]' suivant `
` est toujours considéré comme une adresse IPv4, mais le type de socket et la méthode de transport sont forcés à « datagram ». En fonction de l'instruction utilisant cette adresse, un port ou une plage de ports peut ou doit être spécifié. Il est considéré comme un alias de 'dgram+ipv4@'. 'udp6@`
`[:port1[-port2]]' suivant `
` est toujours considéré comme une adresse IPv6, mais le type de socket et la méthode de transport sont forcés à « datagram ». En fonction de l'instruction utilisant cette adresse, un port ou une plage de ports peut ou doit être spécifié. Il est considéré comme un alias de 'dgram+ipv4@'. 'uxdg@``' : la chaîne qui suit est considérée comme le chemin `` d'un socket Unix, mais la méthode de transport est forcée à "datagram". Ce préfixe est un alias de 'dgram+unix@'. 'uxst@``' : la chaîne qui suit est considérée comme le chemin `` d'un socket Unix, mais la méthode de transport est forcée à "stream". Ce préfixe est un alias de 'stream+unix@'. Dans les versions futures, d'autres préfixes pourraient être utilisés pour spécifier des protocoles comme QUIC, qui propose un transport de flux basé sur des sockets de type « datagram ». ## 2.10. Exemples {#section-2-10} ```haproxy # Simple configuration for an HTTP proxy listening on port 80 on all # interfaces and forwarding requests to a single backend "servers" with a # single server "server1" listening on 127.0.0.1:8000 global daemon maxconn 256 defaults mode http timeout connect 5000ms timeout client 50000ms timeout server 50000ms frontend http-in bind *:80 default_backend servers backend servers server server1 127.0.0.1:8000 maxconn 32 # The same configuration defined with a single listen block. Shorter but # less expressive, especially in HTTP mode. global daemon maxconn 256 defaults mode http timeout connect 5000ms timeout client 50000ms timeout server 50000ms listen http-in bind *:80 server server1 127.0.0.1:8000 maxconn 32 ``` En supposant que HAProxy est dans \$PATH, testez ces configurations dans un shell avec : ```shell $ sudo haproxy -f configuration.conf -c ``` --- Liens inverses : - [7. ACLs et exemples](/fr/docs/haproxy/acls-and-samples/) - [9. Filtres](/fr/docs/haproxy/filters/) - [12. Autres sections](/fr/docs/haproxy/other-sections/) - [11. Tables de persistance et pairs](/fr/docs/haproxy/stick-tables-and-peers/)