Coding Agent-க்கு ஏன் தற்காலிக VM பயன்படுத்த வேண்டும்?

உங்கள் மடிக்கணினியை விட தற்காலிக VM ஏன் சிறந்தது

ஒரு கோடிங் ஏஜென்டிடம் (coding agent) தற்காலிக VM-ஐ வழங்கினால், அது செய்யக்கூடிய மிக மோசமான காரியம், பத்து நிமிடங்களில் மீண்டும் உருவாக்கக்கூடிய ஒரு கணினியை அழிப்பது மட்டுமே. அந்த ஏஜென்ட் தொடர்ந்து root அனுமதியைப் பெறுகிறது, பேக்கேஜ்களை நிறுவுகிறது, ஒவ்வொரு படிக்கும் அனுமதி கேட்காமல் டெஸ்ட் சூட்டை (test suite) இயக்குகிறது. இதில் உள்ள வித்தியாசம் பாதிப்பு எங்கே நிகழ்கிறது என்பதில் தான் உள்ளது. ஒரு மடிக்கணினியில், அந்த ஏஜென்ட் உங்கள் SSH கீகள், பிரவுசர் புரொபைல், உங்கள் .env கோப்புகள் மற்றும் நீங்கள் இதுவரை குளோன் செய்த அனைத்து ரெபாசிட்டரிகளுடன் உங்கள் ஹோம் டைரக்டரியைப் (home directory) பகிர்ந்து கொள்கிறது. ஒரு தற்காலிக சர்வரில், அதற்கு ஒரு ஷெல் (shell), ஒரு செக்அவுட் (checkout) மட்டுமே இருக்கும், திருடுவதற்கு வேறு எதுவும் இருக்காது.

இதுவே முழுமையான வாதம், இது நிகழ்தகவை விட சமச்சீரற்ற தன்மையைப் பற்றிய வாதமாகும். கவனமாகச் செயல்படும் ஒரு ஏஜென்ட், கவனமாகப் பயன்படுத்தப்படும் மடிக்கணினியில் பெரும்பாலான நேரங்களில் சரியாகவே செயல்படும். அது தவறு செய்யும் அந்த ஒரு தருணத்தில், ஏற்படும் இழப்பு ஒரு தவறான கமிட் (commit) மட்டுமல்ல. உங்களிடம் பேக்கப் இருந்தால், அதிலிருந்து மீட்டெடுப்பதே அந்த இழப்பாகும்.

பாதிப்பு எல்லை (Blast radius) குறித்து விவாதிக்கும் முன் அதன் பெயரை வரையறுக்கவும்

பாதிப்பு எல்லை என்பது ஒரு செயல்முறை (process) அணுகக்கூடியவற்றின் தொகுப்பைக் குறிக்கிறது. உங்கள் சாதாரண கணினியில், உங்கள் சாதாரண பயனர் கணக்கில் இயங்கும் ஒரு ஏஜெண்டிற்கு, இந்தத் தொகுப்பு பெரும்பாலானோர் நினைப்பதை விடப் பெரியது.

இதில் ~/.ssh/id_ed25519 அடங்கும், இது பொதுவாக குறியாக்கம் செய்யப்படாமல் இருக்கும், ஏனெனில் நீங்கள் கடவுச்சொல்லை (passphrase) தட்டச்சு செய்து சலிப்படைந்திருப்பீர்கள். இதில் ~/.aws/credentials மற்றும் ~/.config/gh/hosts.yml அடங்கும், இவை வடிவமைப்பிலேயே எளிய உரையாக (plain text) உள்ளன. ~/code-இன் கீழ் உள்ள ஒவ்வொரு சகோதர களஞ்சியமும் (sibling repository) இதில் அடங்கும், இதில் உள்ளூர் env கோப்பில் தயாரிப்பு சூழல் இணைப்பு சரங்களைக் (production connection strings) கொண்டவையும் அடங்கும். இதில் உங்கள் ஷெல் வரலாறு (shell history) அடங்கும், இது நீங்கள் ஒருமுறை நகலெடுத்து ஒட்டிய டோக்கன்களைக் கொண்டுள்ளது. உங்கள் மடிக்கணினி இணைக்கப்பட்டுள்ள பிணையமும் (network) இதில் அடங்கும், இது பெரும்பாலும் அங்கீகரிக்கப்படாத சேவைகளைக் கொண்ட வீடு அல்லது அலுவலக பிணையமாகவே இருக்கும்.

இதற்கு எந்தவொரு தீங்கிழைக்கும் ஏஜெண்டும் தேவையில்லை. தவறாகப் புரிந்துகொள்ளப்பட்ட ஒரு கட்டளை போதுமானது. / என விரிவடையும் ஒரு செட் செய்யப்படாத மாறியுடன் கூடிய rm -rf, தவறான கோப்பகத்தில் இயங்கும் ஒரு git clean -xfd, உங்கள் உள்ளூர் தரவுத்தளத்தை அழிக்கும் ஒரு docker system prune -af --volumes, அல்லது முகப்பு கோப்பகத்தில் (home directory) இயங்கும் ஒரு பயனுள்ள chmod -R 777 போன்றவை இதற்குப் போதுமானவை. மற்ற அனைவருக்கும் அந்தக் கட்டளைகளைக் கற்பித்த அதே இணையதளத்திலிருந்தே ஏஜெண்டுகளும் பயிற்சி பெறுகின்றன.

உங்களைக் காக்கும் பொறிமுறை ஏஜெண்டின் தீர்ப்பு அல்ல. சேதம் ஏற்படும் அந்த இயந்திரத்தை இழக்க நீங்கள் தயாராக இருக்கிறீர்கள் என்பதே அது.

செலவுக் கணக்கீடு சலிப்பானது, அதுவே இதன் நோக்கம்

ஒரு சிறிய VPS-க்கு மாதத்திற்குச் சில டாலர்கள் மட்டுமே செலவாகும். ஒரு டெவலப்பர் லேப்டாப்பை மீட்டெடுக்க ஒரு நாள் முழுவதுமாகத் தேவைப்படும். இது ஒரு நல்ல சூழல், அதாவது பாதிப்பை நீங்கள் உடனடியாகக் கவனித்து, உங்களிடம் பேக்கப் (backup) இருக்கும் பட்சத்தில் மட்டுமே இது சாத்தியம்.

உங்கள் சொந்த எண்களைக் கொண்டு இதைக் கணக்கிடுங்கள். உங்கள் ஒரு மணி நேர ஊதியத்தை எடுத்துக்கொள்ளுங்கள். ஒரு இயங்குதளத்தை (operating system) மீண்டும் நிறுவுதல், home directory-ஐ மீட்டெடுத்தல், SSH key-ஐ மாற்றுதல், personal access token-ஐ மாற்றுதல் மற்றும் இருபது repositories-ஐ மீண்டும் clone செய்தல் ஆகியவற்றிற்குத் தேவைப்படும் மணிநேரங்களுடன் அதைப் பெருக்குங்கள். இந்தத் தொகையை, உங்கள் சேவை வழங்குநர் (provider) விற்கும் மிகச்சிறிய சர்வரின் 12 மாதக் கட்டணத்துடன் ஒப்பிட்டுப் பாருங்கள். பல ஆண்டுகளுக்கு ஒருமுறை ஏற்படும் ஒரு பாதிப்பு கூட, இந்தச் செலவை ஈடுகட்டப் போதுமானது. ஒரு பாதிப்பு மிக மோசமானதாக இருக்க வேண்டிய அவசியமில்லை. சிதைந்த லேப்டாப் சூழலால் (corrupted local environment) வீணாகும் ஒரு மதியப் பொழுது, அந்த ஆண்டிற்கான சர்வர் செலவை ஈடுகட்டிவிடும்.

இந்தக் கணக்கீட்டின் இரண்டாம் பகுதி snapshots ஆகும். ஆபத்தான ஒரு செயலைச் செய்வதற்கு முன்பு எடுக்கப்படும் ஒரு snapshot, "என் வாழ்வை மீட்டெடு" என்ற நிலையை மாற்றி, "மீண்டும் பழைய நிலைக்குச் சென்று (roll back) வேறு வழியை முயற்சி செய்" என்ற நிலையை உருவாக்குகிறது. நீங்கள் தற்போது பயன்படுத்தும் லேப்டாப்பில் இந்த வசதி இல்லை, ஏனெனில் நீங்கள் ஒரு கணினியைப் பயன்படுத்திக் கொண்டிருக்கும்போது அதன் snapshot-ஐ எடுக்க முடியாது.

ஜூலை 2026 நிலவரப்படி தற்போதைய சூழல்

"ஏஜென்ட் எங்கு இயங்க வேண்டும்" என்ற கேள்விக்கு மூன்று நேர்மையான பதில்கள் உள்ளன. இவை இரண்டு விஷயங்களுக்கு இடையே சமநிலையை ஏற்படுத்துகின்றன: எல்லையின் வலிமை மற்றும் நீங்கள் ஏற்கும் அமைவுச் சுமை.

ஒரு உள்ளூர் மைக்ரோ VM. இந்த வகையைச் சேர்ந்த கருவிகள் உங்கள் வன்பொருளில் ஒரு உண்மையான மெய்நிகர் கணினியை (virtual machine) துவக்குகின்றன. உங்கள் களஞ்சியத்தை (repository) அதில் மவுண்ட் செய்து, ஏஜென்ட்டிற்கு உள்ளே root அனுமதியை வழங்குகின்றன. clawk என்பது தற்போதைய உதாரணம். இதன் நோக்கம் இந்த பதிவின் கருப்பொருளைப் போன்றதே: கோடிங் ஏஜென்ட்டுகளுக்கு உங்கள் மடிக்கணினியை வழங்காமல், ஒரு தற்காலிக Linux VM-ஐ வழங்குங்கள். ஜூலை 2026 நிலவரப்படி, இது Apple silicon-ல் இயங்கும் macOS 14 மற்றும் அதற்குப் பிந்தைய பதிப்புகளை இலக்காகக் கொண்டுள்ளது. Firecracker மூலம் Linux-க்கான சோதனை ஆதரவும் உள்ளது. இது brew install clawkwork/tap/clawk மூலம் நிறுவப்படுகிறது. சாண்ட்பாக்ஸைத் துவக்கி ஏஜென்ட்டை இணைக்க களஞ்சியத்திற்குள் clawk கட்டளையையும், அதை நிறுத்த clawk down கட்டளையையும், அதை நீக்க clawk destroy கட்டளையையும் பயன்படுத்த வேண்டும். இதன் எல்லை ஒரு ஹைப்பர்வைசர் (hypervisor) ஆகும், இது மிகவும் வலிமையானது. இதன் வரம்பு என்னவென்றால், VM நீங்கள் எடுத்துச் செல்லும் கணினியிலேயே இயங்குகிறது. எனவே, இது உங்கள் நினைவகத்தைப் (memory) பகிர்ந்து கொள்கிறது மற்றும் நீங்கள் மடிக்கணினியை மூடும்போது இதுவும் நின்றுவிடும்.

ஒரு கன்டெய்னர் (Container). Docker என்பது பெரும்பாலானோர் ஏற்கனவே நிறுவியிருக்கும் தீர்வாகும், இது உண்மையிலேயே பயனுள்ளது.

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm வெளியேறும்போது கன்டெய்னரை நீக்கிவிடும் மற்றும் --network none அதற்கு எந்த நெட்வொர்க் அணுகலையும் வழங்காது. இது ஒரு பில்ட் அல்லது டெஸ்ட் ரன்னிற்குச் சிறந்த இயல்புநிலை அமைப்பாகும். இது எதைச் செய்யாது என்பதில் தெளிவாக இருங்கள்: ஒரு கன்டெய்னர் ஹோஸ்ட் கர்னலைப் (host kernel) பகிர்ந்து கொள்கிறது. எனவே, ஒரு கர்னல் பிழை மூலம் வெளியேற முடியும். நீங்கள் --privileged-ஐச் சேர்க்கும்போது அல்லது /var/run/docker.sock-ஐ மவுண்ட் செய்யும்போது, ஏஜென்ட் "Docker-ஐப் பயன்படுத்த" முடியும் என்பதால், அந்த எல்லை மறைந்துவிடும். Docker சாக்கெட்டை ஒரு கன்டெய்னருக்குள் மவுண்ட் செய்வது, ஹோஸ்டில் அந்த கன்டெய்னருக்கு root அனுமதியை வழங்குவதற்குச் சமமாகும்.

மீண்டும் உருவாக்கக்கூடிய ஒரு சாதாரண VPS. புதிய கருவிகள் தேவையில்லை, உண்மையான கர்னல் எல்லை உள்ளது, வழங்குநரின் ஸ்னாப்ஷாட்கள் (snapshots) உள்ளன, மேலும் நீங்கள் மடிக்கணினியை மூடினாலும் இது தொடர்ந்து இயங்கும். இந்த வழிகாட்டியின் மீதமுள்ள பகுதிகள் இந்த முறையையே விவரிக்கின்றன. நீண்ட நேரம் இயங்கும் ஏஜென்ட் பணிகளுக்கு இதுவே சிறந்தது, ஏனெனில் நான்கு மணிநேரம் எடுக்கும் ஒரு பணிக்கு நீங்கள் வீட்டிற்குச் செல்வது ஒரு தடையாக இருக்காது.

VPS மாதிரி: ஏஜெண்டிற்கு எனத் தனி பயனர் கணக்கை உருவாக்குதல்

பாதுகாக்கப்பட்ட சர்வரில் இருந்து தொடங்கவும். புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்ற பகுதியில் ஏஜெண்ட் சார்ந்தவை அல்லாத அடிப்படைப் பாதுகாப்பு முறைகள் உள்ளன: மென்பொருள் மேம்படுத்தல்கள், root அல்லாத பயனர் கணக்கு, SSH கீ மூலம் மட்டுமே உள்நுழைதல் மற்றும் ஃபயர்வால் அமைப்பு.

பிறகு, ஏஜெண்டிற்காக மட்டுமே ஒரு பயனர் கணக்கை உருவாக்கவும். இதன் மூலம், அந்த ஏஜெண்டில் ஏற்படும் பிழைகள் சர்வரில் உள்ள பிற பகுதிகளைப் பாதிக்காது.

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password என்பது கடவுச்சொல் மூலம் ஊடுருவ முடியாது என்பதைக் குறிக்கிறது. நீங்கள் sudo -u agent அல்லது SSH கீ மூலம் மட்டுமே அந்தக் கணக்கை அணுக முடியும். agent பயனர், sudo குழுவில் வேண்டுமென்றே சேர்க்கப்படவில்லை என்பதைக் கவனிக்கவும். sudo வசதி கொண்ட ஏஜெண்டிற்கு root அதிகாரம் இருக்கும். root பயனர் மற்ற அனைத்து பயனர்களின் கோப்புகளையும் படிக்க முடியும் என்பதால், நீங்கள் உருவாக்கிய இந்தத் தனிமைப்படுத்தல் வெறும் பெயரளவில் மட்டுமே இருக்கும். ஏஜெண்டிற்கு மென்பொருள் தொகுப்புகளை நிறுவ வேண்டிய அவசியம் இருந்தால், அதற்குத் தனி சர்வரைப் பயன்படுத்துவதே சிறந்தது; பகிரப்பட்ட சர்வரில் அதற்கு sudo அதிகாரத்தை வழங்கக்கூடாது. பொதுவான விதிகள் VPS-ல் லினக்ஸ் பயனர்களுக்கான குறைந்தபட்ச அதிகாரக் கொள்கை என்ற பகுதியில் உள்ளன.

பாதுகாப்பு எல்லையைச் சரிபார்க்கவும். agent பயனராக உள்நுழைந்து, உங்கள் சொந்தக் கணக்கிற்குச் சொந்தமான ஒரு கோப்பைப் படிக்க முயற்சிக்கவும்:

sudo -u agent cat /home/you/.ssh/id_ed25519

நீங்கள் cat: /home/you/.ssh/id_ed25519: Permission denied என்ற செய்தியைப் பார்க்க வேண்டும். அதற்குப் பதிலாகக் கோப்பின் உள்ளடக்கத்தைப் பார்த்தால், உங்கள் ஹோம் டைரக்டரி 755 என்ற அனுமதியில் உள்ளது என்று அர்த்தம். அப்போது அந்தத் தனிமைப்படுத்தல் முறையாகச் செயல்படவில்லை. sudo chmod 700 /home/you கட்டளையைப் பயன்படுத்தி அதைச் சரிசெய்யவும்.

நற்சான்றிதழ்களை கணினியில் வைக்க வேண்டாம்

ஒரு தற்காலிக கணினியின் நோக்கம், நீங்கள் உங்கள் தயாரிப்பு ரகசியங்களை (production secrets) அதில் நகலெடுத்தால் வீணாகிவிடும். விதி எளிதானது: அந்த கணினியில் உள்ள எந்தவொரு நற்சான்றிதழும் இன்று பிற்பகலில் மாற்றப்பட வேண்டியதாக இருந்தாலும் கவலைப்படக்கூடாது.

git-க்கு, உங்கள் SSH key-ஐ நகலெடுப்பதற்குப் பதிலாக, உங்கள் SSH agent-ஐ forward செய்யுங்கள். private key உங்கள் மடிக்கணினியிலேயே இருக்கும், கையொப்பக் கோரிக்கைகள் (signature requests) மட்டுமே இணைப்பின் வழியாகச் செல்லும்.

ssh -A agent@203.0.113.10
ssh -T git@github.com

இரண்டாவது கட்டளை Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. என்று பதிலளிக்க வேண்டும். சர்வரில் key கோப்பு ஏதுமின்றி git push வேலை செய்யும் என்பதை இது உறுதிப்படுத்துகிறது. அதன் பிறகு அந்த கணினியில் ls -la ~/.ssh என்பதை இயக்கி, அங்கு private key எதுவும் இல்லை என்பதை உறுதிப்படுத்தவும்.

Agent forwarding-ல் ஒரு முக்கியமான எச்சரிக்கை உள்ளது, அதைத் தெளிவாகக் கூறுவோம்: நீங்கள் இணைக்கப்பட்டிருக்கும்போது, அந்த சர்வரில் root அணுகல் உள்ள எவரும், பகிரப்பட்ட socket-ஐப் பயன்படுத்தி உங்களைப் போலவே அங்கீகாரம் பெற முடியும். நீங்கள் மட்டுமே பயனராக இருக்கும் சர்வரில், இது ஏற்றுக்கொள்ளக்கூடிய ஒரு சமரசம். பகிரப்பட்ட சர்வரில் இது பாதுகாப்பானது அல்ல; அத்தகைய சூழலில், ஒரு குறிப்பிட்ட repository-க்கு மட்டும் வரையறுக்கப்பட்ட deploy key-ஐப் பயன்படுத்துவதே சிறந்த தீர்வாகும். இதற்கான தேர்வுகள் SSH key மேலாண்மை அடிப்படைகள் பகுதியில் விளக்கப்பட்டுள்ளன.

API key-களுக்கு, அந்த agent-க்கு அதன் சொந்த செலவு வரம்புடன் கூடிய தனி key-ஐ வழங்கவும். இதை agent பயனர் உரிமையாளராக உள்ள, mode 600 கொண்ட கோப்பில் சேமிக்கவும். கணினி அழிக்கப்படும்போது, அந்த key கசிந்ததா என்று கவலைப்படுவதற்குப் பதிலாக, அதை ரத்து செய்யவும். ஒவ்வொரு key-க்கும் மாடல் செலவைக் கண்காணிப்பது, VPS-ல் AI agent செலவு கட்டுப்பாடு பகுதியில் உள்ள எண்களைக் கணிக்கக்கூடியதாக வைத்திருக்க உதவுகிறது.

ஏஜென்ட் நெட்வொர்க்கில் அணுகக்கூடியவற்றைக் கட்டுப்படுத்துதல்

கோப்பு முறைமை தனிமைப்படுத்தல் (Filesystem isolation) என்பது எல்லையின் ஒரு பாதி மட்டுமே. மற்றொரு பாதி வெளியேறும் போக்குவரத்து (egress) ஆகும்: அதாவது, ஒரு செயல்முறை எதனுடன் தொடர்பு கொள்ள அனுமதிக்கப்படுகிறது என்பது. லினக்ஸ் (Linux) வெளிச்செல்லும் போக்குவரத்தை அதை உருவாக்கிய பயனரின் அடிப்படையில் வடிகட்ட முடியும், இது இந்த முறைக்கு சரியாகப் பொருந்தும்.

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

விதிகள் வரிசைப்படி வாசிக்கப்படுகின்றன, எனவே இறுதி REJECT முந்தைய வரிகள் அனுமதிக்காத அனைத்தையும் பிடிக்கிறது. இதை ஏஜென்ட்டாகச் சோதிக்கவும்:

sudo -u agent curl -sS -m 5 http://example.com

இது curl: (7) Failed to connect to example.com port 80: Connection refused உடன் தோல்வியடைய வேண்டும், ஏனெனில் இணைப்பு தொங்குவதற்குப் பதிலாக நிராகரிப்பு விதி உடனடியாகப் பதிலளிக்கிறது. அதே ஹோஸ்டுக்கான HTTPS கோரிக்கை இன்னும் வெற்றிபெற வேண்டும்.

இரண்டு உண்மையான வரம்புகள் உள்ளன. முதலாவதாக, sudo apt install -y iptables-persistent மற்றும் பின்னர் sudo netfilter-persistent save மூலம் நீங்கள் அவற்றைச் சேமிக்காவிட்டால், அடுத்த மறுதொடக்கத்தின் போது இந்த விதிகள் இழக்கப்படும். இரண்டாவதாக, இது பெயர்களை அல்ல, போர்ட்கள் மற்றும் முகவரிகளை மட்டுமே வடிகட்டுகிறது. போர்ட் 443-ஐ அனுமதிக்கும் ஒரு விதி இணையத்தில் உள்ள ஒவ்வொரு HTTPS ஹோஸ்டையும் அனுமதிக்கிறது, இது மாடல் API-ஐ அடைய போதுமானது மற்றும் ஒரு pastebin-ஐ அடையவும் போதுமானது. ஒரு உண்மையான டொமைன் அனுமதிப் பட்டியலுக்கு (domain allow-list), கோரப்பட்ட ஹோஸ்ட்பெயரைப் படிக்கும் ஒரு ப்ராக்ஸி (proxy) வழியாக போக்குவரத்து செல்ல வேண்டும், இது பெரும்பாலான தனிப்பட்ட டெவலப்பர் அமைப்புகள் விரும்புவதை விட அதிக இயந்திர அமைப்பைக் கோருகிறது. உங்களிடம் உள்ளதை மட்டும் கோருங்கள்: போர்ட்-நிலை வெளியேறும் கட்டுப்பாடு, நீங்கள் இழக்கத் தயாராக இருந்த ஒரு கணினியில்.

பணிகளுக்கு இடையே தூய்மையான நிலைக்கு மீட்டமைத்தல்

ஒவ்வொரு பணிக்கும் ஒரு தூய்மையான நிலையைப் பராமரிப்பது, பெரிதும் கவனிக்கப்படாத ஒரு நன்மையாகும். கடந்த டிக்கெட்டில் மூன்று மணிநேரம் செலவிட்ட ஒரு ஏஜென்ட், நிறுவப்பட்ட தொகுப்புகள் (packages), பாதியில் நின்ற மைக்ரேஷன்கள், பழைய node_modules மற்றும் எவராலும் சரிபார்க்கப்படாத git மாற்றங்கள் கொண்ட ஒரு வொர்க்கிங் ட்ரீ ஆகியவற்றை விட்டுச் செல்கிறது. அடுத்த பணி இவை அனைத்தையும் அப்படியே பெற்றுக்கொள்கிறது. எந்தக் குழப்பம் எந்த ரன்னுக்கு உரியது என்பதைக் கண்டறியவே உங்கள் சரிபார்ப்பு நேரம் செலவாகிறது.

இதற்கான எளிய வழி, ஒவ்வொரு பணிக்கும் ஒரு புதிய செக்-அவுட் (checkout) செய்வதுதான்.

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

இதற்கான வலுவான வழி, மெஷின் அமைக்கப்பட்ட பிறகு, எந்த ஏஜென்ட்டும் அதைத் தொடுவதற்கு முன்பாக, ஒருமுறை மட்டும் எடுக்கப்படும் பிரொவைடர் ஸ்னாப்ஷாட் (provider snapshot) ஆகும். அந்த ஸ்னாப்ஷாட்டை மீட்டெடுப்பது, தொகுப்புகள் உட்பட முழு சிஸ்டத்தையும் ஒரு தெரிந்த நிலைக்குக் கொண்டு வரும். பெரும்பாலான பிரொவைடர்கள் இதை கமாண்ட் லைன் வழியாக அல்லாமல், கண்ட்ரோல் பேனல் அல்லது API வழியாக வழங்குகிறார்கள். எனவே, இதற்கான துல்லியமான வழிமுறைகள் உங்கள் பிரொவைடரைப் பொறுத்தது. மெஷின் எந்த மாற்றமும் இன்றி சாதாரணமாக இருக்கும்போதே ஸ்னாப்ஷாட் எடுப்பதே சிறந்த நடைமுறை.

உங்களுக்குத் தேவையான எதையும் இந்தத் தற்காலிக மெஷினில் வைத்திருக்காதீர்கள். அதாவது, பிராஞ்சுகளை (branches) லோக்கலில் சேமித்து வைப்பதற்குப் பதிலாக, புஷ் (push) செய்துவிடுங்கள். ஒருவேளை மெஷினில் நீங்கள் இழக்க விரும்பாத தரவுகள் இருந்தால், restic backups on a VPS மூலம் முறையாக பேக்கப் எடுங்கள். அழிப்பதற்கு ஏதுவான ஒரு மெஷின், அதை அழிப்பது எந்தப் பாதிப்பையும் ஏற்படுத்தாதபோது மட்டுமே பயனுள்ளதாக இருக்கும்.

பல சர்வர்களுக்குப் பணம் செலுத்தாமல், பல தனித்தனி சூழல்கள் (isolated environments) தேவைப்பட்டால், ஒரு பெரிய VPS-ஐக் கொண்டு நேரடியாக கெஸ்ட் VM-களை இயக்கலாம். Nested virtualisation on a VPS என்பது இது எவ்வாறு செயல்படுகிறது என்பதையும், உங்கள் பிரொவைடர் இதற்கு அனுமதி அளிக்கிறாரா என்பதை எவ்வாறு சரிபார்ப்பது என்பதையும் விளக்குகிறது.

மடிக்கணினியை கவனமாகப் பயன்படுத்தும்போது அது போதுமானதாக இருக்கும் சூழல்

இதனை வெளிப்படையாகக் கூறுவது அவசியம், ஏனெனில் தனிமைப்படுத்துதலை மிகைப்படுத்திக் கூறுவது பயனர்களின் கவனத்தை சிதறடிக்கும்.

ஒவ்வொரு கட்டளையையும் (command) இயக்கும் முன் நீங்கள் சரிபார்க்கிறீர்கள் என்றால், மடிக்கணினி போதுமானது. அனுமதி கோரும் சாளரம் (permission prompt) ஒரு உண்மையான கட்டுப்பாட்டு கருவியாகும். சர்வரில் Claude Code-ஐ பாதுகாப்பாக இயக்குவது குறித்த பகுதியில், ஒவ்வொரு நிலையும் எதனைத் தடுக்கிறது என்பது விளக்கப்பட்டுள்ளது. உங்கள் பணி ஒரே ஒரு களஞ்சியத்திற்குள் (repository) அடங்கி, அந்த கணினியில் எந்தவொரு தயாரிப்புச் சூழல் சான்றுகளும் (production credentials) இல்லை என்றால், பாதிப்பு ஏற்படும் வாய்ப்பு மிகக் குறைவு. உங்கள் ஏஜென்ட் அமர்வுகள் (agent sessions) குறுகிய காலமாகவும், உங்கள் கண்காணிப்பிலும் இருந்தால், ஆபத்துக்கான கால அவகாசமும் குறைவாகவே இருக்கும்.

நீங்கள் அனுமதி கோரும் சாளரங்களைத் தவிர்க்கும் தருணத்தில் நிலைமை மாறுகிறது. கவனிக்கப்படாத செயல்பாடுகள் (unattended runs), இரவு நேரப் பணிகள் மற்றும் ஒரு திட்டத்தை அங்கீகரித்துவிட்டு நீங்கள் விலகிச் செல்லும் எந்தவொரு பணிப்பாய்வும் (workflow), கட்டுப்பாட்டை உறுதி செய்யும் மனித மேற்பார்வையை நீக்கிவிடுகிறது. அந்தச் சூழலில், கணினியே அந்தப் பாதுகாப்பை உறுதி செய்ய வேண்டிய கட்டாயம் ஏற்படுகிறது. ஏஜென்ட்டின் அணுகல் எல்லையை விரிவுபடுத்தும் எதற்கும் இது பொருந்தும்; இதில் ஒரே நேரத்தில் பல களஞ்சியங்களில் கோடிங் ஏஜென்ட்டை இயக்குவது போன்றவையும் அடங்கும்.

இந்த முடிவு, நீங்கள் அந்த மாதிரியை (model) எவ்வளவு நம்புகிறீர்கள் என்பதைப் பொறுத்தது அல்ல. அந்த மாதிரி தவறான முடிவை எடுக்கும்போது, அதன் அருகில் என்னென்ன பாதுகாப்பு அம்சங்கள் உள்ளன என்பதைப் பொறுத்தது.

FAQ

கோடிங் ஏஜெண்டிற்கு கன்டெய்னர் (container) தனிமைப்படுத்துதல் போதுமானதா?

பெரும்பாலான பணிகளுக்கு, ஆம், இரண்டு நிபந்தனைகளுடன். கன்டெய்னர் --privileged உடன் இயங்கக்கூடாது, மேலும் அதில் /var/run/docker.sock மவுண்ட் (mount) செய்யப்பட்டிருக்கக்கூடாது. ஏனெனில் இவை இரண்டுமே அந்த ப்ராசஸிற்கு ஹோஸ்ட் (host) கணினியில் root உரிமையைப் பெற வழிவகுக்கும். ஒரு கன்டெய்னர் ஹோஸ்ட் கர்னலைப் (kernel) பகிர்ந்துகொள்வதால், அதன் எல்லை ஒரு விர்ச்சுவல் மெஷினை (virtual machine) விட பலவீனமானது. ஏஜெண்ட் இணையத்திலிருந்து பெறப்பட்ட நம்பகத்தன்மையற்ற குறியீட்டை இயக்குகிறது என்றால், உண்மையான VM அல்லது தனி சர்வரைப் பயன்படுத்துவது சிறந்தது.

சர்வரில் ஏஜெண்டிற்கு sudo தேவைப்படுமா?

தேவையில்லை. அதற்கு sudo வழங்குவது நீங்கள் உருவாக்கிய தனிமைப்படுத்துதலைச் செயலிழக்கச் செய்யும், ஏனெனில் root பயனர் கணினியில் உள்ள மற்ற அனைத்து கணக்குகளையும் அணுக முடியும். ஏஜெண்டிற்கான பயனர் கணக்கை sudo இல்லாமல் உருவாக்கி, அதன் சொந்த பணி அடைவிற்கு (work directory) மட்டும் எழுதும் உரிமையை (write access) வழங்கவும். ஒரு பணிக்குக் கண்டிப்பாக பேக்கேஜ் இன்ஸ்டாலேஷன் தேவைப்பட்டால், ஏஜெண்டிற்குப் பகிரப்பட்ட சர்வரில் root உரிமையை வழங்குவதற்குப் பதிலாக, அதற்குச் சொந்தமான ஒரு முழுமையான மெஷினை வழங்கவும்.

எனது SSH கீயை சர்வரில் வைக்காமல், ஏஜெண்டைக் கொண்டு git-ல் புஷ் (push) செய்வது எப்படி?

நீங்கள் கனெக்ட் செய்யும்போது ssh -A மூலம் உங்கள் SSH ஏஜெண்ட்டை ஃபார்வர்ட் (forward) செய்யவும். நீங்கள் கனெக்ட் செய்திருக்கும்போது சிக்னேச்சர் கோரிக்கைகள் அந்த கனெக்ஷன் வழியாகச் செல்லும், அதே சமயம் பிரைவேட் கீ உங்கள் லேப்டாப்பிலேயே இருக்கும். இதனால் ssh -T git@github.com அங்கீகரிக்கப்படும் மற்றும் git push சர்வரில் பிரைவேட் கீ இல்லாமலேயே செயல்படும். இதில் உள்ள சிக்கல் என்னவென்றால், நீங்கள் கனெக்ட் செய்திருக்கும்போது அந்த சர்வரில் உள்ள root பயனர் ஃபார்வர்ட் செய்யப்பட்ட சாக்கெட்டைப் (socket) பயன்படுத்த முடியும். எனவே, மற்றவர்களுடன் பகிரும் எந்தவொரு மெஷினிலும் ரெபாசிட்டரி-ஸ்கோப் செய்யப்பட்ட (repository-scoped) டிப்ளாய் கீயைப் (deploy key) பயன்படுத்தவும்.

ஏஜெண்டிற்கு எந்த அளவுள்ள VPS தேவை?

ஏஜெண்டின் பணி பெரும்பாலும் கோப்புகளை எடிட் செய்வது, பில்ட் (build) செய்வது மற்றும் டெஸ்டுகளை இயக்குவது போன்றவையாகும். எனவே, மெஷினின் அளவை மாடலுக்கு ஏற்ப அல்லாமல், பில்ட் செய்வதற்குத் தேவையான அளவிற்குத் தீர்மானிக்கவும். ஹோஸ்ட் செய்யப்பட்ட மாடல், சேவை வழங்குநரின் ஹார்டுவேரில் இயங்குகிறது, இது நெட்வொர்க் டிராஃபிக்கை மட்டுமே அதிகரிக்கும், உள்ளூர் சுமையை (local load) அதிகரிக்காது. ஸ்கிரிப்டிங் பணிகளுக்கு 2 GB RAM-ல் தொடங்கி, ரெபாசிட்டரி கன்டெய்னர்களை உருவாக்கினாலோ அல்லது பெரிய அளவிலான கம்பைலேஷன் (compilation) செய்தாலோ 8 GB-க்கு உயர்த்தவும்.

மெஷினை எவ்வளவு அடிக்கடி அழித்து மீண்டும் உருவாக்க வேண்டும்?

மெஷினின் நிலை (state) விளக்க முடியாததாக மாறும்போது அதை மீண்டும் உருவாக்கவும். குறைந்தபட்சம், மெஷினில் உள்ள ஏதேனும் ஒரு கிரெடென்ஷியல் (credential) கசிந்திருக்க வாய்ப்பிருந்தால் அதை மீண்டும் உருவாக்கவும். பணிகளுக்கு இடையே புதிய செக்-அவுட் (checkout) செய்வது அன்றாட மாற்றங்களைச் சமாளிக்க உதவும். முதல் ஏஜெண்ட் ரன்னிற்கு முன்பு எடுக்கப்பட்ட ஸ்னாப்ஷாட் (snapshot), நீங்கள் மீண்டும் பழைய நிலைக்குத் திரும்ப ஒரு சுத்தமான சிஸ்டம் இமேஜை (system image) வழங்கும். மெஷினை மீண்டும் உருவாக்குவது கடினமாகத் தோன்றினால், நீங்கள் பயன்படுத்தக்கூடியது (disposable) என்று கருதிய மெஷினில் ஏதோ முக்கியமான ஒன்று இருப்பதாக அர்த்தம்.