Accélérer Ansible

Ce n'est un secret pour personne qu'avec les paramètres par défaut, Ansible peut ne pas faire son travail très rapidement. Dans l'article, je vais souligner plusieurs raisons à cela et offrir un minimum de paramètres utiles qui, très probablement, augmenteront vraiment la vitesse de votre projet.



Nous discutons ici et plus loin d'Ansible 2.9.x, qui a été installé dans le virtualenv fraîchement créé de votre manière préférée.



Après l'installation, nous créons un fichier "ansible.cfg" à côté de votre playbook - cet emplacement vous permettra de transférer ces paramètres avec le projet, en plus ils seront chargés automatiquement.

Pipeline

Quelqu'un pouvait déjà entendre parler de la nécessité d'utiliser le pipelining, c'est-à-dire de ne pas copier de modules sur le FS du système cible, mais de transférer une archive zip en Base64 directement sur le stdin de l'interpréteur Python, mais le fait demeure : Ce paramètre est toujours sous-estimé. Malheureusement, certaines des distributions Linux populaires utilisées pour configurer sudo par défaut ne sont pas très bien - de sorte que cette commande nécessitait un tty (terminal), donc dans Ansible ce paramètre très utile a été laissé désactivé par défaut.

pipelining = True

Recueillir des faits

Saviez-vous qu'avec les paramètres par défaut, Ansible pour chaque jeu lancera la collecte de faits auprès de tous les hôtes qui y participent? En général, si vous ne saviez pas, maintenant vous le savez. Pour éviter que cela ne se produise, vous devez activer le mode de demande explicite pour la collecte de faits (explicite) ou le mode intelligent. Dans ce document, les faits seront collectés uniquement auprès des hôtes qui n'ont pas été rencontrés dans les pièces précédentes.

UPD. Lors de la copie, vous devrez choisir l'un de ces paramètres.

gathering = smart|explicit

Réutilisation des connexions SSH

Si vous avez déjà démarré Ansible en mode débogage (option "v" répétée une à neuf fois), vous avez peut-être remarqué que les connexions ssh sont constamment établies et supprimées. Donc, il y a aussi quelques subtilités ici.



Vous pouvez éviter l'étape consistant à rétablir une connexion ssh à deux niveaux à la fois: à la fois directement dans le client ssh et lors du transfert de fichiers vers un hôte géré depuis un gestionnaire.

Pour réutiliser une connexion ssh ouverte, transmettez simplement les clés requises au client ssh. Ensuite, il commencera à faire ce qui suit: lors de l'établissement d'une connexion ssh pour la première fois, créez en plus un socket de contrôle, sur les suivants - vérifiez l'existence de ce socket même, et, en cas de succès, réutilisez la connexion ssh existante. Et pour que tout cela ait du sens, nous définirons l'heure de sauvegarde de la connexion lorsqu'elle est inactive. Plus de détails peuvent être trouvés dans la documentation ssh , et dans le contexte d'Ansible, nous utilisons simplement le "transfert" des options nécessaires vers le client ssh.

ssh_args = "-o ControlMaster=auto -o ControlPersist=15m"

Pour réutiliser une connexion ssh déjà ouverte lors du transfert de fichiers vers un hôte géré, il vous suffit de spécifier un autre paramètre inconnu ssh_tranfer_method. La documentation à ce sujet est extrêmement rare et trompeuse, car cette option fonctionne d'elle-même! Mais la lecture du code source permet de comprendre ce qui va se passer exactement: la commande dd sera lancée sur l'hôte géré, travaillant directement avec le fichier requis.

transfer_method = piped

D'ailleurs, dans la branche "develop", ce paramètre existe également et n'est allé nulle part .

N'ayez pas peur du couteau, ayez peur de la fourchette

Un autre paramètre utile est les fourches. Il détermine le nombre de processus de travail qui se connecteront simultanément aux hôtes et effectueront des tâches. En raison des particularités de Python en tant que PL, ce sont des processus qui sont utilisés, pas des threads, car Ansible prend toujours en charge Python 2.7 - pas d'asyncio pour vous, il n'y a rien pour engendrer l'asynchronie ici! Par défaut, Ansible lance cinq nœuds de calcul , mais s'il est correctement demandé, il en exécutera plus:

forks = 20

Je vous préviens tout de suite qu'il peut y avoir des difficultés liées à la quantité de mémoire disponible sur la machine de contrôle. En d'autres termes, vous pouvez, bien sûr, mettre fourches = 100500, mais qui a dit que cela fonctionnera?

Mettre tous ensemble

En conséquence, pour ansible.cfg (format ini), les paramètres nécessaires peuvent ressembler à ceci:

[defaults]
gathering = smart|explicit
forks = 20
[ssh_connection]
pipelining = True
ssh_args = -o ControlMaster=auto -o ControlPersist=15m
transfer_method = piped

Et si vous voulez tout cacher dans l'inventaire YaML normal d'une personne en bonne santé, cela pourrait ressembler à ceci:

---
all:
  vars:
    ansible_ssh_pipelining: true
    ansible_ssh_transfer_method: piped
    ansible_ssh_args: -o ControlMaster=auto -o ControlPersist=15m

Malheureusement, cela ne fonctionnera pas avec les paramètres "collecte = smart / explicite" et "forks = 20": il n'y a pas d'équivalents YaML. Soit nous les définissons dans ansible.cfg, soit nous les passons à travers les variables d'environnement ANSIBLE_GATHERING et ANSIBLE_FORKS.





Certains de ces paramètres ont été découverts lors de la lecture du code source du plugin de connexion sous le nom explicite "ssh.py". Je partage les résultats de la lecture dans l'espoir que cela inspirera quelqu'un d'autre à regarder la source, à les lire, à vérifier l'implémentation, à comparer avec la documentation - après tout, tôt ou tard, tout cela vous apportera des résultats positifs. Bonne chance!