Почему Supabase-analytics может не запускаться в Docker и как с этим жить — VogueTech

Что нового

В GitHub-репозитории Supabase появился баг-репорт, который касается работы контейнера supabase-analytics в продакшене. Пользователь запускает Supabase через Docker (на виртуальной машине Altatech) и сталкивается с тем, что контейнер аналитики не поднимается вообще.

Факты:

Используется контейнер supabase-analytics, внутри которого работает Logflare версии 1.26.4.
Ядро — Elixir 1.17.3 и Erlang/OTP со стандартной библиотекой stdlib 6.2.2.2.
Контейнер бесконечно перезапускается и падает уже на этапе boot.
Логи показывают одну и ту же ошибку FunctionClauseError в функции Logflare.Utils.ip_version/1.
В логе явно видно, что Logflare получает nil вместо IP-адреса и не умеет это обрабатывать.
Время ожидания автора — до 50 000 секунд (примерно 14 часов), за которые контейнер так и не стартовал.

По сути, это не новое фиче, а конкретный кейс: при определённой конфигурации окружения Supabase-analytics на базе Logflare не стартует вообще и зацикливается в краш-лупе.

Как это работает

Supabase-analytics использует Logflare как отдельный сервис в Docker-контейнере. При запуске Logflare читает конфигурацию через Config.Reader из runtime.exs и пытается определить IP-версию для хоста.

Ключевые моменты по логам:

В логах каждый раз выводится:
```
LOGFLARE_NODE_HOST is: 127.0.0.1
```

Затем Elixir-конфиг-провайдер падает с ошибкой:

** (FunctionClauseError) no function clause matching in Logflare.Utils.ip_version/1
  (logflare 1.26.4) lib/logflare/utils.ex:243: Logflare.Utils.ip_version(nil)
  /opt/app/rel/logflare/releases/1.26.4/runtime.exs:276: (file)

Ошибка повторяется циклически, после каждого падения создаётся erl_crash.dump, и процесс завершается с Illegal instruction (core dumped).

Из этого видно, что под капотом происходит следующее:

Logflare запускается внутри контейнера supabase-analytics.
Конфигурация читает IP-адрес некоего узла (скорее всего, того же LOGFLARE_NODE_HOST или связанной переменной окружения).
Вместо корректного IP в функцию Logflare.Utils.ip_version/1 попадает nil.
В Logflare.Utils нет варианта функции, который умеет работать с nil, поэтому Elixir выбрасывает FunctionClauseError.
Приложение завершает работу на этапе boot, Erlang/OTP пишет дамп и контейнер перезапускается.

Важная деталь: лог всегда показывает LOGFLARE_NODE_HOST is: 127.0.0.1, но в функцию всё равно прилетает nil. Это намекает на то, что внутри runtime.exs Logflare использует не только LOGFLARE_NODE_HOST, но и ещё один параметр, который в этом окружении остаётся пустым.

Что это значит для вас

Если вы используете Supabase в Docker и рассчитываете на встроенную аналитику, есть несколько практических выводов.

Когда это может ударить по вам

Вы поднимаете Supabase на собственном сервере или VM (как в кейсе с Altatech), а не в управляемом облаке Supabase.
Вы включили контейнер supabase-analytics из стандартного docker-compose.
У вас нет явно настроенных переменных окружения для Logflare, связанных с IP/хостом, либо сетевое окружение даёт неожиданные значения.

В этом сценарии контейнер аналитики может вообще не стартовать. Вся система при этом может продолжать работать, но вы не получите логи и метрики от Supabase-analytics.

Как к этому относиться на практике

Продакшен на Supabase-analytics пока лучше считать нестабильным, если вы запускаете его не в "родной" инфраструктуре Supabase, а в своём Docker-окружении.
Если вам критична аналитика запросов, логирование и трассировка, держите резервный вариант:
- отдельный Logflare (с самостоятельной конфигурацией);
- либо сторонние решения: OpenTelemetry-стек, Prometheus + Loki, Sentry и т.д.
Если вы просто тестируете Supabase локально или в dev-среде, и аналитика не обязательна, можно временно отключить контейнер supabase-analytics в docker-compose.yml, чтобы не тратить ресурсы на бесконечные перезапуски.

Где не стоит на это рассчитывать

Не стоит закладывать Supabase-analytics как единственный источник логов и метрик для продакшена, если вы разворачиваете Supabase на собственном железе или в стороннем облаке.
Не стоит ожидать, что контейнер "сам починится" после долгого ожидания: автор дал ему работать около 50 000 секунд, но сервис так и не стартовал.

Сервис Supabase и GitHub доступны из России без VPN, но конкретные облака-хостеры и образы Docker могут блокироваться операторами. Если вы не можете скачать образ или подключиться к GitHub, придётся использовать VPN или зеркала.

Место на рынке

По этому баг-репорту можно сравнивать не столько Supabase с конкурентами, сколько подход к аналитике и логированию.

Supabase-analytics опирается на Logflare внутри одного контейнера. Это удобно для единого стека, но делает вас зависимыми от стабильности Elixir-приложения и его конфигурации.

Если смотреть на альтернативы:

Самостоятельный стек логов (например, Loki + Promtail, Elasticsearch + Kibana, ClickHouse + Vector) даёт больше контроля, но требует отдельной настройки и поддержки.
SaaS-логгеры (Datadog, Logtail и т.п.) снимают головную боль с инфраструктуры, но стоят дороже и требуют интеграции на уровне приложения.

Здесь Supabase идёт по пути "всё в одном контейнерном наборе". Плюс — быстрое подключение логов и аналитики в одном docker-compose. Минус — вы получаете сразу и баги, которые возникают внутри этого интегрированного стека, как в случае с Logflare.Utils.ip_version(nil).

Если для вас критичны стабильность и предсказуемость логирования, проще вынести аналитику в отдельный, более зрелый стек и использовать Supabase только как базу и API.

Как запустить и что проверять

В исходном баг-репорте нет полного docker-compose.yml, но по логам можно выделить ключевые моменты, которые стоит проверить в своём окружении:

Проверьте переменные окружения для Logflare в контейнере supabase-analytics:
- LOGFLARE_NODE_HOST
- возможные дополнительные переменные, которые используются внутри runtime.exs для определения IP или хоста.

Посмотрите логи контейнера, как это сделал автор:

sudo podman logs <ID_контейнера>

В его случае это выглядело так:

sudo podman logs 60a3bd6c6f4a
LOGFLARE_NODE_HOST is: 127.0.0.1
ERROR! Config provider Config.Reader failed with:
** (FunctionClauseError) no function clause matching in Logflare.Utils.ip_version/1
  (logflare 1.26.4) lib/logflare/utils.ex:243: Logflare.Utils.ip_version(nil)
  /opt/app/rel/logflare/releases/1.26.4/runtime.exs:276: (file)
  (elixir 1.17.3) src/elixir.erl:386: :elixir.eval_external_handler/3
  (stdlib 6.2.2.2) erl_eval.erl:919: :erl_eval.do_apply/7
  (stdlib 6.2.2.2) erl_eval.erl:479: :erl_eval.expr/6
  (stdlib 6.2.2.2) erl_eval.erl:1207: :erl_eval.expr_list/7
  (stdlib 6.2.2.2) erl_eval.erl:446: :erl_eval.expr/6
  (stdlib 6.2.2.2) erl_eval.erl:436: :erl_eval.expr/6

Runtime terminating during boot ({function_clause,[{'Elixir.Logflare.Utils',ip_version,[nil],[{file,"lib/logflare/utils.ex"},{line,243}]},{elixir_eval,'__FILE__',1,[{file,"/opt/app/rel/logflare/releases/1.26.4/runtime.exs"},{line,276}]},{elixir,eval_external_handler,3,[{file,"src/elixir.erl"},{line,386}]},{erl_eval,do_apply,7,[{file,"erl_eval.erl"},{line,919}]},{erl_eval,expr,6,[{file,"erl_eval.erl"},{line,479}]},{erl_eval,expr_list,7,[{file,"erl_eval.erl"},{line,1207}]},{erl_eval,expr,6,[{file,"erl_eval.erl"},{line,446}]},{erl_eval,expr,6,[{file,"erl_eval.erl"},{line,436}]}]})

Crash dump is being written to: erl_crash.dump...done
Illegal instruction (core dumped)

Убедитесь, что контейнер не застрял в краш-лупе. Для этого посмотрите статус через Docker или Podman:
```
docker ps -a
# или
podman ps -a
```
Временное решение — закомментировать или удалить сервис supabase-analytics из docker-compose.yml, если он блокирует развёртывание и при этом не критичен для вас.
Долгосрочное решение — следить за обновлениями Logflare и Supabase. Как только они добавят обработку nil в ip_version/1 или поправят конфиг в runtime.exs, проблема должна уйти.

Итог для практиков

Если вы уже крутите Supabase в Docker и видите бесконечные перезапуски supabase-analytics с FunctionClauseError — это известный сценарий.
Основная причина — Logflare 1.26.4 не умеет обрабатывать nil в Logflare.Utils.ip_version/1 и падает ещё до старта.
Для продакшена сейчас разумнее не полагаться только на встроенный Supabase-analytics, а держать отдельный стек логирования.
Для dev-среды проще отключить контейнер аналитики и не тратить время на его отладку, пока Supabase и Logflare не выпустят фикс.