لماذا تستضيف Gitea ذاتيًا على خادم VPS
تستهلك Gitea بالكاد من 200 إلى 300 ميغابايت من الذاكرة (RAM) في وضع الخمول، ما يجعلها من أكفأ منصات Git للاستضافة الذاتية. على خادم VPS، تحتفظ بالسيطرة الكاملة على شيفرتك المصدرية: لا يحلّل أي طرف ثالث بياناتك، ولا حدّ اعتباطي على عدد المستودعات الخاصة أو المتعاونين، ولا تكلفة تتصاعد مع فريقك. وبالنسبة إلى وكالة أو مطوّر مستقل في المغرب، يمكن لخادم VPS واحد أن يستضيف مجمل مشاريع العملاء بأذونات مقسَّمة حسب المؤسسة. تتضمّن Gitea أصلًا نظام CI/CD متوافقًا مع مسارات عمل GitHub Actions (Gitea Actions)، وسجلّ حزم، ومحرّرًا عبر الويب، ما يغطّي شبه كامل دورة التطوير دون تبعية خارجية.
فوائد ملموسة لـGitea ذاتية الاستضافة
- بصمة ذاكرة ضئيلة: تعمل بأريحية على خادم VPS بذاكرة 2 غيغابايت حتى مع عشرات المستخدمين.
- مستودعات خاصة غير محدودة دون فوترة لكل مقعد، خلافًا لعروض SaaS.
- Gitea Actions مدمج لتشغيل مسارات CI/CD الخاصة بك دون خدمة خارجية.
- سجلّ حزم (Docker وnpm وComposer وMaven) مستضاف على المنصة نفسها.
- مصادقة دقيقة: LDAP وOAuth2 ورموز وصول شخصية ومفاتيح SSH لكل مستخدم.
- نسخ احتياطي بسيط للغاية: كل شيء يتّسع في وحدة تخزين بيانات وقاعدة بيانات.
المتطلبات العتادية والبرمجية
Gitea مقتصدة للغاية. لفريق صغير (حتى 20 مستخدمًا)، يكفي خادم VPS بمعالجَين افتراضيَّين (2 vCPU) و2 غيغابايت من الذاكرة (RAM) وأكثر؛ احسب 4 غيغابايت إذا فعّلت Gitea Actions مع runners محلية تصرّف الشيفرة. خصّص ما لا يقل عن 20 إلى 40 غيغابايت من تخزين SSD بحسب حجم مستودعاتك. على الجانب البرمجي: Docker Engine وإضافة Docker Compose مثبَّتتان، واسم نطاق (أو نطاق فرعي مثل git.yourdomain.com) يشير إلى عنوان IP الخاص بخادم VPS عبر سجل A، والمنفذ 22 محجوز لـSSH الخادم — إذ ستعرض Gitea خدمة SSH خاصة بها على منفذ آخر لتفادي التعارض.
نشر Gitea مع Docker وSSL
تجهيز خادم VPS وDocker
اتصل عبر SSH، وحدّث النظام ثم ثبّت Docker وإضافة Compose. أنشئ مجلدًا مخصّصًا: mkdir -p /opt/gitea && cd /opt/gitea. أنشئ أيضًا وحدة تخزين بيانات تبقى بعد تحديثات الحاوية.
كتابة ملف docker-compose.yml
عرّف خدمتين: gitea (الصورة gitea/gitea:latest) وقاعدة بيانات postgres:16. ركّب ./gitea:/data للاستمرارية، واضبط USER_UID/USER_GID على 1000، واربط SSH الخاص بـGitea بمنفذ المضيف 2222: "2222:22". اترك منفذ HTTP رقم 3000 داخليًا، فسيخدمه reverse proxy.
تشغيل الحاويات
نفّذ docker compose up -d ثم docker compose logs -f gitea لمتابعة عملية التهيئة. تحقّق من نجاح الاتصال بـPostgreSQL قبل المتابعة.
إعداد reverse proxy
مع Caddy، يكفي سطر واحد: git.yourdomain.com { reverse_proxy localhost:3000 }. يحصل Caddy تلقائيًا على شهادة Let's Encrypt ويجدّدها. مع Nginx، أنشئ كتلة server تُمرّر الطلبات إلى http://127.0.0.1:3000 واستخدم certbot --nginx لـSSL.
إنهاء التثبيت عبر الويب
افتح https://git.yourdomain.com، وأكمِل المعالج بإدخال عنوان URL الأساسي بصيغة HTTPS ومضيف قاعدة البيانات (db:5432). اضبط ROOT_URL بشكل صحيح، وإلا ستكون روابط الاستنساخ خاطئة.
تأمين SSH الخاص بالمستودعات
اضبط عملاءك للاستنساخ عبر ssh://[email protected]:2222/...، أو أضِف كتلة Host في ~/.ssh/config لإخفاء المنفذ. عطّل التسجيل العام في لوحة الإدارة إذا كانت المنصة خاصة.
أول تسجيل دخول
افتح الرابط: يعرض Gitea صفحة التثبيت، وبيانات قاعدة البيانات مملوءة مسبقاً — لا تغيّرها. وسّع قسم الإعدادات الاختيارية ثم إعدادات حساب المسؤول (Optional Settings > Administrator Account Settings)، وأنشئ فيه حساب المسؤول الخاص بك، ثم أكّد.
فعّل Gitea Actions منذ التثبيت بإضافة [actions] ENABLED = true إلى app.ini، ثم سجّل runner باسم act_runner في حاوية منفصلة على خادم VPS نفسه. حُدّ ذاكرته عبر mem_limit كي لا يخنق بناءٌ ثقيل Gitea نفسها. للمسارات الثقيلة (التصريف واختبارات التكامل)، خصّص بدلًا من ذلك خادم VPS ثانيًا لـrunner واربطه برمز التسجيل — تُبقي المنصة سريعة الاستجابة حتى أثناء عمليات البناء.
الترقية إلى Gitea 1.27 دون فقدان وصول SSH
يغيّر الإصدار 1.27 المسار الداخلي للملف التنفيذي gitea المُدرج في authorized_keys. عند الترقية، تشير المدخلات الموجودة إلى المسار القديم: يفشل كل استنساخ أو دفع عبر SSH بصمت برسالة Permission denied (publickey)، دون أي رسالة خطأ من جهة الخادم تشير إلى الترقية. تستجيب خدمة Gitea بشكل طبيعي عبر HTTPS، مما يُخفي المشكلة. السبب ليس مفتاح المستخدم بل غلاف الأمر الذي تُدرجه Gitea في authorized_keys. بعد كل ترقية إلى الإصدار 1.27 (أو إلى أي إصدار يغيّر هذا المسار)، نفّذ داخل الحاوية: docker exec -u git gitea gitea admin regenerate keys. تُعيد هذه الأمر كتابة جميع مدخلات authorized_keys بالمسار الصحيح للملف التنفيذي. تحقّق بعد ذلك من نجاح git clone عبر SSH قبل إعلان اكتمال الترقية.
لا يجوز أن يتعايش JWT_SECRET_URI وJWT_SECRET في ملف app.ini. إذا كان كلا المفتاحَين موجودَين، يحمِّل Gitea أحدهما أو الآخر بحسب ترتيب القراءة، فيُبطل بصمت جميع رموز OAuth2 وGitea Actions الصادرة قبل الترقية. يرى المستخدمون أخطاء مصادقة متقطعة دون أي رسالة تُشير إلى app.ini بوصفه السبب. اختَر آليةً واحدة: JWT_SECRET (قيمة نصية صريحة) أو JWT_SECRET_URI (مسار إلى ملف سري)، ثم احذف الأخرى. أعِد تشغيل الحاوية بعد التعديل.
الوثائق الرسمية
للإعداد المتقدّم والخيارات الخاصة بالأداة، ارجع إلى الوثائق الرسمية لـGitea. يغطّي هذا الدليل النشر على خادم VPS؛ وتبقى وثائق الناشر المرجعَ للضبط الدقيق والترقيات الكبرى وحالات الاستخدام الخاصة.
