LINUX.ORG.RU

способы удаленного запуска python-скриптов

 ,


0

2

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

  • запускать программу на «запускаторе», который через ssh будет отправлять последовательно команды на целевые машинки
  • разлить скрипт по машинкам по ssh и уже локальный скрипт дергать удаленно
  • использовать монструозную систему управления конфигурациями

или это зависит требований и контекста? какие еще варианты?

Ответ на: комментарий от router

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

chenbr0 ()
Ответ на: комментарий от chenbr0

это третий пункт

Нет, это четвертый.

Ansible становится монструозным когда на нем делаются монструозные вещи.

А для твоей задачи ansible playbook будет в три раза короче и проще чем любой баш-скрипт который ты попробуешь написать самостоятельно. Строчек в пять можно уложиться.

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

alpha ★★★★★ ()
Последнее исправление: alpha (всего исправлений: 1)
Ответ на: комментарий от alpha

попробуешь написать самостоятельно

Как будто это что-то плохое.
Часто написать скрипт намного проще.
Зачем городить огород, который нужен только для 1.5 землекопа.
А если машин станет больше, обход скриптом по списку машин не сильно изменит трудоемкость.

TomBOY ()
Ответ на: комментарий от TomBOY

Часто написать скрипт намного проще.

Не в случае ansible.

А если машин станет больше, обход скриптом по списку машин не сильно изменит трудоемкость.

И добавление retry не сильно изменит, и параметризация машин, и чуть-чуть разные версии систем. и таймаут, и debug-лог... и потом раз: и у тебя нечитаемая простыня на 100500 строк на баше. Откуда ж она взялась, вроде всё «просто» было?

alpha ★★★★★ ()
Ответ на: комментарий от alpha

И добавление retry не сильно изменит, и параметризация машин, и чуть-чуть разные версии систем. и таймаут, и debug-лог..

А в случае Ansible открывать все эти радости жизни ему не придется? Ansible это выжимка лучшего опыта, это ему поможет, но на это тоже придется немало потратить времени.

TomBOY ()
Ответ на: комментарий от chenbr0

чем ансибль лучше дженкинса, папета и тд?

Это совсем разные категории

Дженкинс - это java-комбайн: планировщик, очередь, обработчики, пост-хуки, web UI, groovy и нечитаемые exceptions.

Puppet - это мастер-слейв, программирование на ruby, ООП, сложные зависимости..

ansible, в своем простейшем варианте, без Tower и фишечек, это по сути аннотированный баш-скрипт. То есть берешь свой скрипт и из каждой строчки делаешь шаг в yaml-е добавив строку описания.

От

#!/bin/bash

dnf install smth
service start smth

к

- name: "Install smth"
  run: "dnf install smth"

- name: "Start service smth"
  run: "service start smth"
...

Потом конечно чуть подумаешь и заменишь стандартные команды на готовые обертки.

- name: "Install smth if not installed"
  pkg:
    name: "smth"
    state: installed

- name: "Start service smth, if not started"
  service:
    name: smth
    state: started
...

и пошла эволюция.

И он не требует никакой предварительной инфраструктуры кроме ssh-доступа на сервер.

alpha ★★★★★ ()
Последнее исправление: alpha (всего исправлений: 1)

Использовать ansible. Он не монструозный, умеет первые два пункта в любых комбинациях и делает это заведомо лучше чем набыдлокодишь ты.

slovazap ★★★★★ ()

Ансибл бери, если тебе не нужно смотреть глазами в вывод, того, что делается, ибо добиться от ансибла нормального вывода очень не просто.

Difrex ★★★★ ()