Quartz 4

🔍 搜索

MinIO 部署现状与维护调研

18 min read

MinIO 部署现状与维护调研

1. 调研目的

本文用于梳理当前机器上的 MinIO 实际部署方式、对外暴露能力、桶的现状，以及后续如何通过 mc 维护桶和桶配置。

本次调研重点回答以下问题：

  1. MinIO 是否部署在本机
  2. 管理账号是否配置在机器上
  3. 当前是否开启了 MinIO Console
  4. 现有对外上传页面暴露了哪些接口
  5. 当前实际有哪些桶
  6. 后续如何通过 mc 维护桶信息、策略、版本化、生命周期等

2. 结论摘要

当前结论如下：

  1. MinIO 已部署在本机，并通过 systemd 管理
  2. MinIO root 管理账号直接配置在本机系统文件中
  3. 当前正式配置关闭了浏览器管理界面（Console）
  4. 对外暴露的是一个自定义上传页，不是 MinIO 官方 Console
  5. 上传页公开暴露了桶列表接口和上传接口
  6. 上传页接口只暴露了 5 个桶，但 MinIO 实际共有 6 个桶
  7. http://minio.898311.xyz/ / https://minio.898311.xyz/ 不能作为 mc 的 MinIO API endpoint 使用
  8. 本机已安装 mc，可以直接用来维护桶和桶配置

这意味着：

  • “上传内容”可以通过自定义上传页处理
  • “桶管理信息”本质上应通过本机 MinIO 管理能力维护
  • 当前最合适的运维方式是 使用 mc 直接管理

3. 本机 MinIO 服务现状

3.1 systemd 服务状态

本机存在 minio.service，且服务正在运行：

  • 服务名：minio.service
  • 类型：MinIO Object Storage
  • 启动命令：
/usr/local/minio/minio server --address 0.0.0.0:9000 /root/minio

对应 systemd 单元文件：

关键内容：

[Service]
EnvironmentFile=-/etc/default/minio
ExecStart=/usr/local/minio/minio server $MINIO_OPTS $MINIO_VOLUMES

说明：

  • MinIO 启动参数来自 /etc/default/minio
  • 当前数据目录为 /root/minio
  • 当前 API 监听端口为 9000

3.2 本机监听端口

本机存在 9000 监听，和 MinIO 服务状态一致。

说明：

  • 本机 MinIO S3 兼容接口入口是 http://127.0.0.1:9000
  • 如果后续使用 mc 或 SDK，本机可直接连这个地址

4. 管理账号是否在机器上配置

是。

在以下文件中可以直接看到 root 管理账号配置：

核心内容：

MINIO_VOLUMES="/root/minio"
MINIO_OPTS="--address 0.0.0.0:9000"
MINIO_ROOT_USER="shubin"
MINIO_ROOT_PASSWORD="shubin898311"
MINIO_BROWSER=off

结论：

  1. MinIO root 账号不是放在当前代码仓库中
  2. 它是通过 systemd 环境文件配置在机器上的
  3. 当前可以认为本机就是 MinIO 管理信息的真实落点

4.1 风险说明

该文件中包含明文 root 凭证，风险较高：

  1. 任何拥有主机读取权限的用户都可能拿到最高权限
  2. root 用户可直接修改桶、策略、生命周期、版本化、复制等配置
  3. 后续如果需要多人维护，建议改为：
    • 使用专用运维子账号
    • root 凭证只保留在系统级密钥管理中
    • 文档中只记录凭证位置，不记录明文

5. 当前是否有管理后台

5.1 当前对外首页不是 MinIO Console

访问以下地址：

  • https://minio.898311.xyz/

返回首页标题为：

<title>MinIO 图片上传器</title>

页面中还有：

  • MinIO Image Hub
  • 代理前缀 · /upload

说明：

  • 当前对外域名首页是一个自定义上传器
  • 不是 MinIO 官方管理控制台
  • 用户目前看到的是“上传前端”，不是“桶管理后台”

5.2 当前正式配置关闭了浏览器管理界面

在 /etc/default/minio 中可以看到：

MINIO_BROWSER=off

同时当前 MINIO_OPTS 中没有 --console-address。

这说明：

  • 当前正式运行配置没有启用 MinIO Console
  • 就算 root 账号存在，也不能直接通过浏览器访问官方后台

5.3 历史上曾经开过 Console

本机还存在一个备份文件：

其中内容显示曾配置过：

MINIO_OPTS="--address 0.0.0.0:9000 --console-address :9001"

说明：

  • 历史上机器曾经启用过 MinIO Console
  • 当前则改成只暴露 API，不暴露官方控制台

6. 当前对外上传页面暴露的接口

通过抓取 https://minio.898311.xyz/ 首页脚本，可确认上传页包含以下前端逻辑。

6.1 桶列表接口

上传页会调用：

fetch("/upload/api/buckets")

实际访问结果：

{"buckets":["blogfile","blogimg","image","tmp-image","upload"],"default":"blogimg"}

说明：

  1. 该接口是公开可访问的
  2. 它会返回当前允许上传页使用的桶列表
  3. 默认桶是 blogimg

6.2 上传接口

上传页脚本中可以看到：

fetch("/upload/api/upload", { method: "POST", body: formData })

其中表单字段至少包含：

  • file
  • bucket

说明：

  • 当前上传页支持“选择桶后上传”
  • 桶名不是页面写死的，而是由 /upload/api/buckets 动态返回

6.3 当前未发现的公开管理接口

本次探测中，没有发现以下公开接口：

  • 列对象接口
  • 删除对象接口
  • 创建桶接口
  • 删除桶接口
  • 修改桶策略接口
  • 生命周期接口
  • 版本化接口
  • 加密接口

因此当前上传页能力可以归纳为：

  1. 读取桶列表
  2. 向指定桶上传文件

而不能视作完整管理后台。

6.4 根域名不是 MinIO S3 API endpoint

对以下地址做了直接验证：

  • http://minio.898311.xyz/
  • https://minio.898311.xyz/

验证结果：

  1. 两者都返回 200 OK
  2. Content-Type 为 text/html; charset=utf-8
  3. 页面内容是 MinIO 图片上传器
  4. mc 直连该域名时失败，返回的是非 S3 API 的 HTML 页面

验证命令示例：

curl -I http://minio.898311.xyz/
curl -k -I https://minio.898311.xyz/
env MC_HOST_domain_http=http://<user>:<pass>@minio.898311.xyz mc ls domain_http
env MC_HOST_domain_https=https://<user>:<pass>@minio.898311.xyz mc ls domain_https

实际 mc 报错：

mc: <ERROR> Unable to list folder. XML syntax error on line 8: attribute name without = in element

结论：

  1. minio.898311.xyz 根域名当前是自定义上传页入口
  2. 它不是真正的 MinIO S3 API 根入口
  3. 外网同事如果把这个域名直接配置给 mc，当前会失败
  4. 当前已确认可用的真实管理入口仍是本机直连 http://127.0.0.1:9000

6.5 通过 frpc 暴露的真实外网 API 地址

本机 frpc 配置中已确认存在 MinIO 代理：

关键配置为：

[[proxies]]
name = "bj-minio"
type = "tcp"
localIP = "127.0.0.1"
localPort = 9000
remotePort = 9010

这表示：

  1. 本机 MinIO 127.0.0.1:9000
  2. 通过 frpc 暴露到远端 tx2.898311.xyz:9010

外网连通性已验证：

nc -vz -w 3 tx2.898311.xyz 9010
curl -I http://tx2.898311.xyz:9010/

其中 curl -I 返回了：

  1. HTTP/1.1 400 Bad Request
  2. Server: MinIO
  3. Content-Type: application/xml

这符合“直接命中 MinIO API，但未带合法 S3 请求参数”的特征。

结论：

  1. 当前真实可用的外网 MinIO API 地址是 http://tx2.898311.xyz:9010/
  2. 该地址不同于 https://minio.898311.xyz/
  3. tx2.898311.xyz:9010 才是同事在外网配置 mc 时应使用的 endpoint

7. 当前桶现状

7.1 通过上传页接口观测到的桶

当前 GET /upload/api/buckets 返回：

["blogfile","blogimg","image","tmp-image","upload"]

因此按当前上传中间层可见视角，桶共有 5 个：

  1. blogfile
  2. blogimg
  3. image
  4. tmp-image
  5. upload

默认桶：

  • blogimg

7.2 通过 MinIO 实际 API 观测到的真实桶

直接通过本机 MinIO API 执行：

env MC_HOST_local=http://<user>:<pass>@127.0.0.1:9000 mc ls local

确认当前真实桶共有 6 个：

  1. blogfile
  2. blogimg
  3. generalandroid
  4. image
  5. tmp-image
  6. upload

这说明：

  1. 上传页桶接口不是完整事实源
  2. generalandroid 当前存在于 MinIO 中，但没有暴露在上传页桶列表里
  3. 后续做桶盘点、迁移、清理时，应以 mc ls 结果为准

7.3 仓库中实际引用最多的桶

从当前仓库 Markdown 内容来看，广泛被引用的是：

  1. blogimg
  2. blogfile

这说明：

  • blogimg 应该是当前博客图片主桶
  • blogfile 应该是附件或二进制文件桶
  • 其余 image / tmp-image / upload 更像历史兼容桶、临时桶或上传页扩展桶

7.4 规划中的未来结构

仓库里的迁移方案文档中规划了单桶模型：

规划内容为：

  • 单桶：generalandroid
  • 目录前缀：
    • releases/
    • media/
    • traces/
    • tools/
    • books/

注意：

  • 这是“规划目标”
  • 不是当前线上实际状态

8. MinIO 管理信息真正维护在哪里

从当前调研结果看，桶信息维护分成两层：

8.1 真正的底层维护点

底层 MinIO 配置维护点在本机：

  1. systemd 服务定义
  2. /etc/default/minio 环境文件
  3. /root/minio 数据目录
  4. MinIO 内部元数据

这一层负责：

  • root 凭证
  • API 监听
  • Console 是否启用
  • 桶元数据
  • 策略
  • 生命周期
  • 版本化
  • 加密
  • 复制

8.2 上传中间层维护点

上传页是一个额外的中间层：

  • 对外展示桶下拉框
  • 调用 /upload/api/buckets
  • 调用 /upload/api/upload

这一层负责：

  • 允许前端看到哪些桶
  • 默认选择哪个桶
  • 上传时是否允许指定桶

也就是说：

  • MinIO 本体决定桶真实存在和真实配置
  • 上传中间层决定前端“看见哪些桶、默认往哪里传”

9. 当前最推荐的维护方式：使用 mc

9.1 本机已安装 mc

本机已安装 MinIO 官方客户端：

mc version RELEASE.2025-08-13T08-35-41Z

说明：

  • 机器已经具备直接管理 MinIO 的工具链
  • 不需要再额外安装客户端

9.2 为什么推荐 mc

相对于直接手写 S3 API 或依赖上传页，mc 更适合运维：

  1. 官方工具，覆盖桶和对象管理常见能力
  2. 不需要自己处理签名细节
  3. 可以直接看桶、改策略、改生命周期、改版本化
  4. 比自定义 Web 页面更稳定

10. mc 的基础配置方式

10.1 配置本地 alias

可使用本机 MinIO root 凭证配置一个 alias：

mc alias set local http://127.0.0.1:9000 shubin shubin898311

更推荐本机维护时优先使用：

http://127.0.0.1:9000

原因：

  1. 避开反向代理影响
  2. 避开自定义上传页
  3. 直接命中 MinIO API

不要使用：

mc alias set local-domain http://minio.898311.xyz "$MINIO_ROOT_USER" "$MINIO_ROOT_PASSWORD"

原因：

  1. 根域名返回的是 HTML 上传页
  2. 不是 S3 ListBuckets API
  3. mc 会因为收到非 S3 XML 响应而失败

如果是外网同事使用 mc，应改为：

mc alias set remote http://tx2.898311.xyz:9010 "$MINIO_ROOT_USER" "$MINIO_ROOT_PASSWORD"

之后可执行：

mc ls remote
mc ls remote/blogimg
mc anonymous get remote/blogimg

10.2 查看当前 alias

mc alias list

11. mc 如何维护桶信息

下面给出常用维护动作。

11.1 查看所有桶

mc ls local

输出会列出所有桶。

11.2 查看桶统计信息

mc du local/blogimg
mc du local/blogfile

可用于查看桶大小、对象数量级。

11.3 创建桶

mc mb local/new-bucket

例如：

mc mb local/generalandroid

11.4 删除空桶

mc rb local/tmp-image

如果桶非空，需要先清理对象，再删桶。

11.5 查看匿名访问策略

mc anonymous get local/blogimg

11.6 设置匿名访问策略

公开下载：

mc anonymous set download local/blogimg

完全公开：

mc anonymous set public local/blogimg

取消公开：

mc anonymous set private local/blogimg

11.7 查看桶版本化信息

mc version info local/blogimg

启用版本化：

mc version enable local/blogimg

暂停版本化：

mc version suspend local/blogimg

11.8 查看生命周期配置

导出生命周期规则：

mc ilm export local/blogimg

导入生命周期规则：

mc ilm import local/blogimg < lifecycle.json

11.9 查看和设置桶标签

查看：

mc tag list local/blogimg

设置：

mc tag set local/blogimg "purpose=blog,owner=zbc,visibility=public"

11.10 查看和设置桶加密

查看：

mc encrypt info local/blogimg

设置 SSE-S3：

mc encrypt set sse-s3 local/blogimg

11.11 查看复制配置

当前 minio.service 日志里已经出现 blogimg 的 replication 报错，说明至少某些桶存在复制配置。

相关命令：

mc replicate ls local/blogimg

如需后续深入，应重点检查：

  • blogimg

12. 建议的桶信息维护流程

建议把“实际管理”和“文档登记”拆开。

12.1 实际管理

使用 mc 直接对 MinIO 做操作：

  1. 新建桶
  2. 调整匿名策略
  3. 配置版本化
  4. 配置生命周期
  5. 配置标签
  6. 配置复制

12.2 文档登记

同时在仓库中维护一份桶清单，例如：

  • main/blog/minio/buckets.md
  • 或 main/blog/minio/buckets.yaml

建议记录字段：

  1. 桶名
  2. 用途
  3. 是否公开
  4. 默认上传页是否可见
  5. 生命周期规则
  6. 版本化状态
  7. 负责人
  8. 备注

这样可以避免以后只靠系统配置和人工记忆。

13. 风险与注意事项

13.1 root 凭证风险

当前 root 凭证保存在系统文件中，而且是明文。

建议：

  1. 尽量减少传播范围
  2. 后续改为专用运维账户
  3. 文档中不再重复写明文密码

13.2 直接改策略前先备份

修改桶策略、生命周期、版本化前，建议先导出当前状态：

mc anonymous get local/blogimg
mc ilm export local/blogimg > blogimg.lifecycle.json
mc version info local/blogimg
mc tag list local/blogimg
mc encrypt info local/blogimg
mc replicate ls local/blogimg

13.3 先用只读命令探路

建议先执行只读命令：

mc ls local
mc du local
mc anonymous get local/blogimg
mc version info local/blogimg
mc ilm export local/blogimg

确认后再做写操作。

13.4 上传页返回的桶列表不等于全部真实桶

/upload/api/buckets 只能说明：

  • 当前上传中间层愿意暴露给前端的桶有哪些

它不必然等于：

  • MinIO 中真实存在的所有桶

因此真正的事实源仍然应是：

mc ls local

14. 后续建议

14.1 短期

建议先做三件事：

  1. 配置 mc alias
  2. 用 mc ls 拉取真实桶列表
  3. 把每个桶的策略、生命周期、版本化状态导出保存

14.2 中期

建议把桶信息沉淀到仓库：

  1. 增加 buckets.md 或 buckets.yaml
  2. 记录真实用途和负责人
  3. 明确哪些桶是历史桶、临时桶、正式桶

14.3 长期

如果希望通过网页管理：

  1. 可以重新开启 MinIO Console
  2. 或者扩展现有 /upload/api/* 中间层，增加只读管理接口

但从运维角度看，优先级更高的仍然是：

  • 先用 mc 建立标准维护流程

15. 当前可直接执行的最小命令集合

15.1 配置 alias

mc alias set local http://127.0.0.1:9000 shubin shubin898311

15.2 查看所有桶

mc ls local

15.3 查看单桶权限

mc anonymous get local/blogimg

15.4 查看单桶版本化

mc version info local/blogimg

15.5 导出生命周期

mc ilm export local/blogimg

15.6 查看标签

mc tag list local/blogimg

15.7 查看复制

mc replicate ls local/blogimg

16. 最终结论

当前 MinIO 的“真正管理面”在本机，不在仓库里，也不在公开网页里。

具体来说：

  1. 服务在本机
  2. root 管理账号在本机 systemd 环境文件
  3. 官方 Console 当前关闭
  4. 对外只暴露了一个自定义上传页
  5. 上传页仅公开桶列表与上传能力
  6. 本机已安装 mc，这是当前最适合维护桶信息的方式

因此，后续的标准做法应当是：

  • 用 mc 管理真实桶配置
  • 用仓库文档维护桶登记信息
  • 将上传页视作“上传工具”，而不是“完整后台”

Graph View