我的理解是MinIO就是OSS服务。
MinIO 是在 GNU Affero 通用公共许可证 v3.0 下发布的高性能对象存储。它与 Amazon S3 云存储服务 API 兼容。使用 MinIO 为机器学习、分析和应用程序数据工作负载构建高性能基础架构。
目前MinIO有2套官方文档,可以结合查看
第一套是访问到MinIO后点击左侧菜单Documentation跳转
第二套是即将发布的 MinIO 文档版本
纠删码
是把双刃剑,设置合理理论上可保证在损坏50%硬盘的情况下仍然能正常工作,但同时需要至少双倍的存储空间,
扩容
官方是不建议垂直扩容的。
MinIO扩容的节点数量至少需要是当前节点的2倍,例如,初始为4个节点,第1次扩容至少总结点数量要8个,第2次扩容至少总节点数量要16个...
MinIO 通常建议规划容量,以便 仅在部署正常运行 2 年以上后才需要扩展服务器池。
例如,考虑一个估计每年产生 10TB 数据的应用程序套件。MinIO 部署至少应提供:
10TB + 10TB + 10TB = 30TB
MinIO 建议添加缓冲存储以应对存储数据的潜在增长(例如 40TB 的总可用存储)。作为经验法则,为了满足容量需求,最初需要更多容量而不是频繁的即时扩展。
Service Accounts
一个与创建者拥有相同(默认)权限的临时用户
MinIO 服务帐户是经过身份验证的 MinIO 用户的子身份,包括外部管理的身份。每个服务帐户都根据附加到其父用户或父用户具有成员资格的组的策略继承其权限。服务帐户还支持可选的内联策略,该策略进一步限制对父用户可用的操作和资源子集的访问。
一个 MinIO 用户可以生成任意数量的服务帐户。这允许应用程序所有者为其应用程序生成任意服务帐户,而无需 MinIO 管理员采取行动。由于生成的服务帐户与父级具有相同或更少的权限,因此管理员可以专注于管理顶级父级用户,而无需对生成的服务帐户进行微观管理。
Groups
用户创建时可以指定所属组,方便管理。可理解为传统ERP中的部门
策略policy
创建用户时要指定其策略(角色),或为Group指定策略。页面操作示例
策略是一段JSON格式的文本,包含访问策略、资源、条件等。官方文档
MinIO的策略格式与阿里云OSS的策略语法类似,通过制作模板在使用时替换可以做到通用
SSO登录(openID简易Demo)
- 搭建keycloak,进行简单配置
- 配置MinIO后重启
- 使用其他浏览器访问MinIO(原浏览器会有缓存,看不到效果)
- 点击按钮跳转到keycloak页面,输入keycloak的账号,就能正常登录了
集成了MinIO、阿里云OSS 的对象管理器
业务系统通过访问对象管理器操作对象而不必关心底层用的什么,程序启动是通过加载配置文件决定使用哪种
- 整体架构
- 基本操作
- 调用方式
- policy接口
- 获取临时凭证
STSCredentials stsCredentials = STSService.getSTSCredentials(FileClientConstants.ALL_OSS_TOKEN,
ReplacementPolicyService.publicBucketAllPolicy());