Référence de configuration de l'agent
La configuration par défaut de l'agent se trouve dans le fichier /etc/redirectionio/agent.yml
.
Configuration minimale
Après avoir installé l'agent, vous devez modifier ce fichier afin d'insérer le nom de votre instance redirection.io. Voici la configuration minimale :
# name of this instance, mandatory for logging
instance_name: "A UNIQUE NAME"
Référence de configuration
L'agent supporte cependant d'autres clés d'options, détaillées dans les sections ci-dessous.
instance_name
- Type :
string
- Par défaut :
-
- Cette directive est requise
La directive de configuration instance_name
permet de donner un nom unique à cette instance d'agent. Vous devez utiliser un nom unique pour ce paramètre pour tous les agents exécutés pour votre projet. Sinon, l'agent apparaîtra comme "mal configuré" sur le tableau de bord du projet (son nom sera le nom d'hôte du serveur exécutant l'agent), et ses journaux seront ignorés.
Une bonne idée peut être d'utiliser une combinaison du nom d'hôte et de l'environnement de déploiement comme instance_name
. De plus, rappelez-vous que vous pouvez utiliser des variables d'environnement n'importe où dans le fichier de configuration.
listen
- Type :
string
- Par défaut :
127.0.0.1:10301
- Cette directive est optionnelle
La directive de configuration listen
détermine sur quelle interface l'agent écoute. Elle est par défaut à 127.0.0.1:10301
(port 10301
sur l'hôte local), mais peut prendre d'autres valeurs :
/var/run/redirectionio.sock
: si vous préférez utiliser un fichier, assurez-vous que l'utilisateur exécutant l'agent (redirectionio
, par défaut) a le droit de créer ce fichier""
: une chaîne vide, si vous voulez que votre agent écoute sur toutes les interfaces réseau, sur le port10301
(non conseillé)
persist
- Type :
boolean
- Par défaut :
true
- Cette directive est optionnelle
La directive de configuration persist
permet de définir si les règles doivent être stockées sur le disque. Cela permet de redémarrer l'agent avec des règles existantes sans avoir besoin d'appeler le backend de redirection.io, et ajoute bien sûr plus de résilience à votre configuration.
datadir
- Type :
string
- Par défaut :
/var/lib/redirectionio
- Cette directive est optionnelle
Si la directive persist
est activée, datadir
définit le répertoire où les règles seront persistées sur le système de fichiers local. Bien sûr, l'utilisateur exécutant redirectionio-agent
doit avoir la permission d'écriture sur ce répertoire.
cache
- Type :
integer
- Par défaut :
10000
- Cette directive est optionnelle
La directive de configuration cache
définit le nombre de versions compilées des règles qui seront stockées en mémoire (RAM). Ce paramètre rend l'agent beaucoup plus rapide, mais peut consommer plus de mémoire sur de très grands jeux de règles s'il est défini à une valeur élevée.
La valeur par défaut est 10000
, ce qui devrait utiliser environ 150-200 Mo de mémoire pour un très grand jeu de règles. Il n'est pas nécessaire de définir cette valeur beaucoup plus haut, car l'agent mettra en cache en priorité les chemins fréquemment utilisés.
Vous pouvez complètement désactiver le cache de règles en mémoire, afin de minimiser l'utilisation de la mémoire, en définissant cache: 0
logging
- Type :
boolean
- Par défaut :
undefined
- Cette directive est optionnelle
Le paramètre logging
permet de définir le comportement de journalisation pour cette instance. S'il est défini à "true
", l'instance sera marquée comme autorisée à journaliser le trafic. S'il est défini à "false
", l'instance ne collectera pas les journaux de trafic. Si ce paramètre n'est pas défini, ou défini avec toute autre valeur que "true
" ou "false
", il sera géré par la valeur définie dans l'interface graphique du gestionnaire. Sinon, ce paramètre prime sur le comportement de journalisation défini dans l'interface graphique du gestionnaire.
test_mode
- Type :
boolean
- Par défaut :
undefined
- Cette directive est optionnelle
Le paramètre test_mode
permet de définir cette instance en mode "test". Si ce paramètre n'est pas défini, ou défini avec toute autre valeur que "true
" ou "false
", il sera géré par la valeur définie dans l'interface graphique du gestionnaire. Sinon, ce paramètre prime sur le comportement de journalisation défini dans l'interface graphique du gestionnaire. S'il est activé, la valeur du paramètre "logging
" sera forcée à "false
".
project_keys
- Type :
list of strings
- Par défaut :
[]
- Cette directive est optionnelle
Le paramètre project_keys
permet de précharger l'agent avec certains jeux de règles de projets au démarrage. Si cette directive n'est pas définie, l'agent démarrera avec un jeu de règles vide, et il ne chargera les règles de votre ou vos projets que lorsque la première requête arrivera.
Afin d'éviter que les premières requêtes ne échouent (parce que le jeu de règles ne serait pas chargé à temps), vous pouvez utiliser cette directive de configuration pour définir une liste de clés de projet à charger au démarrage de l'agent.
proxies
Cette section optionnelle permet d'exécuter l'agent en tant que proxy inverse au lieu de le faire fonctionner uniquement comme un serveur. Si cette section est manquante dans le fichier de configuration, l'agent ne fonctionnera tout simplement pas comme un proxy inverse.
Le nœud de configuration proxies
est un tableau qui peut contenir une ou plusieurs configurations de proxy inverse. Pour chaque proxy que vous devez définir, utilisez les directives de configuration décrites dans les sections ci-dessous.
Voici un exemple de configuration de proxy :
proxies:
-
listen: "127.0.0.1:80"
forward: "http://localhost:8080/"
project_key: "SOME_PROJECT_KEY_HERE"
preserve_host: true
Dans cette configuration, le proxy écoutera le trafic HTTP, ce qui signifie que l'agent inspectera les requêtes qui arrivent avec le schéma http
. Par conséquent, une requête sur http://example.com/demo
sera considérée comme une requête pour le schéma http
, le nom d'hôte example.com
et le chemin demo
.
Comme l'indicateur preserve_host
est défini à true
, la requête sera transmise au service backend (à http://localhost:8080/
) avec un en-tête de requête Host: example.com
.
Veuillez noter que, si le proxy redirection.io est situé derrière un logiciel de terminaison SSL (HAProxy, Varnish, nginx, Envoy, ou tout autre proxy inverse) et reçoit des requêtes qui sont transmises par ce proxy, ces requêtes seront considérées comme des requêtes http
, et non https
. Cependant, si vous avez correctement configuré la directive trusted_proxies
, le proxy intégré de redirectionio-agent fera confiance à l'en-tête Forwarded
, s'il est présent, puis se rabattra sur l'en-tête X-Forwarded-Proto
, puis utilisera l'URI de la requête.
En d'autres termes, cela signifie que, dans le cas où des requêtes HTTPS sont reçues dans votre infrastructure par un proxy inverse SSL, puis transmises au proxy redirectionio-agent en tant que requêtes http
, elles seront toujours considérées comme des requêtes https
par le moteur de routage de redirection.io (et elles seront journalisées en tant que requêtes https
), tant que le proxy inverse SSL ajoute l'en-tête Forwarded
ou X-Forwarded-Proto
et que l'adresse IP du proxy inverse est listée dans la directive trusted_proxies
.
listen
- Type :
string
- Par défaut :
-
- Cette directive est requise
L'adresse de l'interface à écouter, sous la forme adresse:port
. Les valeurs valides sont, par exemple, 0.0.0.0:80
, 0.0.0.0:443
(pour écouter sur toutes les interfaces réseau), 127.0.0.1:8080
, etc. Les requêtes HTTP(s) reçues sur cette interface seront analysées et éventuellement transmises à l'adresse forward
, si nécessaire.
L'écoute sur un port privilégié peut nécessiter des autorisations supplémentaires, vous devrez donc peut-être exécuter le binaire redirectionio-agent
avec un utilisateur disposant des autorisations appropriées.
Lors de l'écoute sur le port 443, vous pouvez vous attendre à des requêtes chiffrées SSL. Dans ce cas, vous devez configurer les directives de configuration tls_cert_file
et tls_key_file
(voir ci-dessous).
forward
- Type :
string
- Par défaut :
-
- Cette directive est optionnelle depuis la version 2.6.0. Elle était requise dans les versions précédentes.
L'adresse de l'interface vers laquelle transmettre les requêtes HTTP, sous la forme schéma://adresse:port
. Les valeurs valides sont, par exemple, http://127.0.0.1:8080
, https://192.168.0.30:443
, etc.
Avant la version 2.6.0
, cette directive était requise. Depuis la version 2.6.0
, elle est optionnelle. Si aucune valeur n'est fournie pour la clé forward
(ou si la directive de configuration est complètement supprimée), aucune requête ne sera transmise à un backend. Dans ce cas, l'agent renvoie soit une réponse générée à l'aide d'une règle redirection.io (si une règle correspond à la requête), soit une réponse d'erreur 404
, si aucune règle ne correspond.
project_key
- Type :
string
- Par défaut :
-
- Cette directive est requise
C'est la clé de projet à utiliser pour ce proxy HTTP. Les requêtes HTTP reçues par ce proxy seront comparées au jeu de règles de ce projet redirection.io, et les transformations définies dans les règles (redirections, etc.) exécutées directement au niveau du proxy.
access_log
- Type :
boolean
- Par défaut :
false
- Cette directive est optionnelle
- Disponible depuis :
2.6.0
Si ce paramètre est activé (avec la valeur true
), il produira des journaux de requêtes HTTP, avec le niveau info
. Les journaux d'accès sont ajoutés sous la forme :
INFO [2023-03-14][14:10:49] [access] 127.0.0.1 "GET /example-request HTTP/1.1" 200 50055 "-" "Demo/1.0.0" 0.032220
Chaque ligne de journal contient respectivement :
- le niveau de journal (
INFO
) - la date (
2023-03-14
) et l'heure (14:10:49
) de la requête - l'adresse IP du client (
127.0.0.1
) - la méthode HTTP (
GET
) - l'URL de la requête (
/example-request
) - la version HTTP utilisée (
HTTP/1.1
) - le code de statut de la réponse (
200
) - la taille de la réponse, en octets, y compris les en-têtes HTTP (
50055
) - le Referer (
-
si non fourni) - le User-Agent (
Demo/1.0.0
) - le temps mis pour servir la requête (en secondes avec 6 décimales)
Ces journaux d'accès sont produits dans tous les loggers définis sous la section log du fichier de configuration de l'agent.
add_rule_ids_header
- Type :
boolean
- Par défaut :
false
- Cette directive est optionnelle
- Disponible depuis :
2.2.5
Si ce paramètre est activé (valeur true
), un en-tête de réponse nommé X-RedirectionIo-RuleIds
sera ajouté à la réponse. Sa valeur contiendra la liste des identifiants de règles redirection.io appliquées à cette réponse, séparés par le caractère ;
.
allow_invalid_certificates
- Type :
boolean
- Par défaut :
false
- Cette directive est optionnelle
- Disponible depuis :
2.5.2
Si ce paramètre est activé (valeur true
), l'agent autorisera le transfert de requêtes vers des backends SSL avec des certificats invalides. Si le backend est un simple backend HTTP, ce paramètre n'a aucun effet. Si le paramètre allow_invalid_certificates
est désactivé (c'est-à-dire non défini ou défini à false
) et que le backend SSL sert des certificats invalides, le proxy renverra une réponse 503 Service not available
.
allow_ipv6_forward
- Type :
boolean
- Par défaut :
false
- Cette directive est optionnelle
- Disponible depuis :
2.6.0
Cette directive permet d'utiliser IPv6 pour le transfert des requêtes vers le backend.
La valeur configurée comme adresse du serveur backend peut être une adresse IPv4, une adresse IPv6 ou un nom d'hôte :
- si une adresse IPv4 est utilisée, le routage vers le backend sera effectué en utilisant IPv4
- si une adresse IPv6 est utilisée, le routage vers le backend sera effectué en utilisant IPv6
- si un nom d'hôte est utilisé, le routage vers le backend sera effectué en utilisant IPv4 ou IPv6, selon la valeur de
allow_ipv6_forward
:- si
allow_ipv6_forward
estfalse
, la résolution DNS sera effectuée en utilisant le champA
, et le routage sera exclusivement effectué en utilisant IPv4 - si
allow_ipv6_forward
esttrue
, la résolution DNS sera effectuée en utilisant les champsA
etAAAA
, et le routage sera effectué aléatoirement en utilisant IPv4 ou IPv6
- si
Veuillez noter que cette option est désactivée par défaut, car le support IPv6 est toujours considéré comme expérimental dans le proxy inverse de l'agent redirection.io.
compress
- Type :
boolean
- Par défaut :
false
- Cette directive est optionnelle
- Disponible depuis :
2.5.0
Si ce paramètre est activé (valeur true
), le proxy inverse de l'agent enverra des réponses compressées au client, en fonction de la valeur de l'en-tête de requête Accept-Encoding
.
Si ce paramètre est désactivé, l'agent renvoie toujours des réponses non compressées.
keep_alive.enabled
- Type :
boolean
- Par défaut :
true
- Cette directive est optionnelle
- Disponible depuis :
2.7.0
Cette directive de configuration permet de définir s'il faut utiliser ou non une connexion HTTP persistante entre le proxy redirection.io et le serveur backend.
Pour désactiver keepalive, définissez la configuration de cette manière :
keep_alive:
enabled: false
Lorsque keep_alive
est désactivé, une nouvelle connexion au serveur backend sera créée pour chaque requête entrante. Désactiver keep_alive
peut aider à résoudre les situations où le backend ne prend pas correctement en charge la réutilisation des mêmes connexions.
override_matching_request_host
- Type :
string
- Par défaut :
-
- Cette directive est optionnelle
- Disponible depuis :
2.3.0
Cette directive permet de forcer le nom d'hôte à utiliser lors de la correspondance de la requête. Ceci est utile si vous avez défini des règles utilisant des déclencheurs d'URL avec des valeurs d'URL absolues (contenant un schéma, un nom de domaine, etc.), alors que le proxy reçoit les requêtes en utilisant un autre nom d'hôte.
Veuillez noter que, la plupart du temps, vous devriez préférer l'utilisation de la directive trusted_proxies
conjointement avec l'en-tête de requête X-Forwarded-Host
correct.
override_matching_request_scheme
- Type :
string
- Par défaut :
-
- Valeurs possibles :
http
ouhttps
- Cette directive est optionnelle
- Disponible depuis :
2.3.0
Cette directive permet de forcer le schéma à utiliser lors de la correspondance de la requête. Ceci est utile si vous avez défini des règles utilisant un déclencheur d'URL avec une valeur d'URL absolue (contenant un schéma, un nom de domaine, etc.), mais que vous souhaitez utiliser les mêmes règles dans une définition de proxy avec un autre schéma.
Imaginez, par exemple, une définition de proxy écoutant uniquement le trafic https
, utilisant un projet dans lequel les règles sont définies à l'aide du schéma http://
: les URL ne seraient jamais mises en correspondance, car aucune règle n'utilise le schéma https://
. Dans ce cas, la définition de la valeur override_matching_request_scheme
à http
forcera le module à effectuer la correspondance avec ce schéma, et non le schéma réel de la requête.
Veuillez noter que, la plupart du temps, vous devriez préférer l'utilisation de la directive trusted_proxies
conjointement avec l'en-tête de requête X-Forwarded-Scheme
correct.
preserve_host
- Type :
boolean
- Par défaut :
false
- Cette directive est optionnelle
Ce paramètre permet de transmettre l'en-tête Host
à la destination de transfert, afin que votre application backend puisse utiliser la valeur du nom d'hôte. La plupart du temps, vous devriez vouloir activer cette option.
Si cette option est désactivée (false
), la requête sera transmise au backend forward
en utilisant le nom d'hôte défini dans l'adresse forward
.
request_body_size_limit
- Type :
string
- Par défaut :
2MiB
- Cette directive est optionnelle
- Disponible depuis :
2.4.2
Ce paramètre permet de définir une limite pour la taille du corps de la requête. Les valeurs valides sont des chaînes de la forme <nombre><unité>
, où <unité>
peut être l'une des suivantes : B
, KiB
, MiB
, GiB
(unités du système binaire) ou KB
, MB
, GB
, etc. (unités du système décimal). L'<unité>
peut être en minuscules.
timeout
- Type :
int
- Par défaut :
0
- Cette directive est optionnelle
- Disponible depuis :
2.7.0
Cette valeur définit un délai d'attente, en secondes, pour les requêtes transmises au serveur backend. En d'autres termes, si le serveur backend n'envoie pas de réponse dans le délai défini par la valeur de configuration timeout
, la connexion backend sera abandonnée et une réponse 504
sera renvoyée au client.
Si la valeur 0
est utilisée, aucun délai d'attente ne sera appliqué, ce qui signifie que la connexion restera active jusqu'à ce que le backend la ferme. Il peut être judicieux de définir une valeur de délai d'attente au cas où votre serveur backend serait très lent. Par exemple, définir timeout: 30
garantira qu'aucune requête ne passera plus de 30 secondes.
tls_cert_file
- Type :
string
- Par défaut :
-
- Cette directive est optionnelle
Si ce proxy écoute sur le port 443 ou est censé recevoir du trafic https, veuillez définir dans la directive tls_cert_file
le chemin absolu vers un fichier de certificat SSL, dans un emplacement lisible par le binaire redirectionio-agent
.
tls_key_file
- Type :
string
- Par défaut :
-
- Cette directive est optionnelle
Si ce proxy écoute sur le port 443 ou est censé recevoir du trafic https, veuillez définir dans la directive tls_key_file
le chemin absolu vers un fichier de clé SSL, dans un emplacement lisible par le binaire redirectionio-agent
.
trusted_proxies
- Type :
list of strings
- Par défaut :
[]
- Cette directive est optionnelle
- Disponible depuis :
2.3.0
Cette directive est utilisée par l'agent pour restreindre les proxys qui sont considérés comme fiables avant d'évaluer les en-têtes X-Forwarded-*
. Ceci est particulièrement utile lors de l'utilisation du déclencheur d'adresse IP, afin de s'assurer que l'adresse IP évaluée est valide et n'a pas été falsifiée.
La valeur à utiliser pour cette directive est une liste d'adresses IP de proxys séparées par des virgules qui doivent être considérées comme fiables (il peut également s'agir d'une notation CIDR pour les sous-réseaux). Par exemple :
trusted_proxies: ['192.168.10.7', '192.168.11.0/28']
Cette option est disponible depuis la version 2.3.0
.
metrics_server
- Type :
string
- Par défaut :
-
- Cette directive est optionnelle
- Disponible depuis :
2.2.0
- Sera déprécié dans :
3.0.0
(remplacé parmetrics
)
L'adresse de l'interface de surveillance http à écouter, sous la forme adresse:port
. Les valeurs valides sont, par exemple, 0.0.0.0:8080
(pour écouter sur toutes les interfaces réseau), 127.0.0.1:8080
, etc. Décommenter cette option active un point de terminaison HTTP qui sert un flux JSON contenant des métriques.
Voici un exemple de réponse :
[
{
"id": "5e11a6df-3a1a-4f30-ba91-3c79715857d2:60c680c1-3a5b-491f-a3e4-d701a82d64cd",
"name": "example-com",
"rules": 4242,
"milliseconds_since_last_update": 14452,
"last_update_duration": 325,
"log_buffer_size": 1233,
"total_requests": 18279
},
{
"id": "fe75016c-1b78-4e6b-a769-3ecd38c4c4b1:2552637c-1080-4069-960a-07da9eb25bc3",
"name": "other-example-com",
"rules": 117392,
"milliseconds_since_last_update": 13273,
"last_update_duration": 1581,
"log_buffer_size": 899,
"total_requests": 21924
}
]
Les clés du tableau JSON sont les clés de projet pour les projets redirection.io dont cette instance d'agent a connaissance.
metrics
Lors de l'exécution d'une infrastructure, les opérateurs ont souvent besoin de surveiller le fonctionnement des services et de pouvoir détecter si des problèmes sont sur le point de se produire.
L'agent redirection.io fournit un point de terminaison de surveillance optionnel, qui expose plusieurs métriques destinées à être chargées par votre tableau de bord de surveillance préféré.
Voici un exemple de configuration de métriques :
metrics:
listen: 127.0.0.1:31401
format: "prometheus" # "json" or "prometheus"
listen
- Type :
string
- Par défaut :
-
- Cette directive est optionnelle
- Disponible depuis :
2.4.1
L'adresse de l'interface de surveillance http à écouter, sous la forme adresse:port
. Les valeurs valides sont, par exemple, 0.0.0.0:8080
(pour écouter sur toutes les interfaces réseau), 127.0.0.1:8080
, etc.
Décommenter cette option active un point de terminaison HTTP qui sert un flux JSON contenant des métriques (voir l'option format
ci-dessous).
format
- Type :
string
- Par défaut :
json
- Valeurs possibles :
json
ouprometheus
- Cette directive est optionnelle
- Disponible depuis :
2.4.1
Ce paramètre définit le format des données exposées par le point de terminaison de surveillance.
Lorsque le format est défini comme json
(qui est la valeur par défaut), une requête sur l'adresse d'écoute des métriques génère une réponse de la forme :
[
{
"id": "5e11a6df-3a1a-4f30-ba91-3c79715857d2:60c680c1-3a5b-491f-a3e4-d701a82d64cd",
"name": "example-com",
"rules": 4242,
"milliseconds_since_last_update": 14452,
"last_update_duration": 325,
"log_buffer_size": 1233,
"total_requests": 18279
},
{
"id": "fe75016c-1b78-4e6b-a769-3ecd38c4c4b1:2552637c-1080-4069-960a-07da9eb25bc3",
"name": "other-example-com",
"rules": 117392,
"milliseconds_since_last_update": 13273,
"last_update_duration": 1581,
"log_buffer_size": 899,
"total_requests": 21924
}
]
Les clés du tableau JSON sont les clés de projet pour les projets redirection.io dont cette instance d'agent a connaissance.
Le format peut également être défini comme prometheus
, ce qui expose alors un format compatible avec Prometheus, avec plus d'informations disponibles :
- métriques globales de l'agent :
process_cpu_seconds_total
: Temps CPU total utilisateur et système passé, en secondes.process_max_fds
: Nombre maximal de descripteurs de fichiers ouverts autorisés pour le processus de l'agent.process_open_fds
: Nombre de descripteurs de fichiers ouverts.process_resident_memory_bytes
: Taille de la mémoire résidente, en octets.process_start_time_seconds
: Heure de démarrage du processus depuis l'époque Unix en secondes.process_threads
: Nombre de threads OS dans le processus.process_virtual_memory_bytes
: Taille de la mémoire virtuelle en octets.
- métriques par projet :
redirectionio_matching_requests
: Nombre de fois qu'une requête correspondante a été exécutée par le routeurredirectionio_rules_count
: Nombre de règles dans le routeurredirectionio_last_update_duration
: Durée, en millisecondes, de la dernière mise à jourredirectionio_logs_buffer_size
: Taille en mémoire du tampon de journaux, en octetsredirectionio_duration_since_last_update
: Durée depuis la dernière mise à jour du routeur, en millisecondesredirectionio_duration_since_last_matching_request
: Durée depuis la dernière requête de routage, en millisecondes
log
Cette section optionnelle contient des directives pour configurer la journalisation de l'agent. Chaque sous-section est optionnelle et indépendante des autres. Si cette section est manquante dans le fichier de configuration, l'agent ne journalisera pas les erreurs ou les avertissements.
file
Cette sous-section peut contenir des directives pour la journalisation des fichiers.
level
- Type :
string
- Par défaut :
info
- Cette directive est optionnelle
Ceci fixe la verbosité du journal. Il peut s'agir de debug
, info
, error
.
path
- Type :
string
- Par défaut :
-
- Cette directive est requise
Chemin du fichier journal dans lequel écrire. Veuillez vous assurer que l'utilisateur exécutant l'agent (redirectionio
, par défaut) a le droit de créer ce fichier.
stderr
Utilisez stderr
pour afficher les messages de journalisation sur la sortie d'erreur standard.
level
- Type :
string
- Par défaut :
info
- Cette directive est requise
Ceci fixe la verbosité du journal. Il peut s'agir de debug
, info
, error
.
syslog
Cette sous-section peut contenir des directives pour la journalisation syslog.
network
- Type :
string
- Par défaut :
""
- Cette directive est requise
Le type de connexion à utiliser (""
, udp
ou tcp
). Utilisez une chaîne vide (""
) pour utiliser un serveur syslog local.
address
- Type :
string
- Par défaut :
""
- Cette directive est requise
L'adresse du serveur de journalisation à utiliser. Utilisez une chaîne vide (""
) pour utiliser un serveur syslog local. Pour utiliser un serveur distant, ou un serveur fonctionnant sur un port non standard, utilisez une chaîne de la forme adresse:port
, par exemple 192.168.0.30:514
.
level
- Type :
string
- Par défaut :
info
- Cette directive est requise
Ceci fixe la verbosité du journal. Il peut s'agir de debug
, info
, error
.
tag
- Type :
string
- Cette directive est optionnelle
Ceci permet d'attacher une étiquette aux journaux envoyés à syslog.
Utiliser les variables d'environnement dans le fichier de configuration
Il est possible d'utiliser des variables d'environnement dans le fichier de configuration, ce qui peut être utile dans des environnements dynamiques comme les déploiements basés sur le cloud :
Voir cet exemple :
instance_name: "${REDIRECTIONIO_INSTANCE_NAME}"
datadir: "${REDIRECTIONIO_APPLICATION_DIR}/rules"
log:
file:
level: info
path: "${REDIRECTIONIO_APPLICATION_DIR}/log/agent.log"
Dans cet exemple, les variables d'environnement REDIRECTIONIO_INSTANCE_NAME
et REDIRECTIONIO_APPLICATION_DIR
doivent être définies au démarrage de l'agent (bien sûr, vous pouvez utiliser n'importe quel nom pour les variables d'environnement). Si elles ne sont pas définies, les variables seront remplacées par une chaîne vide :
$ redirectionio-agent
level=error msg="[server] The agent is Misconfigured: The 'instance_name' is not defined."
Lorsque les variables d'environnement requises sont définies, elles sont interprétées lors du démarrage de l'agent :
$ export REDIRECTIONIO_INSTANCE_NAME=example-agent
$ export REDIRECTIONIO_APPLICATION_DIR=/tmp/redirectionio
$ redirectionio-agent
level=info msg="redirectionio-agent (version: 2.2.6, build date: 2021-08-05T13:25:14Z)" instance_name=example-agent
...
Si elle est définie, la variable d'environnement spéciale HTTPS_PROXY
sera utilisée par l'agent pour acheminer les communications avec les API redirection.io via un proxy https.
Exemple complet
Voici un exemple de configuration complet, à titre de référence :
# Name of this instance, mandatory for logging
instance_name: "A UNIQUE NAME"
# Interface listening. "" for all interfaces (not advised)
# /run/redirectionio.sock or 127.0.0.1:10301
listen: 127.0.0.1:10301
#listen: /run/redirectionio.sock # If you use a file, please make sure that user running the agent has the right to create it
# Whether or not to store rules on the disk.
# This allows to restart the agent with existing rules without the need to call redirection.io's backend
persist: true
# Directory where the rules will be persisted
datadir: /var/lib/redirectionio
# This setting allows to define the logging behavior for this instance. If it is set to "true", the instance will
# be marked as allowed to log traffic. If it is set to "false", the instance will not collect traffic logs.
# If this setting is not defined, or defined with any other value than "true" or "false", it will be managed
# by the value defined in the manager graphical interface. Else, this setting takes precedence over the logging
# behavior defined in the manager graphical interface.
logging: true
# This setting allows to set this instance in "test" mode. If this setting is not defined, or defined
# with any other value than "true" or "false", it will be managed by the value defined in the
# manager graphical interface. Else, this setting takes precedence over the logging behavior defined in the
# manager graphical interface. If it is enabled, the value of the "logging" setting will be forced to "false".
test_mode: false
# Number of items to store in memory.
# This makes the agent much faster, but will consume more memory on very large rulesets if this setting is high
# With the default value, a very large ruleset should consume about 150-200 MB of memory
# Set to 0 to disable the cache and minimize memory usage
cache: 10000
# Keys of projects to preload
# This allows to preload the agent with some projects rulesets at startup time
project_keys:
- "A VALID PROJECT KEY"
# Run the agent as a reverse proxy
# Leave it empty to disable the reverse proxy feature
proxies:
-
listen: "0.0.0.0:80"
forward: "http://127.0.0.1:8080"
project_key: "A PROJECT KEY"
preserve_host: true # Preserve host header, defaults to false
add_rule_ids_header: true # Add a X-RedirectionIo-RuleIds response header, defaults to false
compress: true # compress the responses, depending on the Accept-encoding header
-
listen: "0.0.0.0:443"
forward: "http://192.168.1.47:80"
project_key: "A SECOND PROJECT KEY"
preserve_host: true # Preserve host header
tls_cert_file: /path/to/ssl/cert.pem
tls_key_file: /path/to/ssl.key
-
listen: "0.0.0.0:9080"
forward: "https://192.168.1.47:443"
project_key: "A THIRD PROJECT KEY"
preserve_host: true
compress: true
allow_invalid_certificates: true # allow proxifying requests to the SSL backend, served with invalid certificates
-
listen: "127.0.0.1:8080"
forward: "http://127.0.0.1:8081"
project_key: "A FOURTH PROJECT KEY"
preserve_host: true # Preserve host header, defaults to false
trusted_proxies:
- "127.0.0.1"
- "192.168.10.0/28"
-
listen: "127.0.0.1:8081"
forward: "http://127.0.0.1:8090"
project_key: "A FIFTH PROJECT KEY"
preserve_host: true # Preserve host header, defaults to false
override_matching_request_scheme: https
override_matching_request_host: "example.com"
-
# proxify the incoming requests to the host resolved at "some-other-domain.tld", with this domain as the Host of the request
# use for this proxy configuration the same project key as the first proxy defined above
listen: "127.0.0.1:8083"
forward: "http://some-other-domain.tld:80"
project_key: "A PROJECT KEY"
preserve_host: false
# enable access logs, to log all the requests
access_log: true
-
# receive requests on port 8404
# return a response built with redirection.io, if a rule matches,
# or a 404 otherwise (as no forward is defined)
listen: "127.0.0.1:8404"
project_key: "A PROJECT KEY"
# Define the metrics monitoring endpoint configuration. This enables a http endpoint which serves some metrics about the agent
metrics:
# Where the metrics server should listen, example values: 127.0.0.1:8080, 0.0.0.0:8080, /run/redirectionio-metrics.sock
listen: 127.0.0.1:31401
# Metrics format, can either be "json" or "prometheus", defaults to "json"
format: "prometheus"
# Sets log configuration. Each section is optional and independent of one another.
log:
file:
level: debug
path: /proc/self/fd/2
stderr:
level: info
syslog:
# pushes to the local syslog
network: "" # empty string
address: "" # empty string
level: info
tag: redirectionio-agent
Options de ligne de commande de l'agent
L'agent redirection.io prend en charge plusieurs options de ligne de commande :
$ redirectionio-agent --help
Usage of redirectionio-agent:
--config-file string
Use this option to explicitly pass a configuration file
--debug
Enable debug mode
--test
Test config and exit, return non zero exit code if there is an error in the config
--version
Show version and exit
Fichier de configuration défini au démarrage
Par défaut, l'agent démarrera en utilisant un fichier de configuration /etc/redirectionio/agent.yml
ou $HOME/.redirectionio/agent.yml
. Si nécessaire, vous pouvez également passer l'option --config-file
pour forcer un fichier de configuration donné :
/usr/bin/redirectionio-agent --config-file /path/to/some/configuration/directory/some-config-file.yml
Niveau de débogage
L'option --debug
donne plus de détails sur le comportement de l'agent. Vous pouvez l'utiliser pour dépanner votre installation de l'agent redirection.io :
/usr/bin/redirectionio-agent --debug
Test de configuration
L'option --test
permet de tester le fichier de configuration et d'obtenir des informations sur les erreurs de configuration. Cette commande renvoie un code non nul lorsque l'agent n'est pas correctement configuré, vous pouvez donc l'utiliser dans des scripts de provisionnement pour ne redémarrer/recharger l'agent que lorsque la configuration est correctement définie.
/usr/bin/redirectionio-agent --test
time="2021-05-03T12:42:42+00:00" level=info msg="redirectionio-agent (version: 2.2.0, build date: 2021-05-03T12:42:00Z)" instance_name=example-com
Cette option est disponible depuis la version 2.2.0
.
Obtenir la version actuelle de l'agent
L'option --version
affiche le nom de la version de l'agent redirection.io installé :
/usr/bin/redirectionio-agent --version
2.3.0
Cette option est disponible depuis la version 2.2.0
.
Utiliser l'agent derrière un proxy HTTPS
Dans certaines configurations d'entreprise, il peut être compliqué d'obtenir une connexion directe entre l'agent et les API redirection.io. Certaines architectures d'hébergement exigent que les connexions aux services externes passent par un proxy d'entreprise.
L'agent redirection.io est capable d'utiliser un proxy https pour communiquer avec les API redirection.io. Cela peut être fait en utilisant une variable d'environnement HTTPS_PROXY
:
HTTPS_PROXY=http://192.168.0.254:8443 /usr/bin/redirectionio-agent
Veuillez noter que la variable d'environnement peut être en minuscules ou en majuscules, les deux fonctionnent. Si vous utilisez un proxy http, utilisez la variable d'environnement HTTP_PROXY
.
Cette option est disponible depuis la version 2.2.4
.
Ajuster le fichier de service redirectionio-agent
Si vous avez installé l'agent en utilisant nos paquets APT officiels ou nos paquets RPM officiels, vous pourriez avoir besoin de surcharger le fichier de service systemd fourni avec le paquet. Cela peut être fait de manière élégante en utilisant systemctl
:
$ sudo systemctl edit redirectionio-agent.service
Dans l'éditeur, collez ce qui suit :
[Service]
Environment="https_proxy=http://192.168.0.254:8443"
Ensuite, redémarrez l'agent, il devrait utiliser le proxy configuré :
$ sudo systemctl restart redirectionio-agent.service
Pour supprimer cette surcharge de service, supprimez le fichier de surcharge :
$ sudo rm -Rf /etc/systemd/system/redirectionio-agent.service.d
$ sudo systemctl daemon-reload
$ sudo systemctl restart redirectionio-agent.service
Si vous avez besoin d'inclure plusieurs variables d'environnement, vous pouvez utiliser la surcharge suivante (où /etc/environment
est un fichier contenant les variables d'environnement) :
[Service]
EnvironmentFile=/etc/environment