OpenRun: декларативная альтернатива Dokku и Coolify для деплоя внутренних инструментов
Создание внутренних инструментов на Streamlit, Flask или Gradio занимает минимум времени. Основная сложность — безопасность деплоя: настройка HTTPS, корпоративной аутентификации (OIDC/SAML), прав доступа (RBAC), секретов и автоматических обновлений.
Обычно для деплоя используют Dokku или Coolify, но они требуют ручного конфигурирования через UI или CLI, что ведет к конфигурационному дрейфу. Проект OpenRun (лицензия Apache-2.0) предлагает декларативное управление инфраструктурой прямо из Git по принципам GitOps.
Зачем внутренним инструментам отдельная платформа
Внутренние панели администрирования часто создаются хаотично. Развертывание таких сервисов на классических PaaS-платформах сопряжено со следующими сложностями:
- Отсутствие декларативности для инфраструктуры: В большинстве популярных систем (Dokku, Coolify, CapRover) через Git управляется только сам исходный код приложения. Настройка доменных имен, лимитов ресурсов или прав доступа выполняется администратором вручную в графической панели или через команды в терминале. Это затрудняет аудит конфигурации и лишает команду возможности рецензировать изменения инфраструктуры (code review).
- Сложность масштабирования: Если команда вырастает и решает перенести приложения с одиночного сервера в кластер Kubernetes, ей приходится переписывать всю конфигурацию с нуля, изучать Helm-чарты и настраивать Ingress-контроллеры.
- Избыточное потребление ресурсов: Внутренние сервисы часто нужны лишь периодически — например, несколько раз в неделю. Тем не менее, контейнеры продолжают работать круглосуточно, расходуя оперативную память и процессорное время сервера.
OpenRun решает эти проблемы, предлагая единый декларативный формат описания приложений на языке Starlark (диалекте Python), который преобразуется в работающие контейнеры как на одном сервере, так и в кластере Kubernetes.
Декларативный GitOps вместо ручной конфигурации
Главная отличительная черта OpenRun — глубокая декларативность. Все операции с инфраструктурой выполняются через обновление файлов конфигурации в Git-репозитории. Разработчик описывает параметры приложения в конфигурационном файле Starlark (Appspec). После слияния изменений в основную ветку репозитория платформа OpenRun автоматически синхронизирует состояние окружения. Это позволяет применить к конфигурации приложений полноценный цикл разработки (SDLC): историю изменений, ветвление, согласование пулл-реквестов и быстрый откат к предыдущим версиям.
Встроенный планировщик OpenRun регулярно опрашивает Git-репозиторий на предмет изменений. Если обнаруживается новая конфигурация, платформа выполняет сборку образа и обновление приложения. Для безопасного деплоя поддерживается механизм staged deployment (двухэтапное развертывание) и blue-green обновления: новые контейнеры запускаются параллельно со старыми и переключают трафик только после успешного прохождения проверок работоспособности (health checks). В случае сбоя при обновлении группы взаимосвязанных приложений OpenRun выполняет атомарный откат всей группы.
Под капотом: Scale-to-Zero и собственная маршрутизация
Архитектурно OpenRun спроектирован как самостоятельный веб-сервер и маршрутизатор запросов. В отличие от аналогичных PaaS-решений, он не требует обязательной установки внешних прокси-серверов вроде Nginx или Ingress-контроллеров вроде Traefik. Платформа самостоятельно слушает порты, управляет TLS-сертификатами (с помощью библиотеки Certmagic и Let's Encrypt для продакшена или mkcert для локальной разработки) и распределяет входящий трафик по доменам и путям.
Собственный сетевой стек позволил реализовать функцию автоматического масштабирования до нуля (idle scale-to-zero). Если к внутреннему инструменту никто не обращается в течение заданного времени, OpenRun переводит контейнер в спящий режим и освобождает системные ресурсы. При поступлении HTTP-запроса платформа запускает контейнер и перенаправляет запрос пользователю. Для внутренних сервисов с низкой интенсивностью использования это позволяет экономить до 80% серверных мощностей.
Для работы с данными и обеспечения высокой производительности OpenRun использует СУБД SQLite для хранения метаданных и виртуальную файловую систему с кэшированием файлов по контентному хэшу. Это позволяет отдавать статический контент с минимальными задержками и поддержкой сжатия Brotli.
Безопасность из коробки: Auth, RBAC и аудит
Внутренние корпоративные инструменты требуют контроля доступа. Создатели OpenRun встроили механизмы безопасности непосредственно в ядро платформы:
- Интеграция с провайдерами авторизации: Поддерживаются протоколы OAuth, OIDC (OpenID Connect) и SAML. Это позволяет подключить вход через корпоративные учетные записи (например, Google, Okta, Keycloak или GitHub) без написания дополнительного кода.
- Ролевая модель доступа (RBAC): Платформа позволяет разграничивать права как для административных действий, так и для доступа к самим развернутым сервисам на основе групп пользователей.
- Журнал аудита и секреты: Любые изменения конфигурации, запуски контейнеров и обращения к ресурсам фиксируются в защищенном логе аудита. OpenRun также интегрируется с менеджерами секретов, позволяя передавать API-ключи и пароли в контейнеры через переменные окружения, не раскрывая их в исходном коде Starlark-манифестов.
Руководство по развертыванию: от первого запуска до Kubernetes
Развертывание OpenRun состоит из установки управляющего демона (сервера) и последующего декларативного описания приложений. Для запуска контейнеризованных приложений на одиночном сервере необходимо установить Docker, Podman или Orbstack.
Установка управляющего демона OpenRun
Установка на сервер под управлением Linux или macOS выполняется с помощью официального скрипта:
curl -sSL https://openrun.dev/install.sh | sh
После завершения работы скрипта откройте новое окно терминала и запустите сервер:
openrun server start
Для пользователей macOS доступна альтернативная установка через Homebrew:
brew tap openrundev/homebrew-openrun
brew install openrun
brew services start openrun
По умолчанию консоль управления сервером будет доступна по адресу https://localhost:25223 (порт для HTTP-запросов — 25222).
Декларативное развертывание приложений
Чтобы развернуть приложение на основе Starlark-файла конфигурации из Git, выполните команду применения манифеста:
openrun apply --approve github.com/openrundev/openrun/examples/utils.star
Флаг --approve подтверждает запуск приложения. Для настройки автоматической синхронизации изменений в фоновом режиме (режим GitOps) добавьте расписание синхронизации:
openrun sync schedule --approve --promote github.com/openrundev/openrun/examples/utils.star
Для локального тестирования и отладки приложения можно запустить в dev-режиме:
openrun apply --dev --approve github.com/openrundev/openrun/examples/utils.star
Если вам нужно быстро запустить готовое приложение без создания GitOps-пайплайна, можно использовать императивную команду:
openrun app create --approve github.com/openrundev/apps/utils/bookmarks /book
В данном примере закладки (bookmark manager) будут доступны по адресу https://localhost:25223/book.
Масштабирование до Kubernetes
При росте нагрузки приложения можно перенести в кластер Kubernetes. Установка OpenRun в кластер осуществляется с помощью Helm-чарта или конфигурации Terraform. Благодаря абстракции OpenRun, манифесты приложений (Starlark-конфиги) переносить не требуется — OpenRun самостоятельно транслирует их в сущности Kubernetes (Services, Deployments, Pods) и выступает в роли API-сервера и маршрутизатора для кластера.
Ограничения, риски и особенности эксплуатации
При планировании внедрения OpenRun необходимо учитывать следующие факторы:
- Зрелость проекта: Проект находится на ранней стадии (версия v0.18.3, менее 1000 звезд на GitHub) и требует тестирования перед использованием в продуктовой среде.
- Резервное копирование: В режиме single-node состояние хранится в SQLite. Необходимо настроить бэкап рабочей директории OpenRun (
OPENRUN_HOME). - Холодный старт: Функция scale-to-zero создает задержку при первом обращении к уснувшему приложению. Для критических систем ее лучше отключить.
- Роль CI/CD: Отсутствие сборочного сервера не отменяет необходимость внешних CI-систем для запуска тестов, линтеров и проверок безопасности перед деплоем.
- Сложность Kubernetes: Использование OpenRun в кластере упрощает конфигурирование приложений, но не избавляет от администрирования самого Kubernetes (безопасности, сетей, реестров образов).