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


Процессы и команды, которые нужно запустить на сервере, описываются в виде блоков кода. Каждый такой блок представляет собой команду для запуска на сервере. Коротко говоря — «B<Process as Codeblock>»!


Идея запуска процессов в AxonaCloud на основе блоков кода в документе


caption

picture

По сути, каждый кодовый блок — это I<bash-скрипт>, который выполняется на стороне сервера.


У блока может быть атрибут B<cron>, в котором задаётся периодичность запуска.
Если атрибута C<cron> нет, то скрипт запускается автоматически при старте:


если это сервис — он продолжает работать,


item

если это инициализация — он завершает выполнение.


Если в документе изменился какой-то блок, соответствующий процесс на сервере перезапускается.


Скрипты с атрибутом C<cron> запускаются по расписанию.


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


В целом, получается нечто вроде «B<Jupyter Notebook>», но для серверных процессов.
Можно назвать это «B<Process/Ops/DevOps Notebook>».


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


para

root

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


На данный момент документ выглядит так:


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


Блоки кода можно сопровождать подписями и поясняющим текстом. Их также можно группировать по темам с помощью заголовков.


База знаний монтируется внутрь docker-контейнера в каталог C</base> и доступна для запускаемых скриптов в режиме только чтения.


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


Docker образ, в котором будет запущен скрипт можно указать явно с помощью атрибута B<dockerImage>: 


code

=begin code :allow<B Z>
Z<>=begin code :id<reset> B«:dockerImage<'docker:27-cli'>»
#!/bin/sh
echo "   - Docker: $(docker --version 2>/dev/null || echo 'Not available')"
echo "  - Docker: $(docker system prune -f 2>/dev/null || echo 'Not available')"
Z<>=end code
=end code


Каждый блок кода с атрибутом B<cron> запускается по расписанию, а без атрибута - один раз при старте сервера или перезапуске процесса.
Например вот как публикуется сайт C<zag.im>:


=begin code :allow<B Z>
Z<>=begin code :id<publish-zag.im> B<:cron("20 7-21 * * *")> :dockerImage<'podlite/podlite-web:v0.2.9'>
#!/bin/sh
# prepare ENV
export SITE_URL="https://zag.im"
export SITE_ARGS="./pub -s ${SITE_URL}  --preset pubdate  -i ./pub/digitalGarden/03-zag.im-site/index.pod6"
echo "Running publish for ${SITE_URL}"

#  skip a piece of real code because it's just an example

# publish website
( cd /base/cloud/secure && bash publish.zag.im.bash )
Z<>=end code

=end code


Из-за проблем с атрибутами для блоков кода в C<markdown> (I<их просто нет> 🥴) для Markdown разметки доступен только однократный запуск в Ubuntu контейнере. Записал себе в планы этот вопрос проработать.


Планирую пожить с новой системой какое-то время и посмотреть, как всё это работает. 
А также подумать, в каком направлении можно дальше развивать идею self-hosted облака поверх локальной базы знаний.


Начал смотреть проекты для запуска GitHub Actions локально, например L<https://github.com/nektos/act>.
Потом прикинул, что мне на самом деле нужно выполнять одну команду: C<docker build -f Dockerfile .>.
Поэтому я упростил себе задачу: перенёс эту команду на Raspberry Pi и настроил запуск каждые 4 часа.


С первого раза публикацию запустить не получилось: падала при сборке этого блога.
Начал уже думать, что проблема из‑за архитектуры, но всё оказалось проще: на Raspberry Pi 4ГБ ОЗУ, а для сборки нужно около 8ГБ. 😬


Вспомнились резидентные программы на ассемблере, которые я писал в тетради, а потом раз в неделю переносил
на компьютер и отлаживал — каждый регистр был на счету, как впрочем и компьютеры, доступные для программирования.
Кстати, в новых Raspberry Pi уже есть 16ГБ — за 120$. Я обошёлся бесплатным решением: подключил swap.


Итак публикация базы знаний запускается на self-hosted "облаке" (до свидания GitHub Actions!) и работает около часа.
Способов ускорить много, но сейчас это не так важно. 
Мне важнее получить первые впечатления от работы self-hosted решения.


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


Хочу, чтобы всё работало как сейчас с публикацией статей: нажал «Сохранить» — и дальше все само опубликовалось.
То же самое с приложениями: сохранил файл в редакторе — в моём личном "облаке" автоматически запустилась команда или процесс.  Или чтобы процесс остановился, если я удалил файл или перезапустился, если я его изменил. Как-то так.


Пусть там будет «докер в докере», «утка в зайце» или ещё какая магия — главное, чтобы управлять приложениями в личном "облаке" было просто.
