需求讨论
qinix opened this issue · comments
- 是否需要 replication？如果需要，优先级有多高？
- 是否需要 LDAP 等其他认证方式？如果需要，优先级有多高？
- 使用与 harbor 相同的基于 project 的认证模型还是与 hub.docker.com 相同的基于 user&organization 的认证模型？
- 是否需要提供对外 API
复制和LDAP暂时不要，权限模型与hub.docker.com保持一致即可，外部API暂不提供，但未来可能需要
我昨天整理了一下思路，发出来参考一下
原始意图
由于想法还待完善，这里先说明一下原始意图，目前打算是做一个一个docker镜像的管理系统，大致上应该类似hub.docker.com，主要是弥补目前中小型团队自建docker基础设施时缺乏镜像管理工具的短板。目前在github上已经有了一个开源项目 https://vmware.github.io/harbor ，但它基于golang写的，代码数已经超过了12000行，因此现在希望开发一个Rails版本的，希望能够将ruby代码规模控制在1000行以内。
核心功能描述：整合docker官方的registry，对registry提供基于UI的管理
主要功能：
- 普通用户：
- 镜像管理：显示项目列表、显示镜像详情页、在镜像详情页中设定tag、删除镜像（或镜像的指定版本）
- 管理员
- 用户管理：新增、删除、搜索用户，设置用户所提交的镜像权限
- 管理员选择本系统的用户注册模式，可以是用户申请后在邮件中确认，也可以由管理员审查批准
- 镜像复制：期望通过这个功能解决在多数据中心的场景下使用镜像的问题
- 用户管理：新增、删除、搜索用户，设置用户所提交的镜像权限
harbor参考
具体做法可以参考harbor的介绍，有些地方可以调整简化：
- Role based access control: harbor支持一个用户有多个project，这个做法和hub.docker.com不同，本系统应该和后者保持一致
- Image replication: harbor支持镜像在来源节点间进行复制，这个功能是否需要实现可以讨论
- Graphical user portal: 需要
- AD/LDAP support: 不必支持，但是如果有可能，是否可以提供接口便于第三方实现
- Auditing: 审计功能在harbor中是提供了专门的操作表，本系统可以参考但不限制实现方式
- Internationalization: 需要
- RESTful API: 初期先搁置，未来可以根据简化以后的模型提供服务，不必受harbor影响
这样看来之前还是有一些理解偏差。之前理解的是直接把 harbor 抄到 rails 上。现在看来应该描述为一个 hub.docker.com clone 比较恰当。
这样的话我打算从头再开始写。之前写的代码过于复制 harbor 了，有一些 harbor 不好的设计。
技术栈上，我打算全部使用 rails 默认的技术栈。JS 方面使用默认的 SJR, Turbolinks。
在开发计划上，首先是实现将 registry 与本项目连接起来，将环境跑起来。然后做 UI 界面，UI 界面简单完成后，在保证项目一直可以跑起来的情况下继续开发新功能。
是的，我可以先确认核心功能，这样可以避免做多余的工作。
harbor的做法未必真的多余，我现在还在研究试用它的镜像复制功能，但是原则上应该尽量少做，因为给软件做减法比做加法要难得多，不必给未来添加困难