Remote-Automatisierungstools unter Linux
Angenommen, man hat eine Computerumgebung unter Linux, die statisch und persistent ist. Ich habe Einweg-SSH-Verbindungen und die Infrastruktur ist vertrauenswürdig - es ist meine.
Es gibt eine Vielzahl von Marken-Tools für Unternehmen, z. B. Ansible, die mit vordefinierten Routinen geliefert werden. Wenn man sie modifizieren will, sind sie letztendlich ein Schmerz.
Als nächstes haben Sie Ihre Airflows (Dags) und Luigis (Gnu-Make-Klon in Python; Python ist eine niedrigere Sprache als make und bash, ohne Unterstützung für binäre Schnittstellen im Gegensatz zu make). Dies ist ein Schmerz in dem Sinne, dass man Low-Level-Code für High-Level-Aufgaben schreiben muss (Python ist zu einer Low-Level-Sprache mit einem Tipp- und Versionsproblem geworden), und man muss sich mit dem Python-Gepäck (dem virtuellen env /) befassen. anaconda / plattformübergreifendes Interop), um etwas zu nutzen.
Rund um diese "Produkte", Schemata und Tools gibt es die nativen Unix / Linux-Betriebssysteme und Docker-Images, die "einfach funktionieren".
In diesen Docker-Images und Subsystemen (Windows-Subsystem für Linux) befinden sich all diese Tools, die "einfach funktionieren", einschließlich des 50 Jahre alten Projekts "Make" sowie zsh/bashneben parallelund ssh.
makeist in der Tat völlig allgemein gehalten, und wenn ich eine schnelle Automatisierung schreiben möchte, ist sie weitaus schneller als alles, was ich in ein oder zwei Wochen mit luigi/ tun könnte airflow. Es dient auch dazu, neue Werkzeuge zu identifizieren: Wenn etwas zu kompliziert wird, sollte es sich eindeutig um ein gepacktes Werkzeug in einer niedrigeren Sprache handeln.
Außerdem fallen keine Fixkosten an, die durch das Herumschleppen des Python-Stapels von Abhängigkeiten über verschiedene Linux-Distributionen und -Fenster entstehen.
Es scheint jedoch eine fehlende Kachel zu geben: Die Effektivität von make schwächt sich ab, sobald ich eine Aufgabe automatisieren möchte, die auf einer Remote-Box ausgeführt wird. Ich habe es versucht, ssh -c "..."aber es war ein bisschen kludge.
Auf der Suche nach einer Problemumgehung bin ich auf pachyderm(Data Science Data Versioning), luigi(Make Clone) airflow(kein Spaß) ansible(wieder: Tinkery Python-basierte Zeitsenke ) gestoßen, und vielleicht gibt es noch andere.
Ich bin auch auf ein Werkzeug aus den 1980er / 90er Jahren gestoßen, das als expectund bekannt ist autoexpect. Dieses Tool scheint nativ zu sein linuxund fällt in die Kategorie "funktioniert einfach" unter Windows-Subsystemen für Linux, Cygwin, meine Remote-Linux-Computer usw.
Es scheint genau das Richtige zu sein, und noch besser passt es gut zu meinem makeAutomatisierungsansatz. Ich bin im Allgemeinen völlig in Ordnung automation.exp, wenn die Skripte innen verrauscht sind, da sie automatisch generiert werden. Der wichtige Teil ist, dass der Mensch Komponenten erstellt hat - die kleinen components.exppassen ohne Unsinn zusammen (die gesamte Flusskontrolle, Konfiguration, Benutzeranmeldungen, Dokumentation und Installationsgepäck, die mit neuen Werkzeugen verbunden sind).
Es handelt sich jedoch autoexpectum einen Makrorecorder, und vieles, was Sie damit tun möchten, beinhaltet nicht deterministische Antworten von der Remote-Maschine. Dies stellt ein Problem dar, es sei denn, Sie nehmen sich die Zeit, expectExperte zu werden.
Abgesehen von der Präambel war ich neugierig: Gibt es Alternativen dazu autoexpect, die auch systemübergreifend in die Kategorie "nur" Werke fallen?
Und um das Offensichtliche einzuschränken, muss ich nicht nach meinem Automatisierungssystem suchen, um Maschinen herumzuschleppen, um virtuelle Python-Umgebungen zu installieren und zu warten - ich habe es satt, mit diesem Durcheinander fertig zu werden.
Antworten
Für die Remote-Ausführung sollten Sie sich Folgendes ansehen env_parallel:
dostuff() {
mystuff "$@" } alias mystuff='echo $my'
my=My
env_parallel -S server dostuff ::: a b c
Die Idee ist hier, GNU Parallel die Umgebung auf den Remote-Server kopieren zu lassen. Dies erleichtert das Definieren komplexer Funktionen auf dem lokalen Server und deren Remote-Ausführung, ohne dass Sie sich mit dem Zitierzirkus befassen müssen, mit dem Sie möglicherweise in Kontakt kommen ssh -c "...".
Es ist unklar, ob Sie die Interaktivität von benötigen expect. Wenn ja, wird dies Ihren Anforderungen nicht entsprechen.