새 빌드봇 워커

Python의 빌드봇으로 작업하기 시스템은 앞에서 설명했습니다. 빌드 워커 집합을 “빌드봇 플릿”이라고 부르기도 합니다. 플릿을 구성하는 머신은 자발적으로 제공된 리소스입니다. 다수는 개인 자원봉사자가 자신의 비용과 시간을 들여 운영하며, 나머지는 기업의 지원을 받습니다. 하지만 기업이 후원하는 빌드봇조차도 대개 어떤 개인이 이를 적극적으로 추진하여 현실화하고 유지 관리에 전념하기 때문에 존재합니다.

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

플릿에 속한 빌드봇을 운영하는 사람은 누구나 python-buildbots 메일링 리스트를 구독해야 합니다. 빌드봇을 제공하고 싶지만 궁금한 점이 있는 경우에도 이 메일링 리스트에 문의할 수 있습니다.

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

빌드봇 워커 설정 준비

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

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

빌드봇 워커 설정

일반적인 상시 가동 머신

최신 버전의 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을 설치하십시오.

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

  • 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

빌드봇 사용자의 터미널 창에서 다음 명령을 실행하십시오. (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초의 연결 유지 간격을 사용합니다. 기본값 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 문서에 설명된 대로 워커 서비스를 설정하십시오.

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

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를 저장하십시오. 새 AMI를 생성하기 전에 재부팅 후 업데이트 작업이 모두 완료되도록, 업데이트를 수행한 후에는 (특히 Windows 워커의 경우) 인스턴스를 적어도 한 번 다시 시작해야 합니다.

  • 기존 워커 이름과 비밀번호를 사용하여 더 최신의 베이스 AMI에서 완전히 새로운 설정을 생성하십시오.

어떤 방식으로 AMI를 업데이트하든 빌드마스터 관리자에게 새 AMI ID를 제공해야 합니다.

빌드봇 워커 운영

대부분의 경우 워커 실행은 “설정 후 잊어버리는” 작업이지만, 빌더가 발견한 버그를 해결하는 데 얼마나 관여하고 싶은지에 따라 달라집니다. 그러나 직접 관여하는 것이 도움이 되거나 심지어 필요한 경우도 있습니다. 위에서 언급했듯이, 플릿 전체의 문제를 알 수 있도록 python-buildbots@python.org를 구독해야 합니다.

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

현재 워커 소프트웨어에는 최소 버전 요구 사항이 없습니다. 그러나 플릿을 조정하면서 이러한 요구 사항을 설정할 가능성이 있으므로, 빌드봇 워커 소프트웨어를 때때로 업그레이드하는 것도 또 하나의 작업이 될 것입니다. 이에 관한 조율은 python-buildbots@python.org를 통해 이루어집니다.

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

필수 포트

워커는 buildmaster에 대한 client로 작동합니다. 이는 모든 네트워크 연결이 outbound임을 의미합니다. 테스트 스위트의 네트워크 테스트에도 마찬가지로 적용됩니다. 대부분의 소비자용 방화벽은 모든 아웃바운드 트래픽을 허용하므로, 일반적으로 빌드봇이 사용하는 포트를 걱정할 필요가 없습니다. 그러나 기업용 방화벽은 때때로 더 제한적이므로, 빌드봇과 파이썬 테스트 스위트가 사용하는 모든 아웃바운드 포트를 나열한 표를 아래에 제공합니다(이 표가 마지막으로 검토된 이후 새 테스트가 추가되었을 수 있으므로 이 목록은 완전하지 않을 수 있습니다):

포트

호스트

설명

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 중 하나를 사용합니다.

필수 리소스

빌드봇 요구 사항에 관해 마지막으로 실시한 설문 조사를 바탕으로 할 때, Python 빌드봇에 권장되는 최소 리소스 할당량은 다음과 같습니다:

  • CPU 2개

  • RAM 512MB

  • 디스크 여유 공간 30GB

많은 테스트에는 훨씬 더 많은 메모리가 필요하므로 이 구성에서는 실행되지 않지만, 이 정도의 리소스면 충분합니다. 최소 설정을 사용하는 빌더는 더 많은 유지 관리가 필요할 수 있습니다. 이러한 빌더는 리소스를 많이 사용하는 Python 테스트에 태그가 지정되고 해당 테스트를 올바르게 건너뛰는지 확인합니다.

보안 고려 사항

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

코드는 권한 있는 사용자와 권한 없는 사용자로 실행할 때 다르게 동작합니다. 빌더를 권한 있는 계정으로 실행할 수 있으면 좋겠지만, root 접근 권한이 있으면 VM 환경에서도 예상치 못한 리소스(예: 위조된 IP 패킷, MAC 주소 변경 등)에 접근할 수 있으므로 보안상의 고려 때문에 그렇게 하기는 어렵습니다. 하지만 설정에 확신이 있다면 Python을 root로 실행하는 빌드봇을 제공해 주시면 좋습니다.

위 내용은 권한이 중요한 테스트의 예를 포함하여 빌드봇 보안을 다룬 python-dev의 토론을 요약한 것임에 유의하십시오. 최종 합의에는 이르지 못했지만, 이 정보는 참고 자료로 유용합니다.