Outils d'automatisation à distance sous Linux
Supposons que l'on dispose d'un environnement informatique, sous Linux, qui est statique et persistant. J'ai des connexions SSH unidirectionnelles et l'infrastructure est fiable - c'est la mienne.
Il existe une variété d'outils «d'entreprise» de marque, tels que ansible, qui sont livrés avec des routines prédéfinies. En fin de compte, si on veut les modifier, c'est une douleur.
Ensuite, vous avez vos flux d'air (dags) et Luigis (clone gnu-make en python; python est un langage de niveau inférieur à make et bash, sans prise en charge de l'interface binaire d'application, contrairement à make). C'est une douleur dans le sens où il faut écrire du code de bas niveau pour les tâches de haut niveau (python est devenu un langage de bas niveau avec un problème de frappe et de versioning), et vous devez gérer le bagage python (l'environnement virtuel / anaconda / interopérabilité multiplateforme) afin d'utiliser quoi que ce soit.
Tout autour de ces «produits», schémas et outils, il existe les systèmes d'exploitation natifs unix / linux et les images docker qui «fonctionnent».
À l'intérieur de ces images et sous-systèmes de docker (sous-système Windows pour Linux), vous avez tous ces outils qui "fonctionnent juste", y compris le projet vieux de 50 ans, "Make", et à zsh/bashcôté parallelet ssh.
makeest en fait totalement générique, et quand je voudrais écrire une automatisation rapide, c'est de loin plus rapide que tout ce que je pourrais faire en, disons, une semaine ou deux avec luigi/ airflow. Cela sert également à identifier de nouveaux outils: si quelque chose devient trop compliqué, il devrait clairement s'agir d'un outil emballé dans une langue de niveau inférieur.
De plus, je n'engage aucun coût fixe lié au déplacement de la pile de dépendances python entre différentes distributions et fenêtres Linux.
Cependant, il semble qu'il manque une tuile: l'efficacité de make affaiblit le moment où je voudrais automatiser une tâche qui s'exécute sur un boîtier distant. J'ai essayé ssh -c "..."mais cela a fini par être un peu un kludge.
Dans la recherche d'une solution de contournement, j'ai rencontré pachyderm(gestion des versions des données de la science des données), luigi(faire un clonage), airflow(pas amusant), ansible(encore une fois: un puits de temps basé sur Python bricolé), et peut-être qu'il y en a d'autres.
J'ai également rencontré un outil des années 80/90 connu sous le nom de expectet autoexpect. Cet outil semble être natif de linux, et tombe dans la catégorie "fonctionne juste" sur le sous-système Windows pour linux, cygwin, mes machines Linux distantes, etc.
Cela semble correspondre à la facture, et mieux encore, il s'intègre bien dans mon makeapproche de l'automatisation. Je suis, en général, tout à fait d'accord avec le fait que les automation.expscripts soient bruyants à l'intérieur, car ils sont générés automatiquement. La partie importante est que les composants créés par l'homme - les petits components.exps'intègrent sans aucun non-sens kludge-y (tout le contrôle de flux, la configuration, les connexions utilisateur, la documentation et les bagages d'installation associés aux outils new-age).
Cependant, il autoexpects'agit d'un macro-enregistreur, et une grande partie de ce que vous pourriez vouloir en faire implique des réponses non déterministes de la machine distante. Cela pose un problème, à moins que vous ne preniez le temps de devenir un expectexpert.
Laissant de côté tout le préambule, j'étais curieux: y a-t-il des alternatives à autoexpectcela qui tombent également dans la catégorie «juste» des œuvres dans ces systèmes?
Et, pour limiter l'évidence, ne pas chercher mon système d'automatisation pour m'obliger à trimballer des machines pour installer et maintenir des environnements virtuels python - marre de gérer ce désordre.
Réponses
Pour une exécution à distance, vous pouvez consulter env_parallel:
dostuff() {
mystuff "$@" } alias mystuff='echo $my'
my=My
env_parallel -S server dostuff ::: a b c
L'idée est ici de laisser GNU Parallel copier l'environnement sur le serveur distant. Ainsi, il est plus facile de définir des fonctions complexes sur le serveur local et de les faire fonctionner à distance sans avoir à gérer le cirque de citations dans lequel vous pourriez entrer ssh -c "...".
Il n'est pas clair si vous avez besoin de l'interactivité de expect. Si tel est le cas, cela ne répondra pas à vos besoins.