Тримати клієнт бази даних на сервері, а не на ноутбуці: як це вирішено у вас?

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт, спільното!

Я з невеликої команди, ми робимо LibreDB Studio, це клієнт баз даних під ліцензією MIT, який ставиш на власний сервер і відкриваєш у браузері. Проєкт некомерційний, код відкритий, посилання дам наприкінці. Але питання в мене не про сам проєкт, а про підхід, бо цікаво почути, як це влаштовано у вас.

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

Ми спробували навпаки: програма стоїть поруч з базами, людина відкриває вкладку в браузері. Облікові дані лишаються на сервері, оновлюється одна копія, доступ відкликається теж на сервері.

Найбільше часу з’їла не архітектура, а сумісність. Своїх драйверів у нас 16. Ще 26 рушіїв заявляють сумісність по протоколу з якимось із основних. Підключення проходить, звичайні запити проходять, а щойно питаєш, які в базі таблиці і які в них типи, відповіді розходяться. Багато таких рушіїв ще й у рядку версії називають того, кого імітують, тому вірити їй не можна. Ми після підключення просто пробуємо і дивимось, що реально працює.

Питання до вас. Як у ваших командах вирішено доступ до продакшен-баз: кожен зі своїм клієнтом і тунелем, спільний bastion, чи щось на кшталт вебклієнта на сервері? І чи стикалися ви з тим, що «сумісний» рушій ламається саме на системних каталогах?

Код: github.com/libredb/libredb-studio