새 빌드봇 워커

Python의 빌드봇으로 작업하기 시스템은 앞에서 다루었습니다. 우리는 빌드 워커의 모음을 “빌드봇 플릿”이라고 부르기도 합니다. 플릿을 구성하는 머신은 자발적으로 기여된 자원입니다. 상당수는 개인 자원봉사자가 자신의 비용과 시간을 들여 운영하며, 나머지는 기업의 지원을 받습니다. 그러나 기업이 후원하는 빌드봇조차도 대개는 어떤 개인이 이를 앞장서 추진하고 실현했으며 유지 관리에 힘쓰고 있기 때문에 존재합니다.

누구나 플릿에 빌드봇을 기여할 수 있습니다. 이 문서는 빌드봇 워커를 설정하고 플릿에 추가하는 방법과 빌드봇 유지 관리에 관한 몇 가지 조언을 설명합니다.

플릿에 속한 빌드봇을 운영하는 사람은 누구나 python-buildbots 메일링 리스트를 구독해야 합니다. 빌드봇을 기여하고 싶지만 궁금한 점이 있을 때 연락할 곳도 이 메일링 리스트입니다.

어떤 종류의 빌드봇을 운영할지에 대해서는… 우리의 현재 플릿을 살펴보십시오. 그 목록에 없는 것이라면 거의 무엇이든 흥미로울 것입니다: 다른 Linux/Unix 배포판, 여러 운영 체제의 다른 버전, 그리고 여러분이나 다른 누군가가 새 운영 체제에서 테스트 스위트가 실제로 통과하도록 만들 준비가 되어 있다면 다른 운영 체제도 좋습니다. 이미 목록에 있는 운영 체제만 실행하고 싶더라도 이를 설정하는 것은 유용할 수 있습니다. 다양한 대체 빌드 구성에서도 python을 빌드하고 테스트해야 하기 때문입니다. 메일링 리스트에 글을 올려 무엇을 기여하고 싶은지 이야기해 주십시오.

빌드봇 워커 설정 준비

목표는 소스에서 Python을 빌드하는 것이므로, 시스템에는 일반적인 python 개발에 필요한 모든 것이 갖추어져 있어야 합니다: 컴파일러, 링커, 그리고 (Windows를 제외하고) 해당 플랫폼에서 지원하는 선택적 모듈(zlib, OpenSSL 등)의 “개발” 헤더가 필요합니다. 대상 플랫폼에 대해 설정과 빌드에 설명된 단계를 따라, 컴파일된 Python이 제대로 동작할 때까지 진행하십시오.

빌드봇 소프트웨어를 설정하려면 워커가 플릿에 합류할 수 있도록 워커의 식별자와 비밀번호를 받아야 합니다. 구성 저장소에 이슈를 열어 워커 추가를 논의하고 필요한 워커 이름과 비밀번호를 받으십시오. (관리자가 따르는 절차는 README의 “Add a worker” 항목에 문서화되어 있습니다.) 이어지는 단계 중 일부는 자격 증명을 받기 전에도 진행할 수 있지만, 아래의 “빌드봇 워커” 단계 전에 자격 증명을 받아 두는 것이 가장 편합니다.

빌드봇 워커 설정

상시 가동되는 일반 머신

최신 버전의 buildbot 워커 소프트웨어가 필요합니다. 대부분의 플랫폼에서는 배포판의 패키지 관리자가 buildbot-worker 패키지를 제공하며, 이 패키지는 전용 서비스 계정, systemd 유닛(또는 그에 상응하는 것), 필요한 디렉터리도 함께 만듭니다. 패키지가 없는 플랫폼에서는 pip install buildbot-worker를 대안으로 사용할 수 있지만, 서비스 계정, 디렉터리, 서비스 유닛을 직접 만들어야 합니다. 시스템을 관리하는 방식에 따라 가상 환경을 사용하여 빌드봇을 설정할 수도 있습니다. 그러한 경로를 택한다면 아래 단계를 적절히 조정해야 합니다.

Fedora:

dnf install buildbot-worker

RHEL 8 (EPEL 필요):

subscription-manager repos --enable codeready-builder-for-rhel-8-$(arch)-rpms
dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
dnf install buildbot-worker

RHEL 9 (EPEL 필요):

subscription-manager repos --enable codeready-builder-for-rhel-9-$(arch)-rpms
dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
dnf install buildbot-worker

CentOS Stream 9 / 10 (CRB + EPEL 필요):

dnf config-manager --set-enabled crb
dnf install epel-release epel-next-release
dnf install buildbot-worker

RPM은 buildbot-worker 시스템 사용자를 만들고, 템플릿 systemd 유닛 buildbot-worker@.service를 설치하며, 워커 인스턴스의 기본 디렉터리로 /var/lib/buildbot/worker/를 만듭니다.

팁

시스템의 디스크 공간 대부분이 루트 파티션이 아닌 /home에 있다면, 워커 데이터를 /home 아래에 만들고 심볼릭 링크를 걸어 패키지에 포함된 systemd 유닛이 그대로 동작하도록 하십시오:

mkdir -p /home/buildbot-worker/worker
ln -s /home/buildbot-worker/worker /var/lib/buildbot/worker

소유권과 경로는 사용하는 배포판의 관례에 맞게 조정하십시오.

워커를 생성하십시오(WORKERNAME과 WORKERPASSWD를 빌드마스터 구성(buildmaster-config) 이슈에서 받은 자격 증명으로 바꾸십시오):

sudo -u buildbot-worker buildbot-worker create-worker \
    /var/lib/buildbot/worker/WORKERNAME \
    buildbot-api.python.org:9020 WORKERNAME WORKERPASSWD

워커 디렉터리에 있는 info/admin, info/host, buildbot.tac을 편집하십시오(권장 설정은 아래를 참조하십시오).

서비스를 활성화하고 시작하십시오:

systemctl enable --now buildbot-worker@WORKERNAME.service

apt install buildbot-worker

이 패키지는 buildbot 시스템 사용자를 만들고, 템플릿 systemd 유닛인 buildbot-worker@.service를 설치하며, 워커 인스턴스의 기본 디렉터리로 /var/lib/buildbot/workers/를 만듭니다.

팁

시스템의 디스크 공간 대부분이 루트 파티션이 아닌 /home에 있다면, 워커 데이터를 /home 아래에 만들고 심볼릭 링크를 걸어 패키지에 포함된 systemd 유닛이 그대로 동작하도록 하십시오:

mkdir -p /home/buildbot/workers
ln -s /home/buildbot/workers /var/lib/buildbot/workers

소유권과 경로는 사용하는 배포판의 관례에 맞게 조정하십시오.

워커를 생성하십시오(WORKERNAME과 WORKERPASSWD를 빌드마스터 구성(buildmaster-config) 이슈에서 받은 자격 증명으로 바꾸십시오):

sudo -u buildbot buildbot-worker create-worker \
    /var/lib/buildbot/workers/WORKERNAME \
    buildbot-api.python.org:9020 WORKERNAME WORKERPASSWD

워커 디렉터리에 있는 info/admin, info/host, buildbot.tac을 편집하십시오(권장 설정은 아래를 참조하십시오).

서비스를 활성화하고 시작하십시오:

systemctl enable --now buildbot-worker@WORKERNAME.service

buildbot-worker 패키지가 없는 배포판에서는 pip로 설치하십시오:

pip install buildbot-worker

NixOS 사용자는 내장된 services.buildbot-worker NixOS 모듈을 사용해야 합니다. 사용할 수 있는 옵션은 nixpkgs 모듈 소스를 참조하십시오.

Arch Linux에는 AUR에 빌드봇 패키지가 있지만, 현재는 관리되지 않고 있습니다. pip를 사용하는 편이 더 안정적입니다.

pip는 시스템 사용자, 디렉터리, 서비스 유닛을 만들지 않습니다. 이것들은 직접 설정하십시오. useradd가 있는 배포판에서는:

useradd --system --shell /sbin/nologin \
    --home-dir /var/lib/buildbot/worker --create-home buildbot-worker

Alpine Linux(BusyBox)에서는:

adduser -S -D -H -h /var/lib/buildbot/worker -s /sbin/nologin buildbot-worker

그런 다음 디렉터리를 만드십시오:

mkdir -p /var/lib/buildbot/worker
chown buildbot-worker:buildbot-worker /var/lib/buildbot/worker

워커를 생성하십시오(WORKERNAME과 WORKERPASSWD를 빌드마스터 구성(buildmaster-config) 이슈에서 받은 자격 증명으로 바꾸십시오):

sudo -u buildbot-worker buildbot-worker create-worker \
    /var/lib/buildbot/worker/WORKERNAME \
    buildbot-api.python.org:9020 WORKERNAME WORKERPASSWD

워커 디렉터리에 있는 info/admin, info/host, buildbot.tac을 편집하십시오(권장 설정은 아래를 참조하십시오).

systemd 기반 배포판에서는 서비스 유닛도 설치해야 합니다. 아래의 서비스 관리 절을 참조하십시오.

pkg install devel/py-buildbot-worker

이 패키지는 buildbot 시스템 사용자를 만들고, 프로필을 지원하는 rc.d 서비스를 설치하며, 워커 인스턴스의 기본 디렉터리로 /var/db/buildbot/workers/를 만듭니다.

워커를 생성하십시오(WORKERNAME과 WORKERPASSWD를 빌드마스터 구성(buildmaster-config) 이슈에서 받은 자격 증명으로 바꾸십시오):

su -m buildbot -c "buildbot-worker create-worker \
    /var/db/buildbot/workers/WORKERNAME \
    buildbot-api.python.org:9020 WORKERNAME WORKERPASSWD"

워커 디렉터리에 있는 info/admin, info/host, buildbot.tac을 편집하십시오(권장 설정은 아래를 참조하십시오).

서비스를 활성화하고 시작하십시오. rc.d 스크립트는 프로필 이름을 셸 변수 식별자로 사용하므로, 하이픈이 없는 짧은 이름을 고르십시오(워커 이름과 같을 필요는 없습니다):

sysrc buildbot_worker_enable=YES
sysrc buildbot_worker_profiles="myworker"
sysrc buildbot_worker_myworker_enable=YES
sysrc buildbot_worker_myworker_basedir=/var/db/buildbot/workers/WORKERNAME
service buildbot-worker start

pkg_add buildbot-worker

이 패키지는 _buildslave 시스템 사용자를 생성하고, rc.d 서비스를 설치하며, 기본 워커 디렉터리로 /var/buildslave/를 생성합니다.

워커를 생성하십시오(WORKERNAME과 WORKERPASSWD를 빌드마스터 구성(buildmaster-config) 이슈에서 받은 자격 증명으로 바꾸십시오):

su -m _buildslave -c "buildbot-worker create-worker \
    /var/buildslave \
    buildbot-api.python.org:9020 WORKERNAME WORKERPASSWD"

워커 디렉터리에 있는 info/admin, info/host, buildbot.tac을 편집하십시오(권장 설정은 아래를 참조하십시오).

서비스를 활성화하고 시작하십시오:

rcctl enable buildbot_worker
rcctl start buildbot_worker

rc.d 스크립트는 하나의 워커만 지원합니다. 여러 워커를 실행하려면 각 워커를 하위 디렉터리에 생성하고 서비스 플래그가 원하는 워커를 가리키도록 설정하십시오(또는 rc.d 스크립트를 추가로 생성하십시오):

su -m _buildslave -c "buildbot-worker create-worker \
    /var/buildslave/WORKERNAME \
    buildbot-api.python.org:9020 WORKERNAME WORKERPASSWD"
rcctl enable buildbot_worker
rcctl set buildbot_worker flags /var/buildslave/WORKERNAME
rcctl start buildbot_worker

  • macOS 제어판의 사용자 관리 기능을 사용하여 빌드봇 사용자를 생성하십시오. 이 사용자는 “표준” 사용자여야 합니다.

  • 빌드봇 사용자로 로그인하십시오.

  • pip install buildbot-worker를 실행하여 빌드봇 워커 [1]를 설치하십시오.

빌드봇 사용자의 터미널 창에서 다음 명령을 실행하십시오(buildarea는 원하는 위치 어디에나 둘 수 있습니다):

mkdir buildarea
buildbot-worker create-worker buildarea buildbot-api.python.org:9020 WORKERNAME WORKERPASSWD

  • 빌드봇 사용자를 “표준” 사용자로 생성하십시오.

  • python.org에서 최신 버전의 파이썬을 설치하십시오.

  • 명령 프롬프트를 여십시오.

  • python -m pip install pywin32 buildbot-worker를 실행하십시오(python.exe는 기본적으로 PATH에 추가되지 않으며, python 명령을 사용할 수 있게 만드는 작업은 사용자의 연습 과제로 남겨 둡니다).

Windows에서는 경로의 최대 길이가 제한되어 있습니다. 이 때문에 긴 경로 지원을 활성화하지 않으면 일부 테스트가 실패할 수 있습니다.

다음 PowerShell 명령을 사용하여 긴 경로가 활성화되어 있는지 확인하십시오:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled"

값이 “1”이 아니면 다음 PowerShell 명령을 사용하여 긴 경로를 활성화할 수 있습니다:

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force

빌드봇 사용자의 터미널 창(Windows)에서 다음 명령을 실행하십시오. (buildarea는 원하는 곳 어디에나 두어도 됩니다.) buildbot-worker 명령은 Python 설치의 Scripts 디렉터리에 있다는 점에 유의하십시오. 여기와 이 안내서의 나머지 부분에서는 전체 경로를 사용하여 이 명령을 실행해야 할 수도 있습니다.

mkdir buildarea
buildbot-worker create-worker buildarea buildbot-api.python.org:9020 WORKERNAME WORKERPASSWD

워커 디렉터리의 info/admin 파일에는 여러분의 연락처 정보가 들어 있어야 하고, info/host에는 호스트 구성이 설명되어 있어야 합니다. 이 정보는 빌드봇 웹 인터페이스에 표시됩니다. 이 페이지들은 공개되어 있으므로 웹 스크레이퍼로 인한 스팸을 피하려면 이메일 주소를 난독화하는 방안(예: user AT example.com)을 고려하십시오.

권장하는 buildbot.tac 설정은 다음과 같습니다:

  • keepalive = 60 – 빌드마스터는 60초의 연결 유지(keepalive) 간격을 사용합니다. 기본값인 600은 너무 길어서 불필요한 연결 끊김을 일으킬 수 있습니다.

  • delete_leftover_dirs = 1 – 마스터가 더 이상 필요로 하지 않는 빌드 디렉터리를 자동으로 정리합니다.

팁

빌드 디렉터리와 twistd.log 로테이션 파일은 시간이 지나면서 쌓일 수 있습니다. delete_leftover_dirs를 활성화했더라도 워커 디렉터리가 있는 파티션의 여유 디스크 공간을 모니터링하십시오.

서비스 관리

머신이 재부팅될 때 워커가 시작되도록 설정해 두는 것도 좋습니다:

배포판 패키지(Fedora, RHEL, CentOS, Debian 또는 Ubuntu)로 설치했다면 위의 설치 단계에서 서비스가 이미 활성화되었습니다.

pip로 설치했다면 systemd 유닛을 직접 설치해야 합니다. 업스트림 빌드봇 프로젝트는 기여된 템플릿 유닛과 sysusers.d 및 tmpfiles.d 설정을 함께 제공합니다.

다음 내용으로 /etc/systemd/system/buildbot-worker@.service 파일을 만드십시오:

[Unit]
Description=Buildbot Worker %i
Documentation=man:buildbot-worker(1) https://docs.buildbot.net/
After=network.target
ConditionDirectoryNotEmpty=/var/lib/buildbot/worker/%i
ConditionFileNotEmpty=/var/lib/buildbot/worker/%i/buildbot.tac

[Service]
Type=simple
User=buildbot-worker
Group=buildbot-worker
WorkingDirectory=/var/lib/buildbot/worker/
StateDirectory=buildbot/worker
ExecStart=/usr/local/bin/buildbot-worker start --nodaemon %i
Restart=always
ProtectSystem=full
ProtectHome=yes
PrivateDevices=yes
PrivateTmp=yes

[Install]
WantedBy=multi-user.target

User, Group, WorkingDirectory 및 ExecStart 경로를 여러분의 환경에 맞게 조정하십시오. 워커 데이터가 /home에서 심볼릭 링크로 연결되어 있다면(위의 파일 시스템 배치 팁 참조) systemd가 심볼릭 링크를 따라갈 수 있도록 ProtectHome=yes를 ProtectHome=no로 변경하십시오. 그런 다음:

systemctl daemon-reload
systemctl enable --now buildbot-worker@WORKERNAME.service

systemd가 없는 배포판(예: OpenRC를 사용하는 Alpine Linux)을 위해 업스트림은 SysV init 스크립트와 기본 설정 파일을 함께 제공합니다. 이 파일들을 각각 /etc/init.d/buildbot-worker와 /etc/default/buildbot-worker로 설치한 다음, 기본 설정 파일에서 워커 인스턴스를 구성하십시오.

systemd와 SysV init 스크립트를 모두 사용하기 어렵다면 cron 작업을 사용할 수 있습니다. /etc/crontab에 다음 줄을 추가하십시오:

@reboot buildbot-worker restart /path/to/workerdir

비정상 종료로 인해 twistd.pid 파일이 남아 있을 경우에 대비하여 start 대신 restart를 사용한다는 점에 유의하십시오.

FreeBSD나 OpenBSD에서 패키지로 설치했다면 위의 설치 단계에서 서비스가 이미 활성화되었습니다. 수동으로 관리하려면 다음과 같이 하십시오:

FreeBSD에서:

service buildbot-worker status
service buildbot-worker restart

OpenBSD에서:

rcctl check buildbot_worker
rcctl restart buildbot_worker

pip로 설치했다면 rc.d 스크립트를 작성하거나 Linux 탭에 설명된 cron 작업 방식을 사용해야 합니다.

  • 빌드봇 사용자를 위한 bin 디렉터리를 만드십시오:

    mkdir bin

  • run_worker.sh라는 이름의 다음 스크립트를 그 디렉터리에 넣으십시오:

    #!/bin/bash
export PATH=/usr/local/bin:/Library/Frameworks/Python.framework/Versions/Current/bin:$PATH
export LC_CTYPE=en_US.utf-8
cd /Users/buildbot/buildarea
twistd --nodaemon --python=buildbot.tac --logfile=buildbot.log --prefix=worker

  • 다음 내용이 담긴 파일을 /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입니다.

  • 빌드봇 사용자로 buildbot-worker start buildarea를 “컴퓨터가 시작될 때” 실행하도록 예약된 작업을 추가하십시오. buildbot-worker 명령과 buildarea 디렉터리는 절대 경로로 지정하는 것이 가장 좋습니다. 또한 buildarea 디렉터리를 포함하는 디렉터리에서 작업이 실행되도록 설정하는 것을 권장합니다.

  • 또는 (주의: 둘 다 하지 마십시오!) 빌드봇 문서에 설명된 대로 워커 서비스를 설정하십시오.

아직 서비스 관리자를 통해 워커를 시작하지 않았다면, 초기 테스트를 위해 수동으로 시작할 수 있습니다:

buildbot-worker start /path/to/workerdir

그런 다음 누군가 커밋하기를 기다리거나, 빌더 목록에서 여러분의 워커와 연결된 빌더를 골라 빌드를 강제로 실행할 수 있습니다.

어떤 경우든 처음에는 여러분의 빌더에서 실행되는 빌드를 지켜보면서 테스트가 통과하는지 확인하고, 실패한 테스트로 드러날 수 있는 플랫폼 문제를 해결해야 합니다. 안타깝게도 현재는 여러분의 빌더에서 발생한 실패만 골라 알려 드릴 방법이 없으므로, 주기적으로 직접 점검하는 것도 좋습니다.

잠재 워커

AWS EC2 서비스에서 잠재 워커를 실행하는 것도 지원합니다. 이러한 워커를 설정하려면 다음과 같이 하십시오:

  • 선택한 기본 AMI로 인스턴스를 시작하고 일반 워커로 설정하십시오.

  • 인스턴스가 일반 워커로 완전히 설정되고 나면(워커 이름과 비밀번호, 관리자 및 호스트 정보 포함), 해당 인스턴스로 AMI를 만들고 인스턴스를 중지하십시오.

  • 워커 이름과 비밀번호를 발급해 준 빌드마스터 관리자에게 연락하여 다음 정보를 전달하십시오:

    • 인스턴스 크기(예: m4.large)

    • 전체 리전 지정(예: us-west-2)

    • AMI ID(예: ami-1234beef)

    • 액세스 키 ID와 액세스 키. 주 계정의 액세스 키 정보를 제공하기보다는, EC2에 대한 전체 접근 권한을 가진 별도의 IAM 사용자를 만들고 그 사용자의 액세스 키 정보를 제공하는 것을 권장합니다.

빌드마스터가 여러분의 인스턴스를 항상 종료한다고 보장할 수는 없으므로, 빌드봇 마스터가 생성한 “좀비” 인스턴스가 여러분의 계정에서 실행 중이지 않은지 주기적으로 확인하는 것을 권장합니다. 또한 워커가 예상보다 오랫동안 중단된 것 같다면, python-buildbots 메일링 리스트에 연락하여 마스터를 재시작해 달라고 요청하십시오.

잠재 워커도 운영 체제나 기타 소프트웨어 업데이트를 반영하도록 주기적으로 업데이트해야 하지만, 이러한 유지 보수를 언제 할지는 대체로 워커 소유자인 여러분에게 달려 있습니다. 이러한 업데이트를 하는 방법에는 몇 가지가 있습니다:

  • 기존 AMI로 인스턴스를 시작하여 그 인스턴스에서 업데이트를 수행하고, 업데이트된 인스턴스로 새 AMI를 저장하십시오. (특히 Windows 워커의 경우) 새 AMI를 만들기 전에 재부팅 후 진행되는 업데이트 작업이 모두 끝나도록, 업데이트 후 인스턴스를 적어도 한 번은 재시작해야 한다는 점에 유의하십시오.

  • 기존 워커 이름과 비밀번호를 사용하여 더 새로운 기본 AMI로 완전히 새로 설정하십시오.

어떤 방법으로 AMI를 업데이트하든, 빌드마스터 관리자에게 새 AMI ID를 알려 주어야 합니다.

빌드봇 워커 운영

빌더가 드러낸 버그를 해결하는 데 얼마나 관여하고 싶은지에 따라 다르지만, 대부분의 경우 워커 운영은 “설정해 두고 잊어버리면 되는” 작업입니다. 하지만 여러분이 관여하는 것이 도움이 되거나 심지어 꼭 필요한 때도 있습니다. 앞서 언급했듯이, 전체 워커에 걸친 문제를 알 수 있도록 python-buildbots@python.org를 구독해야 합니다.

필요한 작업에는 당연히 빌드봇이 계속 실행되도록 유지하는 일이 포함됩니다. 현재 워커가 오프라인 상태가 되었을 때 빌드봇 소유자에게 알리는 시스템이 작동하지 않고 있으며, 이는 저희가 해결하고자 하는 문제입니다. 따라서 현재로서는 워커의 상태를 주기적으로 확인해 주시면 도움이 됩니다. 또한 일정 기간 해결되지 않은 문제를 발견했는데 python-buildbots 목록에 올라온 관련 게시물에 응답하지 않으신 경우, info/admin에 있는 연락처 주소로 연락을 드릴 것입니다.

현재 워커 소프트웨어에 대한 최소 버전 요구 사항은 없습니다. 하지만 이는 워커 전체를 조정해 나가면서 아마 정하게 될 사항이므로, 가끔 빌드봇 워커 소프트웨어를 업그레이드하는 것도 또 하나의 작업이 될 것입니다. 이에 관한 조율은 python-buildbots@python.org에서 이루어집니다.

가장 흥미로운 추가 참여는 워커가 고유하거나 거의 고유한 문제, 즉 다른 시스템에서는 실패하지 않지만 여러분의 시스템에서는 실패하는 테스트를 드러낼 때입니다. 이 경우 버그를 다루는 사람들에게 디버깅 도움을 제공할 준비가 되어 있어야 합니다. 즉, 워커 머신에서 직접 테스트를 실행하거나, 가능하다면 커미터가 문제 해결을 위한 실험을 할 수 있도록 ssh 접근 권한을 제공해야 합니다.

필요한 포트

워커는 빌드마스터에 대한 클라이언트로 동작합니다. 이는 모든 네트워크 연결이 아웃바운드라는 뜻입니다. 이는 테스트 스위트의 네트워크 테스트에도 마찬가지로 적용됩니다. 대부분의 일반 소비자용 방화벽은 모든 아웃바운드 트래픽을 허용하므로, 보통은 빌드봇이 어떤 포트를 사용하는지 신경 쓸 필요가 없습니다. 하지만 기업 방화벽은 때때로 더 제한적이므로, 빌드봇과 python 테스트 스위트가 사용하는 모든 아웃바운드 포트를 나열한 표를 아래에 제공합니다 (이 표를 마지막으로 검토한 이후 새 테스트가 추가되었을 수 있으므로 이 목록은 완전하지 않을 수 있습니다):

포트

호스트

설명

20, 21

ftp.debian.org

test_urllib2net

53

your DNS server

test_socket 및 암묵적으로 기타 테스트

80

python.org example.com

(여러 테스트)

119

news.gmane.org

test_nntplib (Python 버전 < 3.13)

443

(various)

test_ssl

465

smtp.gmail.com

test_smtpnet

587

smtp.gmail.com

test_smtpnet

9020

buildbot-api.python.org

빌드마스터로의 연결

또한 많은 테스트가 로컬 TCP 소켓을 만들고 그에 연결하며, 보통 localhost 또는 127.0.0.1 중 하나를 사용합니다.

필요한 자원

빌드봇 요구 사항에 대해 마지막으로 실시한 설문 조사에 따르면, 파이썬 빌드봇에 권장되는 자원 할당량은 최소한 다음과 같습니다:

  • CPU 2개

  • 512 MB RAM

  • 30 GB의 여유 디스크 공간

많은 테스트는 훨씬 더 많은 메모리가 필요하므로 이 구성에서는 실행되지 않지만, 이 정도 자원이면 충분할 것입니다. 최소 설정으로 구성된 빌더는 더 많은 유지 보수가 필요할 수 있습니다: 이러한 빌더는 자원을 많이 사용하는 Python 테스트에 태그가 올바르게 지정되어 제대로 건너뛰어지는지 확인합니다.

보안 고려 사항

빌드는 GitHub의 CPython 저장소에 대한 커밋으로만 트리거되도록 허용합니다. 즉, 여러분의 빌드봇이 실행할 코드는 커미터의 검토를 거친 코드입니다. 하지만 실수와 버그는 일어나기 마련이고 보안 침해가 발생할 수도 있으므로, 네트워크에서 빌드봇을 배치할 위치를 정하고 그 주변의 보안을 구성할 때 이 점을 염두에 두십시오. 빌드봇은 외부에 공개되어 해킹당할 수 있는 다른 모든 자원과 마찬가지로 다루십시오(VM 및/또는 jail/chroot/solaris zone을 사용하고, DMZ에 두는 등). 빌드봇에는 인바운드 트래픽을 위해 열어 둔 포트가 없지만(그런 의미에서 외부에 공개되어 있지는 않지만), 커미터도 실수를 하며 릴리스된 코드와 릴리스되지 않은 코드 모두에서 보안 결함이 발견되므로, 빌드봇을 완전히 외부에 공개된 것처럼 다루는 것이 좋은 방침입니다.

코드는 권한이 있는 사용자로 실행될 때와 권한이 없는 사용자로 실행될 때 다르게 동작합니다. 권한이 있는 계정으로 실행되는 빌더가 있으면 매우 좋겠지만, root 권한에 접근하면 VM 환경에서조차 예상치 못한 자원(위조된 IP 패킷, MAC 주소 변경 등)에 접근할 수 있으므로 보안상의 이유로 그렇게 하기는 어렵습니다. 하지만 설정에 자신이 있다면, python을 root로 실행하는 빌드봇을 꼭 갖추고 싶습니다.

참고로 위 내용은 빌드봇 보안에 관해 python-dev에서 있었던 논의를 요약한 것이며, 이 논의에는 권한 여부가 중요한 테스트의 예가 포함되어 있습니다. 최종 합의에 이르지는 못했지만, 이 정보는 참고 자료로 유용합니다.