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 அந்தப் பணிகளைச் செய்து முடிக்கும்.

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

கீழே கொடுக்கப்பட்டுள்ள அனைத்தும் Ubuntu 24.04 மற்றும் runner version 2.338.0 ஆகியவற்றைக் கொண்டுள்ளன. இது 12 October 2026 நிலவரப்படி தற்போதைய வெளியீடாகும். 4 November 2026 நிலவரப்படி GitHub-ன் சமீபத்திய வெளியீடு 2.338.2 ஆகும்; கீழே உள்ள கட்டளைகளும் checksum-ம் 2.338.0 பதிப்பிற்கே நிர்ணயிக்கப்பட்டுள்ளன.

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

ஒரு சாதாரண 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.338.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.338.0 x64 tarball-க்கானது. தற்போதைய release-க்கான மதிப்பை GitHub அதன் release பக்கத்திலும், New self-hosted runner திரையிலும் காட்டுகிறது. ஒவ்வொரு பதிப்பிற்கும் இது மாறுபடும் என்பதால், வேறு பதிப்பை நிறுவும் போது அங்கிருந்து நகலெடுக்கவும்.

echo "af4b794c1bc41d73d40535e3fe092a39f9679cd8d965954c2aca25a05ca41d32  actions-runner-linux-x64-2.338.0.tar.gz" | sha256sum -c

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

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

பாதி தரவிறக்கம் செய்யப்பட்ட அல்லது மாற்றப்பட்ட கோப்பு, தோல்வியையும் எச்சரிக்கையையும் காட்டும்:

actions-runner-linux-x64-2.338.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.338.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 பதிப்புகளிலும் வேலை செய்கிறது.

ldd மூலம் சோதிக்கப்படும் ஒரு library விடுபட்டிருந்தால், runner தொடங்குவதற்கு முன்பே ./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 என்று காட்டும். இவை இரண்டுமே ஒரே இடத்திலிருந்து வருகின்றன: runner தொடங்குவதற்கு முன், config.sh தனது bundled libraries-ஐ ldd மூலமும், libicu-ஐ ldconfig மூலமும் சரிபார்க்கிறது. இதனால், குழப்பமான crash ஏற்படுவதற்குப் பதிலாக, unresolved link இருக்கும்போதே script நின்றுவிடுகிறது. இந்தச் சோதனைகள் installer குறிப்பிடும் அனைத்து package-களையும் உள்ளடக்கியவை அல்ல. விடுபட்ட liblttng-ust1t64 இந்தச் சோதனைகளைத் தூண்டுவதில்லை: .NET ஆனது LTTng tracing-ஐ விருப்பத்தேர்வாகவே (optionally) ஏற்றுகிறது, எனவே அதன் tracing dependencies கிடைக்கவில்லை என்றாலும் அது தொடர்ந்து இயங்கும்.

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

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

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-ல் காத்திருந்தால், பொருத்தமான runner ஆன்லைனில் மற்றும் idle நிலையில் உள்ளதா எனச் சரிபார்க்கவும். runs-on-ல் உள்ள ஒவ்வொரு லேபிளும் runner-ல் இருக்க வேண்டும்; எனவே, ஒரு கூடுதல் வார்த்தை இருந்தாலும், பொருத்தமான runner கிடைக்கும் வரை அல்லது 24 மணிநேரத்திற்குப் பிறகு பணி தோல்வியடையும் வரை அது queued நிலையிலேயே இருக்கும். repository settings-ல் runner-க்கு அருகில் காட்டப்பட்டுள்ள லேபிள்களுடன் இந்த பட்டியலை ஒப்பிட்டுப் பார்க்கவும்.

Self-hosted runners மற்றும் public repositories ஏன் ஒன்றாகச் செயல்படக்கூடாது

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

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

Approval settings இதைச் சரிசெய்யாமல், அதன் தீவிரத்தைக் குறைக்கின்றன. ஒரு public repository-க்கான இயல்புநிலை கொள்கை, முதல்முறை பங்களிப்பவரின் fork workflow-க்கு ஒப்புதல் அளிக்குமாறு பராமரிப்பாளரைக் கேட்கிறது. ஒருவரின் commit அல்லது pull request repository-ல் இணைக்கப்படும் வரை மட்டுமே அவர் முதல்முறை பங்களிப்பவராகக் கருதப்படுவார். அதற்குப் பிறகு, அவர்களின் அடுத்தடுத்த pull requests எந்தத் தடையுமின்றி இயங்கும். ஒரு சிறிய திருத்தத்தை merge செய்வதே இதற்குப் போதுமானது என்று GitHub-மே எச்சரிக்கிறது. எனவே, இந்தத் தடுப்பு என்பது ஒரு மனிதர் diff-ஐப் பார்ப்பதை மட்டுமே சார்ந்துள்ளது; ஒரு build script-ல் மூன்று நிலைகளுக்குக் கீழே மறைத்து வைக்கப்பட்டிருக்கும் payload-ஐக் கண்டறிவது எளிதல்ல.

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

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

பின்வரும் விதிகள் சுருக்கமானவை. Self-hosted runners-ஐ private repositories-க்கு பயன்படுத்துங்கள். ஒருவேளை நீங்கள் அதை ஒரு public repository-டன் இணைக்க வேண்டியிருந்தால், அதில் fork pull requests-ஐ இயக்காதீர்கள், அந்த server-ல் வேறு எதையும் வைத்திருக்காதீர்கள், மேலும் அந்த machine-ஐ எப்போது வேண்டுமானாலும் தூக்கி எறியக்கூடிய ஒன்றாகக் கருதுங்கள்.

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

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

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

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

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

கைமுறையான மேம்படுத்தலின் போது registration விவரங்கள் அப்படியே இருக்கும், ஏனெனில் .runner மற்றும் .credentials ஆகியவை tarball-க்குள் இருப்பதில்லை. Service-ஐ நிறுத்திவிட்டு, புதிய tarball-ஐ gharunner ஆகத் தரவிறக்கம் செய்து checksum சரிபார்க்கவும், பின் tar xzf மூலம் அதே கோப்பகத்தில் (directory) extract செய்யவும், அதன் பிறகு 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 செய்யாமல் கோப்பகத்தை மட்டும் நீக்கினால், அந்த runner repository-ல் Offline என்று காட்டும். ஒரு நிர்வாகி Force remove this runner என்பதை அழுத்தும் வரை அல்லது 14 நாட்கள் இணைப்பு இல்லாமல் 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) இருக்கிறீர்கள். config.sh பதிவு செய்யும் பணியை முடிக்காததால், svc.sh இன்னும் உருவாக்கப்படவில்லை. runner-ஐப் பதிவு செய்துவிட்டு, பிறகு service-ஐ நிறுவவும்.

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

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

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

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