Runtipi: как корректно переключить встроенный Postgres-контейнер на внешний Postgres? (.env.local / runtipi-cli / docker compose)

Привет! Нужна помощь знающих людей по Runtipi.

Исходные условия

  • Runtipi установлен в LXC-контейнере (Proxmox).

  • Установка была через скрипт start-samohosting bash -c "$(wget -qLO - install.samohosting.ru)".

  • Runtipi версия: v4.6.5

  • Каталог: /opt/runtipi

  • Runtipi запускается контейнерами: runtipi, runtipi-reverse-proxy, runtipi-queue, runtipi-db (postgres:14).

Цель

Хочу подключить Runtipi к внешнему PostgreSQL (на другом lxc контейнере в той же сети), чтобы не держать runtipi-db (postgres:14) внутри LXC.

Внешний Postgres доступен, подключение проверял:

docker run --rm --network runtipi_tipi_main_network postgres:14 \
  psql "host=192.168.100.106 port=5432 dbname=tipi user=tipi password=***" \
  -c "select current_user, current_database(), inet_client_addr(), current_setting('search_path');"

Команды выполняются, create schema if not exists drizzle; тоже проходит.

Что было изначально

В .env после установки была заданна переменная окружения POSTGRES_HOST=runtipi-db и Runtipi заводится со своим runtipi-db контейнером.

Что я пробовал

  1. Попробовал прописать переменные прямо в docker-compose.yml (у сервиса runtipi), предварительно создав базу данных tipi и выдав все права:
environment:
  POSTGRES_HOST: 192.168.100.106
  POSTGRES_PORT: "5432"
  POSTGRES_DBNAME: tipi
  POSTGRES_USERNAME: tipi
  POSTGRES_PASSWORD: ***

Но при старте ловил ошибки миграций вида:
Error migrating database: Failed query: CREATE SCHEMA IF NOT EXISTS "drizzle"

(Внешняя база при этом доступна и schema создаётся, если делать вручную через psql).

  1. Нашёл в доках runtipi про .env.local:

When running CLI commands, you can override any environment variable by providing a custom .env file
sudo ./runtipi-cli start --env-file ./.env.local

Сделал:

cp .env .env.local
nano .env.local

В .env.local оставил минимально:

POSTGRES_HOST=192.168.100.106
POSTGRES_PORT=5432
POSTGRES_DBNAME=tipi
POSTGRES_USERNAME=tipi
POSTGRES_PASSWORD=****
LOG_LEVEL=info

Далее:

docker compose down
sudo ./runtipi-cli start --env-file ./.env.local

После запуска:

  • docker inspect runtipi ... | grep POSTGRES показывает, что переменные в конфиге контейнера есть.

  • Но внутри контейнера runtipi переменных нет:

docker exec -it runtipi sh -lc 'env | sort | egrep "^(POSTGRES_|DATABASE_URL|LOG_LEVEL)="'

Выводит только:

LOG_LEVEL=info

POSTGRES_* внутри env отсутствуют.

Также docker compose --env-file ./.env config почему-то показывает POSTGRES_HOST: runtipi-db, то есть будто бы берётся .env, а не .env.local.

И при этом runtipi-db всё равно поднимается как контейнер postgres:14.

Дополнительно пробовал

  • Пробовал прописывать параметры подключения к PostgreSQL напрямую в docker-compose.yml в секции environment сервиса runtipi (POSTGRES_HOST / PORT / DBNAME / USERNAME / PASSWORD).
    Конфигурация принималась, контейнер пересобирался, но:

    • либо Runtipi всё равно пытался подключаться к runtipi-db,

    • либо возникали ошибки на этапе миграций (CREATE SCHEMA drizzle).

  • Проверял, не перезаписываются ли значения переменных на этапе старта:

    • сравнивал вывод docker compose config,

    • docker inspect runtipi,

    • и env внутри контейнера — данные между ними расходятся.

  • Пробовал сделать файл .env только для чтения:

  1. volumes:
      - /opt/runtipi/.env:/opt/runtipi/.env:ro
    

    а также через chmod 444 .env, чтобы Runtipi не мог его перегенерировать или модифицировать.

  2. Несмотря на режим read-only, при старте через runtipi-cli:

    • .env всё равно пересобирается / используется с дефолтными значениями,

    • POSTGRES_HOST снова указывает на runtipi-db.

  3. Также проверял, не влияет ли наличие контейнера runtipi-db:

    • останавливал его вручную,

    • запускал Runtipi без него,

    • но сервис всё равно не начинал использовать внешний PostgreSQL.

Вопросы

  1. Как правильно и “канонично” перевести Runtipi на внешний PostgreSQL?
    Должно ли это делаться только через runtipi-cli и --env-file, или надо править docker-compose.yml, или есть ещё какой-то supported-way?

  2. Почему может быть ситуация, когда:

  • docker inspect показывает POSTGRES_* в .Config.Env,

  • но внутри контейнера env их не видно?

  1. Есть ли у Runtipi ещё один слой генерации/перезаписи env, который игнорирует POSTGRES_HOST и возвращает runtipi-db?

Если нужно — могу приложить docker-compose.yml, .env, .env.local, логи docker logs runtipi и вывод ./runtipi-cli команд.

Заранее спасибо!

UPD:

Собрал архив и залил в репозиторий https://github.com/DataArchitectPro/runtipi_habr_debug со всеми конфигами/логами/inspect’ами до и после попытки переключения Runtipi v4.6.5 на внешний PostgreSQL.

Что делал: добавил параметры внешней БД в .env.local (POSTGRES_HOST=192.168.100.106 и т.д.), проверил env внутри контейнера runtipi — там POSTGRES_* действительно указывают на внешний хост. Но при этом docker compose config после изменений всё равно показывает POSTGRES_HOST: runtipi-db + depends_on: runtipi-db, и контейнер runtipi-db продолжает подниматься. В docker inspect runtipi видно, что /opt/runtipi/.env смонтирован внутрь контейнера как /data/.env, а в этом .env всё ещё POSTGRES_HOST=runtipi-db. В логах runtipi есть Generating system env file — похоже, Runtipi на старте генерирует/перезаписывает системный env из /data/.env, игнорируя .env.local.

В архиве 2 снимка: 00_Исходное_состояние и 01_Попытка_внешний_PostgreSQL, плюс diffs и выводы команд (env внутри контейнера, compose config, inspect).

Нужен совет: какой supported-way “правильно” указать внешний Postgres так, чтобы Runtipi не возвращал runtipi-db?

Полистал документацию runtipi..

Выглядит так, что Вы делаете все верно..
Увы, но идей, что идет не так - нет..

1 лайк

Привет, спасибо за то, что посмотрел и отдельное большое спасибо за то, что ты делаешь для сообщества. С Новым годом, рождеством и наступающим старым Новым годом!

Посмотрел, что встроенный постгресс потребляет совсе ничего ресурсов, решил оставить как есть пока что.

IMHO runtipi это не про архитектуру, тут смысла выносить СУБД или еще что-то нет.

Или разворачивать самостоятельно и по своему желанию настраивать все или сидеть на том, что runtipi и подобные сервисы дает

1 лайк

Согласен. для удовлетворения своего ОКР хотел так сделать )