Алекс Заг

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

🖥 Проекты

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

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

📄 Информация

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

Ссылки: rss, github

Недавнее:

До вчерашнего дня моя система публикации базы знаний работала на бесплатных аккаунтах GitHub, Vercel и Google Drive. Это был обычный MVP — нужно было проверить, жизнеспособна ли сама идея: из набора локальных файлов собрать и обновлять web сайт, испольуя только текстовый редактор. Как показала практика, идея оказалась очень удачной: система проработала несколько лет, пока не уперлась в лимиты.

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

Домашний сервер на базе Raspberry Pi с накопителем 2ТБ для работы с self-hosted облачным сервисом AxonaCloud

Для запуска self-hosted облака я использовал Raspberry Pi и жёсткий диск на 2 ТБ. Сейчас это набор сервисов для синхронизации файлов между рабочей машиной и сервером внутри виртуальной домашней сети на базе WireGuard. В основе лежит сервис Syncthing. Я добавил к нему небольшой API, который воспроизводит необходимые функции Google Drive. Таким образом, я полностью отказался от Google Drive как хранилища базы знаний. Теперь система публикации работает в два раза быстрее: время на скачивание файлов заметно сократилось.

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

Следующий шаг — перенос оставшегося функционала из GitHub Actions в self-hosted облако. Планирую изучить готовые проекты, которые позволяют упростить миграцию с GitHub Actions.

Как-то подзабылось, что на GitHub Actions продолжает работать публикация базы знаний. И это, на самом деле, было приятно — временное решение, которое запустилось пару лет назад и с тех пор просто жило своей жизнью, без лишнего шума и напоминаний. Достаточно было сохранить файл с правками для нужного сайта, и можно было быть уверенным: обновления пусть не сразу, но появятся на сайте в течение дня, а заметка с датой публикации опубликуется в блоге примерно тогда, когда нужно. Но в конце марта, где-то в последний день месяца, пришло знакомое сообщение — об использовании 75% ресурсов бесплатного аккаунта. В апреле лимит исчерпался за несколько дней до конца месяца, а в мае, как видно, ресурсы закончились уже к 22 числу. Статистика использования ресурсов GitHub Actions за май Ничего критического, конечно, не случилось. Пришлось просто зайти и отключить actions, чтобы они перестали слать сообщения об ошибках запуска. Попытался посмотреть, что так повлияло на использование ресурсов. По логам actions видно, что публикация занимает 48 минут, хотя в апреле было 25 минут. Напомню, что бесплатный аккаунт GitHub даёт 2000 минут работы actions в месяц. Так что, если время публикации растёт, лимит расходуется быстрее. Похоже, больше времени стало уходить на скачивание файлов с Google Drive — база знаний растёт, туда складываются не только текстовые файлы, но и изображения. Впрочем, не похоже, что за пару месяцев размер базы увеличился настолько, чтобы время обработки выросло в два раза. Может, дело в изменениях на стороне Google Drive — пару раз приходили сообщения об ошибках при скачивании, но они были настолько редкими, поэтому внимания особо не привлекали. Как вариант, можно поискать другие способы скачивания файлов с Google Drive — сейчас используется gdrive-linux-x64, даже не помню уже, откуда взял этот бинарник. В долгосрочной перспективе всё это, конечно, лишь отсрочка. Неизбежно придётся делать собственное self-hosted решение для хранения и синхронизации базы знаний.
←↑