🥇Accélérer Ansible

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

Ici et ci-dessous, nous discutons d'Ansible 2.9.x, qui a été installé dans un environnement virtuel fraîchement créé de votre manière préférée.

Après l'installation, créez un fichier « ansible.cfg » à côté de votre playbook - cet emplacement vous permettra de transférer ces paramètres avec le projet, et ils se chargeront tout à fait automatiquement.

Pipeline

Certains ont peut-être déjà entendu parler de la nécessité d'utiliser le pipeline, c'est-à-dire de ne pas copier les modules dans le système de fichiers du système cible, mais de transférer une archive zip enveloppée en Base64 directement vers le stdin de l'interpréteur Python, mais d'autres ne le peuvent pas, mais le fait reste un fait : ce paramètre reste encore sous-estimé. Malheureusement, certaines des distributions Linux populaires ne configuraient pas très bien sudo par défaut - de sorte que cette commande nécessitait un tty (terminal), donc Ansible a laissé ce paramètre très utile désactivé par défaut.

pipelining = True

Rassembler des faits

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

gathering = smart|explicit

Réutiliser les connexions ssh

Si vous avez déjà exécuté Ansible en mode débogage (l'option « v », répétée une à neuf fois), vous avez peut-être remarqué que les connexions ssh sont constamment établies et interrompues. Il y a donc ici aussi quelques subtilités.

Vous pouvez éviter l'étape de rétablissement d'une connexion ssh à deux niveaux à la fois : à la fois directement dans le client ssh et lors du transfert de fichiers vers l'hôte géré depuis le gestionnaire.
Pour réutiliser une connexion ssh ouverte, transmettez simplement les clés nécessaires au client ssh. Ensuite, il commencera à faire ce qui suit : lors de l'établissement d'une connexion ssh pour la première fois, il créera en plus ce qu'on appelle une socket de contrôle, lors des installations ultérieures, il vérifiera l'existence de cette même socket et, en cas de succès, réutilisera le connexion ssh existante. Et pour que tout cela ait du sens, définissons l’heure de maintien de la connexion lorsqu’elle est inactive. Vous pouvez en lire davantage dans documentation ssh, et dans le contexte d'Ansible, nous utilisons simplement « transférer » les 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 un hôte géré, spécifiez simplement un autre paramètre inconnu ssh_tranfer_method. La documentation à ce sujet est extrêmement chere et trompeur, car cette option fonctionne plutôt bien ! Mais lire 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 souhaité.

transfer_method = piped

D'ailleurs, dans la branche « develop » ce paramètre existe également pas allé nulle part.

N'aie pas peur du couteau, ait peur de la fourchette

Un autre paramètre utile est celui des fourchettes. 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 langage, 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, cela ne sert à rien d'introduire un comportement asynchrone ici ! Par défaut, Ansible s'exécute cinq travailleurs, mais si on lui demande correctement, il lancera plus :

forks = 20

Je vous préviens tout de suite qu'il peut y avoir ici quelques 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 définir forks=100500, mais qui a dit que cela fonctionnerait ?

Mettre tous ensemble

Par conséquent, 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 souhaitez tout cacher dans un inventaire YaML normal d'une personne en bonne santé, cela peut 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 « gathering = smart/explicit » et « forks = 20 » : 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 du mitogène
- Où est-ce que c'est à propos de Mitogen ? - vous avez le droit de demander, cher lecteur. Nulle part dans cet article. Mais si vous êtes vraiment prêt à lire son code et à comprendre pourquoi votre playbook plante avec Mitogen, mais fonctionne bien avec Vanilla Ansible, ou pourquoi le même playbook fonctionnait bien avant, mais après une mise à jour a commencé à faire des choses étranges - eh bien, Mitogen pourrait potentiellement être votre outil. Appliquez-le, comprenez-le, écrivez des articles - je le lirai avec intérêt.

Pourquoi est-ce que je n'utilise pas personnellement Mitogen ? Parce que Gladiolus ne fonctionne que tant que les tâches sont vraiment simples et que tout va bien. Cependant, si vous tournez un peu à gauche ou à droite, ça y est, nous y sommes : en réponse, une poignée d'exceptions indistinctes volent vers vous, et pour compléter le tableau, il ne manque que la phrase courante « merci à tous ». , tout le monde est libre. En général, je ne veux tout simplement pas perdre de temps à découvrir les raisons du prochain « coup clandestin ».

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

Seuls les utilisateurs enregistrés peuvent participer à l'enquête. se connecters'il te plait.

Parmi les paramètres Ansible suivants, lesquels utilisez-vous pour accélérer vos projets ?

69,6%pipeline = true32
34,8%rassemblement = intelligent/explicite16
52,2%ssh_args = "-o ControlMaster=auto -o ControlPersist=..."24
17,4%méthode_transfert = piped8
63,0%fourches = XXX29
6,5%Rien de tout cela, juste Mitogen3
8,7%Mitogène + je noterai lequel de ces paramètres4

46 utilisateurs ont voté. 21 utilisateur s'est abstenu.

Vous voulez en savoir plus sur Ansible ?

78,3%oui, bien sûr54
21,7%oui, je veux juste plus de trucs hardcore !15
0,0%non, et ce n'est nécessaire à rien0
0,0%non c'est compliqué !!!0

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

Source: habr.com

Accélérer Ansible