Options Swarm et destinations des journaux

Tous les réglages Docker Swarm qu'une application peut avoir au-delà de sa taille et de sa commande, ceux qui demandent votre propre cluster, et comment envoyer les journaux vers Loki, Elastic, Graylog ou Splunk.

La taille, les copies, l'environnement, la commande, le contrôle de santé et le déploiement progressif d'une application ont leurs propres panneaux. Les options Swarm sont tout le reste de ce que Docker Swarm peut régler sur le service. Chaque option laissée vide garde la valeur par défaut de Docker, et en effacer une remet cette valeur au prochain déploiement.

Réglez-les dans la console (page de l'application, Options Swarm), avec isogrid apps options <app>, ou dans un fichier de stack, où les clés compose habituelles sont lues.

Ce que vous pouvez régler

Domaine Options Clés compose
Placement répartir les copies selon une étiquette de nœud, copies au plus par machine, CPU réservés par copie deploy.placement.preferences, max_replicas_per_node, deploy.resources.reservations.cpus
Conteneur répertoire de travail, nom d'hôte, signal d'arrêt, processus init, système de fichiers en lecture seule, TTY, ulimits, limite de processus, groupes supplémentaires, capacités retirées working_dir, hostname, stop_signal, init, read_only, tty, ulimits, group_add, cap_drop
Fichiers fichiers de configuration créés à partir de texte (configs Swarm) configs avec un content: en ligne
Réseau lignes /etc/hosts supplémentaires, serveurs, domaines et options DNS, une adresse par copie (dnsrr) extra_hosts, dns, dns_search, dns_opt, deploy.endpoint_mode
Journaux la destination de la sortie logging.driver, logging.options

Les fichiers servent à la configuration qui n'est pas secrète. Les secrets vont dans un coffre et arrivent dans le conteneur sous forme de fichiers ou de variables.

Les options qui demandent votre propre cluster

Certaines options touchent la machine elle-même. Elles ne s'exécutent que sur un cluster qui est le vôtre : un cluster privé réservé à votre organisation, ou un cluster géré par votre agent Nomad. Dans une région partagée elles sont refusées, et la console l'indique.

  • capacités ajoutées (cap_add) et réglages du noyau (sysctls)
  • le score OOM (oom_score_adj)
  • le réseau de la machine (network_mode: host) : l'application quitte alors son réseau privé
  • les répertoires de la machine (montages bind)
  • les ports publiés sur les machines (ports avec mode: host ou mode: ingress)
  • les ressources de nœud comme les GPU (generic_resources)
  • une copie sur chaque machine (deploy.mode: global). Passer à ce mode ou en sortir recrée le service, avec une courte interruption, et une telle application ne peut pas être mise à l'échelle, ni manuellement ni automatiquement.
  • relever une limite autre que nofile, ou la rendre illimitée

Sur un cluster géré par l'agent Nomad, celles qui donnent root sur la machine (capacités, sysctls, score OOM, réseau de la machine, montages bind) demandent en plus l'accord de l'agent : définissez ISOGRID_NOMAD_ALLOW_PRIVILEGED=true sur l'agent. Sans cela, l'agent les refuse, quoi que demande ISOGrid.

Où vont les journaux

Par défaut la sortie reste sur la machine, où la console et la recherche dans les journaux la lisent. Vous pouvez l'envoyer ailleurs :

  • Les pilotes de Docker : syslog, gelf (Graylog, Logstash), fluentd, splunk, et, sur votre propre cluster seulement, awslogs, gcplogs et journald, qui utilisent l'identité ou le journal de la machine.
  • Les plugins de journaux : Grafana Loki et Elastic. Un plugin est d'abord installé sur chaque machine de la région : isogrid regions log-plugins <région> --install loki, ou le bouton du panneau Options Swarm. Un plugin s'exécute en root sur chaque machine : vous l'installez sur un cluster qui est le vôtre ; dans une région partagée, ce sont les opérateurs d'ISOGrid qui décident.
isogrid apps options boutique --log-driver loki \
  --log-secret-opt loki-url=https://USER:TOKEN@logs.example.com/loki/api/v1/push --deploy

La console continue d'afficher la sortie quelle que soit la destination : Docker en garde une copie locale, de la taille de vos journaux conservés. Une destination lente ou en panne ne bloque jamais l'application : la sortie est mise en mémoire tampon (4 Mo), et ce qui dépasse est abandonné.

Un jeton ou un mot de passe dans une option de journal va dans les options secrètes : il est conservé dans le coffre de secrets et jamais réaffiché. Sur un cluster géré par votre agent Nomad, écrivez-le plutôt sous la forme {{secret:<référence>}}, pour qu'il reste dans votre Vault.

Dans une région partagée, une destination doit être une adresse publique : la machine envoie elle-même les journaux, et n'a pas le droit de joindre des réseaux privés à votre place.

Rechercher dans des journaux JSON

Quand votre application écrit des lignes JSON, la recherche les lit comme des champs. Le niveau est celui du logger (level, severity, les nombres de pino), le message est son msg, et les champs se filtrent avec @ :

Requête Trouve
@status>=500 un nombre comparé (>, >=, <, <=)
@http.method:GET égal, sans tenir compte de la casse ; champs imbriqués avec des points
@user.id:* le champ est présent
@path:/api/* commence par
@msg~timeout contient
-@env:dev pas cela

Elles se combinent comme avant avec les mots, les phrases, level: et replica:.