Хостинг Pano Instance для других

Если вы запускаете Pano для других людей — друзей, клиентов, сети сообщества, — у каждого должен быть свой Pano, которым он управляет, обновляет и делает резервные копии, не затрагивая чужие. Эти страницы описывают модель, которую использует Pano Host. Ту же модель можно применить на своих серверах.

• Эта страница: один instance = один контейнер + одна база данных, релиз в /data, версии.
• Изоляция: защита контейнеров, сети, пользователи БД, исходящий трафик, почта, квоты.
• Эксплуатация: обновления и откат, резервные копии, сбои, логи.

NOTE

Эти страницы опираются на образы контейнеров, которые публикуются начиная с Pano 1.0.0-alpha.520.

Один контейнер и одна база данных на instance

Каждый Pano Instance получает:

Часть	На каждый instance	Общее
Контейнер	один, из ghcr.io/panomc/pano:runtime-jre<N>	—
Том данных	своя папка, смонтированная в /data	—
База данных	своя база и свои пользователи БД	сервер MySQL / MariaDB
Сеть	своя сеть Docker	к ней подключаются reverse proxy, БД и почтовый relay
Диск	своя квота	—

Никогда не запускайте два instance в одном контейнере и не давайте им общую базу данных: каждый instance должен переноситься, восстанавливаться и удаляться отдельно.

Pano Host называет всё по внутреннему id instance, а не по данным клиента. Например, контейнер и сеть — pw-<id>, база данных — w_<id>. Имена, выбранные клиентом, видны только в доменах и в интерфейсе.

Релиз хранится в /data

В образе runtime-jre<N> есть только Java и лаунчер. Сам релиз Pano — jar и его UI — лежит в папке /data instance рядом с config.conf, плагинами, темами и загрузками:

1. Скачайте jar и UI нужной версии из релиза PanoMC/Pano на GitHub и проверьте их sha256.
2. Положите их в /data instance и запишите имя файла jar в /data/.pano-jar.
3. Запустите контейнер. Лаунчер запустит jar, указанный в .pano-jar.

Так работает любая прошлая версия Pano, а не только те, для которых собран образ. Обновления из панели самого Pano тоже записываются в /data и сохраняются после перезапуска. См. Режим контейнера.

Определяйте запущенную версию по манифесту jar в /data, а не через API instance. Instance принадлежит другому человеку, поэтому ему нельзя доверять (см. Изоляция).

Версии

• Позвольте владельцу выбрать любой канал (alpha, beta, stable) и любую версию при создании instance. По умолчанию Pano Host берёт последнюю stable-версию.
• Не навязывайте обновления. Показывайте «доступно обновление» и дайте владельцу обновиться самому или включить автообновление. См. Эксплуатация.
• Выбирайте версию Java для каждого instance. В семействе runtime всегда есть минимум Pano — Java 11; новее — можно, старее — отклоняется. Pano Host запускает новые instance на минимуме, который нужен выбранной версии Pano, и позволяет владельцу выбрать более новую Java, например для плагина, которому нужна Java 21. См. Версия Java.
• Задавайте размер кучи по лимиту памяти контейнера. Pano Host отдаёт около 75 % памяти instance и не позволяет владельцам увеличить кучу своими JVM-аргументами. См. Память.

Конфигурация

Передавайте настройки базы данных и SMTP через переменные окружения. Pano записывает их в config.conf при первом запуске. При остановке Pano перезаписывает config.conf, поэтому, если его нужно изменить вручную, сначала остановите контейнер, затем отредактируйте и запустите.

Pano Host также задаёт PANO_HOSTED и другие переменные Pano Host. Они носят только информационный характер: версии Pano с их поддержкой показывают «управляется Pano Host» и баннер квот. Внутри Pano они ничего не блокируют.