ติดตั้ง GitHub Actions runner บน VPS ด้วย Ubuntu 24.04

การทำงานของ GitHub Actions runner แบบโฮสต์เอง

GitHub Actions runner แบบโฮสต์เองเป็นโปรแกรมที่คุณติดตั้งบน VPS ของคุณเอง โปรแกรมนี้ขอรับงานจาก GitHub แล้วเรียกใช้งานบนฮาร์ดแวร์ของคุณ คุณลงทะเบียน runner กับ repository หนึ่งรายการ ติดตั้งเป็นบริการ systemd และ runner จะกลับมาทำงานหลังจากรีบูตทุกครั้ง GitHub เป็นผู้จัดตารางงาน เซิร์ฟเวอร์ของคุณเป็นผู้ประมวลผล

CI (continuous integration) บนเครื่องที่คุณเป็นเจ้าของมีประโยชน์ด้วยเหตุผล 2 ประการ นาทีการทำงานสำหรับ build จะไม่ถูกคิดตามการใช้งาน และงานสามารถเข้าถึงทรัพยากรที่มีเฉพาะในเครื่องของคุณได้ เช่น build cache ที่เตรียมไว้แล้วหรือ private network ความเสี่ยงอยู่ที่ความปลอดภัย runner จะเรียกใช้งานทุกอย่างตามที่ระบุในไฟล์ workflow โดยใช้สิทธิ์ของผู้ใช้ที่คุณกำหนด ดังนั้นไฟล์ workflow จึงเป็นการเรียกใช้โค้ดจากระยะไกลโดยการออกแบบ สำหรับ private repository เรื่องนี้ไม่มีปัญหา เพราะเฉพาะบุคคลที่คุณไว้วางใจเท่านั้นที่สามารถเพิ่มไฟล์ดังกล่าวได้ สำหรับ public repository เรื่องนี้เป็นความเสี่ยงจริง และหัวข้อเกี่ยวกับ fork pull requests จะอธิบายกลไกนี้

เนื้อหาทั้งหมดต่อไปนี้ใช้ Ubuntu 24.04 กับ runner version 2.336.0 ซึ่งเป็น release ปัจจุบัน ณ July 2026

สิ่งที่ต้องเตรียมก่อนเริ่ม

เริ่มจาก VPS ที่มีบัญชีผู้ดูแลระบบทั่วไปและสิทธิ์ sudo ซึ่งเป็นสถานะที่ได้หลังทำตาม ขั้นตอนสิบนาทีแรกบน VPS ใหม่ คุณไม่จำเป็นต้องเปิดพอร์ตขาเข้า runner จะเปิดการเชื่อมต่อ HTTPS (hypertext transfer protocol secure) ขาออกไปยัง GitHub และคงการเชื่อมต่อนี้ไว้ระหว่างรอรับงาน ดังนั้น GitHub จะไม่เชื่อมต่อเข้ามายังเซิร์ฟเวอร์ของคุณ ไฟร์วอลล์สามารถปิดกั้นการเชื่อมต่อจากภายนอกทั้งหมดได้ และงานยังคงเข้ามาได้

คุณต้องมีสิทธิ์ผู้ดูแลระบบของ repository ด้วย เนื่องจากโทเค็นสำหรับลงทะเบียนจะแสดงอยู่ในการตั้งค่า repository

สร้างผู้ใช้เฉพาะสำหรับ runner

อย่าเรียกใช้ runner ในฐานะ root หรือผู้ดูแลระบบของคุณเอง งานทุกงานจะสืบทอดสิทธิ์ของผู้ใช้ runner ดังนั้น workflow ที่เรียกใช้ sudo จะทำงานสำเร็จ หากผู้ใช้ runner สามารถใช้ sudo ได้ สร้างผู้ใช้ที่ไม่มีสิทธิ์พิเศษ โดยให้ผู้ใช้นี้เป็นเจ้าของเฉพาะ home directory ของตนเองเท่านั้น บัญชีผู้ใช้ที่มีสิทธิ์น้อยที่สุดบน VPS อธิบายรูปแบบทั่วไป ส่วนต่อไปนี้เป็นการกำหนดค่าที่ใช้ในกรณีนี้

sudo useradd -m -s /bin/bash gharunner
sudo passwd -l gharunner
sudo chmod 750 /home/gharunner
sudo install -d -m 700 -o gharunner -g gharunner /home/gharunner/actions-runner

passwd -l จะล็อก password เพื่อไม่ให้ผู้ใดเข้าสู่ระบบในฐานะ gharunner ด้วย password ดังกล่าว การกำหนดโหมด 700 ให้กับ runner directory มีความสำคัญ เนื่องจาก runner จะจัดเก็บข้อมูลรับรองไว้ที่นั่นในรูปแบบข้อความธรรมดา และ checkout อาจมี source code ส่วนตัวอยู่

ตรวจสอบคุณสมบัติทั้งสองรายการก่อนดำเนินการต่อ:

sudo passwd -S gharunner
sudo -l -U gharunner

passwd -S จะแสดงบรรทัดที่ขึ้นต้นด้วย gharunner L โดย L หมายความว่า password ถูกล็อกไว้ sudo -l -U gharunner ควรแสดงผลเป็น is not allowed to run sudo หากแสดงรายการคำสั่งที่อนุญาตแทน แสดงว่าบัญชีนี้อยู่ใน sudo group และการแยกสิทธิ์ที่เพิ่งตั้งค่าไว้จะไม่ทำงานแล้ว

ดาวน์โหลด runner และตรวจสอบ tarball

ตั้งแต่ขั้นตอนนี้ ให้ดำเนินการในฐานะผู้ใช้ runner

sudo -iu gharunner
cd ~/actions-runner
RUNNER_VERSION=2.336.0
curl -fL -o actions-runner-linux-x64-${RUNNER_VERSION}.tar.gz \
  "https://github.com/actions/runner/releases/download/v${RUNNER_VERSION}/actions-runner-linux-x64-${RUNNER_VERSION}.tar.gz"

เรียกใช้ uname -m ก่อน หากไม่แน่ใจเกี่ยวกับสถาปัตยกรรม x86_64 ใช้ไฟล์ linux-x64 ด้านบน ส่วน aarch64 ใช้ actions-runner-linux-arm64-${RUNNER_VERSION}.tar.gz

ตรวจสอบไฟล์ที่ดาวน์โหลดมา ค่า SHA256 (secure hash algorithm, 256 bit) ด้านล่างใช้สำหรับ tarball รุ่น 2.336.0 x64 GitHub จะแสดงค่าสำหรับรุ่นปัจจุบันในหน้า release และหน้าต่าง New self-hosted runner ค่านี้จะเปลี่ยนทุกครั้งที่มีรุ่นใหม่ ดังนั้นให้คัดลอกจากหน้านั้นเมื่อติดตั้งรุ่นอื่น

echo "04cf0be1aff4c3ec3554466c39124ca250e3effd8873bb7e8d68535aa9505d5d  actions-runner-linux-x64-2.336.0.tar.gz" | sha256sum -c

การดาวน์โหลดที่ถูกต้องจะแสดง 1 บรรทัด:

actions-runner-linux-x64-2.336.0.tar.gz: OK

ไฟล์ที่ถูกตัดให้สั้นหรือถูกแก้ไขจะแสดงข้อผิดพลาดและคำเตือน:

actions-runner-linux-x64-2.336.0.tar.gz: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

อย่าข้ามการตรวจสอบแล้วปล่อยให้ tar ตรวจพบปัญหาแทน ไฟล์ archive ที่เขียนไม่สมบูรณ์จะล้มเหลวด้วย gzip: stdin: unexpected end of file และ tar: Unexpected EOF in archive ซึ่งแสดงว่าไฟล์เสียหาย แต่ไม่ระบุว่าไฟล์ถูกตัดให้สั้นหรือถูกแทนที่

tar xzf ./actions-runner-linux-x64-2.336.0.tar.gz
ls

tarball มีอะไรบ้าง และไม่มีอะไรบ้าง

หลังจากแตกไฟล์แล้ว ไดเรกทอรีจะมี config.sh, run.sh, env.sh, safe_sleep.sh, bin/ และ externals/ โดย bin/ จะมีไบนารีของ runner และ bin/installdependencies.sh ส่วน externals/ จะมี Node runtime ที่รวมมาให้ ซึ่งใช้รัน action ของ JavaScript

ขณะนี้ยังไม่มี svc.sh เอกสารของ GitHub อธิบายว่าไฟล์นี้เป็นสคริปต์ “ที่สร้างขึ้นหลังจากเพิ่ม runner สำเร็จ” เนื่องจากไฟล์นี้สร้างจากเทมเพลต โดยฝังชื่อ repository และชื่อ runner ของคุณไว้ในชื่อ service ดังนั้น sudo ./svc.sh install ก่อน ./config.sh จะล้มเหลวด้วย sudo: ./svc.sh: command not found ให้ลงทะเบียนก่อน แล้วจึงติดตั้ง service

ติดตั้ง dependencies ของ runner

runner เป็นแอปพลิเคชัน .NET จึงต้องใช้ shared libraries บางรายการ ให้คง shell ของผู้ใช้ runner ไว้ และติดตั้ง libraries เหล่านี้ด้วย sudo เนื่องจาก script จะเขียนลงในฐานข้อมูลแพ็กเกจของระบบ

exit
cd /home/gharunner/actions-runner
sudo ./bin/installdependencies.sh

บน Ubuntu 24.04 คำสั่งนี้จะติดตั้ง libkrb5-3, zlib1g, liblttng-ust1t64, libssl3t64 และ libicu74 โดย script จะลองใช้ชื่อเวอร์ชันหลายรูปแบบสำหรับแต่ละ library และเลือกชื่อที่ release ของคุณมีอยู่ จึงใช้ script เดียวกันได้ทั้งบน Ubuntu รุ่นเก่าและ Debian

หากข้ามขั้นตอนนี้ ./config.sh จะหยุดก่อนเริ่มทำงาน:

Dependencies is missing for Dotnet Core 6.0
Execute sudo ./bin/installdependencies.sh to install any missing Dotnet Core 6.0 dependencies.

กรณีไม่มี libicu จะแสดงคำแนะนำเดียวกัน แต่ใช้บรรทัดแรกต่างกัน คือ Libicu's dependencies is missing for Dotnet Core 6.0 ทั้งสองกรณีมีสาเหตุเดียวกัน: config.sh จะเรียกใช้ ldd กับ libraries ที่รวมมาให้ก่อนเริ่มทำงาน ดังนั้นหาก link ใดแก้ไขไม่ได้ script จะหยุดทำงาน แทนที่จะเกิด crash ที่ทำให้สับสนในภายหลัง

ลงทะเบียน runner กับ repository

รับ token จาก repository เปิด Settings จากนั้นเลือก Actions แล้วเลือก Runners และ New self-hosted runner หน้านี้จะแสดง registration token ที่ขึ้นต้นด้วย A token นี้จะหมดอายุหลังสร้าง 1 ชั่วโมง ดังนั้นให้สร้างเมื่อพร้อมนำไปวางแล้ว

ลงทะเบียนในฐานะผู้ใช้ที่เรียกใช้ runner config.sh ไม่อนุญาตให้ทำงานภายใต้ sudo

sudo -iu gharunner
cd ~/actions-runner
./config.sh --url https://github.com/YOUR-USER/YOUR-REPO \
  --token PASTE_REGISTRATION_TOKEN_HERE \
  --name vps-runner-1 \
  --labels vps \
  --work _work \
  --unattended \
  --replace

คำอธิบาย flag เหล่านี้ --name คือชื่อที่ runner แสดงใน repository ดังนั้นให้เลือกชื่อที่ยังจำได้ในอีก 6 เดือน --labels เพิ่ม label ที่กำหนดเอง ส่วน runner จะมี self-hosted, Linux และ X64 อยู่แล้วโดยอัตโนมัติ --work ระบุชื่อไดเรกทอรีที่เก็บ checkout ภายในไดเรกทอรีของ runner --unattended ใช้ค่าเริ่มต้นตอบ interactive prompt ซึ่งเหมาะเมื่อคำสั่งนี้อยู่ในสคริปต์ --replace ใช้ registration เดิมที่มีชื่อเดียวกันแทนการหยุดทำงาน ซึ่งเหมาะเมื่อสร้าง server ใหม่

การทำงานที่สำเร็จจะจบด้วยบรรทัดเหล่านี้:

√ Runner successfully added
√ Runner connection is good
√ Settings Saved.

ขณะนี้ registration อยู่ในไดเรกทอรีของ runner ในชื่อ .runner, .credentials และ .credentials_rsaparams สองรายการสุดท้ายใช้ระบุ runner นี้กับ GitHub ดังนั้นผู้ที่อ่านไฟล์เหล่านี้ได้สามารถปลอมตัวเป็น runner นี้ได้ นี่คือเหตุผลที่ไดเรกทอรีมีโหมด 700 และผู้ใช้ไม่มีสิทธิ์ใช้ sudo

ติดตั้ง runner เป็นบริการ systemd

การเรียกใช้ ./run.sh ในเทอร์มินัลเหมาะสำหรับการทดสอบครั้งเดียว แต่โปรเซสจะหยุดเมื่อเซสชัน SSH สิ้นสุดลง ให้ติดตั้งบริการเพื่อให้ runner เริ่มทำงานเมื่อระบบบูต บริการและตัวจับเวลาของ systemd บน VPS อธิบายไฟล์ unit โดยละเอียด ส่วน svc.sh จะสร้างไฟล์ดังกล่าวให้คุณ

exit
cd /home/gharunner/actions-runner
sudo ./svc.sh install gharunner
sudo ./svc.sh start
sudo ./svc.sh status

svc.sh ต้องใช้สิทธิ์ root เนื่องจากสคริปต์จะเขียน unit ลงใน /etc/systemd/system และเปิดใช้งาน unit นั้น อาร์กิวเมนต์หลัง install คือผู้ใช้ที่บริการจะทำงานด้วย ให้ระบุ gharunner อย่างชัดเจน หากไม่ระบุอาร์กิวเมนต์ สคริปต์จะใช้ค่าเริ่มต้นเป็น $SUDO_USER ซึ่งเป็นบัญชีผู้ดูแลระบบของคุณ จากนั้นทุกงานจะทำงานด้วยผู้ใช้ที่สามารถใช้ sudo ได้

ชื่อ unit ตั้งตาม repository และ runner ในรูปแบบ actions.runner.YOUR-USER-YOUR-REPO.vps-runner-1.service คุณไม่จำเป็นต้องพิมพ์ชื่อดังกล่าวเอง:

systemctl list-units 'actions.runner.*'
sudo journalctl -u 'actions.runner.*' -n 20 --no-pager

runner ที่ทำงานปกติจะบันทึก √ Connected to GitHub จากนั้นบันทึกอีกบรรทัดที่ลงท้ายด้วย Listening for Jobs และหน้า Runners ของ repository จะแสดงสถานะเป็น Idle หาก runner แสดงสถานะเป็น Offline แสดงว่า runner ไม่ได้ทำงานหรือไม่สามารถเชื่อมต่อ GitHub ผ่านพอร์ต 443 ได้

ส่งงานไปยัง runner

runs-on ใช้เลือก runner ตาม label ขอ self-hosted พร้อม label ของคุณเอง เพื่อป้องกันไม่ให้งานไปทำงานบน runner ที่ไม่ได้ตั้งใจ

name: build
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: [self-hosted, linux, vps]
    steps:
      - uses: actions/checkout@v5
      - run: uname -a

หากงานค้างอยู่ที่ Waiting for a runner to pick up this job แสดงว่า label ไม่ตรงกัน label ทุกตัวใน runs-on ต้องมีอยู่บน runner หากมีคำเกินมาเพียงหนึ่งคำ งานจะยังคงอยู่ในคิวโดยไม่มีข้อผิดพลาดปรากฏที่ใด ตรวจสอบรายการนี้เทียบกับ label ที่แสดงถัดจาก runner ในการตั้งค่า repository

เหตุใด self-hosted runners และ public repositories จึงไม่ควรใช้ร่วมกัน

นี่คือส่วนที่หลายคนมักข้ามไป คำแนะนำของ GitHub ระบุไว้อย่างชัดเจนว่า self-hosted runners "ควรแทบไม่ใช้กับ public repositories" และ "ไม่มีการรับประกันว่าจะทำงานใน virtual machines ที่สะอาดและใช้ชั่วคราว อีกทั้งอาจถูกโค้ดที่ไม่น่าเชื่อถือใน workflow เจาะระบบและคงการเข้าถึงไว้ได้"

กลไกนี้เข้าใจได้ง่าย pull request จาก fork จะนำสำเนาของไฟล์ workflow มาด้วย หาก public repository ของคุณเรียกใช้ workflow สำหรับ pull request บน runner ของคุณ ทุกคนที่ fork repository ได้ก็สามารถเสนอ workflow ที่เรียกใช้คำสั่งของตนบน VPS ของคุณได้ พวกเขาไม่จำเป็นต้องมีสิทธิ์เขียน เพราะสิ่งที่พวกเขาเสนอคือสิ่งที่จะถูกเรียกใช้

การตั้งค่าให้อนุมัติช่วยลดความเสี่ยง แต่ไม่สามารถแก้ปัญหาได้ นโยบายเริ่มต้นของ public repository จะขอให้ maintainer อนุมัติ workflow ของ fork จากผู้มีส่วนร่วมครั้งแรก หลังจากคุณอนุมัติบุคคลนั้นแล้ว pull request ถัดไปของบุคคลดังกล่าวจะทำงานโดยไม่ถามใหม่ ดังนั้นด่านป้องกันจึงขึ้นอยู่กับการที่มนุษย์อ่าน diff ทุกครั้ง และ payload ที่ซ่อนอยู่ลึกลงไป 3 ระดับใน build script อาจถูกมองข้ามได้ง่าย

pull request จาก fork จะไม่ได้รับ secrets ของคุณ และ GITHUB_TOKEN จะเป็นแบบอ่านอย่างเดียว ซึ่งจำกัดความเสียหายภายใน GitHub แต่ไม่ช่วยป้องกัน server ของคุณ ผู้โจมตีจะมี shell ในชื่อ gharunner จึงสามารถอ่านไฟล์ทุกไฟล์ที่ผู้ใช้นั้นอ่านได้ เข้าถึงทุกสิ่งที่ VPS เข้าถึงได้บน private network และทิ้งสิ่งที่ทำงานค้างไว้ใน ~/.bashrc หรือใน user systemd unit ที่จะทำงานระหว่าง job ถัดไป

การลงทะเบียนด้วย --ephemeral ทำให้ runner ยอมรับ job 1 รายการแล้ว deregister ดังนั้น job หนึ่งจะไม่สามารถอ่าน workspace ของ job ถัดไปได้ วิธีนี้ช่วยได้เฉพาะเมื่อมีสิ่งสร้างเครื่องหรือ container ใหม่สำหรับแต่ละ job เพราะ backdoor ที่เขียนลงใน home directory ของ runner user จะยังคงอยู่แม้ลงทะเบียนใหม่

กฎต่อไปนี้สั้นและชัดเจน ใช้ self-hosted runners กับ private repositories หากจำเป็นต้องเชื่อมต่อ runner เข้ากับ public repository อย่าเรียกใช้ pull request จาก fork บน runner นั้น อย่าวางสิ่งอื่นไว้บน server เดียวกัน และให้ถือว่าเครื่องดังกล่าวเป็นเครื่องที่พร้อมทิ้งได้เสมอ

งาน Docker และกลุ่มที่มีสิทธิ์เทียบเท่า root

งานในคอนเทนเนอร์ คอนเทนเนอร์บริการ และขั้นตอนใดก็ตามของ workflow ที่เรียกใช้ docker build ต้องมี Docker daemon ทำงานอยู่บนโฮสต์ runner ติดตั้ง Docker ตามวิธีมาตรฐานตามที่ Docker และ Docker Compose บน VPS อธิบายไว้ จากนั้นเพิ่มผู้ใช้ runner ลงในกลุ่ม docker

ทำความเข้าใจข้อแลกเปลี่ยนก่อนดำเนินการ การเป็นสมาชิกกลุ่ม docker เทียบเท่ากับการมีสิทธิ์ root เนื่องจากคอนเทนเนอร์สามารถ bind mount / และทำงานเป็น root ภายในคอนเทนเนอร์ได้ ดังนั้น workflow ที่เชื่อมต่อกับ Docker socket ได้จึงสามารถอ่านและเขียนไฟล์ทุกไฟล์บน VPS รวมถึง /etc/shadow ได้ด้วย สำหรับ repository ส่วนตัวที่มีผู้ร่วมพัฒนาที่เชื่อถือได้ นี่อาจเป็นข้อแลกเปลี่ยนที่ยอมรับได้ แต่ในกรณีอื่นจะทำให้การใช้ผู้ใช้ที่ไม่มีสิทธิ์พิเศษหมดความหมาย Rootless Docker จะจำกัดการ build คอนเทนเนอร์ให้อยู่ภายใต้สิทธิ์ของผู้ใช้ runner เอง โดยแลกกับ storage driver ที่ทำงานช้าลงและไม่สามารถใช้คอนเทนเนอร์ที่มีสิทธิ์พิเศษได้

การอัปเดตและการนำ runner ออกอย่างถูกต้อง

โดยค่าเริ่มต้น self-hosted runner จะอัปเดตตัวเอง เมื่อพบ release ใหม่ ระบบจะแทนที่ไฟล์ของตัวเองและเริ่ม service ใหม่ ดังนั้นโดยปกติคุณไม่ต้องดำเนินการใด ๆ ./config.sh --disableupdate จะปิดการอัปเดตตัวเองเมื่อคุณต้องการใช้เวอร์ชันที่กำหนดตายตัว หลังจากนั้นคุณต้องอัปเดตเอง โดยเอกสารของ GitHub ระบุไว้อย่างชัดเจนว่า runner ที่กำหนดค่าโดยใช้ --disableupdate ต้องอัปเดตด้วยตนเอง

การอัปเดตด้วยตนเองจะคงการลงทะเบียนไว้ เนื่องจาก .runner และ .credentials ไม่ได้อยู่ใน tarball ให้หยุด service ดาวน์โหลดและตรวจสอบ checksum ของ tarball ใหม่เป็น gharunner จากนั้นแตกไฟล์ทับไดเรกทอรีเดิมด้วย tar xzf แล้วเริ่ม service อีกครั้ง:

cd /home/gharunner/actions-runner
sudo ./svc.sh stop
sudo ./svc.sh start

หากต้องการนำ runner ออก ให้ถอนการติดตั้ง service ก่อน จากนั้นยกเลิกการลงทะเบียน removal token มาจากหน้า Runners เดิม โดยอยู่ใต้ปุ่ม Remove ของ runner นั้น

cd /home/gharunner/actions-runner
sudo ./svc.sh stop
sudo ./svc.sh uninstall
sudo -iu gharunner
cd ~/actions-runner
./config.sh remove --token PASTE_REMOVAL_TOKEN_HERE

การลบไดเรกทอรีโดยไม่ยกเลิกการลงทะเบียนจะทำให้ runner ยังคงแสดงเป็น Offline ใน repository เนื่องจาก GitHub จะทราบว่า runner ถูกนำออกแล้วก็ต่อเมื่อ runner แจ้งสถานะดังกล่าว หรือผู้ดูแลระบบลบรายการนั้นด้วยตนเอง

ความล้มเหลวที่อาจเกิดขึ้น พร้อมข้อความที่คุณจะพบ

Must not run with sudo config.sh จะแสดงข้อความนี้และยุติการทำงานเมื่อเรียกใช้ในฐานะ root การตรวจสอบนี้มีเจตนาเช่นนั้น เนื่องจากไฟล์ใน _work ที่เป็นของ root จะทำให้งานถัดไปทั้งหมดที่ทำงานในฐานะผู้ใช้บริการล้มเหลว เรียกใช้ ./config.sh ในฐานะ gharunner ตัวแปร RUNNER_ALLOW_RUNASROOT จะข้ามการตรวจสอบนี้ แต่การใช้ตัวแปรดังกล่าวจะเพียงเลื่อนปัญหาไปเกิดภายหลัง

sudo: ./svc.sh: command not found คุณอยู่ในไดเรกทอรีที่ถูกต้อง แต่ยังไม่มี svc.sh เนื่องจาก config.sh ยังลงทะเบียนไม่เสร็จ ลงทะเบียน runner แล้วจึงติดตั้ง service

Http response code: NotFound from 'POST https://api.github.com/actions/runner-registration' token ไม่ใช่ registration token ที่ถูกต้อง token นี้อาจหมดอายุ เนื่องจากมีอายุเพียง 1 ชั่วโมง หรืออาจวาง personal access token แทน registration token จากหน้า Runners ให้สร้าง token ใหม่ แล้ววางอีกครั้ง

Dependencies is missing for Dotnet Core 6.0 เรียกใช้ sudo ./bin/installdependencies.sh จากไดเรกทอรีของ runner ในฐานะ root แล้วลงทะเบียนอีกครั้ง

Runner ออฟไลน์หลังจากรีบูต เรียกใช้ systemctl is-enabled 'actions.runner.*' หากไม่มีรายการใดแสดง แสดงว่ายังไม่เคยเรียกใช้ ./svc.sh install ดังนั้น runner จึงมีอยู่เฉพาะภายในเซสชันเทอร์มินัลของคุณเท่านั้น หาก unit เปิดใช้งานอยู่และ runner ยังคงออฟไลน์ ให้อ่าน journalctl -u 'actions.runner.*' และตรวจสอบการเชื่อมต่อ HTTPS ขาออก

ดิสก์เต็ม checkout, build cache และ Docker image จะสะสมอยู่ภายใต้ _work และใน home directory ของผู้ใช้ runner โดยไม่มีการลบข้อมูลเก่าให้โดยอัตโนมัติ ตรวจสอบ du -sh /home/gharunner/actions-runner/_work และเพิ่มงานล้างข้อมูลตามกำหนดเวลา ก่อนที่ดิสก์จะเต็มเอง

FAQ

เหตุใด sudo ./svc.sh install จึงแสดงว่าไม่พบคำสั่ง

เนื่องจาก svc.sh ไม่มีอยู่ในไฟล์ tarball ของ runner ระบบจะสร้างไฟล์นี้ในไดเรกทอรีของ runner เมื่อ ./config.sh ลงทะเบียนเสร็จ โดยใช้ชื่อ repository และชื่อ runner ของคุณเพื่อสร้างชื่อ service เรียกใช้ ./config.sh ในฐานะผู้ใช้ runner ก่อน จากนั้น sudo ./svc.sh install gharunner จะพบสคริปต์และเขียน unit ชื่อ actions.runner.OWNER-REPO.RUNNER-NAME.service ลงใน /etc/systemd/system

ต้องเปิดพอร์ตไฟร์วอลล์สำหรับ self-hosted runner หรือไม่

ไม่ต้อง runner จะเปิดการเชื่อมต่อ HTTPS ขาออกไปยัง GitHub และคงการเชื่อมต่อนั้นไว้ขณะรอ job ดังนั้น GitHub จึงไม่เป็นฝ่ายเริ่มการเชื่อมต่อไปยัง VPS ของคุณ อนุญาตการเชื่อมต่อขาออกที่พอร์ต 443 และคงกฎการเชื่อมต่อขาเข้าไว้ไม่ให้เปิด หาก runner แสดงสถานะ Offline ขณะที่ service กำลังทำงาน ให้ตรวจสอบการกรองการเชื่อมต่อขาออกและ DNS แทนการตรวจสอบกฎการเชื่อมต่อขาเข้า

สามารถใช้ self-hosted runner กับ public repository ได้หรือไม่

ทำได้ แต่ GitHub ไม่แนะนำ pull request จาก fork จะมีไฟล์ workflow ของตนเอง ดังนั้นทุกคนที่สามารถ fork repository ของคุณอาจเสนอคำสั่งให้ทำงานบนเครื่องของคุณได้ ข้อความแจ้งอนุมัติครอบคลุมเฉพาะการเรียกใช้ครั้งแรกของ contributor เท่านั้น หากคุณเชื่อมต่อ runner กับ public repository ให้ปิดใช้ workflow ของ pull request จาก fork บน runner นั้น อย่าเก็บสิ่งอื่นไว้บน server ดังกล่าว และสร้างเครื่องใหม่ตามกำหนดเวลา

เหตุใดการลงทะเบียนจึงล้มเหลวด้วย Http response code: NotFound

การเรียกใช้สำหรับลงทะเบียนจะตอบกลับ NotFound เมื่อ credential ไม่ถูกต้อง ไม่ใช่เฉพาะเมื่อ URL ไม่ถูกต้องเท่านั้น จึงทำให้ข้อความนี้ทำให้เข้าใจผิด registration token จะหมดอายุหนึ่งชั่วโมงหลังจากแสดง และไม่สามารถใช้ personal access token สำหรับการเรียกใช้นี้ได้ เปิด Settings, Actions, Runners, New self-hosted runner อีกครั้ง คัดลอก token ใหม่ และยืนยันว่าค่า --url ชี้ไปยัง repository ที่คุณมีสิทธิ์ระดับ admin