Fabric: Хуки удаленного выполнения Python

Шон Хейс (Sean_Hayes) написал:

Я создал форк на GitHub: https://github.com/SeanHayes/fabric

В Fabric.decorators я добавил декоратор run_on_remote. Это своего рода дистанционная казнь бедняка.

По сути, когда вы оборачиваете в него функцию, если env.hosts не пуст, декоратор запустит «fab func_name» на хосте вместо того, чтобы позволить функции выполняться локально. Например:

from fabric.api import *

env.hosts = []

def remote():
    env.hosts = ['your_host']

@runs_on_remote(remote_fabfile_path='/path/to/fabfile/dir/')
def foo():
    print local('ls /')

Локальный запуск fab remote foo приведет к запуску fab foo на your_host.

16 января 2011 г., 20:27 по восточному поясному времени

Больше прогресса в этом. После использования ткани некоторое время, я вижу это как одну из больших недостающих частей. Возможность писать удаленные служебные методы на чистом питоне, безусловно, может упростить написание удаленных задач.

Нет комментариев == нет прогресса, извините :) Это не сильно блокирует большинство пользователей - большинство в основном комфортно работает со сценариями оболочки. Так что, хотя это _определенно_ в верхней части списка "хорошо иметь", он все еще в списке "хорошо иметь".

Я ожидаю, что это будет рассмотрено более подробно, когда мы приступим к организации версии 2.x (где-то в ближайшие несколько месяцев, если не раньше), так как это прекрасное время, чтобы сделать «выполнить X в месте Y» более абстрактной операцией.

Одно упрощение, которое, возможно, стоит рассмотреть, — это возможность просто запустить временный скрипт Python в удаленной системе. Я даже рассматривал способ сделать это вручную, создав файл «remote_utils.py» или что-то, что я помещал в удаленную систему при запуске, а затем вызывал этот скрипт с именем функции, которую я хочу запустить в модуле.

Предполагая, что вы имеете в виду какую-то форму «скопировать локальный .py в удаленную систему, выполнить ее, а затем, возможно, снова удалить», да, это тоже иногда пинают. (См. даже некоторые комментарии выше.)

Но для этого не требуется поддержка ядра, поэтому он, вероятно, будет принадлежать вашей локальной библиотеке кода или, например, Patchwork .

Я просто хотел бы отметить, что уже есть библиотека, разветвленная из 'sshuttle', которая реализует это:

Remote Exec позволяет отправлять код Python на удаленную машину и запускать его там, не устанавливая ничего, кроме стандартного интерпретатора Python на сервере.

Он подключается к удаленному хосту с помощью SSH, отправляет указанные вами файлы Python, компилирует их на сервере и передает управление указанной основной функции.

Кроме того, клиент обеспечивает подключение stdin/stdout на стороне сервера к сетевому сокету на стороне клиента, чтобы вы могли взаимодействовать с загруженным двоичным файлом сервера, как если бы вы подключались к нему в обычном режиме.

https://bitbucket.org/danderson/py-remoteexec

Тем не менее, исходный код (и, следовательно, ответвление тоже) находится под лицензией GPLv2, и я не уверен, что авторы захотят повторно лицензировать его.

@bitprophet Я думал о том же, что это может быть локальный модуль расширения. Я просто не нашел хорошей реализации, которую я мог бы скопировать и улучшить. Если кто-то знает о таком, я хотел бы увидеть его и попробовать.

@abierbaum Проверьте библиотеки, перечисленные в # 461, я уверен, что по крайней мере одна из них может иметь некоторую реализацию этого.

Фантастическая реализация будет просто иметь декоратор @remote для любой функции Python, и при вызове фактическая функция запускается на удаленной цели. Из указанных библиотек execnet кажется лучшим, но и самым сложным. (Просто пропуская документацию).

Различные подходы «поместить код на сервер и запустить его» не кажутся более полезными, чем просто «поместить» файл, запустить его с помощью sudo и удалить. Не говоря уже о том, что этот метод позволяет запускать любой код, а не только код Python.

Это то, что было бы очень полезно для меня, если бы это работало хорошо. например, я хотел бы использовать что-то вроде _psutils_ для управления процессами, а не методы ps > grep > awk > kill, которые я должен использовать сейчас.

Если бы кто-то захотел реализовать это, какой метод вы бы, скорее всего, включили в вклад?

Почему бы просто не

print run("""python -c 'import re
m = re.search("1", "m1m")
print m'""")

[localhost] run: python -c 'import re
m = re.search("1", "sfsdf1231231231dfads")
print m'
[localhost] out: <_sre.SRE_Match object at 0x1086cd8b8>

Недавно я добавил обходной путь (поставить, запустить, удалить) в Patchwork, https://github.com/fabric/patchwork/blob/master/patchwork/commands.py#L11 — это первый черновик, поэтому можно использовать какая-то любовь когда-нибудь, я уверен.

Это работает, если ваши функции автономны, поэтому вам нужно импортировать в тело функции.

def rpc(f):
    @wraps(f)
    def wrapper(*l, **kw):
        c = 'python -c "import marshal,pickle,types;types.FunctionType(marshal.loads(%r),globals(),%r)(*pickle.loads(%r),**pickle.loads(%r))"'
        c = c % (marshal.dumps(f.func_code),f.func_name,pickle.dumps(l),pickle.dumps(kw))
        run(c)
    return wrapper

Пример:

<strong i="9">@task</strong>
<strong i="10">@rpc</strong>
def f(): print 1+1

Работает нормально, но ткань терпит неудачу при сериализации длинных функций в своем bash, избегающем механизма.
Дизайн ткани полностью ошибочен, потому что ее API, run(string) подразумевает побег.
Правильный API запуска должен быть run(cmd=[]), где cmd — это список.
Ткань не должна экранироваться, а должна сериализоваться, и вместо строки exec /bin/sh -c следует использовать execv.
run(string) может поддерживаться, но его использование не рекомендуется.

Если ssh не поддерживает execv char *const argv[], то на удаленной стороне следует использовать небольшой хелпер, мы могли бы сделать этот хелпер на python или на perl. Этот помощник также может поддерживать python rpc, как в примере выше.

Итак, я попробовал то, что @antonylesuisse предложил выше, но столкнулся с некоторыми проблемами. По какой-то причине я не мог импортировать модули напрямую, и даже если бы я импортировал их на удаленной стороне с помощью exec, как только я попытался бы получить к ним доступ, интерпретатор выдал бы segfault. Похоже, это может быть связано с тем, что я запускаю разные версии Python, причем версия Python, на самом деле работающая с тканью, находится в среде miniconda.

Вот несколько функций, которые помещают исходный код, выполняют его после обработки/распаковки аргументов, а затем возвращают обработанный ответ по сети прямо из выходного файла. Я думаю, что это должно избежать каких-либо проблем с выходом из оболочки. Конечно, ответы по-прежнему должны быть доступными/недоступными для обработки, но до тех пор, пока они есть, кажется, что они работают нормально.

Пример скрипта прилагается.
rpc_example.py.zip
.
Это по-прежнему не интерактивно, но, по крайней мере, вы можете запускать с ним неинтерактивный код. Кто-нибудь занимался интеграцией execnet или Pushy?

@raddessi Кажется, палочки для еды могут быть библиотекой, которую вы ищете.

я использовал ткань как палочки для еды. и я думаю, что это очень просто.
在 Пт, 18 августа 2017 г. 14:23:20 +0000 (UTC)
Фабьен Мегази[email protected]已寫入：

@raddessi Кажется, что
Палочки для еды могут быть
библиотека, которую вы ищете.

https://mitogen.readthedocs.io/en/latest/ является новичком на этой сцене, и хотя я уже не помню, как именно работают другие, перечисленные выше, этот буквально запускает удаленный интерпретатор Python в памяти ( не требует удаленной установки Python; использует SSH — но не Paramiko, соб) и проталкивает в него код для выполнения.

По-видимому, это также может заставить подпроцессы использовать локальный процесс для SSH, что позволяет ему делать такие вещи, как SFTP-over-sudo (я не совсем понимаю, как это работает, но еще не читал источник).

Однако это не совместимость с Python 3, и утверждается, что у него нет планов, поэтому может быть блокировщиком, поскольку Fabric 2 / Invoke явно совместим с 2 + 3.

@bitprophet «Mitogen — это библиотека Python для написания распределенных самовоспроизводящихся программ». Действительно ли это подходит. Почему не Ансибль? Вы смотрели на Ansible? Мне любопытно, что вы думаете. Мы перешли с ткани на соль, но я ею не на 100% доволен. Думаю, в следующий раз я бы воспользовался Ansible.

Некоторое время назад я изучил и Salt, и Ansible, и мне они не очень понравились. Тем не менее, я считаю, что Fabric в основном ортогонален подобным «полным» системам управления конфигурацией, поэтому это не совсем справедливое сравнение. (Вы можете получить, скажем, 75-85% пути с помощью Fabric, как это делают многие люди, и я хотел бы улучшить это там, где мы можем, но Fabric всегда будет скорее библиотекой типов строительных блоков снизу вверх. тогда как большинство инструментов CM, таких как Salt/Ansible/Chef/Puppet, больше похожи на нисходящие фреймворки.)

@bitprophet спасибо за ответ.

Я не доволен солью, я не доволен тканью.

Ткань иногда похожа на «удаленное выполнение оболочки». Я перешел со сценариев оболочки на Python несколько лет назад, так как люблю трассировку и исключения. Оболочка, подобная выполнению (при ошибке запись в stdout/stderr и продолжение со следующей строки) неприемлема в моем контексте. Я предпочитаю неперехваченные исключения «продолжению при ошибке», особенно в производственных системах.

Ткань казалась шагом назад.

Мы использовали его несколько раз, но перешли на соль.

Но соль слишком сложна.

В моей команде большинство разработчиков пренебрежительно относятся к соли.

С тканью было иначе.

Я сижу между стульями.

Я не пробовал Ansible до сих пор. Но он кажется проще, и это важно для меня.

Надеюсь, следующие слова не задели вас. ... Я думаю, что не вернусь на ткань.

Для меня ткань — это инструмент удаленного исполнения. SaltStack/Ansible/Puppet/Chef — это своего рода платформа управления состоянием. Цель другая.
Fabric предоставляет простой способ управления удаленным хостом. Некоторые библиотеки предлагают фрагменты кода для Fabric. Это направление «Государственное управление».
Если мы хотим, чтобы Fabric решил более сложную проблему удаленного выполнения, он просит пользователей написать свои компоненты для обработки соединения или другого персонала. Митоген подходит для этого случая.

Оболочка, подобная выполнению (при ошибке запись в stdout/stderr и продолжение со следующей строки) неприемлема в моем контексте. Я предпочитаю неперехваченные исключения «продолжению при ошибке», особенно в производственных системах.

Справедливости ради следует отметить, что Fabric не должен продолжать работу из-за ошибки, поэтому, если вы видите это, происходит что-то еще.

Тем не менее, это все еще не так чисто с точки зрения исключений, как хотелось бы (в основном, все ошибки приводят к SystemExit), а версия 2 строится так, чтобы быть намного более удобной для исключений (с SystemExit поднимается только на самых внешних краях окна). программа.)

Привет @bitprophet , просто хочу отметить, что поддержка Python 3 для Mitogen в наши дни является более явной целью. Это не займет больше пары недель, и в любом случае необходимо поддерживать Ansible в следующих версиях Fedora.

Привет, @bitprophet , еще одна заметка о том, что Python 3 в последний раз достиг мастера, и результат будет на PyPI в качестве первого выпуска стабильной серии к завтрашнему вечеру. Поддержка «fakessh» в настоящее время нарушена и не входит в область применения, но я умираю от желания застрять в ее исправлении и обобщить ее для пересылки TCP/UDP/pipe — надеюсь, что после того, как этот депрессивный период Python 3 позади, энергия вернется и много нового будет происходить очень быстро :)

Круто, рад это слышать @dw! Я не знаю, когда у меня будет время взглянуть на интеграцию Mitogen с моей стороны, но я очень рад, что теперь барьер версии интерпретатора исчез 👍

@bitprophet какие-нибудь обновления по этому поводу?

@bitprophet эта функция очень полезна для нашей цели (удаленная отладка), мы будем рады помочь в реализации любым возможным способом.

я только что узнал о митогене, и я думаю, что это был бы отличный бэкэнд для ткани.

на самом деле, я думаю, что это может с успехом заменить большую часть кода ткани (и, возможно, большую часть pyinvoke). он удаляет различие «особого случая» между тканью/вызовом (ssh/local) и объединяет все это в волшебный «контекст», который также работает с такими бэкэндами, как «sudo», более прозрачно, чем ткань (ИМХО).

прямо сейчас я действительно чувствую боль от этой функции, отсутствующей в ткани. я рассматриваю реализацию все более и более сложной бизнес-логики на удаленном конце. прямо сейчас это включает в себя передачу файлов туда и обратно с sftp , чтобы убедиться, что все правильно настроено, и это немного неуклюже. было бы намного лучше просто сделать это удаленно: просто откройте файл, найдите содержимое, выполните поиск/замену и т. д. становится гораздо более интуитивно понятным.

это также позволяет писать код Python, который можно повторно использовать за пределами структуры. прямо сейчас я не могу этого сделать, если только я не прищуриваюсь очень сильно, потому что, по сути, код Python работает только локально. поэтому мне нужно копировать файлы (или процессы?!) туда и обратно между хостами, чтобы делать то, что мне нужно. это далеко не идеал...

прямо сейчас я нахожусь на стыке: либо я продолжаю идти по маршруту ткани, либо я просто портирую весь свой код на митоген и делаю вокруг него небольшую оболочку исполнителя.. я недостаточно использую функцию fabfile чтобы гарантировать сложность фабрики, в то время как митоген дает мне гораздо более мощные функции для моего основного варианта использования (который включает загрузку и восстановление серверов из гетерогенных сред)...

но я понимаю, что, конечно, есть и другие варианты использования для ткани и вызова. Я просто чувствую, что было бы гораздо более естественно писать собственный код на Python, даже для существующей функциональности в Fabric (например, выполнение кода), потому что это заставит обработку ошибок, управление конвейером и существующие рефлексы работать более или менее нормально...