LINUX.ORG.RU

Управление демоном из командной строки.


0

2

Например запущен сервис. Он по определенным причинам должен работать постоянно.

Нужно соорудить к нему клиента командной строки чтобы запускать определенные операции в нем. Нужно чтобы сервис имел возможность писать логи в консоль клиента запустившего команду о прогрессе выполнения задачи. Не хотелось бы просто отправлять какие-то сигналы и отдельно tail -f лога делать.

Есть протоколы, примеры, подходы? В принципе понимаю как сделать, могу написать с нуля, хоть бы даже через curl+http. Но я просто хочу найти примеров приложений чтобы посмотреть как существующие приложения которые так делают, поиграться чтобы узнать удобно это, может какие-то нюансы.

Еще нужно упомянуть фактор безопасности. Если использовать сетевое соединение, или например HTTP, то придется возможно пользоваться HTTPS/SSL. Можно обойтись возней с сертификатами напрямую если разрешить только локальный доступ, но для удаленный соединений создавать SSH туннель. Как вам такая идея?

Казалось бы задача простая, но начинаешь делать и появляются вопросы

Альтернативная форма вопроса

Если бы вам дали готовую платформу для разработки приложений и такая функциональность была готовая, как бы вы хотели чтобы она работала внутри?

JMX

JMX видел. Люто доставляет древними консольными клиентами, возней в SSL, java-only, логи не потоком не отправляет (разве что можно вернуть строку статуса)

HTTP/HTTPS

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

★★★★★

Последнее исправление: vertexua (всего исправлений: 5)

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

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

Это сильно. Так КО и я могу. Безопасность городить ручками? SSL? И ясное дело писать дистрибуцию сертификатов. Вот я думаю как приткнуть может SSH, просто потому что тогда я перекладываю много ответственности за все на него

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

xml-rpc как вариант.

MikeDM ★★★★★
()

Не хотелось бы просто отправлять какие-то сигналы и отдельно tail -f лога делать.

Использую websocket. Оператор системы (работает через web-браузер) нажимает кнопку, появляется всплывающее окно, окно подписывается на логи.

На самом деле оператор хочет чтобы выполнилась некая бизнес-логика на стороне сервера, вся эта последовательность действий подписана неким session id. Точнее это акторы с неким sid. Клиенту интересены сообщения только с этим конкретным sid.

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

И как полет?

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

Через HTTPS гоняете?

Пока нет. Хотя система предполагает секурность и буду внедрять https.

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

У вас однокомандные процессы? Тоесть запустили и смотрим. Или бывает что потом задаются дополнительные вопросы и взаимодействие в виде диалога?

А если разрыв соединения, то вы сохраняете позицию до которой логи были закачаны или закачиваете заново? Логи у вас текстовики или в бд по id процесса?

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

У вас однокомандные процессы? Тоесть запустили и смотрим. Или бывает что потом задаются дополнительные вопросы и взаимодействие в виде диалога?

Однокомандные. Никаких диалогов.

А если разрыв соединения, то вы сохраняете позицию до которой логи были закачаны или закачиваете заново? Логи у вас текстовики или в бд по id процесса?

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

Логи которые видит диспетчер дублируются, они видны как json в общем логе (так надо, несколько полей, ну и через WS их передаю). Программисту потом проще разобраться. Команды хранятся в бд (уже писал, постгресс) и преобразуются в очередь специальным демоном (постгрес ивент реактор), который дергает ферму воркеров по http.

outtaspace ★★★
()

Стивенса почитать уже советовали?

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

Логи у вас текстовики или в бд по id процесса?

Забыл конкретику - логи это простые тектовики. В каждом сообщении, помимо статуса (info-error-etc) есть sid. sid очень упрощает дебаг, ибо риалтайм от которого крыша едет.

outtaspace ★★★
()

ЯННП. В любом линуксе есть такой функционал. Выбирай на вкус.

emulek
()

такая функциональность была готовая, как бы вы хотели чтобы она работала внутри?

если нужна навороченная реализация:

-перечитка конфигов по сигналу

-обновление кода без остановки процессов

-запуск нескольких экземпляров

-«удобствия» отладки

-интерфейс командной консоли

-управление по irc

Для собственных нужд делал бы на эрланге.

Пример реализации: ejabberd (кривовато, но годно)

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

В принципе понимаю как сделать, могу написать с нуля, хоть бы даже через curl+http.

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

HTTP тут совершенно лишняя сущность, достаточно TCP (и SSL, если хочется шифровать)

если не покупать сертификаты, то придется морочиться как бы согласиться с надежностью сертификата один раз

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

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

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

Вот это как раз и гемор

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

Если предполагается использовать специализированное клиентское приложение («управление демоном из консоли» же), и это не curl или nc, то можно приложить корневой сертификат к нему и явно использовать его при работе с SSL.

annulen ★★★★★
()

Делал такое на перле. Смотри в сторону эрланга.

gh0stwizard ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.