注意
本文档适用于 Ceph 的开发版本。
Ceph 发布流程
先决条件
签署机器
签署机器是 Sepia 实验室中的一个虚拟机。对签署机器的 SSH 访问仅限于通常的基础设施管理员以及少数其他组件负责人(例如,nfs-ganesha、ceph-iscsi)。
机器上的 ubuntu 用户拥有一些 构建脚本,可帮助拉取、推送和签署软件包。
GPG 签署密钥永久保存在 Nitrokey Pro 上,并通过 RHV 传递给虚拟机。这有助于确保密钥无法以任何方式导出或离开数据中心。
新的主要版本
对于每个新的主要(按字母顺序)版本,您必须为每个 RPM 存储库创建一个 ceph-release RPM(例如,一个用于 el8,一个用于 el9)。chacra 是我们用于存储 DEB 和 RPM 存储库的 python 服务。chacra 存储库配置为包含此 ceph-release RPM,但必须单独构建它。您必须确保 chacra 已正确配置为包含此特定版本的 RPM。
更新 chacra,使其了解新的 Ceph 版本。有关示例,请参阅 此 PR。
重新部署 chacra(例如,
ansible-playbook chacra.ceph.com.yml)
摘要构建流程
QE 完成测试并找到一个停止点。该提交被推送到 ceph.git 中的
$release-release分支(例如,squid-release)。这使得工作可以继续在正在工作的$release分支中进行,而无需在发布过程中冻结它。Ceph 理事会批准并通知“构建负责人”。
“构建负责人”启动 Jenkins multijob,它会触发所有构建。
软件包被推送到 chacra.ceph.com。
软件包从 chacra.ceph.com 拉取到签署虚拟机。
软件包已签署。
软件包被推送到 download.ceph.com 上的预发布区域。
预发布容器被构建并推送到 quay.ceph.io。
对预发布软件包和容器进行最终测试和验证。
预发布软件包和容器被提升为 download.ceph.com 和 quay.io 上的官方版本。
热修复发布流程偏差
热修复发布有几个不同之处。
检出最新的标签。例如,如果我们要发布基于 19.2.1 的热修复,则运行
git checkout -f -B squid-release tags/v19.2.1。git cherry-pick -x必要的修复提交(注意:必须仅使用“cherry-pick”)。git push -f origin squid-release.验证
$release-release分支中的提交要检查与上一个点版本(如果我们要创建 19.2.2,这将是 19.2.1)的差异,请运行
git log --pretty=oneline --no-merges tags/v19.2.1..origin/squid-release。验证生成的提交是否正是我们想要的下一个点版本中的内容。要检查与“ceph-ci”存储库中 RC 的差异(在本例中为
ceph-ci),请运行git log --pretty=oneline --no-merges origin/squid-release...ceph-ci/squid-release。如果 ceph 存储库中的$release-release分支与ceph-ci中的 RC 相同,则不应有任何输出。注意使用 git 三点表示法,它显示了两个引用之间的任何提交差异。
通知“构建负责人”开始构建。
“构建负责人”应将
RELEASE_TYPE=HOTFIX而不是STABLE。
安全发布流程偏差
安全/CVE 发布类似于热修复发布,但有两个不同之处
修复程序应推送到 ceph-private 存储库而不是 ceph.git(需要 GitHub 管理员角色)。
标签(例如 v19.2.3)必须由“构建负责人”手动推送到 ceph.git。
检出最新的标签。例如,如果我们要发布基于 19.2.2 的安全修复,则运行
git checkout -f -B squid-release origin/v19.2.2git cherry-pick -x必要的安全修复提交git remote add security git@github.com:ceph/ceph-private.gitgit push -f security squid-release通知“构建负责人”开始构建。
“构建负责人”应将
RELEASE_TYPE=SECURITY而不是STABLE。最后,ceph-tag 步骤需要由“构建负责人”在尽可能接近公告时间手动运行
# Example using squid pretending 19.2.3 is the security release version # Add the ceph-releases repo (also requires GitHub Admin Role). The `ceph-setup <https://jenkins.ceph.com/job/ceph-setup>`_ job will have already created and pushed the tag to ceph-releases.git. git remote add releases git@github.com:ceph/ceph-releases.git git fetch --all # Check out the version commit git checkout -f -B squid-release releases/squid-release git push -f origin squid-release git push origin v19.2.3 # Now create a Pull Request of squid-release targeting squid to merge the version commit and security fixes back into the squid branch
1. 准备发布分支
一旦 QE 确定了工作(例如,squid)分支中的停止点,该提交应推送到相应的 squid-release 分支。
通知“构建负责人”发布分支已准备就绪。
2. 开始构建
我们将使用 Squid 的稳定/常规 19.2.2 版本作为本文档的示例。
浏览到 https://jenkins.ceph.com/view/all/job/ceph-release-pipeline/build?delay=0sec
使用 GitHub OAuth 登录
根据需要设置参数
BRANCH=squid TAG=checked VERSION=19.2.2 RELEASE_TYPE=STABLE ARCHS=x86_64 arm64
注意:如果由于某种原因必须重新启动构建(例如,如果某个发行版失败),则必须取消选中 TAG 选项。
使用 https://docs.ceph.net.cn/en/latest/start/os-recommendations/?highlight=debian#platforms 来确定
DISTROS参数。例如,版本
发行版代号映射
pacific (16.X.X)
focal bionic buster bullseyequincy (17.X.X)
jammy focal centos9 bullseyereef (18.X.X)
jammy focal centos9 windows bookwormsquid (19.X.X)
jammy centos9 windows bookwormtentacle (20.X.X)
jammy centos9 noble windows bookworm rocky10点击
Build。
3. 发布说明
软件包需要数小时才能构建完成。利用这些时间创建发布说明和公告
ceph.git 发布说明(例如,v19.2.2 的 ceph.git (docs.ceph.com) PR)
ceph.io 发布说明(例如,v19.2.2 的 ceph.io.git (www.ceph.io) PR)
电子邮件公告
4. 签署并发布构建
从 构建作业 或 ceph-setup 作业创建的
sha1文件中获取版本提交的 sha1。将软件包从 chacra.ceph.com 下载到签署虚拟机。这些软件包下载到
/opt/repos,Sepia Lab Long Running (Ceph) Cluster 安装在此处。注意:此步骤还将运行一个命令,通过 SSH 连接到 download.ceph.com 并运行 /home/signer/bin/get-tarballs.sh,将源 tarball 从 chacra.ceph.com 直接传输到 download.ceph.com。ssh ubuntu@signer.front.sepia.ceph.com sync-pull ceph [pacific|quincy|etc] <sha1>
示例
$ sync-pull ceph squid 0eceb0defba60152a8182f7bd87d164b639885b8 sync for: ceph squid ******************************************** + : 0eceb0defba60152a8182f7bd87d164b639885b8 + project=ceph + release=squid + sha1=0eceb0defba60152a8182f7bd87d164b639885b8 + echo 'sync for: ceph squid' sync for: ceph squid + echo '********************************************' ******************************************** + [[ ceph == \c\e\p\h ]] + current_highest_count=0 + for combo in debian/bookworm debian/bullseye ubuntu/bionic ubuntu/focal ubuntu/jammy ++ wc -l ++ curl -fs https://chacra.ceph.com/r/ceph/squid/0eceb0defba60152a8182f7bd87d164b639885b8/debian/bookworm/flavors/default/pool/main/c/ceph/ + combo_count=161 + [[ 0 -eq 22 ]] + '[' 161 -gt 0 ']' + current_highest_count=161 + highest_combo=debian/bookworm etc...
签署 DEB
merfi gpg /opt/repos/ceph/squid-19.2.2/debian/示例
--> Starting path collection, looking for files to sign --> 1 repos found --> signing: /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/bookworm/Release --> Running command: gpg --batch --yes --armor --detach-sig --output Release.gpg Release --> Running command: gpg --batch --yes --clearsign --output InRelease Release --> signing: /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/jammy/Release --> Running command: gpg --batch --yes --armor --detach-sig --output Release.gpg Release --> Running command: gpg --batch --yes --clearsign --output InRelease Release etc...
签署 RPM
sign-rpms ceph squid示例
$ sign-rpms ceph squid + [[ 2 -lt 1 ]] + project=ceph + shift + '[' 1 -eq 0 ']' + releases=("$@") + distros=(centos rhel) + distro_versions=(7 8 9) + read -s -p 'Key Passphrase: ' GPG_PASSPHRASE Key Passphrase: + echo + for release in "${releases[@]}" + for distro in "${distros[@]}" + for distro_version in "${distro_versions[@]}" + for path in /opt/repos/$project/$release* + '[' -d /opt/repos/ceph/squid-19.1.0/centos/7 ']' ... + echo 'Checking packages in: /opt/repos/ceph/squid-19.1.0/centos/9' Checking packages in: /opt/repos/ceph/squid-19.1.0/centos/9 + update_repo=0 + cd /opt/repos/ceph/squid-19.1.0/centos/9 ++ find -name '*.rpm' + for rpm in `find -name "*.rpm"` ++ grep '^Signature' etc...将软件包发布到 download.ceph.com
sync-push ceph squid-19.2.2 2
这会将软件包和 tarball 留在 download.ceph.com 上受密码保护的预发布区域 https://download.ceph.com/prerelease/ceph。从那里验证它们。完成后并准备发布时,登录 download.ceph.com 并将目录和 tarball 从预发布主目录(/data/download.ceph.com/www/prerelease/ceph)移动到发布目录(/data/download.ceph.com/www)。
5. 构建容器
与 CI 构建不同,CI 构建可以访问适用于容器的正确形式的软件包,而发布构建则不能,因为构建不会签署软件包。因此,发布构建不会构建容器。这必须在4. 签署并发布构建之后完成。
存在一个名为 ceph-release-containers 的 Jenkins 作业,以便我们可以在发布前测试镜像。该作业的存在既是为了方便,也是因为它需要访问 x86_64 和 arm64 构建器。在 Jenkins 服务器上以“使用参数构建”启动作业,设置 BRANCH、SHA1 和 VERSION 字段,并将其余字段保留为默认值。此作业
构建特定于架构的容器镜像,并将它们推送到
quay.ceph.io/ceph/prerelease-amd64和quay.ceph.io/ceph/prerelease-arm64将特定于架构的镜像融合在一起,形成一个“manifest-list”或“fat”容器镜像,并将其推送到
quay.ceph.io/ceph/prerelease
最后,当所有适当的测试和验证都在容器镜像上完成时,从 Ceph 源代码树(位于 container/make-manifest-list.py)运行 make-manifest-list.py --promote,将它们提升到 quay.io/ceph/ceph 上的最终发布位置(您必须确保使用适当的权限登录到 quay.io/ceph 和 quay.ceph.io/ceph)
cd <ceph-checkout>/container ./make-manifest-list.py --promote
--promote 步骤应仅作为发布容器的最后一步执行,在容器镜像经过测试并确认良好之后。
6. 宣布发布
版本提交 PR
ceph-tag Jenkins 作业在 ceph.git 中创建一个针对发布分支的拉取请求。
如果这是一个常规发布(不是热修复发布或安全发布),则该拉取请求中唯一的提交应该是版本提交。例如,请参阅 v15.2.17 的版本提交 PR。
请求审核,然后合并拉取请求。
宣布
在通过电子邮件宣布发布之前,在 ceph.io 上发布发布说明,因为电子邮件公告引用了 ceph.io 博客文章。