LINUX.ORG.RU

Удаланное управление сервером на скриптах

 


1

2

Есть у меня одна не сложная в разработке хотелка. Прежде чем начать ее реализовывать, хочу убедиться что я не буду делать велосипед. Поэтому вопрос в следующем, кто-что знает идентичное или подобное следующему концепту.

Концепт:

Программа предназначена для выполнения операций на уделенном сервере. Скриптами для программы являются lua скрипты. Данные скрипты могут взаимодействовать с удаленным сервером в режиме ssh - отправлять команды и обрабатывать их вывод. А так же они могут выполнять другие действия, например передачу файлов на сервер или с него. Особенностью программы является тот факт, что операции являются транзакционными. Т е например есть группа команд, для нее всегда имеется группа команд отката. Если в процессе выполнения скрипта что-то упадет, программа будет иметь транзакционный лог, т е полную последовательность операций отката до первоначального состояния до старта скрипта.

Зачем мне нужна эта программа. У меня есть 0..N dev серверов, которые постоянно приходится реконфигурировать, перезаливать на них сервисы, и делать прочие простые но жутко нудные задачи. Хочется автоматизировать данный процесс и сделать это таким образом, что бы если автоматизация где-то навернется, была возможность такого же автоматического отката до состояния как было до ее запуска.

Кто какие готовые решения знаете подобного рода?

P. S. Тяжелые системы вроде дженкинса в рассмотрение не беру. Мне нужна простая консольная программа, загнал в нее список скриптов, получил ок или ошибку выходе, никаких лишних наворотов.

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

Ну как вариант. Но тут момент в том, что в нем нет как такового скриптования. Я как понял в нем задачи описываются как команды различным модулям, которые являются плагинами для головной программы. Т е допустим я хочу выполнить некоторую интерактивную программу. Мне нужно ветвить логику в зависимости от того, что я получаю в вывод. Исходя из того, как я понял принцип работы ансибля, мне нужно будет писать к нему плагин на питоне, который будет работать с этой конкретной интерактивной программой и уже через yaml нужно задавать его вызов. Ну и не очень ясно есть ли в нем транзакционность. Вот выполнил он 50 операций, а на 51ой при попытке установки пакета ему apt сообщил - иди как ты нахрен, сертификат у репозитория протух, не буду ставить этот пакет. Не очень ясно что произойдет далее. В моем представлении хотелось бы получить откат, так как как правило это оборачивается полной лажей. Лучше есть старую версия сервера, чем почти новую но полностью нерабочую.

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

Ну вот я и хочу понять что это за подобные решения. Вот aquadon предложил Ansible. Я почитал доки, ну да круто, но уж больно абстрактная система получается. Писать под каждый нестандартный чих модули к нему не айс. По такой логике я могу с таким же успехом под каждую задачу просто отдельный скрипт на питоне или tcl написать. Плюс нет транзакционности в нем (и принципе очевидно почему, потому что там не как таковой системы скриптования, система полностью перекладывает данную задачу на модули).

Поэтому пока задача велосипедостроения остается актуальной.

Serbis ()

Зачем мне нужна эта программа. У меня есть 0..N dev серверов, которые постоянно приходится реконфигурировать, перезаливать на них сервисы, и делать прочие простые но жутко нудные задачи. Хочется автоматизировать данный процесс и сделать это таким образом, что бы если автоматизация где-то навернется, была возможность такого же автоматического отката до состояния как было до ее запуска.

rundeck+ansible+zfs snapshot. Фиг знает ещё сходу)

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

Плюс нет транзакционности в нем

Конкрено с ansible я не знаком, но по-моему идея транзакционности заведомо гиблая. Все возможные косяки не предусмотришь, это будет работать только при небольших апдейтах, но скорее всего всё равно руками придётся лезть.

Если у тебя много серверов и дистры не совсем ископаемые, то проще будет по максимуму напихать софт в контейнеры и взять тот же ansible.

WitcherGeralt ★★ ()

Фраза «Если в процессе выполнения скрипта что-то упадет, программа будет иметь транзакционный лог, т е полную последовательность операций отката до первоначального состояния до старта скрипта» особенно смешна. Накатываете вы пакет, а пост-инсталл скрипт по-быстрому создает вам пару юзеров. Так что программа будет думать что откатила, но не факт что это будет иметь место

Nastishka ★★★☆ ()

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

targitaj ★★★★★ ()

Есть много прог позволяющих выполнять список команд на удалённом оборудовании.

Вот по поводу безошибочности этого списка. Тестируй предварительно, оборудование должно быть одинаково. Семь раз отмерь один раз отрежь.

Есть вендорагнтстик решения, например когда-то написал прогу которая VLAN в сети разношерстнтго оборудования прошибала: оператор вводил два крайних девайса, номера портов на них, тегированные или нет порты и жал кнопку. Прога вычисляла все или кратчайший путь, определяла какой тип оборудования на узлах по пути используется, какие команды надо выполнить для настройки статического VLAN на каждом узле, выполняла их и записывала в конфиги этого оборудования, чтобы после перезагрузки VLAN не пропадал. Ну и прочие фичи имела: карты VLAN-ов строила, выдавала инфу какие порты принадлежат каким VLAN-ам или наоборот. Удаляла VLAN с сети, на всем оборудовании.

К чему это я. Задача пробивки VLAN-а - сложная, трудоемкая и в принципе давала много ошибок, кольца делала трудно обнаруживаемые и прочие. Но после внедрения моего ПО ошибки исчезли как таковы, а VLAN-ами смогли управлять даже пяные монтажников, которые даже словосочитания cisco cli не слышали.

Ошибается человек всегда в какой-то рутене, какие-то команды опции призабудет. Если решился писать скрипты надо делать вендорагностик систему, где вся рутина, хорошо вылизана спрятана под капотом. А человек только глобальные вещи говорит системе, что зделать.

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

Накатываете вы пакет, а пост-инсталл скрипт по-быстрому создает вам пару юзеров. Так что программа будет думать что откатила, но не факт что это будет иметь место

Это потому, что в линуксах всё через жёппу, в солярисе и фре вполне себе работают boot environments на снапшотах zfs, и хотя в nixos и есть похожая концепция, это не совсем то, и beadm даже кто-то портировал под линукс, только работает оно вестимо как.

С одиночным пакетом, понятное дело, be не вариант, но кто же тебе виноват, что ты в сценарии отката не прописала удаление этих пользователей?

anonymous ()

То, что вы хотите, можно сделать. Но сделать это будет тяжело, потому как основные дистрибутивы (т.е. все кроме Guix и Nix) плохо умеют откатывать изменения. Гораздо проще реализовать сценарий:

  • Есть Ansible playbook, задающий конфигурацию сервера/ов.
  • Естественно под системой управления версиями.
  • В случае ошибки уничтожаем поломанный сервер, создаём новый и накатываем рабочую конфигурацию с нуля.
ugoday ★★★★★ ()

Ну в общем перечитал я кучу всего. Исследовал такие продукты как Puppet, Chef и Anisble. Все это в общем не то что нужно. Вернее частично. Все эти продукты рассчитаны на очень долгую подготовку и длительно использование на идентичных группах задач. Моя же цель иметь под рукой максимально подвижный набор скриптов. На практике мне получается нужны из эти систем только концепции рецептов, при этом рецепты должны быть сами по себе скриптами а не описаниями для модулей.

Посему пришел я к такому тривиальному решению - libssh + lua с hight level api между ними.

Serbis ()