اختر طبقة التعاون
Forgejo وGitea أمثلة على برامج forge خفيفة؛ قد يكفي Git العادي SSH لسير عمل أصغر. طابق المشكلات والمراجعات وتخزين الحزم ومتطلبات الهوية مع المشروع. تحقق من الإصدارات المدعومة الحالية والتراخيص.
افصل البناء عن الـ forge
CI runner بينفّذ كود بيتحكم فيه المشروع، وماينفعش يحمل بيانات اعتماد forge أو مضيف غير مقيّدة. اعزل الـ runners وحدّد نطاق التوكنات وتجنّب تشغيل مهام غير موثوقة على نفس الحساب المميز بتاع خدمة المستودع.
احمِ الوصول والتسجيل
عطّل التسجيل العام عندما تكون الخدمة خاصة. استخدم حسابات فردية ومصادقة قوية ومفاتيح نشر محددة النطاق بعناية. وثّق منفذ SSH ومفتاح المضيف؛ لا تدرّب المستخدمين بصمت على تجاهل تحذيرات مفتاح المضيف.
اعمل نسخة احتياطية للخدمة كاملة
المستودعات لوحدها ممكن متشملش المشاكل والحسابات والمرفقات والإعدادات. اتبع إجراء النسخ الاحتياطي المتسق بتاع الـ forge واختبر استعادة بأذونات الملفات وأسرار التطبيق سليمة.
قائمة تحقق لاستعادة المنصة
اعمل تصدير متسق لقاعدة البيانات وحافظ على تخزين المستودع والمرفقات وتخزين الملفات الكبيرة لو مفعّل والإعدادات وأسرار التشفير. تحقق من نسخة مستنسخة عبر مسار SSH أو HTTPS المقصود بعد الاستعادة. خلي منصة التطوير وأي عامل CI معزولين عشان البناء ما يقدرش يعيد كتابة إعدادات الخدمة نفسها.
اجعل صلاحيات النشر محدودة
مفتاح نشر للقراءة فقط ممكن يكون كافي لسيرفر بيسحب الكود بس. أتمتة الإصدارات ممكن تحتاج صلاحية إضافية صغيرة. فضّل مفاتيح مستقلة لكل جهاز، وسجّل الغرض منها، وامسحها لما الجهاز يتقاعد.
استخدم أصغر خدمة تعاون تناسبك
لكام مستودع خاص، Git العادي عبر SSH مقيّد ممكن يكون كافي. Forgejo أو Gitea بيضيفوا حسابات وطلبات سحب ومشاكل وحزم اختيارية على حساب قاعدة بيانات وتحديثات تطبيق وحالة مستمرة أكتر. سجّل الميزات اللي الفريق هيستخدمها فعلاً. خصص ميزانية لنمو المستودع وكائنات الملفات الكبيرة والمرفقات ومخرجات البناء كل واحد لوحده؛ حوسبة CI ممكن تتجاوز الـ forge نفسه.
- اختار اسم HTTPS أساسي واحمي حساب DNS بتاعه.
- حدد إذا كان التسجيل مقفول أو بالدعوة أو بتدقيق.
- امنح خدمة forge هوية غير مميزة وتخزينًا خاصًا دائمًا.
الوثائق الرسمية: تثبيت حاوية Forgejo
افصل مسارات الويب وSSH وقاعدة البيانات
استخدم إعدادات المصدر للإصدار المحدد وثبّت نسخة الصورة المقصودة. يجب أن يصل وكيل عكسي TLS إلى مستمع الويب الداخلي؛ ويجب أن تكون قاعدة البيانات متاحة فقط لـ forge. إذا استخدم Git SSH منفذ حاوية، فحافظ على اتساق المضيف المعلن والمنفذ الخارجي مع التعيين. لا تستبدل أو تعرّض بالخطأ مستمع SSH لمسؤول المضيف أثناء تغيير forge. أغلق وصول التثبيت/الإعداد بمجرد إنشاء المالك الأولي.
- تحقق من ملكية وحدة التخزين الدائمة قبل تشغيل التطبيق.
- استخدم مستخدم قاعدة بيانات مقتصرًا على قاعدة بيانات forge.
- خلّي مشغلات CI على حدود ثقة منفصلة، خصوصًا للمستودعات غير الموثوقة.
الوثائق الرسمية: شبكات Docker واستمرارية البيانات في Forgejo
تحقق من الاستنساخ والدفع وعملية مرفوضة
اعمل مستودع خاص مؤقت واختبر استنساخه بـHTTPS أو SSH URL من حساب مطور عادي. اعمل commit وpush لملف غير ضار، وبعدين تأكد إن قارئ تاني مصرح له يقدر يجيبه. حساب مش مدعو لازم يفشل في قراءة المستودع الخاص. راجع التعامل مع الملفات الكبيرة وإيميل الإشعارات لو مفعّل. للأجهزة المخصصة للنشر بس، اختبر إن مفتاح للقراءة فقط يقدر يجيب ومش يقدر يعمل push؛ نجاح المصادقة لوحده مش بيثبت حدود الصلاحيات المقصودة.
# Use the disposable repository URL advertised by your forge:
git clone ssh://[email protected]:2222/team/check.git
# In a clone, inspect which remote is configured:
git remote -vاسترجع النقاش جنب المستودع
خد نسخة احتياطية متسقة للتطبيق وقاعدة البيانات، وتخزين المستودع، والمرفقات، وبيانات LFS، والإعدادات، وأسرار التشفير المطلوبة. اتبع إجراء النسخ الاحتياطي الخاص بإصدار الـ forge المثبّت؛ أوامر النسخ الاحتياطي في Gitea مش قابلة للتبادل تلقائيًا مع كل إصدار Forgejo. أعد البناء في بيئة معزولة وتحقّق من مشكلة ومرفق وتسجيل دخول واستنساخ. لو الدفع فشل بعد النقل، راجع مضيف/منفذ SSH، وربط المفاتيح، وصلاحيات التخزين، وURL الاستنساخ المعلنة قبل ما تغيّر صلاحيات المستودع عالميًا.
الوثائق الرسمية: نسخ Gitea احتياطيًا واستعادته