Алекс Заг

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

🖥 Проекты

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

🗄 Архив проектов

📄 Информация

Если вы хотите связаться со мной и рассказать о своем проекте, поделится интересной идеей или высказать мнение о каком-то материале на этом сайте, пожалуйста, отправьте мне сообщение на почту: zag(at)cpan.org

Ссылки: rss, github

Недавнее:

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

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

«DevOps Notebook» for axonaCloud

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

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

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

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

Файлы с журналами запусков процессов в облаке axonaCloud доступны в базе знаний локально

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

=begin code :id<reset> :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')"
=end code

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

=begin code :id<publish-zag.im> :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 )
=end code

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

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

Постепенно все размышления привели к следующей схеме, которая очень близка к исходным требованиям. Процессы и команды, которые нужно запустить на сервере, описываются в виде блоков кода. Каждый такой блок представляет собой команду для запуска на сервере. Коротко говоря — «Process as Codeblock»! Идея запуска процессов в AxonaCloud на основе блоков кода в документе По сути, каждый кодовый блок — это bash-скрипт, который выполняется на стороне сервера. У блока может быть атрибут cron, в котором задаётся периодичность запуска. Если атрибута cron нет, то скрипт запускается автоматически при старте: если это сервис — он продолжает работать, если это инициализация — он завершает выполнение. Если в документе изменился какой-то блок, соответствующий процесс на сервере перезапускается. Скрипты с атрибутом cron запускаются по расписанию. Остаются вопросы, связанные с возможным дублированием документа, сохранением логов процессов и деталями состояний документа и процесса на сервере. Но с первой пробной версией все станет определеннее... В целом, получается нечто вроде «Jupyter Notebook», но для серверных процессов. Можно назвать это «Process/Ops/DevOps Notebook». Главное, что идея выглядит вполне реализуемой.
←↑