Как разместить CloudBeaver самостоятельно в 2026 году: драйверы баз данных, workspace и доступ

Краткая демонстрация CloudBeaver доказывает лишь то, что процесс прослушивает порт 8978. Для production нужны более убедительные доказательства. Система должна проходить этот сценарий даже после замены контейнера: завершить настройку администратора, установить нужный драйвер, подключиться по private hostname и выполнить read-only запрос.

CloudBeaver разворачивают с понятной целью: использовать браузерный клиент баз данных для Postgres, MySQL и других СУБД. Самая распространённая проблема при развёртывании — не работают разрешения workspace или container DNS не может разрешить имена хостов баз данных. Поэтому обработке публичного URL и сохранению состояния нужно уделять столько же внимания, сколько и запуску image.

Восстановление CloudBeaver на чистом хосте

До создания первой реальной записи перечислите состояние системы: workspace, пользователи, определения подключений и хранилище credentials. Подключите /opt/cloudbeaver/workspace до bootstrap, запишите безопасные тестовые данные и замените контейнер, чтобы доказать фактическую постоянность этого пути. Проверьте mount: запишите безопасные данные, замените CloudBeaver и прочитайте их обратно.

Snapshots полезны для быстрого rollback, но при исчезновении хоста или volume нужна независимая backup-копия. Восстановите систему в пустом окружении с зафиксированным image и убедитесь, что workspace, пользователи, драйверы и подключения вернулись, а каждая нижележащая база данных использует собственный план резервного копирования. Используйте persistent volumes и snapshots, чтобы разделять эти два механизма восстановления.

Запуск CloudBeaver с наблюдаемыми настройками по умолчанию

Следующая команда делает границу контейнера видимой, не создавая видимость полного развёртывания всех внешних сервисов.

docker run -d \
  --name cloudbeaver \
  --restart unless-stopped \
  -p 127.0.0.1:8978:8978 \
  -v cloudbeaver-data:/opt/cloudbeaver/workspace \
  -e CB_SERVER_NAME=CloudBeaver \
  dbeaver/cloudbeaver:latest

До открытия ingress проверьте resolved environment, mounts и listener. Добавьте проверенные настройки подключений для private routes и драйверы баз данных для каждой целевой базы; для private services используйте private names. Запуск считается успешным, когда вы можете завершить настройку администратора, установить нужный драйвер, подключиться по private hostname и выполнить read-only запрос, а не когда docker ps выводит Up.

От чего зависит CloudBeaver

HTTP-процесс CloudBeaver прослушивает порт 8978; оставьте этот порт в application network и публикуйте только маршрут платформы. Network contract для CloudBeaver — это private routes и драйверы баз данных для каждой целевой базы. Держите private endpoints во внутреннем DNS, разрешайте только необходимые исходящие подключения и выдайте CloudBeaver credentials с ограниченной областью действия.

Зафиксируйте границу в виде короткого контракта: кто отвечает за требование, какие credentials используются, какой timeout допустим и как выглядит сбой. Затем выполните эту транзакцию: завершите настройку администратора, установите нужный драйвер, подключитесь по private hostname и выполните read-only запрос. Во время выполнения отслеживайте состояние workspace, загрузки драйверов, количество одновременных сессий и network latency до каждой базы данных, поскольку такая нагрузка позволяет точнее определить начальный размер ресурсов, чем работа idle container.

Разделяйте внутренние и внешние URL

Публичной границей CloudBeaver должны быть один canonical hostname, автоматический TLS и одна внутренняя target-точка на 8978. Укажите server URL и proxy headers для публичного HTTPS origin, чтобы clients возвращались по адресу, который распознаёт сервис.

Если acceptance transaction завершается ошибкой, классифицируйте первую проблему. Проблемы с DNS, certificate и 502 относятся к TLS validation checklist. Условие «не работают разрешения workspace или container DNS не может разрешить имена хостов баз данных» относится к application side после того, как запрос успешно достиг CloudBeaver.

Production-проверка CloudBeaver

Не используйте трафик первых пользователей в качестве acceptance test для CloudBeaver. Подготовьте безопасное тестовое состояние и выполните полное действие: «завершить настройку администратора, установить нужный драйвер, подключиться по private hostname и выполнить read-only запрос». Зафиксируйте точный публичный URL, результат, image reference и интервал логов, связанный с запуском.

Замените контейнер и повторите проверку без пересоздания данных. Затем восстановите систему на чистом хосте; условие восстановления — возвращение workspace, пользователей, драйверов и подключений, при этом каждая нижележащая база данных должна следовать собственному плану резервного копирования. На каждом проходе отслеживайте состояние workspace, загрузки драйверов, количество одновременных сессий и network latency до каждой базы данных и настройте alert на ухудшение транзакции, а не на метрики idle container.

Одна финальная проверка должна намеренно завершиться ошибкой: временно запретите тестовой identity доступ к private routes и драйверам баз данных для каждой целевой базы. Убедитесь, что полученное сообщение CloudBeaver указывает на соответствующую границу, а не запускает удаление данных или бесконечный restart. Восстановите корректное условие и подтвердите успешное выполнение той же тестовой транзакции. Включите эту короткую проверку в release checklist.

Диагностика CloudBeaver, который выглядит исправным

Первый полезный operational metric для CloudBeaver — возможность завершить настройку администратора, установить нужный драйвер, подключиться по private hostname и выполнить read-only запрос. Дополните его сигналами насыщения для состояния workspace, загрузок драйверов, количества одновременных сессий и network latency до каждой базы данных. Probe, проверяющий только процесс, не должен вызывать дорогие зависимости или перезапускать контейнер из-за временной недоступности upstream.

Считайте обновления изменениями данных, поскольку миграции workspace CloudBeaver и совместимость драйверов нужно проверять до изменения версий image. Зафиксируйте версии, отрепетируйте процедуру на восстановленном состоянии и сохраняйте предыдущий image, пока rollback остаётся возможным. Если не работают разрешения workspace или container DNS не может разрешить имена хостов баз данных, сохраните логи до перезапуска: обычно именно в них содержится сообщение о причине.

Специфические для CloudBeaver решения по безопасности

Не переносите предположения о безопасности из локального tutorial. Специфическая проблема CloudBeaver — разрешение anonymous access к production-подключениям к базам данных. Поэтому в production следует отключить anonymous administration, использовать отдельных пользователей и выдавать учётным записям баз данных только те permissions, которые нужны каждому подключению.

CB_SERVER_NAME управляет поведением, а не confidentiality; проверьте его type и value, а настоящие credentials CloudBeaver храните отдельно. Ограничьте filesystem и network access, защитите setup endpoints и задайте лимиты для upload, request или execution в отношении состояния workspace, загрузок драйверов, количества одновременных сессий и network latency до каждой базы данных.

Для развёртывания в Dockup всё равно нужен acceptance test CloudBeaver

One-click deployment CloudBeaver в Dockup должен делать замену безопасной: route продолжает указывать на 8978, secrets не встраиваются в image, а persistent paths возвращаются в новом контейнере. То же развёртывание можно запускать на compute в Dockup или на подключённой машине.

Выполните специфическую для приложения часть: подключитесь и проверьте private routes и драйверы баз данных для каждой целевой базы, примените canonical public address и запустите эту acceptance check: завершите настройку администратора, установите нужный драйвер, подключитесь по private hostname и выполните read-only запрос. Добавьте результат восстановления в runbook до появления реальных пользователей.

Часто задаваемые вопросы

Что нужно CloudBeaver для production-развёртывания?

Направьте контейнер CloudBeaver через порт 8978 к одному HTTPS origin. Сетевое требование для поддержки — private routes и драйверы баз данных для каждой целевой базы. Не объявляйте CloudBeaver готовым, пока не сможете завершить настройку администратора, установить нужный драйвер, подключиться по private hostname и выполнить read-only запрос.

Какие данные CloudBeaver нужно включить в резервную копию?

Сохраняйте /opt/cloudbeaver/workspace и включайте workspace, пользователей, определения подключений и хранилище credentials в один recovery manifest. Чистое восстановление CloudBeaver считается успешным только тогда, когда возвращаются workspace, пользователи, драйверы и подключения, а каждая нижележащая база данных следует собственному плану резервного копирования.

Нужен ли CloudBeaver HTTPS за reverse proxy?

Используйте HTTPS для публичного CloudBeaver origin и оставляйте порт 8978 во внутреннем route. Корректно примените настройку CloudBeaver: укажите server URL и proxy headers для публичного HTTPS origin. Для CloudBeaver HTTPS защищает credentials или пользовательский контент при передаче и обеспечивает согласованное поведение клиентов, зависящее от origin.

Как тестировать обновление CloudBeaver?

Восстановите текущее состояние CloudBeaver в изолированном deployment, примените candidate version и повторите acceptance transaction. Уделите этому особое внимание: миграции workspace CloudBeaver и совместимость драйверов нужно проверять до изменения версий image. Сохраняйте предыдущий image CloudBeaver, пока не будут понятны границы миграции данных и rollback.