Skip to content

Среда выполнения контейнера ​

Как Pano ведёт себя в контейнере: перезапуски, обновления, runtime-образ, Java, память и пользователи.

Режим контейнера ​

Вне контейнера перезапуск или обновление из панели запускает новый отдельный процесс java, а старый завершается. В контейнере это остановило бы контейнер: когда главный процесс завершается, контейнер тоже завершается. В режиме контейнера Pano делает иначе:

  1. Готовит новый jar в /data и записывает имя его файла в /data/.pano-jar.
  2. Завершается с кодом 75.
  3. Лаунчер образа, работающий под tini, видит код 75 и запускает jar, указанный в /data/.pano-jar. Контейнер продолжает работать.

Любой другой код завершения, как обычно, останавливает контейнер, поэтому ваша политика перезапуска (например, --restart unless-stopped) по-прежнему обрабатывает сбои.

Обновление ​

Скачайте более новый образ и пересоздайте контейнер. С Compose:

bash
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 запускает так каждый инстанс.

bash
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.