第38节 RFC: Sealer 问题提案(中英文)


❤️💕💕记录sealosopen in new window开源项目的学习过程。k8s,docker和云原生的学习open in new window。Myblog:http://nsddd.topopen in new window


[TOC]

问题

目前,Sealer 缺乏清晰和一致的结构,这让开发人员难以进行工作和改进。此外,需要优化和自动化 GitHub actions 流程以提高效率。同样这个过程对于我来说这个过程有助于更加熟悉 sealer 的运行流程以及系统设计。

下面的先后循序符合设计的优先级🎯

RFC:

改进 Makefile 结构

我们提出以下按优先级排序的 Makefile 结构改进:

  1. 实现可选的版权信息检查(如果尚未通过 actions 实现)。
  2. 自动解析所有 makefile 选项的帮助信息。
  3. 确保一致的行为,例如强制执行提交规范。
  4. 添加必要的选项,例如单元测试覆盖率(我们很在意,但目前未提供)。
  5. 添加调试信息和选择性调试。此外,考虑提供通过 sealerseautil 选择性生成二进制的选项,以提高编译速度。
  6. 简化 /Makefile 模块以提高可读性。

优化 GitHub Actions 流程

将进行以下更改以优化 GitHub Actions 流程:

  1. 提供和自动化 CHANGELOG 管理。
  2. 为目前未涵盖的微操作和功能添加自动化操作。

目录设计

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.ioopen in new window 的官方文档。

我们将为 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
RFCSealer 目前缺乏控制 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:

  1. Implement optional copyright check (if not already implemented by actions).
  2. Automatically parse help information for all makefile options.
  3. Ensure consistent behavior, such as enforcing commit guidelines.
  4. Add necessary options, such as unit test coverage (which we care about but currently do not provide).
  5. Add debug information and selective debugging. Also, consider providing options to selectively generate binaries via sealer or seautil to improve compile speed.
  6. Simplify the /Makefile module for readability.

Optimize GitHub Actions Workflow

  • [ ] Optimize directory structure

The following changes will be made to optimize the GitHub Actions workflow:

  1. Provide and automate CHANGELOG management.
  2. 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.ioopen in new window.

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

TypeImprovementIssuesPRStatusPriority
MakefileImprove Makefile structure🥇
Directory DesignOptimize directory structure🥈
GitHub ActionsOptimize actions workflow🥉
Version ControlSeparate versions for Sealer system and pkg runtime, move core commands to /internal and /pkg directories, supplement documentation4
Version Interface Design SchemeCreate runtime layer to abstract version interface, extract versions of k3s, k0s, and Kubernetes5
RFCSupplement k3s implementation6
RFCAdd control for APP calls using Pack, research buildpacks7

END 链接