சிறந்த self-hosted Git server எது? Gitea, Forgejo ஒப்பீடு

எந்த self-hosted Git server-ஐ நீங்கள் இயக்க வேண்டும்

Self-hosted Git server என்பது ஒரே ஒரு தயாரிப்பு அல்ல. உங்கள் VPS-ல் உள்ள RAM (random access memory) அளவே நீங்கள் எந்தப் பதிப்பை இயக்க முடியும் என்பதைத் தீர்மானிக்கிறது. Git-க்கு என்று தனியாக daemon தேவையில்லை: ஒரு bare repository மற்றும் ஒரு SSH (secure shell) கணக்கு இருந்தாலே, நீங்கள் வாடகைக்கு எடுக்கக்கூடிய மிகச்சிறிய server-லும் அது வேலை செய்யும். அதற்கு மேல் உள்ள அனைத்தும் நீங்கள் கூடுதலாக இயக்கும் web application-கள் ஆகும். ஒவ்வொரு அடுத்த கட்டத்திற்கும் கூடுதல் memory தேவைப்படும், இது சிறிய VPS-ல் கிடைக்காமல் போகலாம்.

இதில் நான்கு நிலைகள் உள்ளன. SSH வழியாக இயங்கும் bare repository, இது ஏற்கனவே இயங்கிக்கொண்டிருக்கும் சேவைகளைத் தவிர வேறு எதையும் பயன்படுத்தாது. cgit, இது database இல்லாத வேகமான read-only web view ஆகும். Forgejo அல்லது Gitea, இது சில நூறு megabytes-ல் கணக்குகள், issues மற்றும் pull requests வசதிகளுடன் கூடிய முழுமையான forge ஆகும். GitLab, இது மற்றவற்றை விட பல மடங்கு பெரிய server-ஐ எதிர்பார்க்கிறது.

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

ஒவ்வொரு விருப்பத்திற்கும் தேவைப்படும் உண்மையான RAM அளவு

இத்திட்டங்களில் இரண்டு மட்டுமே வன்பொருள் தேவைகளை வெளியிடுகின்றன. வெளியிடப்பட்ட அளவை ஒரு உறுதிமொழியாகக் கருதாமல், குறைந்தபட்ச அளவாகக் கருதுங்கள். உங்கள் instance இயங்கத் தொடங்கியதும், systemd-cgtop அல்லது ps -o rss= -C forgejo மூலம் அதன் பயன்பாட்டை நீங்களே அளவிடுங்கள்.

[
  {
    "label": "Gitea, small team",
    "ram_gb": 1
  },
  {
    "label": "GitLab, memory constrained",
    "ram_gb": 8
  },
  {
    "label": "GitLab, single node baseline",
    "ram_gb": 16
  }
]

சிறிய குழுக்கள் மற்றும் திட்டங்களுக்கு 2 CPU cores உடன் 1 GB RAM போதுமானது என்று Gitea ஆவணப்படுத்துகிறது; சிறிய வேலைகளுக்கு Raspberry Pi 3 போதுமானது என்றும் குறிப்பிடுகிறது. GitLab ஒரு single node நிறுவலுக்கு 16 GB அளவை அடிப்படைத் தேவையாகக் குறிப்பிடுகிறது, மேலும் நினைவகக் கட்டுப்பாடுள்ள சூழலுக்கு 8 GB அளவை குறைந்தபட்சத் தேவையாகக் குறிப்பிடுகிறது. Forgejo எந்த வன்பொருள் தேவையையும் வெளியிடுவதில்லை. இது Gitea-வின் fork என்பதால், அதன் செயல்பாடும் அவ்வாறே இருக்கும்; எனவே Gitea-வின் அளவீடே உங்களுக்குக் கிடைக்கும் மிக நெருக்கமான வழிகாட்டியாகும்.

1 GB VPS-ல் இதன் பொருள் என்னவென்றால்: bare repositories மற்றும் cgit ஆகியவை எஞ்சிய நினைவகத்துடன் இயங்கும், ஏனெனில் இவை இரண்டிற்கும் resident service தேவையில்லை. Forgejo அல்லது Gitea ஆகியவை SQLite-ல் ஒரு சிறிய குழுவிற்குச் சேவை செய்யும், ஆனால் நீங்கள் ஆவணப்படுத்தப்பட்ட குறைந்தபட்ச எல்லையில் இருப்பதால், PostgreSQL மற்றும் CI (continuous integration) runner ஆகியவற்றை அந்த server-ல் தவிர்க்கவும். பிழைச் செய்தி ஏதுமின்றி web interface மறைந்துவிட்டால், sudo dmesg -T | grep -i oom கட்டளையை இயக்கி, Out of memory: Killed process 1181 (forgejo) போன்ற வரியைத் தேடுங்கள்; இது kernel-ன் out of memory killer அந்தச் செயல்முறையை நிறுத்தியதைக் குறிக்கிறது. 1 GB server-ல் GitLab-ஐ இயக்குவது என்பது tuning தொடர்பான சிக்கல் அல்ல; அது இயங்காது.

Tier 0: SSH வழியாக ஒரு bare repository

Git-க்கு நீங்கள் தொடங்க வேண்டிய network daemon எதுவும் இல்லை. SSH வழியாக git push இயங்கும்போது, அது தொலைதூர முனையில் ஒரு சாதாரண Unix process-ஆக git-receive-pack-ஐ இயக்குகிறது. எனவே, ஒரு key மூலம் நீங்கள் அணுகக்கூடிய எந்தவொரு account-ம் ஏற்கனவே ஒரு Git remote-ஆகச் செயல்படும். repositories-க்காக ஒரு தனி account-ஐ உருவாக்கி, அவற்றை அதன் home directory-க்கு வெளியே வைக்கவும். ஏனெனில், Ubuntu 24.04-ல் புதிய home directory-கள் 0750 mode-ல் இருக்கும், இதனால் பிற்காலத்தில் சேர்க்கப்படும் web view-ஆல் அவற்றை வாசிக்க முடியாது.

sudo adduser --system --shell /bin/bash --gecos 'Git Version Control' \
  --group --disabled-password --home /home/git git
sudo install -d -m 0755 -o git -g git /srv/git
sudo -u git git init --bare /srv/git/project.git

--bare என்பது working copy இல்லாத ஒரு repository-ஐ உருவாக்குகிறது; இதுவே ஒரு server-ல் இருக்க வேண்டிய அமைப்பாகும். working copy உள்ள ஒரு repository-க்குள் push செய்ய முயன்றால், அது refusing to update checked out branch: refs/heads/main பிழையுடன் நிராகரிக்கப்படும்; இந்த நிலையில் இதுவே மிகவும் பொதுவான தவறு.

இப்போது அந்த account-க்கு ஒரு key-ஐ வழங்கி, அதை clone செய்யவும்.

sudo -u git install -d -m 700 /home/git/.ssh
sudo -u git tee -a /home/git/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice@laptop
EOF
sudo -u git chmod 600 /home/git/.ssh/authorized_keys

git remote add origin git@vps.example.com:/srv/git/project.git
git push -u origin main

வெற்றிகரமாக முடிந்த முதல் push, * [new branch] main -> main என்று முடிவடையும். git@vps.example.com: Permission denied (publickey) என்று முடிந்தால், அது அங்கீகரிக்கப்படவில்லை (authenticated) என்று பொருள்; எனவே sudo journalctl -u ssh -n 20 மூலம் server log-ஐப் பார்க்கவும். Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys என்று ஒரு வரி இருந்தால், file mode தவறாக உள்ளது என்று பொருள்; ஏனெனில், மற்ற பயனர்கள் எழுதக்கூடிய key file-ஐ sshd நிராகரித்துவிடும்.

பிறகு, அந்த account-க்கான shell அணுகலை நீக்கவும்.

command -v git-shell | sudo tee -a /etc/shells
sudo chsh -s "$(command -v git-shell)" git

git-shell என்பது SSH வழியாக Git அனுப்பும் குறிப்பிட்ட சில கட்டளைகளை மட்டுமே ஏற்கும். எனவே, இப்போது interactive login செய்ய முயன்றால், prompt-க்கு பதிலாக ஒரு செய்தி காட்டப்பட்டு செயல்பாடு நின்றுவிடும்:

fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.

இதுவே முழுமையான server அமைப்பு. இதில் database கிடையாது, upgrade செய்ய வேண்டிய web process-ம் இல்லை. இதில் நீங்கள் இழப்பது ஒரு forge வழங்கும் வசதிகள் மட்டுமே: browsing, issue tracker, pull requests மற்றும் பயனர் வாரியான அனுமதிகள் (per-user permission) இதில் இருக்காது. அந்த file-ல் உள்ள ஒவ்வொரு key-ம் git பயனருக்குச் சொந்தமான அனைத்து repository-களையும் வாசிக்கவும் எழுதவும் முடியும்.

Tier 1: cgit தரவுத்தளம் இன்றி இணையக் காட்சியை வழங்குகிறது

cgit என்பது C மொழியில் எழுதப்பட்ட ஒரு CGI (common gateway interface) நிரலாகும். இணைய சேவையகம் (web server) ஒவ்வொரு கோரிக்கைக்கும் (request) இதை ஒருமுறை இயக்கும். இது repositories-ஐ நேரடியாக வட்டில் (disk) இருந்து வாசிக்கும், மேலும் இது எந்தவொரு நிலையையும் (state) தனக்கென சேமித்து வைப்பதில்லை. Ubuntu 24.04-ன் universe தொகுப்பில் இது கிடைக்கிறது.

sudo apt update
sudo apt install -y cgit fcgiwrap nginx
sudo install -d -o www-data -g www-data /var/cache/cgit

இதை /etc/cgitrc-ல் உள்ள repository கோப்பகத்திற்கு (directory) சுட்டிக்காட்டவும்:

root-title=Git on example.com
css=/cgit.css
logo=/cgit.png
cache-size=1000
cache-root=/var/cache/cgit
snapshots=tar.gz zip
scan-path=/srv/git

scan-path அந்த கோப்பகத்தை ஆய்வு செய்து, அதில் கண்டறியும் அனைத்து repositories-களையும் பட்டியலிடும். எனவே, புதிய bare repo எவ்வித கூடுதல் அமைப்புகளும் இன்றி தானாகவே தோன்றும். cache-size என்பது தற்காலிகமாக சேமிக்கப்பட்ட (cached) பக்கங்களின் எண்ணிக்கை ஆகும். இதன் மதிப்பு பூஜ்ஜியமாக இருக்கும் வரை caching இயங்காது. நீங்கள் புதிய வரிகளைச் சேர்ப்பதற்கு முன், உங்கள் தொகுப்பு ஏற்கனவே /etc/cgitrc-ல் என்ன அமைப்புகளைக் கொண்டுள்ளது என்பதைப் படிக்கவும், ஏனெனில் Debian மற்றும் Ubuntu தொகுப்புகள் சில இயல்புநிலை அமைப்புகளைக் கொண்டுள்ளன.

ஒவ்வொரு பதிவும் அந்த repository-ன் description கோப்பின் முதல் வரியைக் காட்டும். எனவே, ஒரு புதிய bare repo தன்னை Unnamed repository; edit this file 'description' to name the repository. என்று பட்டியலிடும். இதை ஒவ்வொரு repository-க்கும் ஒருமுறை சரிசெய்யவும்:

echo 'Project X, internal tooling' | sudo -u git tee /srv/git/project.git/description

server {
    listen 80;
    server_name git.example.com;
    root /usr/share/cgit;

    try_files $uri @cgit;

    location @cgit {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi;
        fastcgi_param PATH_INFO $uri;
        fastcgi_param QUERY_STRING $args;
        fastcgi_param HTTP_HOST $server_name;
        fastcgi_pass unix:/run/fcgiwrap.socket;
    }
}

sudo systemctl enable --now fcgiwrap.socket
sudo nginx -t && sudo systemctl reload nginx
systemctl show fcgiwrap.socket -p Listen

இதை உருவாக்குவதற்கு முன் இரண்டு வரம்புகளைத் தெரிந்துகொள்வது அவசியம். cgit என்பது read-only மற்றும் இதில் login வசதி இல்லை, எனவே scan-path-க்கு கீழ் உள்ள அனைத்தும் பொதுவானவை (public). ஒரு private repository-ஐ அந்த கோப்பகத்திற்கு வெளியே வைக்கவும், அல்லது முழு தளத்திற்கும் முன்னால் HTTP basic authentication-ஐச் சேர்க்கவும். மேலும், இந்த CGI இணைய சேவையக பயனராக (web server user) இயங்குகிறது, எனவே அந்த பயனர் /srv/git-ஐ அணுகவும், ஒவ்வொரு repository-ஐயும் வாசிக்கவும் அனுமதி தேவை. அந்த பயனரால் நுழைய முடியாத கோப்பகம் பிழையைக் காட்டாமல், காலியான பட்டியலாகவே தோன்றும்.

Tier 2: சிக்கல்கள் மற்றும் pull requests-க்கான Forgejo அல்லது Gitea

Forgejo மற்றும் Gitea ஆகிய இரண்டும் ஒரே கருத்தைக் கொண்டவை: பயனர்கள், நிறுவனங்கள், சிக்கல்கள் (issues), pull requests, releases, package registry மற்றும் உள்ளமைக்கப்பட்ட CI அமைப்பு ஆகியவற்றுடன் கூடிய ஒரு web forge-ஐ வழங்கும் ஒற்றை Go binary. Binary மற்றும் SQLite மட்டுமே முழுமையான நிறுவல் என்பதால், GitLab-ஐ இயக்க முடியாத வன்பொருளிலும் இவை இயங்கும். கீழே உள்ள Compose file, Forgejo ஆவணத்தில் உள்ளது; ஆகஸ்ட் 2026 நிலவரப்படி அதில் குறிப்பிடப்பட்டுள்ள image tag பயன்படுத்தப்பட்டுள்ளது.

networks:
  forgejo:
    external: false

services:
  server:
    image: codeberg.org/forgejo/forgejo:16
    container_name: forgejo
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: always
    networks:
      - forgejo
    volumes:
      - ./forgejo:/data
      - /etc/localtime:/etc/localtime:ro
    ports:
      - '3000:3000'
      - '222:22'

docker compose up -d
docker compose ps
curl -sI http://127.0.0.1:3000 | head -1

curl வரியானது HTTP status line-ஐக் காட்ட வேண்டும். முதல்முறை அமைப்பை (first-run setup) முடிப்பதற்கு முன், இது /install-க்கு வழிமாற்றலாம் (redirect), இது சேவை இயங்குகிறது என்பதையே குறிக்கும். மாறாக container வெளியேறினால் (exits), அதற்குப் பொதுவான காரணம் ownership ஆகும்: ./forgejo கோப்பகம் USER_UID-ல் உள்ள UID (user id)-க்குச் சொந்தமானதாக இருக்க வேண்டும், இல்லையெனில் அந்த process-ஆல் அதன் சொந்த தரவுக் கோப்பகத்தில் எழுத முடியாது. Docker Compose on a VPS அந்த file layout மற்றும் volume ownership விதியை முழுமையாக விளக்குகிறது.

setup பக்கத்தில் உள்ள இரண்டு பதில்கள் clone URL-கள் வேலை செய்யுமா என்பதைத் தீர்மானிக்கின்றன. SSH port 222 ஆக இருக்க வேண்டும், ஏனெனில் Compose file host port 222-ஐ container-ன் port 22-க்கு map செய்கிறது. மேலும், domain என்பது பயனர்கள் உண்மையில் தட்டச்சு செய்யும் பெயராக இருக்க வேண்டும். இதில் தவறு செய்தால், ஒவ்வொரு repository பக்கத்திலும் காட்டப்படும் clone command-ஐ நகலெடுக்கும் அனைவருக்கும் அது தோல்வியடையும். இவை இரண்டும் பின்னர் app.ini-ன் [server] பகுதியில் SSH_PORT, SSH_DOMAIN மற்றும் ROOT_URL என அமையும்.

பொதுப் பயன்பாட்டிற்கான instance-க்கு, web port-ஐ loopback முகவரியில் மட்டும் ('127.0.0.1:3000:3000') வெளியிடவும், TLS (transport layer security)-க்காக அதற்கு முன்னால் nginx-ஐப் பயன்படுத்தவும். Gitea-வும் அதே gitea/gitea image மூலம் இதே முறையில் நிறுவப்படும், அல்லது ஒரு systemd unit மற்றும் ஒரு app.ini கொண்ட ஒற்றை binary-ஆக நிறுவலாம். ஆகஸ்ட் 2026 நிலவரப்படி இதன் தற்போதைய stable release 1.27.1 ஆகும்.

முடிந்தவரை SQLite-லேயே இருக்கவும். இது instance-ஐ ஒரே process மற்றும் ஒரே கோப்பாக வைத்திருக்கும், மேலும் reboot-க்குப் பிறகு கூடுதல் சேவை எதையும் கண்காணிக்க வேண்டிய அவசியமின்றி இது இயங்கும். பல பயனர்கள் ஒரே நேரத்தில் எழுதும் சூழலில் மட்டுமே PostgreSQL-ன் தேவை எழுகிறது, ஏனெனில் SQLite எழுதும் பணிகளை வரிசைப்படுத்தும் (serialises), மேலும் நீண்ட CI ஓட்டங்கள் தொடர்ந்து எழுதும் பணிகளைக் கொண்டிருக்கும். இரண்டு திட்டங்களுமே ஏற்கனவே உள்ள instance-ஐப் பின்னர் PostgreSQL-க்கு மாற்ற அனுமதிக்கும் என்பதால், இது நிரந்தரமான முடிவு அல்ல.

Forgejo அல்லது Gitea: உண்மையில் என்ன வேறுபாடு

இவை இரண்டும் ஒரே வம்சாவளியைச் சேர்ந்தவை. Gitea, 2016-ல் Gogs-லிருந்து பிரிக்கப்பட்டது (forked). 2022-ன் இறுதியில், Gitea domain மற்றும் trademark-ன் கட்டுப்பாடு Gitea Ltd என்ற நிறுவனத்திற்குச் சென்றது. இதைத் தொடர்ந்து, பல பராமரிப்பாளர்கள் (maintainers) இணைந்து Codeberg-ன் கீழ் Forgejo-வைத் தொடங்கினர். Forgejo, ஜெர்மனியில் பதிவுசெய்யப்பட்ட இலாப நோக்கற்ற அமைப்பான Codeberg e.V.-ஆல் வெளியிடப்படுகிறது. இது 2024-ல் MIT உரிமத்திலிருந்து GPLv3 (GNU general public license version 3) உரிமத்திற்கு மாறியது. Gitea தொடர்ந்து MIT உரிமத்திலேயே உள்ளது மற்றும் வணிக ரீதியான ஆதரவுடன் உருவாக்கப்படுகிறது.

தினசரி பயன்பாட்டில், இவற்றின் அம்சங்கள் (feature sets) நெருக்கமாகவே உள்ளன. ஆனால், அவற்றுக்கு இடையேயான மாற்றம் எளிதானதல்ல. ஜனவரி 2025-ல் வெளியான Forgejo v10.0 தான், Gitea database-ஐ நேரடியாகப் பயன்படுத்தக்கூடிய கடைசி பதிப்பாகும்; அதுவும் Gitea v1.22 அல்லது அதற்கு முந்தைய பதிப்புகளுக்கு மட்டுமே பொருந்தும். ஆகஸ்ட் 2026 நிலவரப்படி, Gitea v1.27.1-ல் உள்ளது. எனவே, தற்போதைய Gitea instance-ஐ நேரடியாக Forgejo-விற்கு மாற்ற ஆதரவு இல்லை. தரவுகளை உள்ளிடுவதற்கு முன்பே ஏதேனும் ஒன்றை முடிவு செய்யுங்கள். பிற்காலத்தில் மாற நினைத்தால், அதை export மற்றும் re-import முறையிலேயே செய்ய வேண்டும்.

தேர்வு செய்வதற்கான ஒரு எளிய விதி: நிர்வாகக் கட்டமைப்பு (governance) உங்களுக்கு முக்கியமென்றால் அல்லது திட்டம் இலாப நோக்கற்ற அமைப்பின் கீழ் இருக்க வேண்டுமென்றால், Forgejo-வைப் பயன்படுத்துங்கள். அதிகப்படியான பயனர்கள் மற்றும் வணிக ரீதியான ஆதரவு தேவைப்பட்டால், Gitea-வைப் பயன்படுத்துங்கள். இரண்டுமே வெளிப்படையாகப் பராமரிக்கப்படுகின்றன மற்றும் அடிக்கடி புதிய பதிப்புகளை வெளியிடுகின்றன: Forgejo ஒவ்வொரு மூன்று மாதங்களுக்கும் ஒரு stable release-ஐயும், ஒவ்வொரு ஆண்டும் ஒரு LTS (long term support) release-ஐயும் வெளியிடுகிறது. ஆகஸ்ட் 2026 நிலவரப்படி, v16.0.2 தற்போதைய பதிப்பாகவும், v15.0.6 LTS பதிப்பாகவும் உள்ளன.

Tier 3: GitLab எதையும் செய்வதற்கு முன்பே ஏற்படும் செலவுகள்

GitLab CE என்பது ஒரு தனித்துவமான மென்பொருள் வகை. ஒரு instance என்பது ஒன்றிணைந்து செயல்படும் பல சேவைகளின் தொகுப்பாகும்: web application-க்காக Puma, background jobs-க்காக Sidekiq, PostgreSQL, Redis, repository access-க்காக Gitaly மற்றும் முன்பக்கத்தில் nginx. Omnibus package இவை அனைத்தையும் ஒன்றாக நிறுவுகிறது; இது நிறுவலை எளிதாக்குகிறது, ஆனால் நினைவகத் தேவையை (memory floor) அதிகரிக்கிறது.

GitLab-ன் requirements பக்கம், ஒரு single node நிறுவலுக்கு 16 GB RAM மற்றும் 8 vCPU-வை அடிப்படைத் தேவையாகக் குறிப்பிடுகிறது. நினைவகம் குறைவாக உள்ள சூழலில் 8 GB குறைந்தபட்சத் தேவையாகக் குறிப்பிடப்பட்டுள்ளது. அதே பக்கம் swap-ஐ முடக்கவும் அறிவுறுத்துகிறது, ஏனெனில் சுமையின் கீழ் swap செய்வது instance-ன் செயல்பாட்டை மோசமாகப் பாதிக்கும். இவை ஆகஸ்ட் 2026 நிலவரப்படி வெளியிடப்பட்ட புள்ளிவிவரங்கள். இவை காலப்போக்கில் அதிகரித்துள்ளன, எனவே server-ன் அளவைத் தீர்மானிக்கும் முன் அந்தப் பக்கத்தை மீண்டும் ஒருமுறை சரிபார்க்கவும்.

இந்த பட்ஜெட்டிற்கு நீங்கள் உண்மையான பயன்களைப் பெறுவீர்கள்: container registry, package registry, நுணுக்கமான permissions, compliance மற்றும் audit அம்சங்கள், மற்றும் பெரிய அளவில் சோதிக்கப்பட்ட CI. உங்கள் குழுவில் உள்ள எவருக்கும் இந்த பட்டியலில் உள்ள எந்தவொரு அம்சமும் இந்த காலாண்டில் தேவைப்படாது என்றால், நீங்கள் எதற்கும் பயன்படாத ஒரு பெரிய VPS-க்காக பணம் செலவழிக்கிறீர்கள் என்று அர்த்தம்.

SSH அணுகல் மாதிரி: ஒரு git பயனர் மற்றும் பல சாவிகள்

இங்குள்ள ஒவ்வொரு அடுக்கும் ஒரே முறையில் அங்கீகரிக்கப்படுகிறது. git என்ற பெயரில் ஒரு Unix கணக்கு உள்ளது, மேலும் ஒவ்வொரு பொதுச் சாவியும் (public key) அந்தக் கணக்கின் ~/.ssh/authorized_keys கோப்பில் சேர்க்கப்படுகிறது. அங்கீகாரம் என்பது சாவியை அடிப்படையாகக் கொண்டது. அங்கீகாரம் (Authorisation) என்பது அதே வரியில் சாவிக்கு முன்னால் நீங்கள் குறிப்பிடும் விருப்பத்தேர்வுகளைப் பொறுத்தது.

சாதாரண சாவி வரி, அந்தக் கணக்கிற்கு என்னென்ன செய்ய முடியுமோ, அத்தனையையும் அந்தச் சாவியை வைத்திருப்பவருக்கு வழங்குகிறது. ஒரு கட்டாயக் கட்டளை (forced command) அதை Git-க்கு மட்டும் சுருக்குகிறது:

restrict,command="git-shell -c \"$SSH_ORIGINAL_COMMAND\"" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice@laptop

OpenSSH 7.2 முதல் கிடைக்கும் restrict, port forwarding, agent forwarding, X11 மற்றும் PTY (pseudo terminal) ஒதுக்கீடு ஆகியவற்றை ஒரே சொல்லில் முடக்குகிறது. command=, கிளையண்ட் கோரியதை நீங்கள் குறிப்பிடும் கட்டளையாக மாற்றுகிறது. Git தனது கோரிக்கையை $SSH_ORIGINAL_COMMAND வழியாக அனுப்புவதால், Git தொடர்ந்து வேலை செய்யும்.

ஒரு forge மென்பொருள் உங்களுக்காக அந்தக் கோப்பை எழுதும்; இதுவே அடுக்கு 0 மற்றும் அடுக்கு 2-க்கு இடையிலான உண்மையான வேறுபாடு. Forgejo மற்றும் Gitea ஆகியவை authorized_keys கோப்பை ஒவ்வொரு பதிவு செய்யப்பட்ட சாவிக்கும் ஒரு வரி வீதம் மீண்டும் எழுதுகின்றன. ஒவ்வொன்றும் அதன் தரவுத்தள அடையாளத்தை (database id) குறிப்பிடும் ஒரு கட்டாயக் கட்டளையைக் கொண்டிருக்கும்:

command="/usr/local/bin/forgejo --config=/etc/forgejo/app.ini serv key-3",no-port-forwarding,no-x11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice

அந்தக் கட்டாயக் கட்டளைதான் ஒரு பகிரப்பட்ட Unix கணக்கை, தனிநபர் அனுமதி கொண்ட கணக்காக மாற்றுகிறது: key-3, எந்தப் பயனர் இணைகிறார் என்பதை forge-க்குத் தெரிவிக்கிறது. தரவுகள் பரிமாறப்படுவதற்கு முன்பே, அந்தப் பயனர் அந்த repository-ஐ அணுக அனுமதி உள்ளதா என்பதை அது சரிபார்க்கிறது. forge மூலம் நிர்வகிக்கப்படும் கணினியில் அந்தக் கோப்பை நீங்களாகத் திருத்த வேண்டாம்; ஏனெனில் அது தரவுத்தளத்திலிருந்து மீண்டும் எழுதப்படும்போது உங்கள் வரி நீக்கப்பட்டுவிடும். Deploy keys-ம் இதே பொறிமுறையில்தான் செயல்படுகின்றன: ஒரு deploy key என்பது ஒரு குறிப்பிட்ட repository-க்காகப் பதிவு செய்யப்பட்ட சாதாரண SSH சாவி. இது பொதுவாக read-only முறையில் இருக்கும், மேலும் சரிபார்ப்பு sshd-க்கு பதிலாக forge-ல் நடைபெறும்.

மேலே உள்ள எந்தவொரு உள்ளமைப்பை விடவும் இரண்டு பழக்கங்கள் முக்கியமானவை. ஒரு நபருக்கு அல்லது ஒரு இயந்திரத்திற்கு ஒரு சாவி மட்டுமே வழங்கவும்; ஒருபோதும் பகிரப்பட்ட சாவியைப் பயன்படுத்த வேண்டாம். ஏனெனில் பகிரப்பட்ட சாவியை நீக்குவது என்பது அனைவருக்கும் ஒரே நேரத்தில் அதை மாற்றுவதைக் குறிக்கும். மேலும், ஒருவர் வெளியேறிய அன்றே அவரது சாவியை நீக்கிவிடவும், ஏனெனில் அந்தக் கோப்பில் இருக்கும் பழைய சாவி, யாரும் கவனிக்காத ஒரு நிரந்தர நுழைவு வாயிலாக மாறிவிடும். சர்வரில் சிறந்த SSH சாவி மேலாண்மை என்பது சாவி வகைகள் மற்றும் கடவுச்சொற்றொடர்களைப் (passphrases) பற்றி விளக்குகிறது, அது இங்கும் அப்படியே பொருந்தும். சர்வர் புதியது என்றால், repository-களை வைப்பதற்கு முன் புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்ற வழிகாட்டியைப் பின்பற்றுவது சரியானதாகும்.

எனது சொந்த Git server-ல் GitHub Actions-ஐ இயக்க முடியுமா?

GitHub Actions syntax-ல் எழுதப்பட்ட workflows-ஐ நீங்கள் இயக்க முடியும். ஆனால், GitHub-ஐ உங்களால் இயக்க முடியாது. Forgejo v1.21 பதிப்பிலிருந்து Forgejo Actions இயல்பாகவே செயல்படுத்தப்பட்டுள்ளது; இது ஒவ்வொரு repository-லும் உள்ள .forgejo/workflows கோப்புகளிலிருந்து workflow-களை வாசிக்கும். Gitea Actions-ம் இதே முறையில் செயல்பட்டு .gitea/workflows கோப்புகளை வாசிக்கும். இவை இரண்டிற்கும் runner எனப்படும் இரண்டாவது நிரல் தேவைப்படுகிறது. இதை நிறுவி, admin settings-லிருந்து பெறப்பட்ட token மூலம் உங்கள் instance-உடன் பதிவு செய்ய வேண்டும். வெளியிடப்பட்ட பல actions மாற்றமின்றி இயங்கும்; ஆனால் GitHub API-ஐ அழைக்கும் அல்லது GitHub-ன் உள்கட்டமைப்பை எதிர்பார்க்கும் எந்தவொரு செயலும் இயங்காது.

இதன் விளைவாக இரண்டு விஷயங்களைக் கவனத்தில் கொள்ள வேண்டும். ஒவ்வொரு job-க்கும் runner ஒரு container-ஐத் தொடங்கும், எனவே அதற்குத் தனி container engine மற்றும் memory ஒதுக்கீடு தேவை. இதனால்தான், 1 GB அளவுள்ள forge server-ல் இதை நிறுவக்கூடாது. மேலும், workflow கோப்பில் உள்ள எதையும் runner செயல்படுத்தும். Forgejo-வின் ஆவணங்கள் தெளிவாகக் கூறுவது போல, runner ஒரு remote code execution-ஐச் செய்கிறது. முடிந்தவரை இதற்குத் தனி host-ஐ ஒதுக்குங்கள், அல்லது குறைந்தபட்சம் privileged அல்லாத user-ஐ உருவாக்கி, ஒரு குறிப்பிட்ட repository-க்கு மட்டும் கட்டுப்படுத்தப்பட்ட registration token-ஐப் பயன்படுத்துங்கள்.

உங்கள் repositories GitHub-லேயே இருந்து, நீங்கள் கட்டுப்படுத்தும் hardware-ல் மட்டும் compute வசதி தேவைப்பட்டால், அது வேறுபட்ட அமைப்பு மற்றும் படிகளைக் கொண்டது: a self-hosted GitHub Actions runner ஒரு GitHub repository-உடன் இணையும், இதற்கு மேற்கூறியவை எதுவும் தேவையில்லை. நீங்கள் GitHub-லிருந்து வெளியேறுவதால் ஏற்படும் செலவுகளை இன்னும் கணக்கிட்டுக்கொண்டிருக்கிறீர்கள் என்றால், what GitHub actually gives you என்ற கட்டுரை Git hosting-க்கும் அதைச் சுற்றியுள்ள network வசதிகளுக்கும் உள்ள வித்தியாசத்தைப் பிரித்துக் காட்டும்.

Backups: repositories என்பது நிலையின் ஒரு பகுதி மட்டுமே

Bare repository என்பது ஒரு directory ஆகும், எனவே அதை நகலெடுக்கும்போது அதிலுள்ள அனைத்தும் நகலெடுக்கப்படும். மற்றொரு machine-லிருந்து செய்யப்படும் mirror clone ஒரு உண்மையான backup ஆகும், இது அந்த இடத்திலேயே புதுப்பிக்கப்படும்:

git clone --mirror git@vps.example.com:/srv/git/project.git
cd project.git && git remote update

இது ஒவ்வொரு ref மற்றும் ஒவ்வொரு object-ஐயும் இழுக்கும். இது server-side hooks அல்லது description கோப்பை இழுக்காது, எனவே நீங்கள் hooks பயன்படுத்தினால், directory-யின் கோப்பு அளவிலான நகலையும் வைத்துக்கொள்ளுங்கள்.

ஒரு forge அதன் database-ல் issues, pull requests, users, keys மற்றும் permissions ஆகியவற்றை வைத்திருக்கும், repositories-ஐ மட்டும் நகலெடுப்பது இவை அனைத்தையும் இழக்கச் செய்யும். இரண்டு திட்டங்களும் database, repositories, configuration மற்றும் attachments ஆகியவற்றை ஒரே archive-ஆக எழுதும் dump கட்டளையை வழங்குகின்றன:

sudo -u git forgejo dump -c /etc/forgejo/app.ini -f /var/backups/forgejo-dump.zip

Docker-ல் அதே கட்டளை container-க்குள் இயங்கும், மேலும் configuration பாதை image-ஐப் பொறுத்தது, எனவே தட்டச்சு செய்வதற்கு முன் கவனிக்கவும்:

docker compose exec server ls /data/gitea/conf
docker compose exec -u git server forgejo dump -c /data/gitea/conf/app.ini

தரவுகளுக்கு உரிமையாளராக உள்ள user-ஆக அதை இயக்கவும், அந்த user எழுதக்கூடிய directory-யில் archive-ஐ எழுதவும். பின்னர் archive-ஐ server-லிருந்து வெளியே நகலெடுக்கவும், ஏனெனில் backup செய்யப்படும் machine-ல் மட்டுமே இருக்கும் backup, உண்மையான backup ஆகாது. Restore செய்வது மக்கள் தவிர்க்கும் ஒரு படிநிலை: இப்போது ஒரு spare box-ல் ஒரு dump-ஐ unpack செய்யவும், அப்போதுதான் ஒரு outage ஏற்படும்போது அல்லாமல், அமைதியான நேரத்தில் அந்த நடைமுறையை நீங்கள் கற்றுக்கொள்ள முடியும்.

சூழல் வாரியான தேர்வு

ஒரு நபர், ஒரு மடிக்கணினி மற்றும் ஒரு VPS, உலாவல் (browsing) தேவையில்லை என்றால்: SSH வழியாக bare repositories-ஐப் பயன்படுத்தவும். இதில் கூடுதல் service எதுவும் இயங்காது, எதையும் upgrade செய்ய வேண்டிய அவசியமும் இல்லை.

அதே சூழல், ஆனால் குறியீட்டை (code) உலாவியில் பார்க்கவும், அதற்கான இணைப்புகளைப் பகிரவும் விரும்பினால்: cgit-ஐச் சேர்க்கவும். இதற்கும் database தேவையில்லை, பின்னணியில் எந்த service-ம் இயங்காது.

குறியீட்டை ஆய்வு செய்து (review), சிக்கல்களைக் கண்காணிக்கும் (track issues) குழுவிற்கு: 2 GB RAM அல்லது அதற்கு மேற்பட்ட வசதி கொண்ட server-ல் Forgejo அல்லது Gitea-ஐப் பயன்படுத்தவும். CI வேலைகள் அதிகரிக்கும் போது, CI runner-ஐ மற்றொரு server-க்கு மாற்றவும்.

Container registry மற்றும் audit trails தேவைப்படும் நிறுவனங்களுக்கு, 16 GB RAM வசதி கொண்ட server-ல் GitLab-ஐப் பயன்படுத்தவும். இந்த அளவு RAM வசதி இல்லையெனில், GitLab-ஐத் தொடங்க வேண்டாம்.

முதல் மூன்று நிலைகளில் இருந்து அடுத்த நிலைக்கு மாறுவது எளிது, ஏனெனில் இவை அனைத்திலும் repositories என்பவை வட்டில் (disk) உள்ள சாதாரண Git directories-தான். உங்கள் தேவைக்கு ஏற்ற மிகக் குறைந்த நிலையில் தொடங்கவும். அதே server-ல் வேறு என்னென்ன சேவைகளை இயக்கலாம் என்று நீங்கள் திட்டமிட்டால், சுய-வழங்கலில் (self-hosting) பயனுள்ள சேவைகளின் பட்டியல் Git server-ஐ மற்ற சேவைகளுடன் ஒப்பிட்டு, RAM பயன்பாட்டிற்கு ஏற்ப தேர்வு செய்ய உதவும்.

FAQ

1 GB VPS-ல் Forgejo அல்லது Gitea-ஐ இயக்க முடியுமா?

ஆம், சிறிய குழுக்களுக்கு, SQLite பயன்படுத்தும் பட்சத்தில், அந்த server-ல் வேறு கனமான பயன்பாடுகள் இல்லாதவரை இயக்க முடியும். Gitea-ன் ஆவணங்களின்படி, 1 GB RAM மற்றும் 2 CPU cores சிறிய குழுக்களுக்கும் திட்டங்களுக்கும் போதுமானது. Forgejo என்பது Gitea-ன் ஒரு fork என்பதால், அதன் தேவைகளும் அதே போன்றதே. அந்த machine-ல் PostgreSQL அல்லது CI runner-ஐச் சேர்க்க வேண்டாம். service-ன் சொந்த log-ல் எந்தப் பிழையும் இல்லாமல் அது திடீரென நின்றால், sudo dmesg -T | grep -i oom கட்டளையை இயக்கவும்: அதில் ஒரு process-ன் பெயர் இருந்தால், kernel-ன் out of memory killer அதை நிறுத்தியுள்ளது என்று அர்த்தம். இதற்கு tuning flag-களை விட, அதிக வசதி கொண்ட server plan-க்கு மாறுவதே தீர்வாகும்.

Forgejo மற்றும் Gitea-க்கு இடையே உள்ள வேறுபாடு என்ன?

இவை இரண்டும் ஒரே codebase வரலாற்றையும் பெரும்பாலான அம்சங்களையும் பகிர்ந்து கொள்கின்றன. Gitea 2016-ல் Gogs-லிருந்து பிரிக்கப்பட்டது (forked). Gitea-ன் வணிக முத்திரை ஒரு நிறுவனத்தின் கட்டுப்பாட்டிற்குச் சென்ற பிறகு, 2022-ன் இறுதியில் Gitea-லிருந்து Forgejo பிரிக்கப்பட்டது. Forgejo ஜெர்மனியில் உள்ள Codeberg e.V. என்ற இலாப நோக்கமற்ற அமைப்பால் GPLv3 உரிமத்தின் கீழ் வெளியிடப்படுகிறது; Gitea வணிக ரீதியான ஆதரவுடன் MIT உரிமத்தில் தொடர்கிறது. நடைமுறை ரீதியான வேறுபாடு அவற்றின் migration பாதையில் உள்ளது. ஜனவரி 2025-ல் வெளியான Forgejo v10.0, Gitea தரவுத்தளத்தை நேரடியாகப் பயன்படுத்தக்கூடிய கடைசி பதிப்பாகும். அதுவும் Gitea v1.22 அல்லது அதற்கு முந்தைய பதிப்புகளிலிருந்து மட்டுமே சாத்தியம். எனவே, தற்போதைய Gitea instance-ஐ நேரடியாக Forgejo-க்கு மாற்ற ஆதரவு இல்லை.

self-hosted Git server-ல் GitHub Actions workflows-ஐ இயக்க முடியுமா?

Forgejo Actions மற்றும் Gitea Actions ஆகிய இரண்டும் GitHub Actions YAML syntax-ல் எழுதப்பட்ட workflows-ஐ .forgejo/workflows மற்றும் .gitea/workflows கோப்புகளிலிருந்து வாசிக்கின்றன. நீங்கள் ஒரு தனி runner நிரலை நிறுவி, அதை உங்கள் instance-உடன் இணைக்க வேண்டும். வெளியிடப்பட்ட பல actions மாற்றமின்றி வேலை செய்யும், ஆனால் GitHub API-ஐ அழைக்கும் எந்தவொரு செயலும் வேலை செய்யாது. runner உங்கள் repositories-லிருந்து தன்னிச்சையான குறியீட்டை (arbitrary code) இயக்கி, ஒவ்வொரு பணிக்கும் ஒரு container-ஐத் தொடங்கும். எனவே, அதைத் தனி host-ல் அல்லது குறைந்தபட்சம் privileged அல்லாத தனி user-ல் இயக்கவும். ஏற்கனவே forge இயங்கும் 1 GB server-ல் இதை இயக்க வேண்டாம்.

self-hosted Git server-ஐ எவ்வாறு backup எடுப்பது?

bare repositories-க்கு, மற்றொரு machine-லிருந்து git clone --mirror கட்டளையைப் பயன்படுத்தி அனைத்து refs மற்றும் objects-ஐயும் நகலெடுக்கலாம், மேலும் அந்த mirror-க்குள் git remote update கட்டளையைப் பயன்படுத்தி அதைப் புதுப்பிக்கலாம். Forgejo அல்லது Gitea-வைப் பொறுத்தவரை, repositories என்பது நிலையின் ஒரு பகுதி மட்டுமே. ஏனெனில் issues, pull requests, users மற்றும் keys ஆகியவை தரவுத்தளத்தில் உள்ளன. உள்ளமைக்கப்பட்ட dump வசதியான sudo -u git forgejo dump -c /etc/forgejo/app.ini கட்டளையைப் பயன்படுத்தவும்; Docker நிறுவலாக இருந்தால், container-க்குள் அதே கட்டளையை இயக்கவும். அந்த archive-ஐ server-லிருந்து வெளியே நகலெடுத்து, ஒருமுறை spare machine-ல் restore செய்து சரிபார்க்கவும். இதன் மூலம் உங்கள் நடைமுறை சரியாக வேலை செய்கிறதா என்பதை உறுதிப்படுத்திக் கொள்ளலாம்.