Среда выполнения контейнера
Как Pano ведёт себя в контейнере: перезапуски, обновления, runtime-образ, Java, память и пользователи.
Режим контейнера
Вне контейнера перезапуск или обновление из панели запускает новый отдельный процесс java, а старый завершается. В контейнере это остановило бы контейнер: когда главный процесс завершается, контейнер тоже завершается. В режиме контейнера Pano делает иначе:
- Готовит новый jar в
/dataи записывает имя его файла в/data/.pano-jar. - Завершается с кодом 75.
- Лаунчер образа, работающий под
tini, видит код 75 и запускает jar, указанный в/data/.pano-jar. Контейнер продолжает работать.
Любой другой код завершения, как обычно, останавливает контейнер, поэтому ваша политика перезапуска (например, --restart unless-stopped) по-прежнему обрабатывает сбои.
Обновление
Скачайте более новый образ и пересоздайте контейнер. С Compose:
docker compose pull && docker compose up -d- Теги каналов (
latest,beta,alpha) сдвигаются с каждым релизом, достаточноpull. - Теги версий не меняются: задайте
PANO_TAG=<version>в.env(или смените тег вdocker run).
При запуске шаг pano-seed копирует jar образа в /data только если образ несёт другой релиз, чем тот, что он установил в прошлый раз. Поэтому:
- Обновление, сделанное в панели, сохраняется между перезапусками контейнера, пока вы не смените образ.
- Смена образа всегда устанавливает релиз образа, даже поверх более нового обновления из панели.
Возврат к более старому тегу устанавливает старый jar, но база данных не откатывается. Перед каждым обновлением делайте резервную копию /data и базы данных.
Не используйте -bg
-bg заставляет Pano перезапустить себя отдельным процессом и завершиться. В контейнере это завершение останавливает контейнер. Образы никогда не передают -bg; не добавляйте его.
Runtime-образ (для опытных)
ghcr.io/panomc/pano:runtime-jre<N> содержит Java N, Bun и лаунчер, но без релиза Pano. Jar лежит в /data, а .pano-jar хранит его имя. Pano Host запускает так каждый инстанс.
mkdir pano && cd pano
# скачайте Pano-<version>.jar с https://panomc.com/download в эту папку
echo "Pano-<version>.jar" > .pano-jar
docker run -d --name pano --user "$(id -u):$(id -g)" --memory 1g \
-v "$PWD":/data -p 8088:8088 ghcr.io/panomc/pano:runtime-jre11Ничего не устанавливается автоматически: версию Pano меняют заменой jar и .pano-jar. <N> — 11, 17, 21 или 25; runtime-jre<N>-<version> закрепляет сборку, вышедшую с релизом.
Версия Java
Pano нацелен на Java 11, поэтому Java 11 — его минимум, и полный образ использует её. Выберите более новый runtime-jre<N>, если этого требует ваш плагин. Управляемым серверам на локальном pano-node нужна Java 17 или новее.
Образы построены на glibc (Eclipse Temurin на Ubuntu). Некоторые нативные библиотеки Pano, например хеширование паролей Argon2, есть только в сборках для glibc; в musl-образе вроде Alpine вход в систему не работает. Если собираете свой образ, начинайте с Java-образа на glibc.
Память
Куча Java следует лимиту памяти контейнера (по умолчанию -XX:MaxRAMPercentage=75), поэтому задайте его (--memory или mem_limit в Compose). Лимит покрывает JVM и процессы Bun, которые отрисовывают UI; см. Память и лимиты. PANO_JVM_ARGS заменяет параметры Java по умолчанию.
Непривилегированный пользователь
Образы запускают Pano от uid 10000 и не требуют дополнительных привилегий. Pano Host запускает инстансы со снятыми привилегиями, no-new-privileges, корневой файловой системой только для чтения, записываемым /data и временным /tmp. Если запускаете с --user, убедитесь, что этот пользователь может писать в /data.