Какие новости на фронте разработки новой версии?

[aolko]

Есть ли свежие новости разработки?

[Максим]

Есть ли свежие новости разработки?

Да, уже скоро. Просто следите за темой, как только будут, здесь всё появится.

[DAGpro]

[Araragi]

Да, уже скоро. Просто следите за темой, как только будут, здесь всё появится.

[Максим]

Итак, думаю пора потихоньку начинать. Как всё планирую делать - сперва обсудить с заинтересованными юзерами в этой теме некоторые вопросы на счёт новой версии (расположение папок и файлов, структура и формат конфигов и прочее.), потом планирую начать выкладывать сюда рабочие файлы для теста, сперва ядро управления процессами, модули (частями), потом наверное будет API, в самом конце уже новый интерфейс управления и новые модули. А спустя несколько месяцев, кода всё здесь протестируем и обсудим, будет уже первый публичный релиз.

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

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

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

- Полная модульность. Теперь всё ПО модульное и все конфиги могут динамически обновляться даже для тех модулей, которые не запускаются и не работают по сети (например обычные программы), но для которых важны правильные пути в файлах конфигурации.
- Полная децентрализация конфигурации модулей. Теперь КАЖДЫЙ модуль имеет собственные настройки.
- В конфиге модуля указывается команда и параметры запуска! А так же кодировка конфиг-шаблонов, разделитель для путей (/,\\,\) и др.
- Все модули можно будет запустить одновременно. Т.е. хоть 10 модулей баз данных, все версии PHP и проч. Работать будет на разных IP (127.0.0.1, 127.0.0.2, 127.0.0.3 и т.д.), однако каждый модуль можно перенастроить как хочется (конфиги независимы) и перевесить всё на один IP с разными портами например.
- Полный контроль над окружением (Environment) запускаемых модулей, всё задаётся прямо в конфиге, причём можно указать не только значения osp но и системные типа %COMSPEC%.
- Умная система защиты от падений. Например, если после длительной работы (по умолчанию более 1 минуты) у вас падает Apache, то система тут же его запустит снова. Причём если модуль упадёт сразу после запуска, то он будет сразу выключен (чтобы избежать зацикливания перезапуска), до тех пор пока вы не изучите проблему, не устраните её и не включите модуль обратно.
- Защита от зависаний в процессе старта или остановки модуля (время настраивается). По умолчанию - если через 30 сек. модуль не запустится или не остановится, то он будет принудительно остановлен (убит).
- Чтобы модуль подхватил новые настройки достаточно перезапустить только его отдельно.
- Реализован полностью параллельный запуск модулей (намного быстрее чем последовательный вариант).
- Больше нет такого понятия как старт и остановка, теперь модуль просто или включён или выключен, т.е. активный модуль всегда работает когда запущена программа (при этом его в любой момент можно выключить или перезапустить).

Про старые принципы (управления, конфигурации и проч.) забудьте совсем и не пытайтесь сравнить. Всё абсолютно новое, на новых принципах.

Давайте сейчас рассмотрим пример конфига, например модуля PostgreSQL-12.2:

[main]
ip=127.0.0.1
port=5432
start_cmd="{root_dir}\modules\{module_name}\bin\pg_ctl.exe" start -w -s -D "{root_dir}\data\{module_name}"
start_dir={root_dir}\modules\{module_name}\bin
force_stop=0
enabled=1
use_pid=1
cfg_sep_1=/
cfg_enc_1=ASCII
cfg_src_1={root_dir}\templates\{module_name}_pg_hba.conf
cfg_dst_1={root_dir}\data\{module_name}\pg_hba.conf
cfg_sep_2=/
cfg_enc_2=ASCII
cfg_src_2={root_dir}\templates\{module_name}_postgresql.conf
cfg_dst_2={root_dir}\data\{module_name}\postgresql.conf

[environment]
Path={root_dir}\modules\{module_name}\bin\bin;%Path%
PGDATA={root_dir}\data\{module_name}
PGDATABASE=postgres
PGUSER=postgres
PGPORT={port}
PGLOCALEDIR={root_dir}\modules\{module_name}\share\locale

Расшифровка:

ip - IP адрес модуля
port - Порт модуля
start_cmd - команда запуска
start_dir - директория запуска
force_stop - указатель способа остановки (0 - обычный корректный способ с посылом в консоль команды CTRL+C, 1 - быстрое убийство, убийство подходит для таких модулей как Nginx Apache и прочие)
enabled - включён или выключен модуль (будет запускаться или нет при старте программы)
use_pid - способ контроля процесса, 0 - прямой или 1 - по pid файлу.
cfg_sep_1 - разделитель для путей в конфигах (MySQL нужно C:\\xxx\\, Apache нужно C:/xxx/ и т.д.)
cfg_enc_1 - кодировка конфига (ASCII или UTF8)
cfg_src_1 - здесь указывается шаблон конфига.
cfg_dst_1 - здесь указывается путь к файлу, в который будет записан готовый конфиг.
... далее шаблоны конфигов и целевые файлы можно указывать просто увеличивая порядковый номер
[environment] - блок описания кастомного окружения, тут всё понятно наглядно, думаю объяснять не нужно как он заполняется.

Сразу много вопросов вкидывать не буду, а то утонем в обсуждении. Пока такой вопрос к аудитории - что ещё было бы неплохо добавить в конфиг модуля, может быть вы хотите сделать ещё какие-то параметры у модулей настраиваемыми или возможно хотите видеть в конфиге дополнительные полезные данные. Что скажете?

Следующий раз порассуждаем о структуре папок, кто как это видит. Ну и потом уже начнём ядро тестить, сперва будут готовы все модули кроме Apache и PHP (они подтянуться позже последними).

[Ink0gnit0]

Максим, приветствую.
Возможно ли добавить параметры в конфиг?
Например:

before_start_cmd=pm2 --name <app_name> && %root_dir%\myscripts\make_certs.cmd
before_stop_cmd=%root_dir%\myscripts\backup_db.cmd

Касательно before_start_cmd, можно, конечно, добавить необходимую цепочку запуска в start_cmd.
Параметр before_stop_cmd пригодился бы, в основном, для осуществения резервного копирования сайтов/баз данных.

Насколько возможно на текущем этапе разработки, реализовать шаблоны конфигов в формате JSON по образу package.json?
К примеру:

{
  "name": "%module_name%",
  "bind_ip": "%bind_ip%",
  "bind_port": %bind_port%,
  "force_stop": false,
  "enabled": true,
  "use_pid": true,
  "start_dir": "%root_dir%\modules\%module_name%\bin",
  "configs": [{
      "dir_separator": "/",
      "encoding": "ASCII",
      "template": "%root_dir%\templates\%module_name%_pg_hba.conf",
      "config": "%root_dir%\data\%module_name%\pg_hba.conf"
    }, {
      "dir_separator": "/",
      "encoding": "UTF8",
      "template": "%root_dir%\templates\%module_name%_postgresql.conf",
      "config": "%root_dir%\data\%module_name%\postgresql.conf"
    }
  },
  "scripts": {
    "start": "\"%root_dir%\modules\%module_name%\bin\pg_ctl.exe\" start -w -s -D \"%root_dir%\data\%module_name%\"",
    "before-start": "pm2 --name <app_name> && %root_dir%\myscripts\make_certs.cmd",
    "before-stop": "%root_dir%\myscripts\backup_db.cmd"
  },
  "environment": {
     "PATH": "%root_dir%\modules\%module_name%\bin;%PATH%",
     "PGDATA": "%root_dir%\data\%module_name%",
     "PGDATABASE": "postgres",
     "PGUSER": "postgres",
     "PGPORT": %bind_port%,
     "PGLOCALEDIR": "%root_dir%\modules\%module_name%\share\locale"
  }
}

Благодарю!

[DAGpro]

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

ENV формат конфигов больше нравится.

[Максим]

Ink0gnit0, В Delphi работа с JSON сделана через одно большое место, совсем не так удобно как в PHP и самое главное - необходимость экранирования и не такая наглядность, как в случае с INI. Т.е. если кто-то шаловливыми ручками вставит строку без экранирования в файл с настройками в JSON формате - всё поломается. Хоть программа будет настраиваться через интерфейс, я прекрасно понимаю что из интереса в конфиг будут лазить все кому не лень и вписывать туда всё что угодно не глядя, поэтому не остаётся выбора кроме как INI, который всё стерпит.

Добавление в конфиг модулей возможности указания собственных .bat файлов с выполнением до/после старта/остановки для автоматического бэкапа и прочих действий - идея хорошая, сделаю это, спасибо.

[Максим]

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

ENV формат конфигов больше нравится.

Все тесты в ближайшее время будут проходить в виде запуска программы без интерфейса (сначала только ядро управления процессами, потом другие возможности). До момента начала теста веб-интерфейса все настройки можно будет делать только руками напрямую в INI файле. Если хочется сразу тыкать кнопочки, то приходите в самом конце, когда начнётся тест и обсуждение интерфейса управления.

[DAGpro]

Все тесты в ближайшее время будут проходить в виде запуска программы без интерфейса (сначала только ядро управления процессами, потом другие возможности). До момента начала теста веб-интерфейса все настройки можно будет делать только руками напрямую в INI файле. Если хочется сразу тыкать кнопочки, то приходите в самом конце, когда начнётся тест и обсуждение интерфейса управления.

Я не про кнопочки писал )), а про оценить модульность на практике и ручками настроить ini файлы, посмотреть чего не хватает, или работает не так как хотелось бы.