Есть требования к размещению
Прикладной стек, конфигурация и операционные данные должны находиться в инфраструктуре компании.
Размещение в инфраструктуре заказчика
MassAccess on-premise в Docker Compose или Kubernetes
Разверните MassAccess on-premise в инфраструктуре компании одним из двух способов: как самодостаточный по составу стек Docker Compose или как версионируемые установки Kubernetes с помощью Helm. Ваша команда управляет инфраструктурой, обновлениями и резервными копиями; облачная связь остаётся обязательной для лицензии, учёта сообщений, оплаты и получения образов.
- 01Размещение
- На сервере или в кластере компании
- 02Эксплуатация
- Силами вашей команды
- 03Связность
- Требуется исходящий HTTPS
Когда on-premise оправдан
Эта модель подходит, если контроль инфраструктуры важнее полностью управляемой эксплуатации.
Нужен контроль изменений
Компания сама выбирает момент установки обновлений и может выполнить откат по документированной процедуре.
Есть команда эксплуатации
Команда эксплуатации отвечает за сервер или кластер Kubernetes, сеть, TLS, мониторинг, резервные копии и восстановление.
Способы развёртывания MassAccess on-premise: Docker Compose или Kubernetes и Helm
Docker Compose и Kubernetes — два отдельных поддерживаемых способа поставки. Выберите один до подготовки инфраструктуры и не смешивайте их команды, файлы и жизненные циклы.
Docker Compose
Самодостаточный по составу стек из 14 служб для одного сервера Linux под управлением заказчика.
- Архив Docker Compose со сценариями установки, проверки состояния, обновления и отката
- Встроенные PostgreSQL, Kafka, ClickHouse и Redis с шестью изолированными томами
- Обратный прокси-сервер, TLS, мониторинг, резервное копирование и восстановление выполняет ваша команда
Kubernetes и Helm
Две версионируемые установки Helm для прикладных компонентов и необязательных встроенных хранилищ данных.
- Профили размещения данных external-data, bundled-data и mixed-data
- Kubernetes 1.33–1.36, Helm 4.2, подтверждённое применение сетевых правил CNI и проверенный CSI StorageClass
- Кластерная платформа, объекты Secret, Ingress или Gateway, TLS, мониторинг и резервные копии остаются ответственностью оператора
Чем on-premise отличается от SaaS
Функциональный способ отправки остаётся тем же; меняется место размещения и зона операционной ответственности.
| Характеристика | SaaS | On-premise |
|---|---|---|
| Размещение приложения | Инфраструктура MassAccess | Инфраструктура компании |
| Панель и API | Доступны на massaccess.net | Доступны через локальный адрес или обратный прокси-сервер компании |
| Обновления | Выполняет MassAccess | Запускает компания через upgrade.sh или процедуры Helm |
| Мониторинг и резервные копии | Зона MassAccess | Зона компании |
| Лицензия, учёт и оплата | Облачные | Остаются облачными |
Что находится локально, а что остаётся в облаке
On-premise переносит прикладной контур, но не превращает MassAccess в изолированный автономный продукт.
В контуре компании
- Прикладные сервисы, локальная панель управления и API
- Конфигурация компании, сценарии, настройки ботов и операционные данные
- Журналы, мониторинг и резервные копии, которыми управляет компания
Облачные сервисы MassAccess
- Выпуск и контроль состояния лицензии
- Подписанный счётчик использования и назначенный тариф
- Баланс, тарификация и получение поставочного пакета и обновлений
Важно: решение не предназначено для полностью изолированной сети
Серверу или кластеру нужен постоянный документированный исходящий доступ для контрольных сообщений лицензии, подписанного учёта использования, облачной оплаты, получения образов и работы интеграций Telegram и MAX. При потере контрольной связи лицензия приостанавливает отправку.
Требования к среде — до начала установки
Требования зависят от выбранного способа поставки. Руководство отдельно описывает исходные требования к серверу Docker Compose и предварительные проверки кластера Kubernetes.
- Способ поставки
- Compose или Helm
- Выберите один жизненный цикл и используйте предназначенные для него пакет и руководство
- Контейнерная платформа
- Docker или Kubernetes
- Compose требует Docker 24+ и Compose 2.24+; Helm — Kubernetes 1.33–1.36 и Helm 4.2
- Вычислительные ресурсы
- Обязательна предварительная проверка
- Проверьте фактическую нагрузку, накладные расходы платформы, квоты и доступные ресурсы узлов
- Постоянное хранилище
- Тома или CSI
- Compose использует тома узла; встроенные хранилища Kubernetes требуют проверенный RWO StorageClass
- Сеть
- Исходящий HTTPS
- Для Kubernetes также нужны рабочая служба имён и подтверждённое применение CNI NetworkPolicy
- Внешний доступ
- Точка входа с TLS
- Используйте обратный прокси-сервер узла или существующий контроллер Ingress/Gateway; чарты не устанавливают контроллер и не выпускают сертификаты
Как проходит развёртывание
Для обоих способов поставки предусмотрен отдельный последовательный жизненный цикл установки и проверки. Выберите способ до получения конфигурации.
- 01
Создайте лицензию и выберите способ
Зарегистрируйте компанию, создайте ключ on-premise и выберите Docker Compose либо Kubernetes в конфигураторе.
- 02
Подготовьте целевую среду
Проверьте сервер Compose или кластер Kubernetes, вычислительные ресурсы, хранилище, сетевые правила и обязательные исходящие соединения.
- 03
Проверьте поставку
До установки проверьте неизменяемый пакет или полный комплект поставки, конфигурацию без секретов и ссылки на объекты Secret.
- 04
Установите в документированном порядке
Для Compose запустите install.sh; для Kubernetes установите с помощью Helm данные перед приложением и выполните helm test.
- 05
Проверьте и передайте в эксплуатацию
Проверьте готовность, вход в панель, API, WebSocket, webhook, подтверждённые операции с данными, мониторинг и контрольное восстановление.
Кто за что отвечает
Граница ответственности должна быть понятна до выбора модели поставки.
Команда компании
- Сервер или кластер Kubernetes, сеть, служба имён, CNI/CSI, точка входа и TLS
- Безопасное хранение конфигурации и секретов
- Мониторинг, свободное место и реакция на сбои
- Резервное копирование, проверка восстановления и запуск обновлений
MassAccess
- Пакет Compose или версионируемые чарты Helm, образы приложения и процедуры жизненного цикла
- Документированные требования, процедуры диагностики и отката
- Облачный жизненный цикл лицензии и подписанный учёт сообщений
- Единый API-контракт и обновления прикладного стека
Что потребуется после запуска
On-premise — это постоянная эксплуатационная ответственность, а не разовая установка.
Наблюдаемость
Контролируйте состояние служб, журналы, доступность внешних зависимостей и запас ресурсов.
Резервное копирование
Копируйте данные и конфигурацию по документированной процедуре и регулярно проверяйте восстановление.
Обновление и откат
Запускайте upgrade.sh или проверенное обновление Helm в выбранное окно изменений; до обновления подтвердите совместимое восстановление.
Тарифы
Стоимость on-premise
За поставочный пакет нет отдельной платы. Сначала расходуются регистрационные бонусные сообщения, затем отправки учитываются по тарифу компании через облачную систему оплаты.
Подробнее о тарифеПри регистрации компании
500
Бесплатных сообщений для старта
Без ограничения срока использования
затем
0,59 ₽
за сообщение
Без абонентской платы
Вопросы перед выбором on-premise
Ответы для ИТ, безопасности, финансовой и продуктовой команд.
Можно ли установить MassAccess в полностью изолированном сегменте?
Нет. Для действующей лицензии, учёта, оплаты, получения образов и интеграций требуется документированный исходящий доступ.
Какие данные передаются за пределы контура?
Облачные сервисы получают состояние лицензии и подписанные данные учёта использования. Для доставки содержимое сообщения и служебные данные взаимодействуют с выбранным мессенджером. Полный сетевой контур нужно сверить с руководством до согласования архитектуры.
Нужны ли публичный IP, домен и TLS?
Для локального доступа внутри сети — не обязательно. Если панель или API доступны через интернет, нужен домен, TLS и обратный прокси-сервер; внутренние служебные порты напрямую наружу не открываются.
Обновления устанавливаются автоматически?
Нет. Компания выбирает окно изменений и запускает upgrade.sh для Compose или документированное обновление Helm для Kubernetes. Обе процедуры требуют проверок и заранее принятого решения о совместимом откате или восстановлении.
Kubernetes заменяет Docker Compose?
Нет. Это два отдельных поддерживаемых способа поставки. Compose остаётся самодостаточным по составу серверным стеком; Kubernetes использует версионируемые установки Helm для приложения и данных с внешним, встроенным или смешанным размещением.
Кто отвечает за резервное копирование и восстановление?
Команда компании. В поставке есть документированные команды, но расписание, хранение копий и регулярная проверка восстановления остаются на стороне заказчика.
Можно ли использовать одну лицензию на нескольких экземплярах?
Нет. Один лицензионный пакет нельзя одновременно запускать на нескольких экземплярах — это может привести к приостановке лицензии.
Как оплачиваются сообщения?
Пакет не имеет отдельной цены. Бонус, баланс и тариф остаются облачными, а on-premise передаёт подписанный счётчик использования для тарификации.
Сначала согласуйте инфраструктурный контур
Выберите Compose или Kubernetes, проверьте соответствующую инфраструктуру и границу ответственности, назначьте владельцев мониторинга и резервного копирования, затем создайте лицензию и переходите к отдельному руководству.