SSD Nodes Learn 8GB RAM — ஆண்டுக்கு $66
கல்வி வழிகாட்டிகள் Matt Connorஆல் Matt Connor · புதுப்பிக்கப்பட்டது 2026-08-01

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

Ubuntu 24.04 VPS-இல் GitHub Actions runner-ஐ எவ்வாறு நிறுவுவது என்பதை அறிக. தனி பயனர் உருவாக்கம், checksum சரிபார்ப்பு, systemd சேவை அமைப்பு மற்றும் பாதுகாப்பு அபாயங்கள் குறித்து

Verified Every command ran end-to-end on a fresh Ubuntu 24.04 server, July 30, 2026.

சுய-வழங்கி (self-hosted) GitHub Actions runner என்றால் என்ன

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

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

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

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

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

உங்களுக்கு அந்த ரெபாசிட்டரியின் (repository) நிர்வாக உரிமைகளும் தேவை. ஏனெனில், பதிவு செய்வதற்கான டோக்கன் (registration token) ரெபாசிட்டரி அமைப்புகளில் காட்டப்படும்.

ரன்னருக்காக பிரத்யேக பயனரை உருவாக்குதல்

ரன்னரை root பயனராகவோ அல்லது உங்கள் சொந்த நிர்வாகி பயனராகவோ ஒருபோதும் இயக்க வேண்டாம். ஒவ்வொரு பணியும் ரன்னர் பயனரின் உரிமைகளைப் பெற்றுக்கொள்ளும், எனவே sudo கட்டளையை அழைக்கும் ஒரு வொர்க்ஃப்ளோ, ரன்னர் பயனரால் sudo பயன்படுத்த முடிந்தால் வெற்றிபெறும். அதன் சொந்த home டைரக்டரியைத் தவிர வேறு எதையும் உரிமை கொள்ளாத ஒரு சலுகையற்ற பயனரை உருவாக்குங்கள். 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 பயனராக கடவுச்சொல்லைப் பயன்படுத்தி உள்நுழைய முடியாது. ரன்னர் டைரக்டரியில் 700 மோட் முக்கியமானது, ஏனெனில் ரன்னர் தனது நற்சான்றிதழ்களை அங்கு தெளிவான உரையாக (cleartext) சேமிக்கிறது, மேலும் ஒரு செக்அவுட் தனிப்பட்ட மூலக் குறியீட்டைக் கொண்டிருக்கலாம்.

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

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) நீங்கிவிட்டது.

ரன்னரைப் பதிவிறக்கம் செய்து 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 கோப்பிற்கானது. 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 மூலம் சிக்கலைக் கண்டறிய விடாதீர்கள். முழுமையடையாத ஆவணக் கோப்பு 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/-இல் ரன்னர் பைனரிகள் மற்றும் bin/installdependencies.sh ஆகியவை உள்ளன. externals/-இல் JavaScript செயல்பாடுகள் இயங்குவதற்கான Node ரன்டைம் தொகுக்கப்பட்டுள்ளது.

இதில் இன்னும் svc.sh இல்லை. GitHub ஆவணங்களின்படி, "ரன்னரை வெற்றிகரமாகச் சேர்த்த பிறகு உருவாக்கப்படும்" ஸ்கிரிப்ட் இதுவாகும். ஏனெனில், இது உங்கள் களஞ்சியம் (repository) மற்றும் ரன்னர் பெயருடன் கூடிய டெம்ப்ளேட்டிலிருந்து உருவாக்கப்படுகிறது. எனவே, ./config.sh-க்கு முன்பாக sudo ./svc.sh install-ஐ இயக்கினால், அது sudo: ./svc.sh: command not found பிழையுடன் தோல்வியடையும். முதலில் பதிவு செய்யுங்கள், அதன் பிறகு சேவையை நிறுவுங்கள்.

runner சார்புகளை நிறுவுதல்

runner என்பது ஒரு .NET செயலி, எனவே இதற்குச் சில பகிரப்பட்ட நூலகங்கள் (shared libraries) தேவைப்படுகின்றன. runner பயனரின் 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 ஒவ்வொரு நூலகத்திற்கும் பல பதிப்புப் பெயர்களை முயற்சி செய்து, உங்கள் release-இல் உள்ள பதிப்பைத் தேர்வு செய்கிறது. இதனால்தான், பழைய Ubuntu மற்றும் Debian பதிப்புகளிலும் இதே script வேலை செய்கிறது.

இந்த நிலையைத் தவிர்த்தால், ./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-ஐ இயக்குகிறது. எனவே, தீர்க்கப்படாத இணைப்பு (unresolved link) இருந்தால், பிந்தைய கட்டத்தில் குழப்பமான செயலிழப்பு ஏற்படுவதற்குப் பதிலாக, script இப்போதே நின்றுவிடும்.

உங்கள் களஞ்சியத்தில் ரன்னரைப் பதிவு செய்தல்

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

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 என்பது களஞ்சியத்தில் ரன்னர் எவ்வாறு காட்டப்படும் என்பதைக் குறிக்கிறது, எனவே ஆறு மாதங்களுக்குப் பிறகும் உங்களுக்கு அடையாளம் காணக்கூடிய ஒரு பெயரைத் தேர்ந்தெடுக்கவும். --labels உங்கள் சொந்த லேபிள்களைச் சேர்க்கிறது; ரன்னரில் ஏற்கனவே self-hosted, Linux மற்றும் X64 ஆகியவை தானாகவே இருக்கும். --work என்பது ரன்னர் கோப்பகத்திற்குள், செக்-அவுட்கள் (checkouts) சேமிக்கப்படும் கோப்பகத்தின் பெயரைக் குறிக்கிறது. --unattended என்பது ஊடாடும் வினவல்களுக்கு அவற்றின் இயல்புநிலை மதிப்புகளை வழங்குகிறது, இது ஒரு ஸ்கிரிப்ட்டில் கட்டளையை இயக்கும்போது தேவைப்படும். --replace என்பது அதே பெயரில் ஏற்கனவே உள்ள பதிவை நீக்கிவிட்டு புதியதை மாற்றும், இது சர்வரை மீண்டும் கட்டமைக்கும்போது தேவைப்படும்.

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

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

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

runner-ஐ systemd சேவையாக நிறுவுதல்

ஒருமுறை சோதனை செய்வதற்கு ./run.sh கட்டளையை டெர்மினலில் இயக்குவது போதுமானது, ஆனால் உங்கள் SSH அமர்வு முடிவடையும் போது அதுவும் நின்றுவிடும். கணினி தொடங்கும் போதே runner இயங்கத் தொடங்க, அதை ஒரு சேவையாக நிறுவவும். VPS-இல் systemd சேவைகள் மற்றும் டைமர்கள் என்பது யூனிட் கோப்புகளைப் பற்றிய விளக்கத்தை அளிக்கிறது. இங்கே svc.sh உங்களுக்காக ஒரு கோப்பை உருவாக்குகிறது.

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 கோப்பகத்தில் ஒரு யூனிட் கோப்பை எழுதி அதைச் செயல்படுத்துகிறது. install கட்டளைக்கு அடுத்து வரும் ஆர்குமென்ட், எந்தப் பயனர் கணக்கில் இந்தச் சேவை இயங்க வேண்டும் என்பதைக் குறிக்கிறது. gharunner என்பதைத் தெளிவாகக் குறிப்பிடவும். எந்த ஆர்குமென்ட்டும் வழங்கப்படாவிட்டால், ஸ்கிரிப்ட் தானாகவே $SUDO_USER என்பதை எடுத்துக்கொள்ளும். இது உங்கள் நிர்வாகி கணக்காகும், இதனால் ஒவ்வொரு பணியும் sudo பயன்படுத்தக்கூடிய ஒரு பயனர் கணக்கில் இயங்கும்.

இந்த யூனிட், ரெபாசிட்டரி மற்றும் 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 என்று லாக் (log) செய்யும், அதைத் தொடர்ந்து Listening for Jobs என்று முடியும் ஒரு வரியைக் காட்டும். ரெபாசிட்டரியின் Runners பக்கத்தில் அது Idle என்று காட்டப்படும். ஒரு runner Offline என்று காட்டப்பட்டால், அது இயங்கவில்லை அல்லது 443 போர்ட் வழியாக GitHub-ஐ அணுக முடியவில்லை என்று பொருள்.

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

runs-on லேபிளைப் பயன்படுத்தி ஒரு ரன்னரைத் தேர்ந்தெடுக்கிறது. self-hosted மற்றும் உங்கள் சொந்த லேபிளைக் குறிப்பிடுங்கள், அப்போதுதான் நீங்கள் விரும்பாத ரன்னரில் பணி இயங்காது.

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-இல் உள்ள ஒவ்வொரு லேபிளும் ரன்னரில் இருக்க வேண்டும். எனவே, ஒரு கூடுதல் சொல் இருந்தாலும் பணி வரிசையில் காத்திருக்கும், ஆனால் எந்தப் பிழையும் காட்டப்படாது. களஞ்சிய அமைப்புகளில் (repository settings) ரன்னருக்கு அருகில் காட்டப்பட்டுள்ள லேபிள்களுடன் உங்கள் பட்டியலை ஒப்பிட்டுப் பாருங்கள்.

சுய-வழங்கி ரன்னர்கள் மற்றும் பொது களஞ்சியங்கள் ஏன் ஒன்றாகச் செயல்படக்கூடாது

இதுவே பலரால் தவிர்க்கப்படும் பகுதி. GitHub-ன் வழிகாட்டுதல் தெளிவாக உள்ளது: சுய-வழங்கி (self-hosted) ரன்னர்களை "பொது களஞ்சியங்களுக்கு (public repositories) ஒருபோதும் பயன்படுத்தக்கூடாது". மேலும், இவை "தற்காலிகமான மற்றும் தூய்மையான மெய்நிகர் இயந்திரங்களில் (ephemeral clean virtual machines) இயங்குவதற்கான உத்தரவாதத்தைக் கொண்டிருக்கவில்லை, மேலும் நம்பகத்தன்மையற்ற குறியீடுகளால் இவை நிரந்தரமாகப் பாதிக்கப்படக்கூடும்".

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

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

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

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

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

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

Container பணிகள், service container-கள் மற்றும் 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 container-களைப் பயன்படுத்த முடியாது.

புதுப்பித்தல்கள் மற்றும் ரன்னரை முறையாக நீக்குதல்

சுயமாக ஹோஸ்ட் செய்யப்பட்ட ரன்னர் இயல்பாகவே தன்னைத்தானே புதுப்பித்துக் கொள்ளும். புதிய ரிலீஸ் (release) வந்தவுடன், அது தனது கோப்புகளை மாற்றியமைத்து சேவையை மறுதொடக்கம் செய்யும், எனவே நீங்கள் பொதுவாக எதையும் செய்ய வேண்டியதில்லை. உங்களுக்கு ஒரு குறிப்பிட்ட வெர்ஷன் (version) தேவைப்படும்போது, ./config.sh --disableupdate மூலம் இந்த தானியங்கி புதுப்பித்தலை முடக்கலாம். அதன் பிறகு, புதுப்பிக்கும் பொறுப்பு உங்களுடையது: --disableupdate மூலம் கட்டமைக்கப்பட்ட ரன்னரை கைமுறையாகத்தான் புதுப்பிக்க வேண்டும் என்று GitHub ஆவணங்கள் தெளிவாகக் கூறுகின்றன.

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

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

ரன்னரை நீக்க, முதலில் சேவையை அன்இன்ஸ்டால் (uninstall) செய்துவிட்டு, பிறகு பதிவை நீக்கவும் (deregister). இதற்கான ரிமூவல் டோக்கன் (removal token), ரன்னரின் அதே Runners பக்கத்தில் உள்ள 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

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

தோல்வி முறைகள் மற்றும் நீங்கள் காணும் சரங்கள்

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

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

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

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

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

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

FAQ

sudo ./svc.sh install கட்டளை கிடைக்கவில்லை என்று ஏன் கூறுகிறது?

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

சுய-ஹோஸ்ட் செய்யப்பட்ட ரன்னருக்கு ஃபயர்வால் போர்ட்டைத் திறக்க வேண்டுமா?

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

பொது களஞ்சியத்தில் சுய-ஹோஸ்ட் செய்யப்பட்ட ரன்னரைப் பயன்படுத்தலாமா?

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

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

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

#github-actions#ci#self-hosted#runner#ubuntu-24-04