Ландыш: веб-управление кластерами через RAS/RAC
для команд разработки и инфраструктуры
Важные замечания
«Ландыш» — независимый self-hosted инструмент автора. Проект не является продуктом фирмы «1С», не аффилирован с ней и не позиционируется как официальная консоль администрирования. Обозначения «1С», «1С:Предприятие» принадлежат правообладателям и используются только для описания совместимости.
Ландыш работает поверх штатных RAS/RAC — того же класса задач, что и оснастка MMC на Windows: кластеры, информационные базы, сеансы, блокировки, рабочие процессы. Автор не гарантирует совместимость со всеми версиями платформы без проверки на вашем контуре. Цифры по численности команд ниже — обобщённый пример. Скриншоты иллюстративные (демо-имена, демо-хосты); перед боем — свои регламенты ИБ и здравый смысл.
Зачем это понадобилось
Работаю в крупной IT-команде вокруг платформы 1С:Предприятие. Порядок величин: около 70 человек. Из них примерно десяток — эксплуатация / DevOps: две отдельные группы примерно по пять человек — «Базис» и «Инфраструктура». Остальные — аналитики и разработчики.
Серверов — десятки; на каждом, как правило, свой кластер. В одном кластере информационных баз может быть сотни (ориентир 250–300 — не редкость). Это не «одна общая база на всех», а парк контуров.
Головная боль инфраструктуры: аналитику снова нужен монопольный режим. Значит — объяснять MMC, сеансы, блокировки, «не тот кластер», «не тот пароль». Если каждое «уберите сеанс» гонять тикетом — получается конвейер рутины. Плюс новые рабочие места часто на Astra Linux, а привычная MMC — про Windows. Учить всех RAC/bash ради монопольного режима — плохой путь.
Я сам из группы инфраструктуры (те самые ~5 человек). Не хотел вечно объяснять MMC — сделал Ландыш: создаю пользователя и спрашиваю «письмо на почту пришло?» — дальше человек самообслуживается в рамках роли.
Рис. 1. От тикетов и MMC к самообслуживанию в браузере (схема)
Рис. 2. Вход (логин или email)
Что такое Ландыш
Веб-приложение на Django + обычный JavaScript. Сервер приложения ходит в RAS/RAC, пользователь работает из браузера: дерево подключений по папкам и контурам, кластеры, ИБ, сеансы, рабочие серверы, блокировки, журнал действий, пользователи и группы.
Базовая функциональность у нас живёт давно: первый коммит — 30.11.2025 (к августу 2026 это порядка восьми–девяти месяцев). Ниже — не каталог всех кнопок, а то, что сняло боль.
Роли: Аналитик и Инфраструктура
Отдельной касты «админы системы вне инфраструктуры» у нас нет: Базис и Инфраструктура — это и есть эксплуататоры / DevOps. В Ландыше для удобства есть расширенные модули (пользователи, группы, настройки, логирование): ими пользуется инфраструктура. В интерфейсе это может отображаться как роль «Администратор» — по смыслу это те же люди из инфраструктурной пятёрки, а не отдельный отдел.
Аналитик — смотреть кластер, блокировать информационную базу, завершать/прерывать сеансы. Основной набор для монопольного режима без эскалации.
Инфраструктура — то же плюс управление серверами и кластерами, а также (когда нужна «админка» Ландыша) пользователи, объединение групп, политики логирования и системные настройки.
Рис. 3. Роли и зоны ответственности (схема)
Рис. 4. Пользователи: корпоративные учётки, роли Аналитик / Инфраструктура
Группы и контуры: не один «общий кластер»
Группы в Ландыше — это периметр видимости подключений и папок. Чаще всего схема такая: 1 аналитик ≈ 1 группа. Объединяют группы редко. У «Базиса» — своя группа, у «Инфраструктуры» — своя (не одна общая «админская» свалка).
Базис и Инфраструктура ходят по всему парку: десятки серверов и кластеров. Аналитик видит только контуры своей предметной области — например прод / предпрод / тест / разработка / внутренний контур разработки. Каждый такой контур — это, как правило, свой кластер с набором рабочих серверов (СУБД / APP / WEB и т.п.), а не «одна общая железяка на компанию».
Рис. 5. Группы: инфраструктура — на все кластеры; аналитик — на свои контуры
Дерево подключений и поиск по версии платформы
Подключения раскладываются по папкам-контурам. У каждого — свой хост RAS и версия платформы. Типовой кейс инфраструктуры: «нужно загрузить конфигурацию, платформа не ниже 8.3.27». В Ландыше открываю умный поиск, вбиваю 8.3.27 — вижу все кластеры с подходящей версией. Дальше смотрю, где меньше нагрузка, и уже понимаю, куда можно создать базу.
Это именно фича Ландыша, а не «удобнее, чем MMC». В MMC версии по парку серверов так не смотрят: консоль сидит на одной версии платформы, при подключении к «чужому» центральному серверу можно словить ошибку вроде «не сходится версия клиента и сервера» и уже из текста ошибки выудить версию — но это не способ обойти десятки контуров. Собирать версии отдельным мониторингом тоже можно, но это снова возня вокруг того же RAC. MMC для другой работы: подобрать нужную версию платформы, кое-как подключиться к серверу, поставить блокировку, удалить сеансы, при необходимости посмотреть по сеансам, кто ест память.
Рис. 6. Папки контуров и разные серверы/версии платформы
Рис. 7. Поиск «8.3.27» — где вообще можно создавать под эту платформу
Кластер, базы, серверы, сеансы
Справа — иерархия кластера: информационные базы, рабочие серверы, сеансы и остальное, с чем обычно работают через консоль.
Типичный сценарий аналитика, которому нужно обновить конфигурацию (получить монопольный доступ к базе):
раскрыть блок «Информационные базы»;
выбрать нужную базу → «Свойства…»;
включить блокировку начала сеансов информационной базы и блокировку регламентных заданий;
ПКМ по «Сеансы» → удалить все сеансы, кроме сеанса Конфигуратора, в котором сидит сам аналитик;
продолжить обновление конфигурации.
Всё это из браузера, без RDP на Windows-машину с MMC и без ручного набора RAC-команд.
Рис. 8. Кластер: разделы как в консоли администрирования
Рис. 9. Информационные базы кластера
Рис. 10. Рабочие серверы
Рис. 11. Сеансы: фильтр, поиск, выгрузка в Excel
Рис. 12. Веб-доступ с Linux-рабочих мест (схема)
Astra Linux и MMC
MMC удобна тем, кто уже на Windows и привык к оснастке: подключился нужной версией платформы, поставил блокировку, почистил сеансы, глянул нагрузку по сеансам. Когда рабочие места заводят на Astra Linux, этот путь пропадает: аналогичной MMC от фирмы «1С» там нет. Ландыш здесь не заменяет «офиктрину» администрирования платформы — даёт веб-UI поверх тех же RAS/RAC. Для пользователя это вкладка браузера; для сервера 1С — те же административные вызовы.
Журнал действий
Самообслуживание без наблюдаемости опасно. В мониторинге смотрим не «красивую статистику ради статистики», а логи действий: кто завершил сеансы, кто поставил блокировку, кто создал подключение. Инфраструктура видит общую картину; участники групп — активность в своём периметре (по ролям и настройкам).
Рис. 13. Логи действий пользователей
Новые опции (коротко)
Две возможности включаются точечно у конкретных групп и не являются ядром:
Десктоп-клиент — оболочка вокруг того же контура; основная работа возможна из браузера.
Групповое хранилище эксплуатационных документов — новая функция (порядка месяца на момент статьи), обкатка ещё идёт.
Главный акцент — роли, группы, дерево контуров и повседневное управление кластером через веб.
Рис. 14. Настройки системы (зона инфраструктуры)
Причины купить
Снять с инфраструктуры поток «научите / удалите сеанс / поставьте блокировку» для монопольного обновления конфигурации
Дать аналитикам понятный сценарий: свойства ИБ → блокировки → сеансы → обновление, без RDP на Windows и без ручного RAC
Быстро находить, на каких кластерах нужная версия платформы, прежде чем создавать базу
Единая точка доступа к десяткам серверов и кластерам вместо набора разрозненных консолей
Контроль через журнал действий при самообслуживании
Бессрочная лицензия на оплаченную версию, без лимита серверов и пользователей Ландыша у покупателя
Опционально: удалённое внедрение и платная поддержка после 30 дней — отдельными позициями на Infostart
Достоинства
Веб-интерфейс поверх RAS/RAC: кластеры, ИБ, сеансы, блокировки без обязательной MMC
Роли Аналитик / Инфраструктура: самообслуживание типовых операций, меньше эскалаций на эксплуатацию
Группы и папки подключений: у аналитика — свои контуры, у инфраструктуры — обзор парка серверов
Умный поиск по версии платформы (например, 8.3.27) по всем подключениям
Журнал действий пользователей: кто ставил блокировки и завершал сеансы
Работа с Linux-рабочих мест (в т.ч. Astra), где привычная MMC недоступна
Исходный код веб-части в поставке; установка как у Django-проекта (venv, migrate, deploy.sh)
Сравнение версий
Одна поставка «Ландыш» (текущая версия архива Infostart):
Веб-приложение — в исходном коде- Landysh Desktop — установщик Windows (.exe), без исходного кода
- Без лимита серверов, контуров и пользователей Ландыша у покупателя
- Бесплатная техподдержка — 30 календарных дней с даты получения прав
- Обновления в период поддержки — файлом на Infostart (автообновления нет)
Не входит в лицензию (отдельные позиции / зона покупателя):
- удалённое внедрение
- платная поддержка после 30 дней
- платформа 1С, RAC/RAS, лицензии 1С, СУБД, SMTP/почта
Установка и развёртывание
По духу это обычный Django-проект: venv, зависимости, БД, миграции, администратор, запуск. Для Linux есть scripts/Linux/deploy.sh.
Быстрый старт
python -m venv venv
source venv/bin/activate # Windows: .\venv\Scripts\activate
pip install -r requirements.txt
python manage.py migrate
# не createsuperuser: нужен ещё Profile с ролью admin
python scripts/all/reset_db.py # или scripts/Windows/reset_db.ps1 / scripts/Linux/reset_db.sh
python manage.py runserver # http://127.0.0.1:8000
Обычный django createsuperuser здесь недостаточен: у пользователя должен появиться профиль Ландыша с ролью admin. Скрипты reset_db как раз создают суперпользователя и профиль (по умолчанию логин «Администратор»). По умолчанию для разработки — SQLite. После первого входа смените пароль.
PostgreSQL
Как у любого Django-проекта: создаёте БД и пользователя, прописываете параметры в config/deployment.py / .env, делаете migrate. В deployment.py есть комментарии со схемой (не обязательно public).
CREATE DATABASE landysh;
CREATE USER landysh WITH PASSWORD '***';
GRANT ALL PRIVILEGES ON DATABASE landysh TO landysh;
-- схема landysh + права (см. комментарии в config/deployment.py)
pip install psycopg2-binary
python manage.py migrate
deploy.sh на Linux
Скрипт scripts/Linux/deploy.sh (упрощённо):
- venv + pip install -r requirements.txt;
- makemigrations / migrate;
- суперпользователь + Profile с ролью admin (не голый createsuperuser);
- systemd-unit с UTF-8 локалью (важно для RAC);
- автозапуск сервиса.
sudo ./scripts/Linux/deploy.sh
systemctl status django-landysh
journalctl -u django-landysh -f
В проде обычно добавляют nginx/HTTPS и gunicorn вместо runserver — это гигиена Django, не специфика Ландыша. На хосте приложения нужен rac совместимой версии и сеть до RAS.
Первый вход
Создаёте пользователей и группы → роли → подключения (хост RAS, порт, обычно 1545) → учётные данные администратора кластера → раскладываете дерево по папкам-контурам и отдаёте группе.
Чем это не «ещё один скрипт на RAC»
На Infostart есть полезные утилиты-обёртки над RAS/RAC (массовое завершение сеансов и т.п.) — это инструмент администратора «скачал → собрал → запустил». Ландыш про другое: многопользовательский веб-контур с ролями и группами, чтобы рутину монопольного режима делали сами аналитики, а инфраструктура не была «телефоном доверия по сеансам». Скрипт админа и веб-портал команды дополняют друг друга.
Итог
Роли снимают ликбез по MMC/RAC, группы дают периметры (инфраструктура — на весь парк, аналитик — на свои контуры), поиск по версии платформы ускоряет выбор места для новой базы, веб спасает Linux-места, журнал действий сохраняет управляемость. Установка — как у Django (venv, Postgres по желанию, migrate, deploy.sh).
Перед внедрением — тест на копии контура и согласование с ИБ.
Остались вопросы?
Для получения дополнительной информации и помощи в настройке модуля под нужды вашего бизнеса — оставьте заявку
