Ubuntu上用Docker部署Databaseus：轻量Web数据库管理工具实践

在一台 Ubuntu 机器上折腾数据库管理工具的人，应该都经历过这种纠结：桌面客户端功能全，但每台机器都要装一遍环境；phpMyAdmin 老牌但界面和体验总差点意思；命令行最自由，可团队里不是每个人都愿意敲 SQL。直到我试用了 Databaseus，这个基于 Web 的轻量数据库管理工具，配合 Docker 一键部署，在 Ubuntu 服务器上跑起来之后，整个管理体验顺畅了很多。这篇文章就把从部署、连接到后面排查坑的完整过程写一遍，适合正在 Ubuntu 上自建服务、或想给团队提供一个统一数据库入口的朋友参考。

1. 为什么最终选了 Databaseus：Web 数据库管理工具的取舍

1.1 桌面客户端和传统 Web 工具，差在哪里

先聊清楚背景。市面上能管数据库的工具非常多，大体分三类：桌面客户端、传统 Web 工具、现代 Web 数据库管理工具。

桌面客户端我最早用的是 DBeaver，后来也短暂用过 Navicat。功能确实强，能画 ER 图、能导出结构、能连各种奇奇怪怪的数据库。但问题在于：只要换一台电脑，就要重新装驱动、配 SSH 隧道、导连接配置。尤其是当数据库跑在 Ubuntu 服务器上，我又不想给服务器装图形界面的时候，桌面客户端只能在本地连，离“随时随地都能看数据库”差了一步。

传统 Web 工具我也用过，phpMyAdmin 主要管 MySQL，Adminer 是单文件，部署简单但界面比较朴素，多用户权限和团队协作基本靠凑合。项目一多了以后，你会发现最大的问题不是“能不能连上数据库”，而是“团队里每个人分别连了哪个库、跑了什么 SQL、有没有人误删数据”。传统 Web 工具在这种场景下很难给你答案。

我用表格把这几类的差异整理一下，你感受会更直观：

Databaseus 正好补上最后这一块。它本身是跑在服务器上的 Web 服务，团队成员打开浏览器输入地址就能用，不需要装任何客户端。我作为管理员，只需要在 Ubuntu 上把 Docker 容器拉起来，后面的事情都发生在浏览器里。

1.2 Databaseus 适合谁用

根据我实际使用的体会，下面这几类人最值得考虑：

• 个人开发者：自己在 VPS 或 Ubuntu 服务器上跑了 MySQL、PostgreSQL，希望有个界面方便日常查数据、改数据，又不想为这事单独装一整套桌面环境。
• 小型团队：大家共用一个开发或测试数据库，需要统一入口，避免数据库密码在群里传来传去。
• 运维和 DBA：需要集中管理多个数据库实例，同时想知道“谁在什么时候执行了什么 SQL”，Databaseus 这类带用户体系的工具比裸的 phpMyAdmin 好用很多。
• 临时演示或交付项目：有时候要给别人提供一个只读的数据查看界面，用 Docker 起一个 Databaseus，配好只读账号，用完直接销毁容器，非常干净。

我当时的使用场景比较典型：公司内部数据库跑在 Ubuntu 服务器上，团队成员分散在不同网络，大家经常找我要查询账号，甚至有人直接在生产库上执行 DELETE 时忘加 WHERE。我把 Databaseus 用一个容器部署好，给每个人开了独立账号，再给非技术人员开只读权限，这类事故基本就杜绝了。

2. Ubuntu 上用 Docker 部署 Databaseus：从零到能访问

2.1 先把 Ubuntu 这边的 Docker 环境检查清楚

部署之前，第一步是确认 Ubuntu 服务器上的 Docker 环境是否正常。很多人在这一步就卡住，所以我把检查和安装命令都列出来。

docker --version docker compose version

如果两条命令都能正常输出版本号，说明 Docker 和 Docker Compose 插件已经装好了。如果没有，可以用 Ubuntu 官方源安装：

sudo apt update sudo apt install -y docker.io docker-compose-v2 sudo systemctl enable --now docker

解释一下为什么直接用 apt 而不是网上常见的“官方安装脚本”。官方脚本可以装到最新版，但在国内服务器上经常遇到下载超时的情况；Ubuntu 仓库里的 docker.io 版本虽然不一定最新，但胜在稳定，和系统自带的 systemd 配合也最省心。对于跑一个 Web 管理工具来说，完全够用。

检查完版本后，我习惯顺手确认 Docker 服务状态：

systemctl is-active docker

如果输出 active，就可以继续了。还需要注意一点：如果你当前登录的用户不是 root，执行 docker 命令时可能会报权限错误。解决办法是把用户加入 docker 组，或者直接在命令前面加 sudo。我建议加入 docker 组，省得后面每条命令都加 sudo：

sudo usermod -aG docker $USER newgrp docker

这里补充一个安全提醒：加入 docker 组等价于拿到 root 权限，因为 Docker 本来就能挂载宿主机目录、执行容器内命令。所以只给可信的管理员用户加这个组，别给普通业务账号开这个权限。

2.2 编写 compose 文件与关键参数解读

Docker 部署有两种方式：直接 docker run，或者用 Docker Compose。我推荐 Compose，原因很简单：docker run 参数一多，命令就变得又臭又长，团队协作时也很难复制；而 Compose 文件是声明式的，所有人拉下来跑 docker compose up -d 就能得到同样一套环境。

先创建目录：

mkdir -p ~/databaseus && cd ~/databaseus

然后新建 docker-compose.yml 文件。不同版本的 Databaseus 镜像参数可能略有差异，但整体结构是这样：

services: databaseus: image: databaseus/databaseus:latest container_name: databaseus restart: unless-stopped ports: - "8080:8080" environment: - TZ=Asia/Shanghai volumes: - ./databaseus-data:/app/data

逐个参数说一下，因为这里面藏着后面很多坑的根源。

• image：指定镜像名和标签。latest 适合先体验，但如果用于生产，建议锁定具体版本号，后面方便回滚。
• container_name：容器名固定为 databaseus，方便用 docker logs databaseus 这种命令快速查看日志。
• restart: unless-stopped：只要不是手动 stop，容器退出后会自动重启。服务器重启后也会自动拉起，很省心。
• ports：左边 8080 是宿主机端口，右边 8080 是容器内应用端口。如果宿主机 8080 已经被占用，就改成 8081:8080。
• environment：TZ=Asia/Shanghai 解决时区问题。不设这个，容器内的日志时间和监控图会显示成 UTC 时间，跟你本地时间差 8 小时，排查问题时心态很容易崩。
• volumes：把容器内的 /app/data 映射到宿主机的 ./databaseus-data 目录。这里存的是 Databaseus 自己的配置、用户信息、连接定义。如果不挂这个卷，容器一删，你配置的所有数据库连接就全没了。目录的具体路径按官方文档为准，但原则是：凡是工具运行时要写入的数据，都必须通过 volume 落到宿主机。

写完之后，先拉取镜像再启动：

docker compose pull docker compose up -d

启动过程如果网络不好可能会等一会儿。看到容器状态为 running 后，浏览器访问 http://你的服务器IP:8080 就能打开登录页。

2.3 启动、验证与日常操作

第一次启动时，我踩过一个不算坑但很影响心情的问题：docker compose up 返回了，但浏览器一直打不开。这时候不要急着重启容器，先用两条命令看状态：

docker compose ps docker compose logs -f --tail 100 databaseus

docker compose ps 看容器是否 running，docker compose logs 看应用日志里有没有真正的报错。如果是第一次启动，数据库初始化可能需要几十秒，日志里会出现类似“initializing database”之类的提示，等它结束就好。

日常最常用的几个操作我也列一下：

docker compose stop # 停止容器，但保留数据和容器状态 docker compose start # 再次启动 docker compose restart # 重启服务，改完环境变量后常用 docker compose down # 删除容器，但保留数据卷

注意 docker compose down -v 这个命令要非常小心，-v 会连带删除数据卷，等于把你配置的连接和用户全清掉。我一般只有确定要彻底重置环境时才用。

还有个细节：如果改了 docker-compose.yml 里的端口或环境变量，执行 docker compose up -d 不会自动重建容器。这时候需要加一个参数：

docker compose up -d --force-recreate

这样 Docker 会按新配置重建容器，但 volume 里的数据依然保留。

3. 连接数据库、查数据、带团队：Databaseus 核心功能实操

3.1 建立数据库连接时的几个关键选择

Databaseus 部署好之后，第一件事是配置要管理的数据库连接。支持的数据库类型通常包括 MySQL、PostgreSQL、SQLite、Redis 等，具体以界面里的选项为准。

新建连接时，界面会让你填几项：连接名称、数据库类型、主机地址、端口、用户名、密码。看起来很简单，实际藏着一个坑：如果你的 MySQL 或 PostgreSQL 是直接跑在宿主机 Ubuntu 系统上的，而 Databaseus 跑在 Docker 容器里，那么主机地址绝对不能填 localhost 或 127.0.0.1。

原因不复杂：Docker 容器有自己独立的网络命名空间，容器内的 localhost 指向的是容器自己，不是宿主机。你要填的是宿主机的局域网 IP。先查一下：

hostname -I

假设输出 192.168.1.100，那就把数据库地址填成 192.168.1.100。同时，数据库那边也要确认两件事：监听地址不是只绑了 127.0.0.1，以及登录用户的 host 允许远程访问。

以 MySQL 为例，检查监听：

sudo netstat -tlnp | grep 3306

如果显示 127.0.0.1:3306，说明 MySQL 只允许本机连接，需要改配置文件里的 bind-address 为 0.0.0.0，重启 MySQL。检查连接用户：

SELECT user, host FROM mysql.user;

如果 host 是 localhost，而你要从另一台机器连接，就要创建一个允许任意 IP 访问的用户，或者至少指定宿主机的网段：

CREATE USER 'dev'@'192.168.1.%' IDENTIFIED BY 'your_password'; GRANT SELECT, INSERT, UPDATE, DELETE ON yourdb.* TO 'dev'@'192.168.1.%'; FLUSH PRIVILEGES;

填完这些参数后点“测试连接”，如果显示成功，说明容器和数据库之间的通路没问题。第一次配置稍微麻烦点，但后面再建连接就是复制粘贴的事。

3.2 数据浏览、SQL 查询与导入导出

连接建立后，Databaseus 的界面会展示出数据库的表、视图、存储过程等信息。常用的操作主要集中在这几个地方。

数据浏览：点击某张表，右侧会出现表结构和数据列表。支持按条件过滤、排序，也可以直接在里面编辑行数据。编辑时会生成对应的 UPDATE 语句，你可以先看到再执行，这点比 Navicat 里直接改单元格要安全一点。

SQL 查询：这是最常用的功能。界面里一般会有一个 SQL 编辑器，支持多标签页，可以同时写多段 SQL。我举个例子，比如要查用户和订单数：

SELECT u.id, u.email, COUNT(o.id) AS order_count FROM users u LEFT JOIN orders o ON o.user_id = u.id GROUP BY u.id, u.email ORDER BY order_count DESC LIMIT 50;

执行后结果会直接显示在下方表格里，可以复制成 CSV、Excel，也可以直接导出完整结果集。对日常运营取数来说非常方便。

导入导出也是经常用到的功能。导出时我一般选 CSV 或 Excel，注意编码选 UTF-8，否则中文可能在 Excel 里变成乱码。导入数据前，先在数据库里把表结构建好，字段顺序和文件列顺序尽量保持一致。如果字段对不上，某些导入工具会报错，非常浪费时间。

另外提一个加分功能：SQL 查询保存。把常用的查询存成“查询模板”，下次团队里任何人打开都能直接看到。比如“本周新增用户数”“每日订单量”这种固定查询，存好后整个团队拿到的口径就是一致的，避免了“同一个指标不同人查出来数字不一样”的尴尬。

3.3 多用户、只读账号和团队协作

单机自己用，Databaseus 只用管理员账号就够了。但一旦要给团队用，就必须把用户体系设计好。

我的习惯是分三种角色：

• 管理员：负责管理连接配置、创建用户、分配权限。
• 开发账号：可以读写，用于调试和修改数据。
• 只读账号：只能执行 SELECT，用于产品、运营、数据分析师等非开发角色。

创建用户时，Databaseus 一般会提供“绑定连接”和“限制权限”的选项。我只给业务同学绑定他们需要的那个库，不要把所有连接都甩给他们。这样做的好处有两个：一是降低了误操作风险，二是数据库密码不用在群里传来传去，所有人的访问都走 Databaseus 这一层。

只读账号尤其重要。运营同学有时候只是想看个数据，你给他生产库的写权限，万一他手滑在后台点了个删除，那场面非常可怕。我在 Databaseus 里给运营开完只读账号后，后面很长时间都没再出现过“数据被误改”的情况。

如果你比较在意审计，可以打开操作日志功能。日志会记录某个用户在哪段时间执行了哪些 SQL。虽然不是所有情况都能完全防住，但出了问题至少能追溯，而不是只能靠猜。

4. 部署后最容易踩的坑：排查思路与安全加固

4.1 连不上数据库：先按这个顺序排查

容器跑起来了，页面也打开了，但“测试连接”就是失败。这种情况我在群里被问过很多次，频率最高的原因无非下面几种。整理成一张速查表，你遇到问题直接按表检查。

还有一个小技巧：如果 Databaseus 和你的 MySQL、PostgreSQL 都跑在 Docker 里，但属于不同的 compose 项目，它们默认不在同一个网络，互相之间是访问不到的。最简单的解决办法是创建一个外部网络，然后让两个容器都加进去：

docker network create db-web-net

然后在各自的 docker-compose.yml 里给服务增加声明：

networks: default: external: name: db-web-net

这样 Databaseus 容器里填数据库容器名（比如 mysql-server）作为主机地址，就能打通了。

4.2 数据容易丢、时区乱、日志疯涨怎么办

这几个问题不是同时出现的，但都是部署后大概率会遇到的，我分开说。

数据丢失问题。最典型的表现是：容器重新创建后，之前配置的连接、用户全没了。原因基本只有一个，就是启动容器时没挂 volume。解决方案已经在 2.2 节的 compose 文件里写了，目录映射成宿主机路径后，卸载容器再重新 docker compose up，数据还在。强烈建议部署完就验证一次：进入配置页面，记住当前状态，然后 docker compose down && docker compose up -d，看看配置是否还在。这一步花不了两分钟，但能避免将来升级时措手不及。

时区问题。如果创建连接后，看到的时间戳和本地时间差了 8 小时，十有八九是容器时区没设置。用环境变量 TZ=Asia/Shanghai 解决。如果容器内的应用有自己的时间配置，还需要去页面的设置里把时区也改一下。这个坑不严重，但特别影响判断，尤其是查日志定位问题的时候。

日志疯涨问题。容器运行时间长了，docker logs 会积累大量日志，不停占磁盘空间。可以在 compose 文件里给服务加一段 log 配置：

logging: driver: "json-file" options: max-size: "10m" max-file: "3"

这样单份日志文件最大 10MB，最多保留 3 份，超过就会滚动清理。对于这种长期跑的 Web 管理工具来说，非常实用。

4.3 公网访问前必须做的安全配置

Databaseus 管的是数据库连接，里面存了服务器地址、用户名、密码信息，属于高价值目标。如果你只是为了内网访问，那基本做好账号密码保护就行。但如果想从公网访问，下面这几项一定要做。

第一，不要直接把 8080 端口暴露到公网。我自己更推荐用 Nginx 反向代理，然后对访问加一层 HTTP Basic Auth。即使有人知道了 Databaseus 地址，也要再输一次独立的访问密码。Nginx 配置大概是这样：

location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.htpasswd; }

第二，有条件就上 HTTPS。现在 Let’s Encrypt 证书申请很方便，用 certbot 就能自动续期。凡是承载用户密码和数据库凭据的 Web 应用，没有加密传输就等于裸奔，登录时密码会被抓包看到。

第三，云服务器的话，在安全组层面只放行需要的端口。比如只开 80 和 443，把 8080 留在内网。这样即使内网某个服务被攻破，攻击者也无法直接通过外网探测到管理界面。

第四，Databaseus 的管理员密码一定要足够强，不要用 admin 这种默认用户名，能改就改。支持多因素认证的话，管理员账号务必开启。安全管理这件事，偷懒一时爽，出事火葬场。

5. 体验复盘与健壮性优化：让工具长期稳定跑

5.1 资源占用与控制策略

部署完用了几天后，我对 Databaseus 的资源占用很关注。毕竟它是常驻服务，如果吃内存太多，会影响同一台 Ubuntu 服务器上的其他业务。

查看实时占用用一行命令：

docker stats databaseus

这个命令输出类似 PS 的实时监控界面，能看到 CPU、内存、网络 IO。以我用的镜像版本为例，空闲状态下内存占用大概在一两百 MB 这个量级，具体取决于镜像基于什么语言写的。如果内存占用偏高，可以在启动容器时加限制：

docker run -d --name databaseus --memory=512m databaseus/databaseus:latest

Compose 文件里可以这样写：

services: databaseus: image: databaseus/databaseus:latest mem_limit: 512m

注意：Docker 限制内存后，如果工具本身需要做大批量数据导出，可能会变慢或报错。所以限制给一个够用的上限即可，不要卡太死。我一般设 512M，日常使用和导出都能兼顾。

另外，如果把 Databaseus 部署在低配机器（比如 1G 内存的 VPS）上，建议不要同时运行太多大型 Web 服务，否则内存不足时内核会 OOM，随机杀进程，受害的往往是最安静的那个容器。

5.2 数据备份与版本升级的稳妥流程

长期使用任何工具，都要考虑两件事：数据备份和版本升级。

Databaseus 的连接配置、用户信息都在我们挂载的数据卷里。备份很简单，就是对宿主机上的数据目录打一个 tar 包：

cd ~/databaseus tar czf databaseus-backup-$(date +%F).tar.gz ./databaseus-data

建议配合 crontab 定时执行，比如每天凌晨备份一次，保留最近 7 天的备份：

0 2 * * * cd /home/yourname/databaseus && tar czf backups/databaseus-$(date +\%F).tar.gz databaseus-data && find backups -type f -mtime +7 -delete

升级时注意流程，不要一上来就 docker compose pull 然后 up -d。稳妥的顺序是：

docker compose pull docker compose up -d --force-recreate

升级前确保数据卷已经备份。因为我遇到过个别版本升级后，数据目录结构有变化，旧备份能帮你随时回滚。回滚操作也不复杂，重新指定旧版本镜像标签，执行 up -d --force-recreate 即可。

还有一个很容易忽略的操作：升级后去页面上确认一下连接还在不在、能不能正常测试连接。有时候镜像升级会顺带升级底层依赖，导致 JDBC 驱动版本变化，数据库连接可能会因此出问题。这些情况虽然少见，但防范一下总没错。

5.3 从单机到团队使用的扩展建议

如果你用完觉得不错，想进一步把它变成团队级工具，下面几个方向可以参考。

首先是统一入口。给 Databaseus 配一个内网域名，比如 db.internal.example.com，通过 Nginx 做 HTTPS 反向代理。这样团队成员只需要记住一个域名，不用记 IP 加端口。配合 4.3 节的 Basic Auth，管理和使用体验都会好很多。

其次是账号规范化。不要让大家用同一个 admin 账号登录。规范化操作分成两步：管理员在 Databaseus 里给每个人创建账号；把数据库层面的访问账号收敛为只读和读写两种，按需分配。这样做以后，每个人做了什么操作能查，数据库密码也不需要分发给所有人。

再一个方向是结合自动化巡检。如果你的 Databaseus 支持 API 或用脚本读取查询结果，可以把“当天新增订单量”“数据库连接数”这类监控查询做成定时脚本，把结果推到内部通知群。这等于把你的数据库管理工具变成一个轻量数据平台入口，比单纯“能查数据”又进了一步。

我个人在实际操作中的体会是：工具选型不用追求大而全，能把“Ubuntu 服务器上统一管数据库”这件事做顺，就已经解决了团队里大部分低效问题。Databaseus 加上 Docker 的体积和轻量优势，尤其适合不想背上重型平台负担的中小型团队。如果你正纠结选哪款 Web 数据库管理工具，可以按照这篇文章的流程先跑一遍，遇到连不上库、数据卷丢失、公网访问不安全这些问题，回到第 4 节对着排查就行。