Set-OPS-Public/ansible.cfg

43 lines
1.9 KiB
INI
Raw Normal View History

[defaults]
perf : forks=20 et creation des VM en parallele Choisis sur le chronometrage d'une reconstruction complete (1 h 12 min 48 s, phase par phase), pas sur l'intuition. FORKS ETAIT AU DEFAUT (5) POUR 14 HOTES. Chaque play qui balaie la flotte — socle, durcissement, enrolement PKI, les cinq agents — tournait en TROIS vagues. Les gros roles n'en profitent pas : Nextcloud (10 min 55 s), Forgejo, Grafana et Keycloak sont sur UN hote. Ce sont les couches larges qui payaient. forks = 20 laisse de la marge au-dela des 14 actuels ; chaque fork est un processus sur le controleur, pas sur les cibles. LA CREATION DES VM SE FAISAIT UNE PAR UNE : 14 x 1 min 35 s = 22 min 08 s, 30 % du total, et surtout de l'ATTENTE (clone, demarrage, SSH, verrou dpkg) sans le moindre recouvrement. flotte-creer en lance quatre a la fois, ajustable par PARALLELE=n. La sortie de chaque hote va dans SON fichier, recopiee ordonnee a la fin : quatre clones ecrivant en meme temps donneraient un journal illisible, ce qui serait un comble apres une journee a traquer des diagnostics masques. Le marqueur `=== Creation VM: <hote> ===` reste emis en direct. Et un echec n'est pas avale : le code de retour de chaque hote est relu, et la cible sort en erreur si l'un a echoue — sinon _attendre-flotte partirait sur une flotte incomplete. Gains ESTIMES, a verifier par la prochaine mesure : ~15 min sur les clones, ~5 min sur les couches larges. Le troisieme levier identifie — l'archive Nextcloud en .tar.bz2, decompressee sur un seul coeur — attend d'etre mesure. Verifie : ansible-config confirme forks=20, make -n passe, prouver.py 35 OK. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 20:40:25 -04:00
# 14 hotes contre 5 forks par defaut : chaque play multi-hote tournait en TROIS vagues.
# Mesure du 2026-08-10 sur une reconstruction complete — les couches qui balaient toute
# la flotte (socle, durcissement, enrolement PKI, les cinq agents) en portaient le cout,
# pendant que les gros roles (Nextcloud, Forgejo, Grafana, Keycloak) ne sont que sur UN
# hote et n'en profitent pas.
#
# 20 laisse de la marge au-dela des 14 actuels sans devenir absurde : chaque fork est un
# processus Python sur le controleur, pas sur les cibles.
forks = 20
inventory = instance/inventories/lab/hosts.yml
roles_path = roles
filter_plugins = filter_plugins
interpreter_python = auto_silent
host_key_checking = False
retry_files_enabled = False
stdout_callback = default
[privilege_escalation]
become = True
become_method = sudo
become_user = root
[ssh_connection]
# Le sshd des hotes est DURCI par le gabarit, bien en dessous des defauts Debian :
# maxstartups 5:30:20 (defaut 10:30:100) maxsessions 2 (defaut 10)
# Au-dela de 5 connexions NON AUTHENTIFIEES simultanees, sshd en refuse une partie
# SANS envoyer de banniere — et l'echec se lit « Connection timed out during banner
# exchange », qui accuse le reseau. Mesure le 2026-08-09 sur infra-dns-01 : les sessions
# arrivaient a une par seconde, puis plus rien ; l'hote n'avait ni redemarre ni perdu son
# reseau, c'est Ansible qui ne parvenait plus a entrer.
#
# On ouvre donc MOINS de connexions au lieu d'affaiblir l'hote :
# pipelining — une seule connexion par tache au lieu de plusieurs allers-retours
# ControlPersist — la connexion maitresse survit entre les taches
# `ControlPath` court : un chemin trop long depasse la limite des sockets UNIX et fait
# retomber Ansible sur une connexion par tache, ce qui ramenerait le probleme.
pipelining = True
ssh_args = -C -o ControlMaster=auto -o ControlPersist=300s -o PreferredAuthentications=publickey
control_path_dir = /tmp/.ansible-cp
retries = 3