Как правильно передать данные?

Question

[Виктор Таран]

Вопрос чисто теоретический, но поскольку я больше к линуксу чем а разработке то страдает моя теоретическая часть.
И так у нас есть некий сервис который управляет виртуальными машинами заказывает их останавливает накатывает ( собствено я готовлю эти баш скрипты.
Соответственно у нас есть фронт публичный.
Все что остается на фронте это :
(сама машина заказывается по апи датацентра и уже грубо говоря готова )
через exec выполнить одну единственную команду на виртуальной машине, в частности скачать bash скрипт с репозитория и запустить его.
Он там магически все делает.

НО остается вопрос в данных.
Скрипт получает на ввод некий массив данных ID кошелька название ноды и тд в общем введеные данные в админке.
И сейчас я их просто заливаю следующим образом просто подавая их в виде дополнительных аргументов, притом они всегда разные и есть стандартные но чаще есть эксклюзивные.
чтото вроде bash.sh a=3 b=423 и тд.
Естественно не очень удобно по двум критериям.
1 в переменных могут быть спецсимволы.
2. мне нужно возвращять часть даных скрипта обратно в админку.
Статус что все готово. естественно для прогресс бара установки а следовательно не один раз.
3. статусы ошибок если они возниктут ( пусть даже эти статусы я готовлю в самом скрипте)
4. Возвращать некие фишки которые генерятся уже на машине, такие как публичный ключ и тд.
Просто stdout я не могу забирать там много мусора.
Демона на стороне машины своего ставить не желательно .
Но обмен данных должен быть двухсторонним,
Как это лучше организовать плюс желательно секрюрно.

Возможно как-то отдавать json с переменными на сервер, но как его грамотно возвращать в реальном времени обратно.
Разбивать один скрипт на разные конечно возможно, дабы получать вывод каждого по отдельности.
Но они будут очень часто обновляться а главное таких видов машин много.
И так хотябы это один файл да и этапов может быть много. В обещм мне кажется если его разбивать на несколько то потом будет тяжело все это отлаживать и чинить при обновлениях.

Comments

[Модератор]

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

[Виктор Таран]

Модератор, С радостью но собственно я отметил ровно те что учувствуют в вопросе.
Мой стек какраз php pyton куча апи и линукс.

[Модератор]

Виктор Таран, если нет кода в вопросе и нет вопроса по нюансам языка - не надо ставить тэг языка. Десяткам тысяч подписчиков тэгов python и PHP ни к чему спамить вашими проблемами с проектированием API.

[Виктор Таран]

Модератор, Если так посудить то 90% вопросов на данной площадке поставленные грамотно гуляться в течение 3 секунд.
что же касается АПИ и тд.
Что касается языков Программировании, все просто это больше к теории разработки. Если вы сможете мне помочь перефразировать вопрос на более удобоваримый только спасибо скажу.
Что касается API
Собственно там зачастую клиент серверная часть
Люди вполне могут юзать и сокеты и AMQP
На мой дилетантский взгляд.

[Модератор]

Виктор Таран, к сожалению, нет возможности объять необъятное. Приходится обнимать по частям.

Тем не менее, есть п.3.1 Регламента, и желательно ему следовать. Если считаете, что нужно уточнить тэги - давайте уточним, всё-таки это не догма.
Но лучше в таких вопросах указать те тэги, к подписчикам которых обращен Ваш вопрос. А языки и другие подобные нюансы указать в самом вопросе, зачастую в названии вопроса. Например, «как правильно передать данные от фронта бэкенду на python в формате json?» или что-то такое.

[Виктор Таран]

Модератор, нет мне не особо принципиален phyton ибо всеравно exeс, не особо принципиален json
тем более что bash ужасно с ним работает ;( приходится доставлять ПО дабы работать с json

[shurshur]

Виктор Таран, если json не сложноструктурированный, а просто набор фиксированного количества параметров, и хочется файликом, то я бы рекомендовал условный заранее правильно экранированный env-файл, который можно было бы включить через source. Или файл, где параметры построчно указаны, а читается он через read с правильным IFS (если точно известно какие символы не будут встречаться в данных, можно использовать и символ в качестве разделителя вместо переноса строки).

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

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

[Виктор Таран]

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

[shurshur]

Виктор Таран, я не разраб, я админ. Когда у тебя десятки серверов и регулярно появляются новые, причём у тебя также и десятки админов, которым нужно что-то иногда накатить/поменять, то разворачивание скриптиками превращается в кошмар.

У нас уже давно есть куча ролей и тасков в ansible, которыми мы управляем инфраструктурой. Когда я пришёл в компанию, админ был всего один и у него конечно же было много скриптиков, которые позволяли удобно создавать/мигрировать зоны на Solaris 10 и ещё много чего сверх того :) Сейчас у нас отдел на 30 человек, из которых 2/3 неизбежно используют ansible (исключая сетевиков, DBA, офисных эникейщиков и начальника), потому что это удобно, надёжно и универсально.

Вот, например, два таска в роли proxy:

- name: set_fact nginx_proxy_ports
  set_fact:
    nginx_proxy_ports: { 2775, 2776, 5235, 8443, 4443, 4444, 4447, 5443, 6443, 7443, 9443, 9090, 6250, 6251, 6252, 6253 }

- name: Set selinux ports for nginx
  seport:
    ports: "{{ item }}"
    proto: tcp
    setype: http_port_t
    state: present
    reload: yes
  with_items: "{{ nginx_proxy_ports }}"

Сколько бы пришлось писать и отлаживать скрипт, который бы сделал то же самое? А ведь ansible не только это сделает хорошо, но также идемпотентно (ничего не сломает при повторном запуске) и корректно упадёт при любой ошибке без каких-либо специальных усилий по обработке ошибок.

В этой роли 20 тасков, которые за 5 минут превращают свежеарендованную виртуалку в прокси-сервер с правильным конфигом и набором софта (nginx, squid, selinux, логи и logrotate, сертификаты итд). Отдельно у нас суперроль common на 118 правил, которые настраивают sshd, почтовый релей, sysctl, ulimits, selinux, sudo, ntp, logrotate, docker, предустанавливаемый обязательный софт итд итп. Есть роли для установки агента мониторинга, для деплоя нод кластеров kubernetes и mesos, для consul/keepalived/envoy/hdfs/elk... Только что с удивлением узнал, что даже виртуалки через ansible создаются на гипервизорах (нашёл роль vm_create). У нас даже пользователи и DNS через ansible раскатываются... (По пользователям давно обсуждается внедрение LDAP, но админов всё равно придётся иметь в ansible как минимум для внешних серверов, куда LDAP так просто не затянуть, а по DNS обсуждали и вяло тестировали powerdns, чтобы не файлами оперировать, и ни к чему так и не пришли пока, но кстати деплой powerdns через ansible уже есть).

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

Answer 1

[Владимир Коротенко]

Сделайте так

1. Фронт создает json спецсимволы экранируются встроенными средствами
2. Скрипт по крону запускается и обрабатывает созданные файлы
3. В ходе обработки скрипт пишет в файл id.json где id номер процесса или идентификатор
4. В фронте отображается id.json там может быть прогресс или результат, в общем все зависит от вашей фантазии
5. После окончания работы временные файлы удаляются

Comments

[Виктор Таран]

уже близко но тут есть прара моментов.
1. запуск скрипт не по крону поскольку это exec да еще не с текущей машины а именно с удалений

ssh [User_Name]@[Rremote_Host_Name or IP] [Command or Script]

соответственно запуск можно как-раз без крона сделать ибо он вполне себе на сабмит сработает.
Собственно вопрос в том что делать с этим джейсоном как его передать обратно.
он выполняется на вообще левом компьюрере по другую сторону материка.
Притом желательно в риалтайме.
Все что я вижу сейчас это
1. http - но очень бы не хотелось поскольку там какраз будет куча кастомных http сервисов в общем хотелось бы не трогать ни nginx ни apache ни какую подобную ересть ( ибо валидационные ноды там все это юзают )
2. Сокет прокидывать в обартку к примеру.

[Владимир Коротенко]

Виктор Таран, где один ssh там и другой. Крон предпочтительней так как время исполнения скрипта ограничено веб сервером. Впрочем можно переводить его в фоновый режим, а отдавать номер пида.
Но я бы сделал микросервис и гонял бы данные по RPC

Answer 2

[rPman]

Первое, sh - отвратительный язык программирования, именно для задач работы с данными, т.е.он конечно может но сильно неудобно. В метках php, он отлично подходит для написания скриптов, поддержка json есть.

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

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

Comments

[Виктор Таран]

Первое, sh - отвратительный язык программирования, именно для задач работы с данными, т.е.он конечно может но сильно неудобно. В метках php, он отлично подходит для написания скриптов, поддержка json есть.

Угу, но тут как ни странно проблем меньше всего, я его кручу куда хочу. Даже пришлось отказаться от bash поскольку даже он не везде идет.
А php pyton и тд нельзя, ибо у всех свои версии порой нужно компилить конкретную версию в общем адаптировать скрипты под тот язык что на машине нельзя. и контейнер тоже нельзя некоторые ноды должны иметь только один контейнер в общем желательно минимум установок хоть чего-то связанного с разработкой ;(

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

тут проблем тоже нет если бы это был один hetzner но там планируется целая пачка. Так что вариант от застройщика тоеж не пдходит.

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

Угу к примеру микс ноды может идти пять дней, скрипт все еще будет работать и последнее оповещение киенет когда микс закончится ;(
Так что в админке должна быть стадия установка завершена идет микс 64%
Так что про быстро тут как повезет, может быстро в течение 30 секунд, может быстро в течение 325 часов
Была тут у меня церемония от ironfish.

[Saboteur]

rPman

sh - отвратительный язык программирования

Так говорят те, кто считает что баш простой язык и из-за этого его просто не знают.
А для работы с данными есть огромное количество консольных команд, которые и являются "библиотеками" для шелла

Виктор Таран, Посмотрите что идет в поставке. base64 точно идет, а им можно много чего кодировать чтобы передавать безопасно. jq для json надо ставить, но в любом дистрибутиве он есть

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

[Виктор Таран]

Saboteur,

sh - отвратительный язык программирования

я в нем и работаю мне нравится но конечно приходится постоянно выходить на костыли типа
jq да на

sed 's/\x22hello\x22\x2C/\x22hello world\x22\x2C/g'

sh много чего не умеет, но не уверен что он это должен уметь. Все-же это шел а не язык в первую очередь.

[rPman]

автор прямо и сказал что у него сложности с текстом

в переменных могут быть спецсимволы.

собственно подавляющее большинство языков программирования позволяют без особых проблем работать с бинарными данными да и строк обычно хвтает, но только в баше пробелы, ковычки и тире (о боже сколько это проблем создает) - это одна большая головная боль.
Код разбора строк на баше (с использованием grep/sed/cut/...) это адский трудночитаемый поток сознания, ошибки в котором искать уже через месяц - сложное занятие. В общем поддержка sh скриптов на порядок сложнее того же php
p.s. про даты и работу со временем сами догадаетесь?

p.p.s. Если не лезть в серьезные дебри php - разные версии не проблема. Мой код, написанный для 5.4, у меня заработал без единой ошибки на 8 (правда наученный работой на с++ я заранее обхожу неоднозначности), плюс я говорю про простые скрипты а не проект на десятки тысяч строк.

Answer 3

[AUser0]

С учётом уже написанных комментариев... Берёте скриптовый язык, для которого есть компиляция в exe-шник. Пусть садится на какой-нибудь порт типа 9876, и отрабатывает коннекты по HTTP. А дальше вертите как хотите.

Answer 4

[Saboteur]

Данные в баш скрипт можно передавать тем же json-ом и парсить через jq
Или фронтом писать в файл, скриптом читать из файла по строкам, убрав проблемы с разными символами
Можно вообще заворачивать все base64 и передавать аргументы в скрипт уже закодировав - тоже все проблемы с символами пропадают.
Вариантов много.

Просто stdout я не могу забирать там много мусора.

Ну можно же правильный stdout сделать. В самом скрипте писать в лог файлы, а в stdout только то, что нужно для ответа серверу в том формате, который нужен серверу.
Можно в stderr писать, если нужно в терминал, а не в файл. И соответсвенно контролировать что пошло в stderr а что в stdout. Тут вообще не проблема.

Comments

[Виктор Таран]

собственно пораскинув мозгами пришел к такому выводу.
1. на стороне сервиса REST API автаризуемся скриптом получаем доступ к целой табличке. в которой собственно все мое барахло.
Читаем ее полностью.
2. изменения статуса инсертим в нее, соотвественно аякс уже с легкостью отображает изменения на сайте.
лафа и полное вселенское счастье.
Что скажите пойдет такой вариант ?
Доступы серкьюрны поскольку можно генерить пару ключей с обих сторон и ограничивать по айпи.

ps.
В момент когда читаю ваш комент
курсор на строке

IP=$(cat server.log | jq  -r '.server["public_net"]["ipv4"]["ip"]')
ID=$( cat server.log | jq  -r '.server["id"]')
NAME=$( cat server.log | jq  -r '.server["name"]')

[Saboteur]

Я обычно заключаю в кавычки и саму подстановку, на случай если результат содержит пробелы или что еще. Кавычки снаружи никак не конфликтуют с кавычками внутри $().

IP="$(cat server.log | jq  -r '.server["public_net"]["ipv4"]["ip"]')"
ID="$( cat server.log | jq  -r '.server["id"]')"
NAME="$( cat server.log | jq  -r '.server["name"]')"