Як розгорнути CloudBeaver на власній інфраструктурі у 2026 році: драйвери баз даних, робочий простір і доступ

Найкоротша демонстрація CloudBeaver доводить лише те, що процес слухає порт 8978. Для production потрібні вагоміші докази. Сценарій має проходити навіть після заміни контейнера: завершити налаштування адміністратора, встановити потрібний драйвер, підключитися за приватним іменем хоста й виконати запит лише на читання.

CloudBeaver розгортають із чіткою метою: як браузерний клієнт для баз даних Postgres, MySQL та інших. Найпоширеніша пастка під час розгортання — помилки дозволів робочого простору або неможливість container DNS визначити хости баз даних, тому налаштуванню публічної URL-адреси та збереженню стану потрібно приділити таку саму увагу, як і запуску образу.

Відновлення CloudBeaver на порожньому хості

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

Знімки корисні для швидкого відкату, але коли хост або том зникає, потрібна незалежна резервна копія. Відновіть дані в порожньому середовищі з образом, версію якого зафіксовано, і перевірте, що робочий простір, користувачі, драйвери та підключення повернулися, а кожна базова база даних має власний план резервного копіювання. Використовуйте постійні томи та знімки, щоб розділяти ці два механізми відновлення.

Запуск 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 перевірте фактично застосоване оточення, монтування та listener. Додайте перевірені параметри підключення для приватних маршрутів і драйвери баз даних для кожної цільової бази; для приватних сервісів використовуйте приватні імена. Успішний запуск завершується тоді, коли ви можете завершити налаштування адміністратора, встановити потрібний драйвер, підключитися за приватним іменем хоста й виконати запит лише на читання, а не тоді, коли docker ps виводить Up.

Від чого залежить CloudBeaver

HTTP-процес CloudBeaver слухає порт 8978; залиште цей порт у мережі застосунку та публікуйте лише маршрут платформи. Мережевий контракт CloudBeaver — це приватні маршрути й драйвери баз даних для кожної цільової бази. Приватні endpoints мають залишатися у внутрішньому DNS, дозволяйте лише необхідні вихідні підключення та надайте CloudBeaver облікові дані сервісу з обмеженими правами.

Зафіксуйте межі у вигляді короткого контракту: хто відповідає за вимогу, які облікові дані використовуються, який timeout є прийнятним і як проявляється збій. Потім виконайте цю транзакцію: завершити налаштування адміністратора, встановити потрібний драйвер, підключитися за приватним іменем хоста й виконати запит лише на читання. Під час запуску спостерігайте за станом робочого простору, завантаженням драйверів, паралельними сесіями та мережевою затримкою до кожної бази даних, адже це навантаження дає корисніший орієнтир для початкового розміру, ніж неактивний контейнер.

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

Публічна межа CloudBeaver має складатися з одного канонічного hostname, автоматичного TLS і однієї внутрішньої цілі на 8978. Налаштуйте URL-адресу сервера та proxy headers для публічного HTTPS origin, щоб клієнти поверталися за адресою, яку розпізнає сервіс.

Якщо приймальна транзакція завершується помилкою, класифікуйте першу помилку. Проблеми DNS, сертифіката та 502 належать до контрольного списку перевірки TLS. Умова «не працюють дозволи робочого простору або container DNS не може визначити хости баз даних» належить до рівня застосунку після того, як запит успішно досяг CloudBeaver.

Приймальне тестування CloudBeaver у production

Не використовуйте трафік першого користувача як приймальний тест CloudBeaver. Підготуйте нешкідливий тестовий стан і виконайте повну дію: «завершити налаштування адміністратора, встановити потрібний драйвер, підключитися за приватним іменем хоста й виконати запит лише на читання». Зафіксуйте точну публічну URL-адресу, результат, посилання на образ і інтервал логів, пов’язаний із запуском.

Замініть контейнер і повторіть тест без повторної побудови даних. Далі відновіть систему на порожньому хості; умова відновлення — повернення робочого простору, користувачів, драйверів і підключень, тоді як кожна базова база даних дотримується власного плану резервного копіювання. На кожному проході спостерігайте за станом робочого простору, завантаженням драйверів, паралельними сесіями та мережевою затримкою до кожної бази даних і налаштуйте alert на погіршення транзакції, а не на метрики неактивного контейнера.

Остання перевірка має навмисно завершитися помилкою: тимчасово забороніть тестовій ідентичності доступ до приватних маршрутів і драйверів баз даних для кожної цільової бази. Переконайтеся, що отримане повідомлення CloudBeaver вказує на відповідну межу, а не запускає видалення даних чи нескінченний restart. Відновіть коректну умову та підтвердьте, що та сама тестова транзакція виконується успішно. Додайте цю коротку перевірку до release checklist.

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

Перший корисний операційний показник для CloudBeaver — здатність завершити налаштування адміністратора, встановити потрібний драйвер, підключитися за приватним іменем хоста й виконати запит лише на читання. Доповніть його сигналами насичення для стану робочого простору, завантаження драйверів, паралельних сесій і мережевої затримки до кожної бази даних. Probe, що перевіряє лише процес, не має звертатися до дорогих залежностей або перезапускати контейнер через короткочасну недоступність upstream-сервісу.

Ставтеся до оновлень як до змін даних, оскільки міграції робочого простору CloudBeaver і сумісність драйверів потрібно тестувати до зміни версій образу. Фіксуйте версії, відпрацьовуйте процедуру на відновленому стані й зберігайте попередній образ доступним, доки rollback залишається можливим. Якщо не працюють дозволи робочого простору або container DNS не може визначити хости баз даних, збережіть логи до перезапуску; зазвичай саме в них міститься повідомлення про причину.

Специфічні для CloudBeaver рішення щодо безпеки

Не переносьте припущення щодо безпеки з локального tutorial. Специфічна проблема CloudBeaver — дозвіл анонімного доступу до підключень production-баз даних. Тому в production слід вимкнути анонімне адміністрування, використовувати окремих користувачів і надавати обліковим записам баз даних лише ті дозволи, які потрібні кожному підключенню.

CB_SERVER_NAME керує поведінкою, а не конфіденційністю; перевіряйте його тип і значення, а справжні облікові дані CloudBeaver зберігайте окремо. Обмежте доступ до файлової системи та мережі, захистіть endpoints налаштування й визначте ліміти завантаження, запитів або виконання для стану робочого простору, завантаження драйверів, паралельних сесій і мережевої затримки до кожної бази даних.

Для розгортання CloudBeaver у Dockup все одно потрібен приймальний тест

Одноклікове розгортання CloudBeaver у Dockup має забезпечувати безпечну заміну: маршрут і далі спрямовується на 8978, секрети не вбудовуються в образ, а постійні шляхи з’являються в новому контейнері. Те саме розгортання може працювати на compute-ресурсах Dockup або на підключеній машині.

Завершіть роботу, специфічну для застосунку: підключіться та протестуйте приватні маршрути й драйвери баз даних для кожної цільової бази, застосуйте канонічну публічну адресу та виконайте цю приймальну перевірку: завершити налаштування адміністратора, встановити потрібний драйвер, підключитися за приватним іменем хоста й виконати запит лише на читання. Додайте результат відновлення до runbook до появи реальних користувачів.

Поширені запитання

Що потрібно CloudBeaver для розгортання в production?

Прокладіть маршрут від контейнера CloudBeaver через порт 8978 до одного HTTPS origin. Необхідна підтримка мережі — приватні маршрути й драйвери баз даних для кожної цільової бази. Не вважайте CloudBeaver готовим, доки не зможете завершити налаштування адміністратора, встановити потрібний драйвер, підключитися за приватним іменем хоста й виконати запит лише на читання.

Які дані CloudBeaver потрібно включити до резервної копії?

Зберігайте /opt/cloudbeaver/workspace і включіть робочий простір, користувачів, визначення підключень і сховище облікових даних до одного маніфесту відновлення. Чисте відновлення CloudBeaver вважається успішним лише тоді, коли повертаються робочий простір, користувачі, драйвери й підключення, а кожна базова база даних дотримується власного плану резервного копіювання.

Чи потрібен CloudBeaver HTTPS за reverse proxy?

Використовуйте HTTPS для публічного CloudBeaver origin і залиште порт 8978 на внутрішньому маршруті. Правильно застосуйте налаштування CloudBeaver: задайте URL-адресу сервера та proxy headers для публічного HTTPS origin. Для CloudBeaver HTTPS захищає облікові дані або вміст користувачів під час передавання та забезпечує узгоджену поведінку клієнта, чутливу до origin.

Як тестувати оновлення CloudBeaver?

Відновіть поточний стан CloudBeaver в ізольованому розгортанні, застосуйте кандидатну версію та повторіть приймальну транзакцію. Приділіть особливу увагу тому, що міграції робочого простору CloudBeaver і сумісність драйверів потрібно тестувати до зміни версій образу. Зберігайте попередній образ CloudBeaver, доки не буде зрозумілою межа міграції даних і rollback.