第38节 RFC: Sealer 问题提案(中英文)
❤️💕💕记录sealos开源项目的学习过程。k8s,docker和云原生的学习。Myblog:http://nsddd.top
[TOC]
问题
目前，Sealer 缺乏清晰和一致的结构，这让开发人员难以进行工作和改进。此外，需要优化和自动化 GitHub actions 流程以提高效率。同样这个过程对于我来说这个过程有助于更加熟悉 sealer 的运行流程以及系统设计。
下面的先后循序符合设计的优先级🎯
RFC:
改进 Makefile 结构
我们提出以下按优先级排序的 Makefile 结构改进：
- 实现可选的版权信息检查（如果尚未通过 actions 实现）。
- 自动解析所有 makefile 选项的帮助信息。
- 确保一致的行为，例如强制执行提交规范。
- 添加必要的选项，例如单元测试覆盖率（我们很在意，但目前未提供）。
- 添加调试信息和选择性调试。此外，考虑提供通过
sealer或seautil选择性生成二进制的选项，以提高编译速度。 - 简化
/Makefile模块以提高可读性。
优化 GitHub Actions 流程
将进行以下更改以优化 GitHub Actions 流程：
- 提供和自动化 CHANGELOG 管理。
- 为目前未涵盖的微操作和功能添加自动化操作。
目录设计
script目录 : 我们建议将 /hack 目录迁移至 /script 目录，并将 Makefile 部分底层实现迁移至 script/make-rules 目录。
**CMD 命令：**sealer 的 命令越来越多，尤其是 alpha 扩展，提议或许可以将 cmd 的核心部分提取到 /internal 目录中（只允许内部访问）和 pkg目录下（允许调用） ，将 /common 目录迁移到 /pkg 目录下
**版本信息：**我建议为 Sealer 系统信息（git 信息、Go 信息等）和 pkg 运行时版本创建单独的版本。应用程序本身 info 的version ，一个是 pkg 的 runtime 的 version ，这两个 version 存放到哪个目录最规范，是都放在 /pkg/version下面还是 放在 /utils/version下面，还是分开放？ 提议：将应用程序 info 调整到 /pkg/version 可供外部调用，对 utils/version 放入到 runtime k8s 的模块中，并且抽象出接口供可供外部调用。
改进版本控制
我建议为 Sealer 系统信息（git 信息、Go 信息等）和 pkg 运行时版本创建单独的版本。我建议将 Sealer 的命令核心（特别是 alpha 扩展）移动到 /internal 目录（仅内部访问）和 /pkg 目录（允许调用）。此外，我们建议补充相关文档，例如版本 API 和 Makefile 指南。
版本接口设计方案
我们将创建一个运行时层以抽象版本层接口并设计接口。我们将提取 k3s、k0s 和 Kubernetes 的版本并从上面的版本调用它们，他们不需要关心调用的是哪个 cluster runtime 的 version
Other RFC
RFC：补充 k3s 的实现。
RFC：Sealer 目前缺乏控制 APP 调用的能力，Pack 可以帮助解决这个问题。我将 buildpacks 的研究并参考 buildpacks.io 的官方文档。
我们将为 Pack 提供抽象上层 Makefile 的构建能力，使构建镜像更加容易。如果 Sealer 可以打包和分发集群，它将具有非常强大的能力。
我们认为这些改变将为 Sealer 创建更有组织和高效的结构，并改进其功能。通过实现这些改变，我们可以使 Sealer 成为一个更加用户友好和高效的开发工具。
Tasks
| 类型 | 改进 | 问题 | PR | 状态 | 优先级 |
|---|---|---|---|---|---|
| Makefile | 可选的版权信息检查、自动解析所有 makefile 选项的帮助信息、保持一致的行为、添加必要的选项、添加调试信息和选择性调试、简化 /Makefile 模块以提高可读性 | ✅ | 1 | ||
| 目录设计 | 将 /hack 目录迁移至 /script 目录，并将 Makefile 部分底层实现迁移至 script/make-rules 目录、将 cmd 的核心部分提取到 /internal 目录中和 /pkg 目录下、将 /common 目录迁移到 /pkg 目录下、为 Sealer 系统信息和 pkg 运行时版本创建单独的版本、将应用程序 info 调整到 /pkg/version 可供外部调用、对 utils/version 放入到 runtime k8s 的模块中，并且抽象出接口供可供外部调用 | ❌ | 2 | ||
| GitHub Actions | 提供和自动化 CHANGELOG 管理、为目前未涵盖的微操作和功能添加自动化操作 | ❌ | 3 | ||
| 版本控制 | 为 Sealer 系统信息和 pkg 运行时版本创建单独的版本、将 Sealer 的命令核心（特别是 alpha 扩展）移动到 /internal 目录（仅内部访问）和 /pkg 目录（允许调用）、补充相关文档，例如版本 API 和 Makefile 指南 | ❌ | 4 | ||
| 接口设计方案 | 创建一个运行时层以抽象版本层接口并设计接口，提取 k3s、k0s 和 Kubernetes 的版本并从上面的版本调用它们 | ❌ | 5 | ||
| RFC | 补充 k3s 的实现 | ❌ | 6 | ||
| RFC | Sealer 目前缺乏控制 APP 调用的能力，Pack 可以帮助解决这个问题。我将 buildpacks 的研究并参考 http://buildpacks.io/ 的官方文档 | ❌ | 7 |
RFC: Sealer Proposal
Problem
Currently, Sealer lacks a clear and consistent structure, making it difficult for developers to work with and improve. In addition, the GitHub actions workflow needs to be optimized and automated for increased efficiency. This process will help me become more familiar with the Sealer runtime and system design.
The following order of priority is based on our design goals 🎯
RFC:
Improve Makefile Structure
- [ ] Improve Makefile structure
We propose the following Makefile structure improvements, sorted by priority:
- Implement optional copyright check (if not already implemented by actions).
- Automatically parse help information for all makefile options.
- Ensure consistent behavior, such as enforcing commit guidelines.
- Add necessary options, such as unit test coverage (which we care about but currently do not provide).
- Add debug information and selective debugging. Also, consider providing options to selectively generate binaries via
sealerorseautilto improve compile speed. - Simplify the
/Makefilemodule for readability.
Optimize GitHub Actions Workflow
- [ ] Optimize directory structure
The following changes will be made to optimize the GitHub Actions workflow:
- Provide and automate CHANGELOG management.
- Add automation for micro-operations and functionality not currently covered.
Directory Design
- [ ] Optimize actions workflow
Script Directory: We recommend migrating the /hack directory to the /script directory and moving the Makefile portion of the backend implementation to the script/make-rules directory.
CMD Commands: Sealer's commands are increasing in number, especially with alpha extensions. We propose extracting the core of the cmd to the /internal directory (only internally accessible) and /pkg directory (allowing for calls). We recommend moving the /common directory to the /pkg directory.
Version Information: We propose creating separate versions for Sealer system information (git information, Go information, etc.) and pkg runtime. Which directory should the two versions be stored in /pkg/version, /utils/version, or separately? We suggest adjusting the application info to /pkg/version for external access and placing utils/version into the runtime k8s module, abstracting an interface for external access.
Improve Version Control
We propose creating separate versions for Sealer system information (git information, Go information, etc.) and pkg runtime. We suggest moving the core of Sealer's commands (especially alpha extensions) to the /internal directory (internal access only) and /pkg directory (allowing for calls). Additionally, we propose supplementing relevant documentation, such as version API and Makefile guidelines.
Version Interface Design Scheme
We will create a runtime layer to abstract the version layer interface and design the interface. We will extract the versions of k3s, k0s, and Kubernetes and call them from the above versions. They do not need to care which cluster runtime version is being called.
Other RFC
RFC: Supplement k3s implementation.
RFC: Sealer currently lacks the ability to control APP calls, and Pack can help solve this problem. I will research buildpacks and refer to the official documentation of buildpacks.io.
We will provide Pack with the ability to build the upper-level Makefile abstractly, making it easier to build images. If Sealer can package and distribute clusters, it will have a very powerful ability.
We believe that these changes will create a more organized and efficient structure for Sealer and improve its functionality. By implementing these changes, we can make Sealer a more user-friendly and efficient development tool.
Tasks
| Type | Improvement | Issues | PR | Status | Priority |
|---|---|---|---|---|---|
| Makefile | Improve Makefile structure | ✅ | 🥇 | ||
| Directory Design | Optimize directory structure | ❌ | 🥈 | ||
| GitHub Actions | Optimize actions workflow | ❌ | 🥉 | ||
| Version Control | Separate versions for Sealer system and pkg runtime, move core commands to /internal and /pkg directories, supplement documentation | ❌ | 4 | ||
| Version Interface Design Scheme | Create runtime layer to abstract version interface, extract versions of k3s, k0s, and Kubernetes | ❌ | 5 | ||
| RFC | Supplement k3s implementation | ❌ | 6 | ||
| RFC | Add control for APP calls using Pack, research buildpacks | ❌ | 7 |
END 链接
✴️版权声明 © ：本书所有内容遵循CC-BY-SA 3.0协议（署名-相同方式共享）©