🥇Ansible beschleunigen

Es ist kein Geheimnis, dass Ansible mit den "Standard-Einstellungen" nicht immer schnell arbeitet. In diesem Artikel werde ich auf einige Gründe dafür hinweisen und nützliche Minimaleinstellungen vorschlagen, die möglicherweise die Geschwindigkeit Ihres Projekts erheblich steigern können.

Hier und im Folgenden diskutieren wir Ansible 2.9.x, das in einer neu erstellten virtualenv mit Ihrer bevorzugten Methode installiert wurde.

Nach der Installation erstellen wir neben Ihrem Playbook die Datei „ansible.cfg“ – diese Positionierung ermöglicht es, die Einstellungen zusammen mit dem Projekt zu übertragen, außerdem werden sie ganz automatisch geladen.

Pipeline-Implementierung

Man hat vielleicht schon gehört, dass Pipelining erforderlich ist, d.h. anstelle von Modulen, die in das Dateisystem des Zielsystems kopiert werden, wird ein in Base64 kodiertes ZIP-Archiv direkt an stdin des Python-Interpreters übergeben, einige haben es vielleicht gehört, andere nicht, aber die Tatsache bleibt bestehen: diese Einstellung bleibt nach wie vor unterschätzt. Leider hatten einige der beliebten Linux-Distributionen standardmäßig das sudo nicht optimal konfiguriert – sodass dieser Befehl ein tty (Terminal) erforderte. Daher wurde diese sehr nützliche Einstellung in Ansible standardmäßig deaktiviert.

pipelining = True

Fakten sammeln

Wussten Sie, dass Ansible mit den Standardeinstellungen für jeden Play das Sammeln von Fakten für alle beteiligten Hosts initiiert? Wenn Sie das bisher nicht wussten, dann wissen Sie es jetzt. Um dies zu verhindern, müssen Sie entweder den expliziten Modus für die Faktensammlung aktivieren oder den smarten Modus. In letzterem Fall werden Fakten nur von den Hosts gesammelt, die in früheren Plays nicht aufgetreten sind.
UPD. Beim Kopieren müssen Sie eine dieser Einstellungen auswählen.

gathering = smart|explicit

Wiederverwendung von SSH-Verbindungen

Wenn Sie Ansible jemals im Debug-Mode ausgeführt haben (Option „v“, wiederholt von eins bis neun Mal), haben Sie vielleicht bemerkt, dass SSH-Verbindungen ständig hergestellt und getrennt werden. Auch hier gibt es einige Feinheiten.

Das Vermeiden einer Neuanmeldung für die SSH-Verbindung kann auf zwei Ebenen geschehen: sowohl direkt im SSH-Client als auch beim Übertragen von Dateien auf den verwalteten Host von der Steuerung aus.
Um die bestehende SSH-Verbindung wiederzuverwenden, genügt es, die erforderlichen Schlüssel an den SSH-Client zu übergeben. Dieser wird dann Folgendes tun: Bei der ersten Einrichtung der SSH-Verbindung wird zusätzlich ein sogenannter Control-Socket erstellt, bei folgenden Verbindungen wird die Existenz dieses Sockets überprüft und bei Erfolg die bestehende SSH-Verbindung wiederverwendet. Damit das Ganze sinnvoll ist, legen wir eine Zeitspanne für die Beibehaltung der Verbindung bei Inaktivität fest. Nähere Informationen finden Sie in der Dokumentation zu SSH, und im Kontext von Ansible verwenden wir einfach die „Weiterleitung“ der erforderlichen Optionen an den SSH-Client.

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

Für die Wiederverwendung einer bereits geöffneten SSH-Verbindung beim Übertragen von Dateien auf den verwalteten Host reicht es aus, eine weitere unbekannte Einstellung, ssh_transfer_method, anzugeben. Die Dokumentation dazu ist äußerst mangelhaft und irreführend, da diese Option durchaus funktionsfähig ist! Das Lesen von Quellcode hilft zu verstehen, was genau passieren wird: Auf dem verwalteten Host wird der Befehl dd ausgeführt, der direkt mit der benötigten Datei arbeitet.

transfer_method = piped

Übrigens existiert diese Einstellung auch im Branch „develop“ und ist nirgendwo verschwunden..

Fürchte nicht das Messer, fürchte die Gabel.

Eine weitere nützliche Einstellung sind die Forks. Sie bestimmen die Anzahl der Arbeitsprozesse, die gleichzeitig mit den Hosts verbunden werden und Aufgaben ausführen. Aufgrund der Besonderheiten von Python als Programmiersprache werden Prozesse und nicht Threads verwendet, da Ansible immer noch Python 2.7 unterstützt - kein asyncio, hier gibt es nichts Asynchrones zu tun! Standardmäßig startet Ansible fünf Worker, aber wenn man richtig darum bittet, kann es mehr starten:

forks = 20

Ich warne jedoch sofort, dass hier einige Schwierigkeiten auftreten können, die mit dem verfügbaren Arbeitsspeicher auf der verwalteten Maschine zusammenhängen. Mit anderen Worten, es ist zwar möglich, forks=100500 zu setzen, aber wer hat gesagt, dass es funktionieren wird?

Fassen wir alles zusammen

Im Ergebnis könnten die benötigten Einstellungen für die ansible.cfg (ini-Format) so aussehen:

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

Und wenn Sie alles in ein normales YaML-Inventory eines gesunden Menschen verstecken möchten, könnte es ungefähr so aussehen:

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

Leider funktioniert dies nicht mit den Einstellungen „gathering = smart/explicit“ und „forks = 20“: Es gibt keine YaML-Äquivalente dazu. Entweder wir setzen sie in ansible.cfg oder übergeben sie über die Umgebungsvariablen ANSIBLE_GATHERING und ANSIBLE_FORKS.

Über Mitogen
— Wo steht hier etwas über Mitogen? — könnten Sie, geschätzter Leser, fragen. In diesem Artikel — nirgendwo. Aber wenn Sie wirklich bereit sind, dessen Code zu lesen und herauszufinden, warum Ihr Playbook mit Mitogen fehlschlägt, während es mit Vanilla Ansible normal funktioniert, oder warum dasselbe Playbook zuvor einwandfrei lief und nach dem Update seltsame Dinge tut — nun, Mitogen könnte potenziell Ihr Werkzeug sein. Wenden Sie es an, beschäftigen Sie sich damit, schreiben Sie Artikel — ich lese mit Interesse.

Warum ich persönlich Mitogen nicht benutze? Weil es nur funktioniert, solange die Aufgaben wirklich einfach sind und alles gut läuft. Sobald man ein wenig nach links oder rechts abweicht, kommt eine Flut von unverständlichen Ausnahmen zurück, und das einzige, was fehlt, ist die gängige Phrase „Vielen Dank, das Meeting ist beendet.“ Kurz gesagt, ich möchte einfach keine Zeit mit der Ursachenforschung für ein weiteres „unterirdisches Klopfen“ verschwenden.

Einige dieser Einstellungen wurden während der Untersuchung gefunden. Quellcode Der Verbindungs-Plugin mit dem sprechenden Namen „ssh.py“. Ich teile die Ergebnisse dieser Untersuchung in der Hoffnung, dass es auch andere inspiriert, den Code zu durchforsten, zu lesen, die Implementierung zu überprüfen und mit der Dokumentation zu vergleichen — denn das wird Ihnen früher oder später positive Ergebnisse bringen. Viel Erfolg!

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte melden Sie sich an.Sind Sie an Contour interessiert?