Ubuntu 24.04-ல் GitHub Actions runner அமைப்பது எப்படி?

Self-hosted GitHub Actions runner-ன் செயல்பாடு

Self-hosted GitHub Actions runner என்பது உங்கள் சொந்த VPS-ல் நீங்கள் நிறுவும் ஒரு மென்பொருள் ஆகும். இது GitHub-லிருந்து பணிகளைப் (jobs) பெற்று, உங்கள் வன்பொருளில் அவற்றை இயக்கும். இதை ஒரு repository-உடன் இணைத்து, systemd service-ஆக நிறுவினால், ஒவ்வொரு reboot-க்குப் பிறகும் இது தானாகவே இயங்கத் தொடங்கும். GitHub பணிகளைத் திட்டமிடும்; உங்கள் server அந்தப் பணிகளைச் செய்து முடிக்கும்.

உங்களுக்குச் சொந்தமான server-ல் CI (continuous integration) அமைப்பது இரண்டு காரணங்களுக்காகப் பயனுள்ளது. முதலாவதாக, build minutes-க்கான கட்டணம் வசூலிக்கப்படாது. இரண்டாவதாக, உங்கள் machine-ல் மட்டுமே உள்ள warm build cache அல்லது private network போன்ற வளங்களை ஒரு பணியால் அணுக முடியும். இதற்கான விலை பாதுகாப்புதான். Workflow file-ல் என்ன கட்டளைகள் உள்ளனவோ, அவற்றை நீங்கள் வழங்கிய user-ன் அனுமதியுடன் இந்த runner இயக்கும். எனவே, workflow file என்பது வடிவமைப்பிலேயே remote code execution-ஐ அனுமதிப்பதாகும். Private repository-ல் இது பாதுகாப்பானது, ஏனெனில் நீங்கள் நம்பும் நபர்கள் மட்டுமே அதில் மாற்றங்களைச் செய்ய முடியும். Public repository-ல் இது ஒரு பெரிய ஆபத்து; fork pull requests குறித்த பகுதியில் இதற்கான வழிமுறை விளக்கப்பட்டுள்ளது.

கீழே உள்ள அனைத்து வழிமுறைகளும் Ubuntu 24.04 மற்றும் runner version 2.336.0-க்கு உரியவை. இது ஜூலை 2026 நிலவரப்படி தற்போதைய release ஆகும்.

தொடங்குவதற்கு முன் உங்களுக்குத் தேவையானவை

ஒரு சாதாரண admin account மற்றும் sudo வசதி கொண்ட VPS-ல் இருந்து தொடங்கவும். இது புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்ற பகுதியில் நீங்கள் அடைந்த நிலையாகும். நீங்கள் எந்தவொரு inbound port-ஐயும் திறக்க வேண்டிய அவசியமில்லை. இந்த runner, GitHub-க்கு ஒரு outbound HTTPS (hypertext transfer protocol secure) இணைப்பை ஏற்படுத்தி, வேலைக்காகக் காத்திருக்கும்போது அதைத் திறந்து வைத்திருக்கும். எனவே, GitHub உங்கள் server-உடன் நேரடியாக இணையாது. உங்கள் firewall-ஐ உலகிற்குத் திறக்காமலேயே பணிகளைப் பெற்றுக்கொள்ள முடியும்.

உங்களுக்கு repository-ன் மீதான admin உரிமைகளும் தேவை. ஏனெனில், registration token-ஆனது repository settings-ல் காட்டப்படும்.

runner-க்காக ஒரு பிரத்யேக பயனர் கணக்கை உருவாக்குதல்

runner-ஐ root பயனராகவோ அல்லது உங்கள் சொந்த admin பயனராகவோ ஒருபோதும் இயக்க வேண்டாம். ஒவ்வொரு பணியும் runner பயனரின் உரிமைகளைப் பெற்றுக்கொள்ளும். எனவே, sudo-ஐ அழைக்கும் ஒரு workflow, 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 கடவுச்சொல்லை முடக்குகிறது, எனவே யாரும் gharunner-ஐப் பயன்படுத்தி உள்நுழைய முடியாது. runner directory-ன் mode 700-ஆக இருப்பது அவசியம், ஏனெனில் runner தனது நற்சான்றிதழ்களை (credentials) அங்கு plain text-ல் சேமிக்கிறது, மேலும் checkout-ல் தனிப்பட்ட source code இருக்கலாம்.

தொடர்வதற்கு முன் இந்த இரண்டு பண்புகளையும் சரிபார்க்கவும்:

sudo passwd -S gharunner
sudo -l -U gharunner

passwd -S என்பது gharunner L-ல் தொடங்கும் ஒரு வரியை அச்சிடும், இதில் L என்பது கடவுச்சொல் முடக்கப்பட்டுள்ளது என்பதைக் குறிக்கிறது. sudo -l -U gharunner என்பது is not allowed to run sudo என்று பதிலளிக்க வேண்டும். அதற்குப் பதிலாக அனுமதிக்கப்பட்ட கட்டளைகளின் பட்டியலை அது அச்சிட்டால், அந்த கணக்கு sudo குழுவில் உள்ளது என்று அர்த்தம்; நீங்கள் உருவாக்கிய பாதுகாப்பு தனிமைப்படுத்தல் (isolation) நீங்கிவிட்டது.

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"

உங்கள் கணினியின் architecture குறித்து உறுதியாகத் தெரியவில்லை எனில், முதலில் uname -m கட்டளையை இயக்கவும். x86_64 கட்டளை மேலே உள்ள linux-x64 கோப்பைப் பயன்படுத்தும். aarch64 கட்டளை actions-runner-linux-arm64-${RUNNER_VERSION}.tar.gz-ஐப் பயன்படுத்தும்.

இப்போது நீங்கள் தரவிறக்கம் செய்த கோப்பைச் சரிபார்க்கவும். கீழே உள்ள SHA256 (secure hash algorithm, 256 bit) மதிப்பு 2.336.0 x64 tarball-க்கானது. தற்போதைய release-க்கான மதிப்பை GitHub அதன் release பக்கத்திலும், New self-hosted runner திரையிலும் குறிப்பிடுகிறது. ஒவ்வொரு பதிப்பிற்கும் இது மாறுபடும் என்பதால், வேறு பதிப்பை நிறுவும் போது அங்கிருந்து நகலெடுத்துக் கொள்ளவும்.

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

சரியான தரவிறக்கம் ஒரு வரியை வெளியீடாகக் காட்டும்:

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-ல் உள்ளவை மற்றும் இல்லாதவை

கோப்புகளைப் பிரித்தெடுத்த பிறகு, அந்த directory-ல் config.sh, run.sh, env.sh, safe_sleep.sh, bin/ மற்றும் externals/ ஆகியவை இருக்கும். bin/-ல் runner binaries மற்றும் bin/installdependencies.sh இருக்கும். externals/-ல் JavaScript actions இயங்குவதற்கான bundled Node runtime இருக்கும்.

இதில் இன்னும் svc.sh இல்லை. GitHub ஆவணங்களின்படி, "runner-ஐ வெற்றிகரமாகச் சேர்த்த பிறகு உருவாக்கப்படும்" script இதுவாகும். ஏனெனில், இது உங்கள் repository மற்றும் runner பெயரை service பெயராகக் கொண்டு ஒரு template-லிருந்து உருவாக்கப்படுகிறது. எனவே, ./config.sh-க்கு முன்னால் sudo ./svc.sh install-ஐ இயக்கினால் sudo: ./svc.sh: command not found பிழை ஏற்படும். முதலில் register செய்யவும், அதன் பிறகு service-ஐ install செய்யவும்.

Runner dependencies-ஐ நிறுவுதல்

Runner என்பது ஒரு .NET application ஆகும், எனவே இதற்குச் சில shared libraries தேவைப்படுகின்றன. Runner user-ன் shell-லிருந்து வெளியேறி, sudo பயன்படுத்தி அவற்றை நிறுவவும். ஏனெனில், இந்த script system package database-ல் மாற்றங்களைச் செய்கிறது.

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

Ubuntu 24.04-ல் இது libkrb5-3, zlib1g, liblttng-ust1t64, libssl3t64 மற்றும் libicu74 ஆகியவற்றைத் தரவிறக்கம் செய்கிறது. இந்த script ஒவ்வொரு library-க்கும் பல version பெயர்களை முயற்சி செய்து, உங்கள் 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 தொடங்குவதற்கு முன்பே bundled libraries-க்கு எதிராக ldd-ஐ இயக்குகிறது. எனவே, unresolved link ஏதேனும் இருந்தால், குழப்பமான crash ஏற்படுவதற்குப் பதிலாக, script அங்கேயே நின்றுவிடும்.

உங்கள் களஞ்சியத்துடன் (repository) runner-ஐ பதிவு செய்தல்

களஞ்சியத்திலிருந்து ஒரு token-ஐப் பெறவும். Settings, பின்னர் Actions, பிறகு Runners, இறுதியாக New self-hosted runner என்பதைத் திறக்கவும். அந்தப் பக்கம் A-ல் தொடங்கும் ஒரு பதிவு token-ஐக் காட்டும். இது உருவாக்கப்பட்ட ஒரு மணி நேரத்திற்குப் பிறகு காலாவதியாகிவிடும், எனவே நீங்கள் அதை ஒட்டுவதற்கு (paste) தயாராக இருக்கும்போது அதை உருவாக்கவும்.

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

அந்தக் கொடிகள் (flags) என்ன செய்கின்றன என்பது இங்கே: --name என்பது களஞ்சியத்தில் runner எவ்வாறு காட்டப்படும் என்பதைக் குறிக்கிறது, எனவே ஆறு மாதங்களுக்குப் பிறகும் உங்களுக்கு அடையாளம் காணக்கூடிய ஒரு பெயரைத் தேர்வு செய்யவும். --labels உங்கள் சொந்த labels-ஐச் சேர்க்கிறது; runner ஏற்கனவே கேட்காமலேயே self-hosted, Linux மற்றும் X64 ஆகியவற்றைக் கொண்டிருக்கும். --work என்பது runner கோப்பகத்திற்குள், checkout-கள் சேமிக்கப்படும் கோப்பகத்தின் பெயரைக் குறிக்கிறது. --unattended ஊடாடும் வினவல்களுக்கு (interactive prompts) அவற்றின் இயல்புநிலை மதிப்புகளை அளிக்கிறது, இது ஒரு script-ல் கட்டளையை இயக்கும்போது உங்களுக்குத் தேவையானதாகும். --replace ஒரே பெயரில் ஏற்கனவே உள்ள பதிவை நீக்கிவிட்டு புதியதை எடுத்துக்கொள்ளும், இது நீங்கள் server-ஐ மீண்டும் உருவாக்கும்போது பயனுள்ளதாக இருக்கும்.

வெற்றிகரமான இயக்கம் இந்த வரிகளுடன் முடிவடையும்:

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

பதிவு இப்போது runner கோப்பகத்தில் .runner, .credentials மற்றும் .credentials_rsaparams ஆக இருக்கும். கடைசி இரண்டு கோப்புகளும் இந்த runner-ஐ GitHub-க்கு அடையாளம் காட்டுகின்றன, எனவே அவற்றை வாசிக்கக்கூடிய எவரும் இந்த runner-ஆக ஆள்மாறாட்டம் செய்ய முடியும். இதனால்தான் கோப்பகத்தின் அனுமதி (mode) 700 ஆக உள்ளது மற்றும் பயனருக்கு sudo அதிகாரம் வழங்கப்படுவதில்லை.

runner-ஐ systemd service-ஆக நிறுவுதல்

./run.sh-ஐ terminal-ல் இயக்குவது ஒரு சோதனைக்கு மட்டுமே உதவும், ஆனால் உங்கள் SSH session முடிந்தவுடன் அது நின்றுவிடும். எனவே, கணினி தொடங்கும்போதே (boot) runner இயங்குவதற்கு அதை ஒரு service-ஆக நிறுவவும். VPS-ல் systemd services மற்றும் timers என்பது unit files பற்றிய விளக்கத்தை அளிக்கிறது. இங்கே svc.sh உங்களுக்காக ஒரு unit file-ஐ உருவாக்குகிறது.

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

svc.sh-க்கு root அதிகாரம் தேவை, ஏனெனில் இது /etc/systemd/system-ல் ஒரு unit file-ஐ எழுதி அதை enable செய்கிறது. install-க்கு அடுத்துள்ள argument, அந்த service எந்த user-ஆக இயங்க வேண்டும் என்பதைக் குறிக்கிறது. gharunner-ஐ தெளிவாகக் குறிப்பிடவும். எந்த argument-ம் வழங்கப்படவில்லை எனில், இந்த script தானாகவே $SUDO_USER-ஐ எடுத்துக்கொள்ளும், இது உங்கள் admin account ஆகும். அவ்வாறு நடந்தால், ஒவ்வொரு job-ம் sudo பயன்படுத்தக்கூடிய ஒரு user-ஆக இயங்கும்.

இந்த 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 என்று முடியும் ஒரு வரியை log-ல் காட்டும். மேலும், repository-ன் Runners பக்கத்தில் அது Idle நிலையில் இருப்பதைக் காணலாம். ஒரு runner Offline என்று காட்டினால், அது இயங்கவில்லை அல்லது port 443 வழியாக GitHub-ஐ அணுக முடியவில்லை என்று பொருள்.

Runner-க்கு ஒரு பணியை அனுப்புதல்

runs-on லேபிளைப் பயன்படுத்தி ஒரு runner-ஐத் தேர்ந்தெடுக்கிறது. self-hosted மற்றும் உங்கள் சொந்த லேபிளைக் குறிப்பிடவும்; அப்போதுதான் நீங்கள் விரும்பாத ஒரு 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-ல் காத்திருந்தால், லேபிள்கள் பொருந்தவில்லை என்று அர்த்தம். runs-on-ல் உள்ள ஒவ்வொரு லேபிளும் runner-ல் இருக்க வேண்டும். எனவே, ஒரு கூடுதல் சொல் இருந்தாலும், எந்தப் பிழையும் காட்டப்படாமல் பணி வரிசையிலேயே (queued) இருக்கும். Repository settings-ல் runner-க்கு அருகில் காட்டப்பட்டுள்ள லேபிள்களுடன் உங்கள் பட்டியலை ஒப்பிட்டுப் பார்க்கவும்.

சுய-வழங்கப்பட்ட (self-hosted) runners மற்றும் பொது களஞ்சியங்கள் (public repositories) ஏன் ஒன்றாக இருக்கக்கூடாது

இதுவே பலரும் தவிர்க்கும் பகுதி. GitHub-ன் வழிகாட்டுதல் மிகவும் தெளிவாக உள்ளது: சுய-வழங்கப்பட்ட runners-ஐ "பொது களஞ்சியங்களுக்கு ஒருபோதும் பயன்படுத்தக்கூடாது", மேலும் அவை "தற்காலிகமான, சுத்தமான virtual machines-ல் இயங்குவதற்கான உத்தரவாதத்தைக் கொண்டிருக்கவில்லை, மேலும் workflow-ல் உள்ள நம்பகத்தன்மையற்ற குறியீடுகளால் (untrusted code) நிரந்தரமாக சமரசம் (compromise) செய்யப்படலாம்".

இதன் செயல்முறை எளிதானது. ஒரு fork-லிருந்து வரும் pull request, அதன் சொந்த workflow கோப்பின் நகலை எடுத்து வருகிறது. உங்கள் பொது களஞ்சியம் pull request workflow-களை உங்கள் runner-ல் இயக்கினால், அந்த களஞ்சியத்தை fork செய்யக்கூடிய எவரும், தங்கள் கட்டளைகளை உங்கள் VPS-ல் இயக்கும் ஒரு workflow-ஐ முன்மொழிய முடியும். அவர்களுக்கு write access தேவையில்லை, ஏனெனில் அவர்கள் முன்மொழியும் விஷயமே இயங்கக்கூடிய ஒன்றாக இருக்கிறது.

அனுமதி அமைப்புகள் (approval settings) இதைச் சரிசெய்யாமல், சற்று எளிதாக்குகின்றன. ஒரு பொது களஞ்சியத்திற்கான இயல்புநிலை கொள்கை, முதல்முறை பங்களிப்பவரின் fork workflow-க்கு ஒரு பராமரிப்பாளரின் (maintainer) ஒப்புதலைக் கேட்கிறது. நீங்கள் ஒருமுறை அந்த நபருக்கு ஒப்புதல் அளித்த பிறகு, அவர்களின் அடுத்தடுத்த pull requests எந்த புதிய தூண்டுதலும் இன்றி இயங்கும். எனவே, ஒவ்வொரு முறையும் ஒரு மனிதர் diff-ஐப் படித்து சரிபார்க்க வேண்டும்; ஒரு build script-க்குள் மூன்று நிலைகளுக்குக் கீழே மறைத்து வைக்கப்பட்டிருக்கும் payload-ஐக் கண்டறிவது எளிதல்ல.

ஒரு fork pull request உங்கள் secrets-ஐப் பெறுவதில்லை, மேலும் அதன் GITHUB_TOKEN read-only நிலையில் இருக்கும். இது GitHub-க்குள் ஏற்படும் பாதிப்பைக் கட்டுப்படுத்துகிறது. ஆனால், இது உங்கள் server-க்கு எந்தப் பாதுகாப்பையும் வழங்காது. தாக்குதல் நடத்துபவருக்கு gharunner என்ற பயனர் கணக்கில் shell கிடைத்துவிடுகிறது, எனவே அந்தப் பயனர் படிக்கக்கூடிய அனைத்துக் கோப்புகளையும் அவர்களால் படிக்க முடியும், அந்த VPS அதன் private network-ல் எதை அடைய முடியுமோ அதை அவர்களால் அடைய முடியும், மேலும் ~/.bashrc-ல் அல்லது அடுத்த வேலையின் போது இயங்கும் ஒரு பயனர் systemd unit-ல் எதையாவது விட்டுச் செல்ல முடியும்.

--ephemeral மூலம் பதிவு செய்வது, runner ஒரு வேலையை ஏற்றுக்கொண்டு பின் தன்னைத்தானே நீக்கிக்கொள்ளச் செய்கிறது, எனவே ஒரு வேலையால் அடுத்த வேலையின் workspace-ஐப் படிக்க முடியாது. ஒவ்வொரு வேலைக்கும் அந்த இயந்திரத்தையோ அல்லது container-ஐயோ மீண்டும் உருவாக்கினால் மட்டுமே இது உதவும், ஏனெனில் runner பயனரின் home directory-ல் எழுதப்பட்ட ஒரு backdoor, புதிய பதிவுக்குப் பிறகும் நீடிக்கும்.

பின்வரும் விதிகள் சுருக்கமானவை. சுய-வழங்கப்பட்ட runners-ஐ private repositories-க்கு மட்டும் பயன்படுத்தவும். ஒரு பொது களஞ்சியத்துடன் இணைக்க வேண்டிய கட்டாயம் இருந்தால், அதில் fork pull requests-ஐ இயக்க வேண்டாம், அந்த server-ல் வேறு எதையும் வைத்திருக்க வேண்டாம், மேலும் அந்த இயந்திரத்தை எப்போது வேண்டுமானாலும் தூக்கி எறியக்கூடிய ஒன்றாக (disposable) கருதவும்.

Docker பணிகள் மற்றும் root-க்கு இணையான குழு

Container பணிகள், service containers மற்றும் docker build-ஐ அழைக்கும் எந்தவொரு workflow படியும், runner host-ல் Docker daemon-ஐக் கொண்டிருக்க வேண்டும். VPS-ல் Docker மற்றும் Docker Compose பகுதியில் விவரிக்கப்பட்டுள்ள வழக்கமான முறையில் Docker-ஐ நிறுவவும், பின்னர் runner பயனரை docker குழுவில் சேர்க்கவும்.

இதைச் செய்வதற்கு முன் அதன் விளைவுகளைப் புரிந்துகொள்ளவும். docker குழுவில் உறுப்பினராக இருப்பது root-க்கு இணையானது, ஏனெனில் ஒரு container-ஆல் /-ஐ bind mount செய்து, அதற்குள் root-ஆக இயங்க முடியும். எனவே, Docker socket-உடன் தொடர்புகொள்ளக்கூடிய ஒரு workflow, /etc/shadow உட்பட VPS-ல் உள்ள ஒவ்வொரு கோப்பையும் படிக்கவும் எழுதவும் முடியும். நம்பகமான பங்களிப்பாளர்களைக் கொண்ட ஒரு private repository-க்கு இது ஏற்றுக்கொள்ளக்கூடிய ஒன்றாக இருக்கலாம். மற்ற இடங்களில், இது unprivileged பயனரைப் பயன்படுத்துவதன் நோக்கத்தையே நீக்கிவிடும். Rootless Docker, container உருவாக்கங்களை runner பயனரின் சொந்த உரிமைகளுக்குள்ளேயே வைத்திருக்கிறது, ஆனால் இதற்கு storage driver வேகம் குறைவாக இருப்பதும், privileged containers-ஐப் பயன்படுத்த முடியாது என்பதும் விலையாகும்.

புதுப்பித்தல் மற்றும் runner-ஐ முறையாக நீக்குதல்

Self-hosted runner இயல்பாகவே தன்னைத்தானே புதுப்பித்துக்கொள்ளும். புதிய release-ஐக் கண்டறிந்ததும், அது தனது கோப்புகளை மாற்றியமைத்து service-ஐ மறுதொடக்கம் செய்யும்; எனவே, நீங்கள் பொதுவாக எதையும் செய்ய வேண்டியதில்லை. ஒரு குறிப்பிட்ட version-ஐ மட்டும் பயன்படுத்த விரும்பினால், ./config.sh --disableupdate மூலம் இந்த self-update வசதியை முடக்கலாம். அதன் பிறகு, புதுப்பிக்கும் பொறுப்பு உங்களுடையது: --disableupdate மூலம் கட்டமைக்கப்பட்ட runner-ஐ கைமுறையாகத்தான் புதுப்பிக்க வேண்டும் என்று GitHub ஆவணங்கள் தெளிவாகக் கூறுகின்றன.

கைமுறையாகப் புதுப்பிக்கும்போது registration விவரங்கள் அப்படியே இருக்கும், ஏனெனில் .runner மற்றும் .credentials ஆகியவை tarball-ல் இருக்காது. Service-ஐ நிறுத்திவிட்டு, புதிய tarball-ஐத் தரவிறக்கம் செய்து gharunner மூலம் checksum சரிபார்க்கவும். பின் tar xzf கட்டளையைப் பயன்படுத்தி அதே கோப்பகத்தில் (directory) கோப்புகளைப் பிரித்தெடுத்து, service-ஐ மீண்டும் தொடங்கவும்:

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

Runner-ஐ நீக்க, முதலில் service-ஐ uninstall செய்துவிட்டு, பின் deregister செய்யவும். இதற்கான removal token, அதே Runners பக்கத்தில், அந்த runner-க்குரிய Remove பொத்தானின் கீழ் கிடைக்கும்.

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

Deregister செய்யாமல் கோப்பகத்தை மட்டும் நீக்கினால், repository-ல் அந்த runner 'Offline' என்றே காட்டும். ஏனெனில், runner தானாகவே தகவல் தெரிவிக்கும் வரை அல்லது நிர்வாகி கைமுறையாக அந்தப் பதிவை நீக்கும் வரை, அது நீக்கப்பட்டதை GitHub அறியாது.

தோல்விக்கான காரணங்கள் மற்றும் நீங்கள் காணக்கூடிய செய்திகள்

Must not run with sudo. config.sh root பயனராக இயக்கும்போது இந்தச் செய்தியைக் காட்டி வெளியேறும். இந்தச் சரிபார்ப்பு வேண்டுமென்றே செய்யப்படுகிறது, ஏனெனில் _work-ல் உள்ள root-க்குச் சொந்தமான கோப்புகள், service பயனராக இயங்கும் பிற்காலப் பணிகளைப் பாதிக்கும். ./config.sh-ஐ gharunner பயனராக இயக்கவும். RUNNER_ALLOW_RUNASROOT மாறியானது இந்தச் சரிபார்ப்பைத் தவிர்க்கும், ஆனால் அதைப் பயன்படுத்துவது சிக்கலைத் தள்ளிப்போடுமே தவிர தீர்க்காது.

sudo: ./svc.sh: command not found. நீங்கள் சரியான கோப்பகத்தில் (directory) உள்ளீர்கள். svc.sh இன்னும் உருவாக்கப்படவில்லை, ஏனெனில் config.sh பதிவு செய்யும் பணியை முடிக்கவில்லை. முதலில் runner-ஐப் பதிவு செய்யவும், பிறகு service-ஐ நிறுவவும்.

Http response code: NotFound from 'POST https://api.github.com/actions/runner-registration'. இந்த token செல்லுபடியாகும் பதிவு token அல்ல. இது காலாவதியாகியிருக்கலாம் (இவை ஒரு மணிநேரம் மட்டுமே செல்லுபடியாகும்), அல்லது Runners பக்கத்தில் உள்ள பதிவு token-க்கு பதிலாக personal access token-ஐ நீங்கள் உள்ளிட்டிருக்கலாம். புதிய token-ஐ உருவாக்கி மீண்டும் உள்ளிடவும்.

Dependencies is missing for Dotnet Core 6.0. runner கோப்பகத்திலிருந்து sudo ./bin/installdependencies.sh-ஐ root பயனராக இயக்கி, மீண்டும் பதிவு செய்யவும்.

Reboot-க்குப் பிறகு Runner Offline ஆதல். systemctl is-enabled 'actions.runner.*'-ஐ இயக்கவும். எதுவும் பட்டியலிடப்படவில்லை என்றால், ./svc.sh install ஒருபோதும் இயக்கப்பட்டிருக்கவில்லை என்று அர்த்தம்; எனவே runner உங்கள் terminal அமர்வுக்குள் மட்டுமே இருந்திருக்கிறது. unit enabled நிலையில் இருந்தும் runner Offline-ல் இருந்தால், journalctl -u 'actions.runner.*'-ஐப் படித்து, outbound HTTPS இணைப்பைச் சரிபார்க்கவும்.

வட்டு (Disk) நிரம்புதல். Checkouts, build caches மற்றும் Docker images ஆகியவை _work-க்கு அடியிலும், runner பயனரின் home கோப்பகத்திலும் சேர்கின்றன. இவற்றை நீக்க தானியங்கி வசதி இல்லை. du -sh /home/gharunner/actions-runner/_work-ஐக் கண்காணித்து, வட்டு நிரம்பும் முன்பே ஒரு திட்டமிடப்பட்ட சுத்தம் செய்யும் பணியைச் (scheduled clean-up) சேர்க்கவும்.

FAQ

sudo ./svc.sh install ஏன் command not found என்று கூறுகிறது?

ஏனெனில் svc.sh என்பது runner tarball-ல் இல்லை. ./config.sh பதிவு செய்வதை முடித்த பிறகு, உங்கள் repository மற்றும் runner பெயரைப் பயன்படுத்தி service பெயரை உருவாக்க, runner கோப்பகத்தில் இது உருவாக்கப்படுகிறது. முதலில் ./config.sh-ஐ runner பயனராக இயக்கவும். அதன் பிறகு, sudo ./svc.sh install gharunner அந்த script-ஐக் கண்டறிந்து, actions.runner.OWNER-REPO.RUNNER-NAME.service என்ற பெயரில் ஒரு unit-ஐ /etc/systemd/system-ல் எழுதும்.

self-hosted runner-க்காக firewall port-ஐ நான் திறக்க வேண்டுமா?

தேவையில்லை. runner GitHub-க்கு ஒரு outbound HTTPS இணைப்பை ஏற்படுத்தி, பணிகளுக்காகக் காத்திருக்கும்போது அதைத் திறந்து வைத்திருக்கும். எனவே, GitHub உங்கள் VPS-க்கு எந்த இணைப்பையும் தொடங்காது. outbound 443-ஐ மட்டும் அனுமதித்து, உங்கள் inbound விதிகளை மூடி வைக்கவும். service இயங்கிக்கொண்டிருக்கும்போது runner Offline என்று காட்டினால், inbound விதிகளைப் பார்ப்பதை விட, outbound filtering மற்றும் DNS-ஐச் சரிபார்க்கவும்.

public repository-ல் self-hosted runner-ஐப் பயன்படுத்தலாமா?

பயன்படுத்தலாம், ஆனால் GitHub அவ்வாறு செய்ய வேண்டாம் என்று அறிவுறுத்துகிறது. ஒரு fork-லிருந்து வரும் pull request அதன் சொந்த workflow கோப்பைக் கொண்டிருக்கும். எனவே, உங்கள் repository-ஐ fork செய்யக்கூடிய எவரும் உங்கள் கணினியில் இயங்கும் கட்டளைகளை முன்மொழியலாம். அங்கீகாரக் கோரிக்கை (approval prompt) ஒரு பங்களிப்பாளரின் முதல் இயக்கத்திற்கு மட்டுமே பொருந்தும். நீங்கள் ஒரு public repository-ல் runner-ஐ இணைத்தால், அதில் fork pull request workflow-களை முடக்கவும், அந்த server-ல் வேறு எதையும் வைத்திருக்க வேண்டாம், மேலும் குறிப்பிட்ட கால இடைவெளியில் அந்த machine-ஐ மீண்டும் உருவாக்கவும் (rebuild).

Http response code: NotFound உடன் பதிவு ஏன் தோல்வியடைகிறது?

URL தவறாக இருக்கும்போது மட்டுமல்லாமல், credential தவறாக இருக்கும்போதும் பதிவு அழைப்பு (registration call) NotFound என்று பதிலளிக்கும். இது செய்தியைத் தவறாக வழிநடத்துகிறது. பதிவு டோக்கன்கள் (registration tokens) காட்டப்பட்ட ஒரு மணி நேரத்திற்குப் பிறகு காலாவதியாகிவிடும், மேலும் இந்த அழைப்பிற்கு personal access token ஏற்றுக்கொள்ளப்படாது. Settings, Actions, Runners, New self-hosted runner என்பதை மீண்டும் திறந்து, புதிய டோக்கனை நகலெடுத்து, --url மதிப்பு உங்களுக்கு நிர்வாக உரிமைகள் உள்ள repository-ஐக் குறிக்கிறதா என்பதை உறுதிப்படுத்தவும்.