# ebpf-Hub

**Repository Path**: yunwei37/ebpf-hub

## Basic Information

- **Project Name**: ebpf-Hub
- **Description**: eBPF 软件应用市场：eBPF 包管理器
- **Primary Language**: Unknown
- **License**: MIT
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 1
- **Created**: 2023-09-30
- **Last Updated**: 2023-09-30

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# eBPF 软件应用市场

## ebpfs: 前端页面

## 命令行工具

## 开发模板


## 背景

eBPF（扩展伯克利数据包过滤器）是 Linux 内核的一项技术，它允许在内核空间运行一些预定义的、有限的程序，不需要修改内核代码或加载任何内核模块。由于其高效和灵活的特性，eBPF 被广泛应用于网络流量过滤、性能监控、安全和其他领域。然而，目前社区中的 eBPF 程序分发不够统一和规范，不同的组件和工具集都有自己的管理和打包方式，例如 cilium、bcc 和 openEuler 内核的 eBPF 插件。eBPF 程序也可能使用多种用户态语言开发（如 Go，Rust，C/C++，Python 脚本等），具有各种不同的接口，甚至并没有预先编译好的二进制程序，用户必须自行配置环境和编译才能使用。

这种分散和缺乏标准化的情况带来了一些问题：首先，eBPF 程序的升级和功能添加通常依赖于整体软件的发布，这可能导致升级周期过长，单个 eBPF 组件的发布需要等待整体软件的发布周期；其次，开发 eBPF 程序需要对内核 eBPF 程序框架有深入的理解，这增加了开发难度。因此，这个项目的目标是希望能借鉴 docker hub 的管理模式，提供一种统一的 eBPF 程序管理方式、openEuler 内核 eBPF 开发模板，以及一个编译和分发工具，以解决上述问题。

综上，整个 eBPF 生态缺少对新手友好的开发方案，和一个类似于 Github 或 Docker hub 的通用分发和托管平台。

### 项目产出要求

项目产出要求主要分为两个部分：

1. **构建 openEuler 应用市场的基础设施**，提供类似于 docker hub 的 eBPF 程序管理模式：这意味着我们需要创建一个可以公开存储、管理和分发 eBPF 程序的平台，就像 docker hub 对 docker 镜像所做的那样。这个平台应该允许开发者上传他们的 eBPF 程序，用户可以下载、安装和升级这些程序。此外，这个平台应该支持版本管理，以便用户可以选择安装特定版本的 eBPF 程序。
2. **提供 openEuler eBPF 软件编写模板**，简化编译和打包及分发流程：这意味着我们需要创建一个模板，来帮助开发者更容易地编写、编译、打包和分发他们的 eBPF 程序。这个模板应该包含基本的代码结构、编译和打包脚本，以及使用说明。这样，开发者只需要按照模板来编写他们的代码，然后使用脚本来编译、打包和分发他们的程序。对于初学者而言，提供一个模板也可以帮助更快速的上手进行开发工作。

### 需求分析

1. **理解用户需求**：项目的主要用户为两类：开发者和用户。开发者需要一个方便的平台来上传、管理和分发他们的 eBPF 程序，而用户需要一个便利的方式来搜索、下载、安装和更新 eBPF 程序。
2. **功能需求定义**：
    - **eBPF 程序存储和管理平台（网页前端）**：平台需要支持开发者上传 eBPF 程序，并提供版本控制功能。用户应能下载、安装和更新程序。此外，平台应具备良好的用户界面和易用性，同时提供搜索功能，以帮助用户找到所需的 eBPF 程序。
    - **eBPF 软件编写模板**：提供一个模板以帮助开发者更方便地编写、编译、打包和分发他们的 eBPF 程序。模板应包含基本的代码结构、编译和打包脚本，以及使用说明。同时，模板需要满足以下特性：可移植性、隔离性、跨语言支持和轻量级。
    - **包管理器**：用户可以用一行命令就能下载、启动程序，无需配置环境或重新编译，或者一行命令创建新项目、打包发布项目。管理器需要提供清晰的文档，方便用户使用。
3. **非功能需求定义**：
    - **性能**：平台需要能够快速处理上传和下载请求，即使在高并发请求的情况下，性能也不应下降。
    - **安全性**：所有上传和下载的 eBPF 程序都应保证安全性。
    - **稳定性**：平台需要具备高可用性，确保用户在任何时候都能访问。
    - **兼容性**：编写模板需要兼容多种用户态语言（如 C、Go、Rust、Java、TypeScript等），以适应不同开发者的需求。

## 打包发布格式与存储格式

打包发布格式与存储格式是项目的关键部分，因为它们决定了如何将 eBPF 程序打包、分发和存储。

### OCI 镜像

OCI（Open Container Initiative）是一个开放的行业标准，旨在定义容器格式和运行时的规范，以确保所有容器运行时（如 Docker、containerd、CRI-O 等）之间的互操作性。OCI 规范主要包括两部分：

1. **运行时规范（runtime-spec）**：定义了容器运行时的行为，包括如何执行容器以及容器应该满足哪些条件等。
2. **镜像规范（image-spec）**：定义了容器镜像的格式，包括镜像的层次结构、配置、文件系统等。

OCI registry 则是用于存储和分发 OCI 镜像的服务。Docker Hub 和 Google Container Registry 都是 OCI registry 的例子。它们提供了一个公开的平台，用户可以在上面上传、存储和分发他们的容器镜像。

OCI 镜像格式主要由两部分组成：**manifest** 和 **layers**。Manifest 是一个 JSON 文件，描述了镜像的元数据，包括镜像的配置以及构成镜像的各个层。Layers 则是镜像的实际内容，每一层都是一个文件系统的增量变化。当运行一个 OCI 镜像时，这些层会被叠加在一起，形成一个统一的文件系统。

首先，我们来看一下 OCI 镜像的 **manifest**。Manifest 是一个 JSON 文件，它包含了镜像的元数据，例如镜像的配置和构成镜像的各个层。一个典型的 manifest 文件可能看起来像这样：

```json
{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "size": 7023,
    "digest": "sha256:b5b2b2c507a0944348e0303114d8d93aaaa081732b86451d9bce1f432a537bc7"
  },
  "layers": [
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "size": 32654,
      "digest": "sha256:9834876dcfb05cb167a5c24953eba58c4ac89b1adf57f28f2f9d09af107ee8f0"
    },
    ...
  ]
}
```

在这个例子中，`config` 字段指向了一个包含镜像配置的 JSON 文件的摘要（digest），而 `layers` 字段则是一个数组，包含了构成镜像的各个层的信息。每一层都有一个媒体类型（mediaType）、大小（size）和摘要（digest）。

然后，我们来看一下 OCI 镜像的 **layers**。每一层都是一个文件系统的增量变化，它包含了从上一层到当前层的所有文件和目录的添加、修改和删除。当运行一个 OCI 镜像时，这些层会被叠加在一起，形成一个统一的文件系统。

例如，假设我们有一个 OCI 镜像，它有两层。第一层添加了一个文件 `/etc/passwd`，第二层修改了这个文件。当我们运行这个镜像时，我们会看到第二层的修改，因为它覆盖了第一层的文件。

这就是 OCI 镜像格式的基本概念。通过使用 manifest 和 layers，我们可以创建非常复杂和灵活的镜像，满足各种不同的需求。