🥇Accélérer Ansible

Il n'est un secret pour personne qu'avec les paramètres par défaut, Ansible peut ne pas fonctionner très rapidement. Dans cet article, je vais souligner quelques raisons à cela et proposer un minimum utile de configurations qui pourraient effectivement augmenter la vitesse de votre projet.

Nous discutons ici et ci-après d'Ansible 2.9.x, qui a été installé dans un virtualenv fraîchement créé de la manière que vous préférez.

Après l'installation, créez un fichier «ansible.cfg» à côté de votre playbook — cette localisation permettra de transférer ces paramètres avec le projet, et ils seront chargés automatiquement.

Pipeline

Certaines personnes ont peut-être déjà entendu parler de l'utilisation de la mise en pipeline, c'est-à-dire de ne pas copier les modules dans le système de fichiers de la machine cible, mais de transmettre une archive zip encodée en Base64 directement sur stdin de l'interpréteur Python. Mais le fait reste que : ce paramètre reste sous-estimé. Malheureusement, certaines distributions Linux populaires ont auparavant mal configuré sudo par défaut — ainsi, cette commande nécessitait la présence d'un tty (terminal), donc dans Ansible, cette option très utile est restée désactivée par défaut.

pipelining = True

Collecte des faits

Savez-vous qu'avec les paramètres par défaut, Ansible initie la collecte des faits sur tous les hôtes impliqués dans chaque play ? Si vous ne le saviez pas, maintenant vous le savez. Pour éviter cela, il faut activer soit le mode de requête explicite pour la collecte des faits (explicit), soit le mode smart. Dans ce dernier, les faits seront collectés uniquement auprès des hôtes qui n'ont pas été rencontrés dans les précédents plays.
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à exécuté Ansible en mode de sortie de débogage (l'option «v», répétée de une à neuf fois), vous avez peut-être remarqué que les connexions ssh sont constamment établies et interrompues. Eh bien, il y a aussi quelques subtilités ici.

Éviter l'étape de réinstallation de la connexion ssh peut se faire à deux niveaux simultanément : à la fois directement dans le client ssh et lors du transfert de fichiers vers l'hôte géré depuis le contrôleur.
Pour réutiliser une connexion SSH ouverte, il suffit de transmettre les clés nécessaires au client SSH. Il commencera alors à faire ce qui suit : lors de la première installation de la connexion SSH, il créera un « contrôle socket » supplémentaire, lors des suivantes, il vérifiera l'existence de ce socket et, en cas de succès, réutilisera la connexion SSH existante. Pour que cela ait tout son sens, déterminons le temps de conservation de la connexion en cas d'inactivité. Vous pouvez en lire plus dans la documentation SSH, et dans le contexte d'Ansible, nous utilisons simplement le « forwarding » des options nécessaires au 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 l'hôte géré, il suffit d'indiquer un autre paramètre inconnu : ssh_transfer_method. La documentation à ce sujet est extrêmement rare et peut prêter à confusion, car cette option est tout à fait fonctionnelle ! Cependant, la lecture code source permet de comprendre ce qui va se passer : une commande dd sera exécutée sur l'hôte géré, interagissant directement avec le fichier nécessaire.

transfer_method = piped

Au fait, dans la branche « develop », ce paramètre existe également et n'a pas disparu.

N'aie pas peur du couteau, crains la fourchette

Une autre option utile est les forks. Cela détermine le nombre de processus de travail qui se connecteront simultanément aux hôtes et exécuteront des tâches. En raison des particularités de Python en tant que langage de programmation, ce sont en effet des processus qui sont utilisés et non des threads, car Ansible prend toujours en charge Python 2.7 — pas de asyncio, il n’y a pas lieu d'introduire de l'asynchrone ici ! Par défaut, Ansible lance cinq travailleurs, mais si vous demandez correctement, il en lancera plus :

forks = 20

Cependant, je vous préviens tout de suite que certaines difficultés peuvent survenir en raison de la mémoire disponible sur la machine de contrôle. Autrement dit, mettre forks=100500 est bien sûr possible, mais qui a dit que cela fonctionnerait ?

Rassemblons tout

Ainsi, pour ansible.cfg (format ini), les paramètres nécessaires pourraient 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 souhaitez tout cacher dans un inventaire YaML sain, 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, avec les paramètres «gathering = smart/explicit» et «forks = 20», cela ne fonctionnera pas : leurs équivalents YaML n'existent pas. Soit nous les définissons dans ansible.cfg, soit nous les transmettons via les variables d'environnement ANSIBLE_GATHERING et ANSIBLE_FORKS.

À propos de Mitogen
— Mais où est mentionné Mitogen ici ? — pourrais-tu, cher lecteur, demander. Dans cet article — nulle part. Mais si tu es réellement prêt à lire son code et à comprendre pourquoi ton playbook échoue avec Mitogen, alors qu'il fonctionne normalement avec Ansible «vanilla», ou pourquoi ce même playbook a bien fonctionné auparavant, mais après une mise à jour, il agissant bizarrement — eh bien, Mitogen peut potentiellement être ton outil. Utilise-le, explore, écris des articles — je les lirai avec intérêt.

Pourquoi je n'utilise pas personnellement Mitogen ? Parce qu'il fonctionne uniquement tant que les tâches sont vraiment simples et que tout va bien. Mais dès que tu dévies légèrement à gauche ou à droite — c'est terminé : un torrent d'exceptions confuses arrive et il ne manque que la phrase habituelle «merci à tous, tout le monde est libre». En résumé, je ne veux tout simplement pas perdre de temps à chercher les raisons d'un énième «bruit souterrain».

Une partie de ces paramètres a été découverte en lisant code source le plugin de connexion portant le nom évocateur «ssh.py». Je partage mes résultats dans l'espoir que cela inspirera quelqu'un d'autre à examiner le code source, à le lire, à vérifier l'implémentation, à la comparer à la documentation — car cela rapportera tôt ou tard des résultats positifs. Bonne chance !

Seuls les utilisateurs enregistrés peuvent participer au sondage. Connectez-vous, s'il vous plaît.

Quels paramètres Ansible de la liste avez-vous utilisés pour accélérer vos projets ?

69,6%pipelining = true32
34,8%gathering = smart/explicit16
52,2%ssh_args = "-o ControlMaster=auto -o ControlPersist=…"24
17,4%transfer_method = piped8
63,0%forks = XXX29
6,5%Rien de tout cela, juste Mitogen3
8,7%Mitogen + je noterai précisément lesquels de ces paramètres4

46 utilisateurs ont voté. 21 utilisateurs se sont abstenus.

Voulez-vous encore d'autres choses sur Ansible ?

78,3%Oui, bien sûr54
21,7%Oui, mais je veux des choses plus hardcore !15
0,0%Non, et pas besoin0
0,0%Non, c'est trop compliqué !!!0

69 utilisateurs ont voté. 7 utilisateurs se sont abstenus.

Source : habr.com

Accélération d'Ansible