新的构建机器人工作者¶
Python 的使用构建机器人系统之前已讨论过。我们有时将构建工作者集合称为我们的“构建机器人机群”。构成机群的机器是自愿贡献的资源。许多机器由个人志愿者自掏腰包和时间运行,而另一些机器则得到公司的支持。然而,即使是公司赞助的构建机器人也往往存在,因为一些个人支持它们,使它们成为现实,并致力于维护它们。
任何人都可以为集群贡献一个构建机器人。本文档描述了如何设置构建机器人工作程序、将其添加以及一些有关构建机器人维护的提示。
任何运行属于该集群的构建机器人都应订阅 python-buildbots 邮件列表。如果您想贡献构建机器人但有疑问,也可以联系此邮件列表。
至于运行哪种构建机器人…请查看我们的 当前集群。该列表中没有的任何内容都很有趣:不同的 Linux/Unix 发行版、不同版本的各种操作系统、如果您或某人准备让测试套件实际通过该新操作系统,则可以使用其他操作系统。即使您只想运行我们列表中已有的操作系统,设置它也可能很有用;我们还需要在各种备用构建配置下构建和测试 python。发帖到邮件列表并讨论您想贡献的内容。
准备构建机器人工作程序设置¶
由于目标是从源代码构建 Python,因此系统需要具备进行常规 python 开发所需的一切:编译器、链接器以及(除 Windows 外)平台支持的任何可选模块(zlib、OpenSSL 等)的“开发”标头。按照 设置和构建 中针对目标平台概述的步骤进行操作,一直到拥有一个正在工作的已编译 python。
为了设置构建机器人软件,您需要为您的工作程序获取一个标识符和密码,以便它可以加入集群。在 配置存储库 中打开一个问题,以讨论添加您的工作程序并获取所需的 workername 和密码。您可以在拥有凭据之前执行以下一些步骤,但最好在执行以下“构建机器人工作程序”步骤之前拥有这些凭据。
设置构建机器人工作程序¶
传统常开机器¶
您需要最新版本的 构建机器人 软件,并且您可能需要一个单独的“构建机器人”用户来运行构建机器人软件。您可能还想使用虚拟环境设置构建机器人,具体取决于您如何管理系统。我们不会在此介绍如何执行此操作;它与为任何其他软件设置虚拟环境没有区别,但是如果您选择该路径,您需要相应地修改以下步骤的顺序。
对于 Linux
如果您的包管理器提供了构建机器人工作程序软件,这可能是安装它的最佳方式;它可能会为您创建构建机器人用户,在这种情况下,您可以跳过该步骤。否则,请执行
pip install buildbot-worker
。在必要时创建
buildbot
用户(例如使用:useradd
)。以构建机器人用户身份登录。
对于 Mac
使用 OS/X 控制面板用户管理员创建构建机器人用户。它应为“标准”用户。
以构建机器人用户身份登录。
通过运行
pip install buildbot-worker
安装构建机器人工作程序 [1]。
对于 Windows
创建一个构建机器人用户作为“标准”用户。
从 python.org 安装最新版本的 Python。
打开命令提示符。
执行
python -m pip install pypiwin32 buildbot-worker
(请注意,默认情况下未将python.exe
添加到PATH
中,因此使python
命令可访问是留给用户练习的)。
在构建机器人用户的终端窗口中,发出以下命令(您可以将 buildarea
放在您想要放置的任何位置)
mkdir buildarea
buildbot-worker create-worker buildarea buildbot-api.python.org:9020 workername workerpasswd
(请注意,在 Windows 上,buildbot-worker
命令将位于 Python 安装的 Scripts
目录中。)
此初始工作程序设置完成后,您应该编辑文件 buildarea/info/admin
和 buildarea/info/host
,分别提供您的联系信息和主机配置信息。此信息将显示在显示有关在您的工作程序上运行的构建器的信息的构建机器人网页中。
您还需要确保在机器重启时启动工作进程
对于 Linux
将以下行添加到
/etc/crontab
@reboot buildbot-worker restart /path/to/buildarea
请注意,我们使用
restart
而不是start
以防崩溃后留下twistd.pid
文件。
对于 OSX
为您的 buildbot 用户创建一个 bin 目录
mkdir bin
将以下脚本(名为
run_worker.sh
)放置到该目录中#!/bin/bash export PATH=/usr/local/bin:/Library/Frameworks/Python.framework/Versions/2.7/bin:$PATH export LC_CTYPE=en_US.utf-8 cd /Users/buildbot/buildarea twistd --nodaemon --python=buildbot.tac --logfile=buildbot.log --prefix=worker
如果您使用 Apple 系统 python 的 pip,请将“/System”添加到 Python bin 目录路径的前面。
将包含以下内容的文件放置到
/Library/LaunchDaemons
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>net.buildbot.worker</string> <key>UserName</key> <string>buildbot</string> <key>WorkingDirectory</key> <string>/Users/buildbot/buildarea</string> <key>ProgramArguments</key> <array> <string>/Users/buildbot/bin/run_worker.sh</string> </array> <key>StandardOutPath</key> <string>twistd.log</string> <key>StandardErrorPath</key> <string>twistd.log</string> <key>KeepAlive</key> <true/> <key>SessionCreate</key> <true/> </dict> </plist>
建议的文件名称为
net.buildbot.worker
。
对于 Windows
添加一个计划任务,在“计算机启动时”以 buildbot 用户身份运行
buildbot-worker start buildarea
。最好为buildbot-worker
命令和buildarea
目录提供绝对路径。还建议将任务设置为在包含buildarea
目录的目录中运行。或者(注意:不要同时执行这两项操作!),按照 buildbot 文档 中所述设置工作进程服务。
要启动工作进程以进行初始测试,您可以执行以下操作
buildbot-worker start buildarea
然后,您可以等待某人提交,或者从 构建程序列表 中选择与您的工作进程关联的构建程序并强制构建。
在任何情况下,您都应最初监视构建程序上的构建,以确保测试通过并解决测试失败可能揭示的任何平台问题。遗憾的是,我们目前没有办法仅通知您构建程序上的失败,因此定期进行现场检查也是一个好主意。
注意
如果您的 buildbot 工作进程定期断开连接,则可能是默认 keepalive
值 (600
,即 10 分钟) 设置 得太高。您可以在构建区域中找到的 buildbot.tac
文件中将其更改为较低的值(例如 180
,即 3 分钟)。
潜在工作进程¶
我们还支持在 AWS EC2 服务上运行 潜在工作进程。要设置此类工作进程
启动您选择的基准 AMI 的实例,并将其设置为常规工作进程。
在该实例完全设置为常规工作进程(包括工作进程名称和密码,以及管理员和主机信息)后,从该实例创建 AMI 并停止该实例。
联系为您提供工作进程名称和密码的构建主服务器管理员,并向他们提供以下信息
实例大小(例如
m4.large
)完整区域规范(例如
us-west-2
)AMI ID(例如
ami-1234beef
)访问密钥 ID 和访问密钥。建议设置一个具有对 EC2 完全访问权限的单独 IAM 用户,并提供该用户的访问密钥信息,而不是提供您的主帐户的访问密钥信息。
构建主服务器无法保证它会始终关闭您的实例,因此建议定期检查并确保您的帐户上没有构建主服务器创建的“僵尸”实例正在运行。此外,如果您发现您的工作进程似乎已经意外长时间宕机,请 ping python-buildbots 列表,请求重新启动主服务器。
潜在工作器也应定期更新以包括操作系统或其他软件更新,但何时执行此类维护工作主要取决于您作为工作器所有者的决定。执行此类更新有几种不同的选择
从现有 AMI 启动一个实例,对该实例进行更新,然后从更新的实例保存一个新的 AMI。请注意(特别是对于 Windows 工作器),在进行更新后,您应至少重新启动该实例一次,以确保在创建新 AMI 之前已完成任何重新启动后更新工作。
使用现有工作器名称和密码从较新的基本 AMI 创建一个全新的设置。
无论您选择哪种方式更新 AMI,您都需要向构建主管理员提供新的 AMI ID。
Buildbot 工作器操作¶
大多数情况下,运行工作器是一种“设置后即可忘记”的操作,具体取决于您希望参与解决构建器发现的错误的程度。但是,有时您参与其中是有帮助的,甚至是有必要的。如上所述,您应订阅 python-buildbots@python.org
,以便了解任何影响整个机群的问题。
必要的任务显然包括保持 buildbot 运行。目前,当工作器脱机时通知 buildbot 所有者的系统无法正常工作;这是我们希望解决的问题。因此,如果您定期检查工作器状态,这将很有帮助。当我们注意到某个问题在一段时间内没有得到解决,并且您没有对 python-buildbots 列表上的帖子做出回应时,我们还将通过 buildarea/info/admin
中的联系地址与您联系。
我们目前没有工作器软件的最低版本要求。但是,随着我们调整机群,这可能是我们可能会确定的内容,因此另一项任务将是偶尔升级 buildbot 工作器软件。此项工作的协调将通过 python-buildbots@python.org
完成。
最有趣的额外参与是当您的工作器发现一个独特或几乎独一无二的问题时:在您的系统上失败但在其他系统上不失败的测试。在这种情况下,您应该准备好向处理该错误的人员提供调试帮助:在工作器机器上手动运行测试,或者(如果可能)为提交者提供 ssh 访问权限以运行实验来尝试解决该问题。
必需的端口¶
工作器作为客户端操作构建主。这意味着所有网络连接都是出站的。测试套件中的网络测试也是如此。大多数消费者防火墙将允许任何出站流量,因此您通常不必担心 buildbot 使用哪些端口。但是,公司防火墙有时会更具限制性,因此这里有一张表格列出了 buildbot 和 python 测试套件使用的所有出站端口(此列表可能不完整,因为自上次审查此表格以来可能已添加了新测试)
端口 |
主机 |
说明 |
---|---|---|
20, 21 |
ftp.debian.org |
test_urllib2net |
53 |
您的 DNS 服务器 |
test_socket 以及其他隐式测试 |
80 |
python.org example.com |
(多个测试) |
119 |
news.gmane.org |
test_nntplib |
443 |
(各种) |
test_ssl |
465 |
smtp.gmail.com |
test_smtpnet |
587 |
smtp.gmail.com |
test_smtpnet |
9020 |
python.org |
连接到构建主 |
许多测试还将创建本地 TCP 套接字并连接到它们,通常使用 localhost
或 127.0.0.1
。
必需的资源¶
根据我们上次对 buildbot 要求 进行的调查,python buildbot 的建议资源分配至少为
2 个 CPU
512 MB RAM
30 GB 可用磁盘空间
bigmem 测试不会在此配置中运行,因为它们需要更多内存,但这些资源应足以确保 Python 在平台上正确编译并可以运行其余测试套件。
安全注意事项¶
我们只允许针对 GitHub 上的 CPython 存储库 中的提交触发构建。这意味着构建机器人将运行的代码已由提交者审查过。但是,错误和漏洞是存在的,妥协也可能发生,因此在将构建机器人部署到网络上并建立其安全性时请牢记这一点。像对待任何面向公众且可能遭到黑客攻击的资源一样对待构建机器人(使用虚拟机和/或 jail/chroot/solaris 区域,将其置于 DMZ 中,等等)。虽然构建机器人没有针对入站流量开放任何端口(并且从这个意义上来说不是面向公众的),但提交者错误确实会发生,并且在已发布和未发布的代码中都发现了安全漏洞,因此将构建机器人视为完全面向公众是一个好策略。
代码以特权和非特权用户身份运行的方式不同。我们希望构建器以特权帐户运行,但安全考虑确实让这变得很困难,因为即使在虚拟机设置中,访问 root 也能访问令人惊讶的资源(例如欺骗性 IP 数据包、MAC 地址更改等)。但是,如果您对自己的设置有信心,我们很乐意让构建机器人以 root 身份运行 python。
请注意,以上内容是对 python-dev 上关于构建机器人安全性的讨论 的总结,其中包括特权重要的测试示例。没有达成最终共识,但这些信息作为参考点很有用。