4. MinIO 持久化与配置:数据卷挂载、Access Key/Secret Key 配置、TLS 证书配置

在 Development 环境中,MinIO 作为 S3 兼容存储的核心组件,其持久化与安全配置直接决定了调试数据的可靠性与接口调用的安全性。本章围绕三个关键维度展开:数据卷挂载确保容器重启后数据不丢失;Access Key / Secret Key 配置建立身份认证基础;TLS 证书配置保障传输层加密。以下内容均基于 Docker Compose 部署方式,兼顾快速验证与生产习惯养成。

4.1 数据卷挂载:持久化存储基石

MinIO 默认将数据存储在容器内部文件系统,容器销毁后数据即丢失。Development 环境必须通过 Docker 卷(Volume) 或 绑定挂载(Bind Mount) 实现持久化。推荐使用命名卷,因其由 Docker 管理,跨平台兼容性更好。

关键原则:MinIO 需要两个独立的数据目录——/data 存储对象数据,/root/.minio 存储配置与凭证。生产环境建议分离挂载,Development 环境可合并挂载以简化管理。

4.1.1 卷挂载配置示例(docker-compose.yml)

version: '3.8'
services:
  minio:
    image: minio/minio:RELEASE.2024-01-01T00-00-00Z
    container_name: dev-minio
    ports:
      - "9000:9000"   # API 端口
      - "9001:9001"   # Console 端口
    volumes:
      - minio-data:/data               # 对象数据持久化卷
      - minio-config:/root/.minio      # 配置与凭证持久化卷
    environment:
      MINIO_ROOT_USER: admin
      MINIO_ROOT_PASSWORD: password123
    command: server /data --console-address ":9001"

volumes:
  minio-data:
    driver: local
  minio-config:
    driver: local

4.1.2 卷类型对比

卷类型 定义位置 数据生命周期 适用场景
命名卷(Named Volume) volumes: 顶层声明 独立于容器,手动删除才消失 推荐用于 Development 与 Production
绑定挂载(Bind Mount) 宿主机绝对路径 与宿主机目录绑定 本地调试时直接查看文件
匿名卷(Anonymous Volume) 仅 volumes: 列表写路径 容器删除后残留,需手动清理 不推荐,易造成磁盘占用
验证持久化:执行 docker compose down 后再 docker compose up -d,之前通过 mc 或 SDK 上传的对象应仍然存在。若丢失,请检查卷挂载路径是否正确。

4.2 Access Key / Secret Key 配置:身份认证体系

MinIO 使用 Access Key(用户名) 和 Secret Key(密码) 进行身份认证。Development 环境可通过环境变量或配置文件设置初始凭证。注意:MinIO 在首次启动后会将凭证持久化到 /root/.minio,后续修改环境变量不会覆盖已有凭证。

4.2.1 环境变量方式(推荐快速启动)

environment:
  MINIO_ROOT_USER: devadmin
  MINIO_ROOT_PASSWORD: devsecret123

4.2.2 配置文件方式(适合版本管理)

创建 config.env 文件,内容如下:

MINIO_ROOT_USER=devadmin
MINIO_ROOT_PASSWORD=devsecret123

在 docker-compose.yml 中引用:

env_file:
  - ./config.env

4.2.3 凭证变更与重置

若需要修改凭证,必须删除已持久化的配置卷:

# 停止并删除容器
docker compose down

# 删除配置卷(注意:这会清除所有配置,包括 TLS 证书)
docker volume rm dev_minio-config

# 重新启动
docker compose up -d
安全提醒:Development 环境不要使用生产级强密码,但也不要使用 minioadmin/minioadmin 等默认值。建议使用 dev-{项目名}-{随机后缀} 格式,既便于记忆又避免冲突。

4.3 TLS 证书配置:传输层加密

Development 环境虽然不涉及真实数据,但启用 TLS 可以提前暴露证书配置问题,避免上线后手忙脚乱。MinIO 支持 自签名证书 和 Let's Encrypt 证书,Development 环境推荐使用自签名证书。

4.3.1 生成自签名证书

使用 OpenSSL 生成 CA 和服务器证书:

# 1. 生成 CA 私钥和证书
openssl req -x509 -newkey rsa:4096 -keyout ca-key.pem -out ca.pem \
  -days 365 -nodes -subj "/CN=MinIO Dev CA"

# 2. 生成服务器私钥和 CSR
openssl req -newkey rsa:4096 -keyout server-key.pem -out server.csr \
  -nodes -subj "/CN=minio.local"

# 3. 使用 CA 签发服务器证书
openssl x509 -req -in server.csr -CA ca.pem -CAkey ca-key.pem \
  -CAcreateserial -out server-cert.pem -days 365

4.3.2 证书挂载与配置

将证书文件放入 ./certs/ 目录,并在 docker-compose.yml 中挂载:

volumes:
  - ./certs:/root/.minio/certs:ro
  - minio-data:/data
  - minio-config:/root/.minio

environment:
  MINIO_ROOT_USER: devadmin
  MINIO_ROOT_PASSWORD: devsecret123
  MINIO_SERVER_URL: "https://minio.local:9000"

MinIO 会自动检测 /root/.minio/certs/ 目录下的 server-cert.pem 和 server-key.pem,并启用 HTTPS。

4.3.3 验证 TLS 配置

# 使用 curl 验证(忽略自签名证书警告)
curl -k https://localhost:9000/minio/health/live

# 使用 mc 客户端配置(需指定 CA 证书)
mc alias set dev https://minio.local:9000 devadmin devsecret123 \
  --api S3v4 --insecure
证书文件命名规则:MinIO 要求证书文件必须命名为 server-cert.pem 和 server-key.pem,否则不会被自动加载。若使用公网证书,需额外挂载 public.crt 和 private.key。

4.4 整体配置架构图

下图展示了 MinIO 持久化与配置的完整架构,包括数据卷、凭证、TLS 证书三者的关系与挂载路径:

MinIO 持久化与配置架构图 宿主机 Docker 引擎 MinIO 容器 minio/minio:latest 端口 9000 / 9001 环境变量: MINIO_ROOT_USER MINIO_ROOT_PASSWORD 数据卷 minio-data 挂载至 /data 存储对象数据 配置卷 minio-config 挂载至 /root/.minio 存储凭证与证书 TLS 证书 server-cert.pem server-key.pem 挂载至 /root/.minio/certs 说明:数据卷与配置卷分离,TLS 证书存放在配置卷的子目录 certs/ 中,凭证通过环境变量注入后持久化到配置卷。

4.5 配置清单与验证步骤

完成上述配置后,按以下清单逐项验证:

序号 验证项 验证方法 预期结果
1 数据持久化 上传文件后重启容器,再次列出 文件仍然存在
2 凭证生效 使用 mc 或 SDK 连接,传入配置的 AK/SK 连接成功,可执行操作
3 HTTPS 访问 curl -k https://localhost:9000/minio/health/live 返回 HTTP 200
4 证书有效期 openssl x509 -in server-cert.pem -text -noout | grep -A2 Validity 有效期大于当前时间
5 Console 访问 浏览器打开 https://localhost:9001 显示登录页面,使用 AK/SK 可登录
最佳实践:将 docker-compose.yml、config.env、certs/ 目录纳入 Git 版本管理(证书除外,建议使用 .gitignore 忽略)。团队成员只需 git clone 后执行 docker compose up -d 即可获得一致的 Development 环境。