注意

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

使用 cephadm 开发

使用 cephadm 开发有多种方法。您使用哪种方法取决于您想要实现的目标。

vstart --cephadm

  • 使用 vstart 启动集群，并配置 cephadm

  • 使用 cephadm 管理任何额外的守护进程

  • 需要编译好的 ceph 二进制文件

在这种情况下，mon 和 manager 至少以通常的 vstart 方式运行，而不是由 cephadm 管理。但是 cephadm 已启用，并且本地主机已添加，因此您可以部署额外的守护进程或添加额外的主机。

这对于开发 cephadm 本身非常有效，因为任何 mgr/cephadm 或 cephadm/cephadm 代码更改都可以通过启动 ceph-mgr 来应用ceph mgr fail x. （当 mgr（重新）启动时，它会将 cephadm/cephadm 脚本加载到内存中。）

MON=1 MGR=1 OSD=0 MDS=0 ../src/vstart.sh -d -n -x --cephadm

  • ~/.ssh/id_dsa[.pub]将用作集群密钥。假设此密钥有权无密码通过 ssh 连接到 root@`hostname`。

  • cephadm 不会尝试管理 vstart.sh 启动的任何守护进程（环境变量中的任何非零数字）。为 mon 或 mgr 没有定义服务规范。

  • 您会看到 cephadm 关于流浪守护进程的健康警告——这是因为 vstart 启动的守护进程不受 cephadm 控制。

  • 默认镜像为quay.io/ceph-ci/ceph:main，但您可以通过传递-o container_image=...或ceph config set global container_image ....

cstart 和 cpatch

The cstart.sh脚本将使用 cephadm 启动集群，并将 conf 和 keyring 放在您的构建目录中，以便 CLI 可以工作（就像使用 vstart 一样）。Thebin/ceph ... CLI works (just like with vstart). The ckill.sh脚本将拆除它。

  • 存储了一个唯一的但稳定的 fsid 在fsid（在构建目录中）。

  • mon 端口是随机的，就像使用 vstart 一样。

  • 容器镜像为quay.io/ceph-ci/ceph:$tag其中 $tag 是 fsid 的前 8 个字符。

  • 当您第一次运行 cstart 时，如果容器镜像不存在，它将使用 cpatch 构建。

这里有几个优点：

  • 集群是一个“正常”的 cephadm 集群，看起来和行为就像用户的集群一样。相比之下，vstart 和 teuthology 集群在微妙（以及不太微妙）的方式上往往很特别（例如，having thelockdep打开）。

要启动测试集群：

sudo ../src/cstart.sh

输出的最后一行将是一行您可以剪切并粘贴以更新容器镜像的行。例如：

sudo ../src/script/cpatch -t quay.io/ceph-ci/ceph:8f509f4e

默认情况下，cpatch 将将其可以想到的本地构建目录中的所有内容修补到容器镜像中。但是，如果您正在处理系统的特定部分，那么您能否通过更小的更改来避免，以便 cpatch 运行得更快。例如：

sudo ../src/script/cpatch -t quay.io/ceph-ci/ceph:8f509f4e --py

将更新 mgr 模块（不包括仪表板）。或者：

sudo ../src/script/cpatch -t quay.io/ceph-ci/ceph:8f509f4e --core

将更新大多数二进制文件和库。将-h传递给 cpatch 以获取所有选项。

容器更新后，您可以通过弹跳它们来刷新/重新启动守护进程：

sudo systemctl restart ceph-`cat fsid`.target

完成后，您可以通过以下方式拆除集群：

sudo ../src/ckill.sh   # or,
sudo ../src/cephadm/cephadm rm-cluster --force --fsid `cat fsid`

cephadm bootstrap --shared_ceph_folder

cephadm 也可以直接使用，而无需编译好的 ceph 二进制文件。

按如下方式运行 cephadm：

sudo ./cephadm bootstrap --mon-ip 127.0.0.1 \
  --ssh-private-key /home/<user>/.ssh/id_rsa \
  --skip-mon-network \
  --skip-monitoring-stack --single-host-defaults \
  --skip-dashboard \
  --shared_ceph_folder /home/<user>/path/to/ceph/

  • ~/.ssh/id_rsa将用作集群密钥。假设此密钥有权无密码通过 ssh 连接到 root@`hostname`。

在pybind/mgr/目录中进行的源代码更改需要守护进程重新启动才能生效。

Kcli：一个虚拟化管理工具，用于简化编排器开发

Kcli旨在与现有的虚拟化提供商（libvirt、KubeVirt、oVirt、OpenStack、VMware vSphere、GCP 和 AWS）交互，并轻松地从云镜像部署和自定义 VM。

它允许您设置一个具有您首选配置（内存、cpu、磁盘）和操作系统风味的环境（多个 VM）。

主要优点：

  • 快速。通常，您可以在不到 5 分钟内准备好一个完全新的 Ceph 集群，用于调试和开发编排器功能。

  • “接近生产”实验室。生成的实验室接近 QE 实验室中的“真实”集群，甚至接近生产。它使在几乎“真实”的环境中测试“真实”事物变得容易。

  • 安全且隔离。不依赖于您机器上安装的内容。并且 VM 与您的环境隔离。

  • 易于工作的“开发”环境。对于“未编译”的软件组件，例如任何 mgr 模块。这是一个允许您交互式测试更改的环境。

安装：

完整文档在kcli 安装但我们建议使用容器镜像方法。

因此要做的：

  • 1. 查看要求并安装/配置满足这些要求的任何内容。

  • 2. 获取 kcli 镜像并创建一个用于执行 kcli 命令的别名

    # podman pull quay.io/karmab/kcli
# alias kcli='podman run --net host -it --rm --security-opt label=disable -v $HOME/.ssh:/root/.ssh -v $HOME/.kcli:/root/.kcli -v /var/lib/libvirt/images:/var/lib/libvirt/images -v /var/run/libvirt:/var/run/libvirt -v $PWD:/workdir -v /var/tmp:/ignitiondir quay.io/karmab/kcli'

Note

这假设 /var/lib/libvirt/images 是您的默认 libvirt 池…… 如果使用不同的路径，请调整

Note

一旦您使用 kcli 工具创建和使用不同的实验室，我们建议您坚持一个给定的容器标签并更新您的 kcli 别名。为什么？kcli 使用滚动发布模型，坚持特定的容器标签将提高整体稳定性。

测试您的 kcli 安装：

查看 kcli基本用法工作流

创建 Ceph 实验室集群

为了简化此任务，我们将使用一个“计划”。

“计划”是一个文件，您可以在其中定义具有不同设置的 VM 集合。您可以定义硬件参数（cpu、内存、磁盘 ..）、操作系统，并且它还允许您自动化安装和配置您想要拥有的任何软件。

输出的末尾有一个存储库with a collection of

# kcli create plan -u https://github.com/karmab/kcli-plans/blob/master/ceph/ceph_cluster.yml

这将使用指向的 URL 的计划文件创建一组三个 VM。几分钟后，让我们检查集群：

  • 查看创建的 VM：

    # kcli list vms

  • 进入引导节点：

    # kcli ssh ceph-node-00

  • 查看安装的 ceph 集群：

    [centos@ceph-node-00 ~]$ sudo -i
[root@ceph-node-00 ~]# cephadm version
[root@ceph-node-00 ~]# cephadm shell
[ceph: root@ceph-node-00 /]# ceph orch host ls

创建 Ceph 集群，以便轻松开发 mgr 模块（编排器和仪表板）

cephadm kcli 计划（以及 cephadm）已准备好做这件事。

这种方法背后的想法是用主机机的源代码文件夹替换每个 ceph 守护进程中的几个 python mgr 文件夹。这个“技巧”将允许您更改任何编排器或仪表板模块，并中间测试它们。（仅需要禁用/启用 mgr 模块）

因此，为了创建用于开发目的的 ceph 集群，您必须使用相同的 cephadm 计划，但使用一个指向您的 Ceph 源代码文件夹的新参数：

# kcli create plan -u https://github.com/karmab/kcli-plans/blob/master/ceph/ceph_cluster.yml -P ceph_dev_folder=/home/mycodefolder/ceph

Ceph 仪表板开发

如果您之前没有生成前端包，则 Ceph 仪表板模块将不会加载。

目前，为了正确加载 Ceph 仪表板模块并应用前端更改，您必须在您的笔记本电脑上运行“ng build”：

# Start local frontend build with watcher (in background):
sudo dnf install -y nodejs
cd <path-to-your-ceph-repo>
cd src/pybind/mgr/dashboard/frontend
sudo chown -R <your-user>:root dist node_modules
NG_CLI_ANALYTICS=false npm ci
npm run build -- --deleteOutputPath=false --watch &

保存更改后，前端包将再次构建。完成后，您将看到：

"Localized bundle generation complete."

然后，您可以重新加载您的仪表板浏览器选项卡。

Cephadm 盒子容器（Podman 内部 Podman）开发环境

由于 kcli 启动时间长，我们创建了一个替代方案，使用 Podman 内部 Podman，速度更快。这种方法也有其缺点，因为我们必须模拟 osd 的创建和设备的添加，使用 loopback 设备。

Cephadm 的盒子环境设置简单。设置要求您获取 Ceph 所需的 Podman 镜像，以及我们所说的盒子。

警告

这种开发环境仍然是实验性的，可能会有意外的行为。请查看路线图和已知问题部分，以了解开发进展。

要求

设置

要设置 Cephadm 的盒子，请运行：

cd src/cephadm/box
./box.py -v cluster setup

Note

建议使用带详细输出（-v）运行 box，因为它将显示正在运行的 shell 命令的输出。

获取所有所需镜像后，我们可以创建一个没有 OSD 和主机的简单集群：

./box.py -v cluster start
如果您想使用更多 OSD 和主机部署集群：

# 默认为 3 个 osd 和 3 个主机

警告

在使用 Podman 的盒子实现中，OSD 仍然不受支持。这是进行中的工作。

如果没有扩展选项，明确添加更多主机或 OSD 不会改变集群的状态。

Note

集群启动将尝试设置，即使集群设置未调用。

Note

OSD 使用 loopback 设备创建，因此需要 sudo 创建能够容纳 OSD 的 loopback 设备。

Note

每个 osd 将需要 5GiB 的空间。

引导集群后，您可以进入种子盒子，您将能够在其中运行 Cephadm 命令：

./box.py -v cluster bash
[root@8d52a7860245] cephadm --help
[root@8d52a7860245] cephadm shell
...

如果您想导航到仪表板，请输入https://localhost:8443在您的浏览器上。

您还可以找到每个盒子容器的主机名和 IP 地址：

./box.py cluster list

并您将看到类似：

IP               Name            Hostname
172.30.0.2       box_hosts_1     6283b7b51d91
172.30.0.3       box_hosts_3     3dcf7f1b25a4
172.30.0.4       box_seed_1      8d52a7860245
172.30.0.5       box_hosts_2     c3c7b3273bf1

要移除集群并进行清理，请运行：

./box.py cluster down

如果您只想清理最后创建的集群，请运行：

./box.py cluster cleanup

要检查所有可用命令，请运行：

./box.py --help

如果您想使用 Docker 运行 box，可以。您必须指定您想要使用的引擎，例如：

./box.py -v --engine docker cluster list

使用 Docker 命令如 bootstrap 和 osd 创建应该使用 sudo，因为它需要权限在 VGs 和 LVs 上创建 osds：

sudo ./box.py -v --engine docker cluster start --expanded

警告

使用 Docker 作为盒子引擎是危险的，因为有一些实例中 Xorg 会话被终止。

已知问题

  • 如果由于 Cephadm 无法推断密钥环和配置而出现权限问题，请按以下示例运行 cephadm：

    cephadm shell --config /etc/ceph/ceph.conf --keyring /etc/ceph/ceph.kerying

  • Docker 容器使用 --privileged 标志运行，这已被发现会导致某些计算机注销。

  • 如果 SELinux 未禁用，您可能会看到意外的行为。例如：

  • 如果运行命令失败运行 podman 命令，因为它找不到容器，您可以通过运行显示标志 -v 的相同的 podman-compose .. up 命令进行调试。

路线图

  • 使用ceph-volume raw.

  • 启用 ceph-volume 以在清单中将 loopback 设备标记为有效的块设备。

  • 使盒子准备好运行仪表板 CI 测试（包括集群扩展）。

关于从 CLI 处理器发起的网络调用的注意事项

执行任何 cephadm CLI 命令，如ceph orch ls将会阻塞 MGR 内部的 mon 命令处理线程，从而防止任何并发 CLI 调用。请注意，按^C不会解决这个问题，因为only客户端将被中止，但编排器管理器模块本身的命令执行不会。这意味着，cephadm 将完全无响应，直到 CLI 处理器执行完全完成。请注意，即使ceph orch ps也不会在另一个处理程序执行时响应。

这意味着我们应该对远程主机进行非常少的同步调用。作为指导，cephadm 应该在 CLI 处理器中进行最多O(1)网络调用。其他所有内容都应该在其他线程中异步完成，如serve().

关于代码中使用的不同变量的注意事项

  • a service_type是定义在ServiceSpec

  • a service_id中的 mon、mgr、alertmanager 等类似。

  • a service_name是<service_type>.<service_id>

  • a daemon_type is the same as the service_type, except for ingress, which has the haproxy and keepalived daemon types.

  • a daemon_id is typically <service_id>.<hostname>.<random-string>。 （例如 OSD。OSD 始终称为 OSD.N）。

  • a daemon_name是<daemon_type>.<daemon_id>

编译 cephadm

较新版本的 cephadm 基于Python Zip 应用程序支持，并且是从 ceph 树中的 Python 源代码文件“编译”的。要创建您自己的 cephadm“二进制”副本，请使用位于src/cephadm/build.py中的脚本。命令应采用./src/cephadm/build.py [output].

形式。--set-version-var或-S选项。值应采用KEY=VALUE形式，有效键包括：CEPH_GIT_VER * CEPH_GIT_NICE_VER * CEPH_RELEASE * CEPH_RELEASE_NAME * CEPH_RELEASE_TYPE

Example: ./src/cephadm/build.py -SCEPH_GIT_VER=$(git rev-parse HEAD) -SCEPH_GIT_NICE_VER=$(git describe) /tmp/cephadm

通常，这些值将由其他更高级别的构建工具（如 cmake）传递给 build.py。

编译的二进制文件可能包含一组经过策划的依赖项。用于获取捆绑依赖项的工具可以是 Python 的pip，本地安装的 RPM，或者可以禁用捆绑依赖项。要选择捆绑依赖项的模式，请使用--bundled-dependencies或-B选项，值为pip, rpm，或none.

编译的 cephadm zipapp 文件保留了有关它是如何构建的元数据。这可以通过运行cephadm version --verbose。命令将发出一个 JSON 格式的对象，显示版本元数据（如果可用）、由构建脚本生成的捆绑依赖项列表（如果启用了捆绑依赖项）以及 zipapp 顶级内容的摘要。示例：

$ ./cephadm version --verbose
{
  "name": "cephadm",
  "ceph_git_nice_ver": "18.0.0-6867-g6a1df2d0b01",
  "ceph_git_ver": "6a1df2d0b01da581bfef3357940e1e88d5ce70ce",
  "ceph_release_name": "reef",
  "ceph_release_type": "dev",
  "bundled_packages": [
    {
      "name": "Jinja2",
      "version": "3.1.2",
      "package_source": "pip",
      "requirements_entry": "Jinja2 == 3.1.2"
    },
    {
      "name": "MarkupSafe",
      "version": "2.1.3",
      "package_source": "pip",
      "requirements_entry": "MarkupSafe == 2.1.3"
    }
  ],
  "zip_root_entries": [
    "Jinja2-3.1.2-py3.9.egg-info",
    "MarkupSafe-2.1.3-py3.9.egg-info",
    "__main__.py",
    "__main__.pyc",
    "_cephadmmeta",
    "cephadmlib",
    "jinja2",
    "markupsafe"
  ]
}

由 Ceph 基金会带给您

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