注意

本文档适用于 Ceph 开发版本。

持续集成架构

在 Ceph 中，我们在开发中依赖于多个 CI 管道。这些管道大多数都围绕 Jenkins 中心。它们的配置是使用Jenkins Job Builder.

让我们以 Jenkins 执行的make check为例。

ceph-pull-requests

ceph-pull-requests是一个由 GitHub 拉取请求或触发短语（如：

jenkins test make check

在这个 Jenkins 任务中涉及多个参与者：

digraph {

其中

Sepia Lab

Sepia Lab是 Ceph 项目使用的测试实验室。该实验室提供了我们 CI 基础设施所需的存储和计算资源。

Jenkins 代理

是一组执行 CI 任务的机器。在这种情况下，它们

  1. 从 GitHub 拉取 git 仓库并

  2. 将拉取请求与最新主分支

  3. 设置必要的环境变量

  4. 之前，运行run-make-check.sh

Chacra

是一个提供 RESTful API 的服务器，允许客户端存储和检索二进制包。它还会自动创建上传的包的仓库。一旦在 chacra 上创建了一个特定的仓库，配置的 shaman 服务器也会更新，然后我们可以查询 shaman 获取相应的仓库地址。Chacra 不仅托管 Ceph 包，还托管相当多的其他包，如各种构建依赖。

Shaman

是一个提供 RESTful API 的服务器，允许客户端查询 chacra 节点上托管的仓库信息。Shaman 也以其Web UI而闻名。但请注意，shaman 并不构建包，它只是提供构建信息。

如下所示，chacra管理多个项目，其元数据存储在数据库中。这些元数据通过 Shaman 作为 Web 服务暴露。chacractl是一个用于与chacra服务。

digraph {

构建依赖

与许多其他软件项目一样，Ceph 既有构建时依赖也有运行时依赖。大多数情况下，我们倾向于使用发行版预构建的包。但在某些情况下

  • 必要的依赖在发行版中缺失，或者

  • 它们的版本太旧，或者

  • 它们没有启用某些重要功能。

  • 我们希望确保某个运行时依赖的版本与我们实验室中测试的版本完全相同。

无论原因是什么，我们都需要从源代码构建它们，或者将它们作为二进制包而不是使用发行版提供的包。许多构建时依赖作为 git 子模块包含在内，但为了避免重复构建这些依赖，我们预先构建了一些并将其上传到我们自己的仓库。因此，在执行make check时，我们的 CI 中的构建主机从托管这些包的内部仓库中拉取它们，而不是构建它们。

目前，以下包已为 ubuntu focal 预构建并上传到chacra:

libboost

包boost。包的名称已从libboost-*toceph-libboost-*更改为/opt/ceph，它们被安装到libboost包冲突。其构建脚本托管在https://github.com/ceph/ceph-boost。https://github.com/ceph/ceph-boost/commit/2a8ae02932b2a1fd6a68072da8ca0df2b99b805c为如何增加版本号的示例。在普通的 Ubuntu Focal OS 上构建 1.79 的命令如下。

sudo apt install debhelper dctrl-tools chrpath libbz2-dev libicu-dev bison \
  flex docbook-to-man help2man xsltproc doxygen dh-python python3-all-dev graphviz
wget http://download.ceph.com/qa/boost_1_79_0.tar.bz2
git clone https://github.com/ceph/ceph-boost
tar xjf boost_1_79_0.tar.bz2
cp -ra ceph-boost/debian boost_1_79_0/
pushd boost_1_79_0
export DEB_BUILD_OPTIONS='parallel=6 nodoc'
dpkg-buildpackage -us -uc -b
popd
BOOST_SHA=$(git ls-remote https://github.com/ceph/ceph-boost main | awk '{ print $1 }')
ls *.deb | chacractl binary create \
  libboost/master/$BOOST_SHA/ubuntu/focal/amd64/flavors/default
libzbd

包libzbd。上游的 libzbd 已经包含 debian 打包。

libpmem

包pmdk。请注意，ndctl是 pmdk 的一项构建依赖，请参阅更新的 debian 打包https://github.com/ceph/ceph-ndctl .

Note

在更新/升级打包时，请确保包版本和打包的发布号正确更新，否则很难确定安装了哪个版本的包。我们在尝试升级它之前检查包版本install-deps.sh.

但除了这些库之外，ceph-mgr-dashboard的前端使用了许多 JavaScript 包。其中许多包没有被发行版打包。更不用说测试这些包的不同版本组合的麻烦了。因此，我们决定使用make-dist.

将这些 JavaScript 包包含在我们的 dist tarball 中。此外，因为我们的下游在重新分发预编译的 Ceph 包时可能不想使用预打包的二进制文件，我们也需要将这些库包含在我们的 dist tarball 中。它们是

  • boost

  • liburing

  • pmdk

make-dist是我们 CI 管道用于创建 dist tarball 的脚本，以便该 tarball 可以在干净的环境中构建 Ceph 包。当我们需要升级这些第三方库时，我们应该

  • 更新 CMake 脚本

  • 重新构建预构建的包并

  • 更新此脚本以反映更改。

上传依赖

为了确保 Jenkins 代理可以获取预构建的包，我们需要将它们上传到apt-mirror.front.sepia.ceph.com或chacra。将包上传到前者需要实验室管理员的帮助，因此如果我们希望定期维护包仓库，更好的选择是使用chacractl. chacra使用资源层次结构表示包仓库，如下所示：

<project>/<branch>/<ref>/<distro>/<distro-version>/<arch>

其中：

project

通常用于表示一组相关包。例如，libboost.

分支

project 的分支。这与 Git 仓库的概念相对应。

ref

给定版本的一组包的唯一 ID。此 ID 用于引用<project>/<branch>下的该组包。将打包配方版本化是一个好习惯，例如用于构建 DEB 包的debian目录和用于构建 RPM 包的spec，并使用打包配方的 SHA1 作为ref。但你也可以使用随机字符串作为ref，例如构建源树标签。

distro

包构建的发行版名称。目前支持的发行版如下：

  • centos

  • debian

  • fedora

  • rhel

  • ubuntu

distro-version

发行版的版本。例如，如果包在 ubuntu focal 上构建，则distro-version应该是20.04.

arch

包的架构。它可以是：

  • arm64

  • amd64

  • noarch

所以，例如，我们可以将预构建的 boost 包上传到 chacra，如下所示

ls *.deb | chacractl binary create \
  libboost/master/099c0fd56b4a54457e288a2eff8fffdc0d416f7a/ubuntu/focal/amd64/flavors/default

更新install-deps.sh

我们还需要更新install-deps.sh以指向新的构建脚本。请参阅脚本，了解更多详细信息。

由 Ceph 基金会带给您

Ceph 文档是一个社区资源，由非盈利的 Ceph 基金会资助和托管Ceph Foundation. 如果您想支持这一点和我们的其他工作，请考虑加入现在加入.