برمجيات مخصصة من مستودعات المصدر
يمكن لوصفات OpenFactory أن تشير إلى مستودع Git كمدخل حزمة مخصصة على بنّائي الصور المدعومين. هذا مسار حسّاس لسلسلة التوريد: المستودع، والمراجعة المحلولة، وتعليمات التعبئة، وتبعيات البناء، والحزمة الناتجة تتطلب كلها مراجعة.
الدعم خاص بالهدف. تُرفض بناءات حزم المصدر لبعض البنّائين، بما في ذلك مسارات Raspberry Pi وProxmox الحالية. أكد التوفر في الوصفة المطبّعة وخطة البناء قبل الوعد بأن حزمة ستُنتج.
شكل الوصفة
تعيش إدخالات الحزم المخصصة تحت os.custom_packages:
{
"os": {
"custom_packages": [
{
"name": "my-agent",
"git_url": "https://github.com/example/my-agent.git",
"branch": "release-1.x"
}
]
}
}يقبل المخطط اسم فرع، لا حقل commit غير قابل للتغيير. لإصدار مضبوط، سجّل الـ commit الدقيق الذي حلّه البناء واجعل ذلك الـ commit جزءا من الأصل المحتفظ به. فرع متحرك وحده ليس مدخلا قابلا للتكرار.
جهّز المستودع
يتوقع مسار الحزمة الحالي بيانات تعبئة أصلية تناسب الهدف. أمثلة شائعة دليل Debian debian/ أو مواصفة RPM. سلوك البنّاء الدقيق وإصدارات الهدف المدعومة يمكن أن تتغير، لذا تحقق من حزمة حدية في البيئة المنشورة بدلا من الاعتماد على جدول توافق ثابت.
لتعبئة Debian، راجع على الأقل:
debian/controlلهوية المصدر/الثنائي والتبعيات؛debian/changelogلإصدار الحزمة؛debian/rulesوسكربتات المشرف التنفيذية الأخرى؛- بيانات التثبيت ووحدات systemd؛ و
- الترخيص والمواد الخارجية المضمَّنة.
لتعبئة RPM، راجع مصادر المواصفة، ومتطلبات البناء، وscriptlets، وقائمة الملفات، وبيانات الترخيص.
لا تفترض أن ملكية المستودع تجعل سكربتات بنائه آمنة. تنفيذ بناء الحزم لمنطق مصدر وتعبئة غير موثوق داخل حد عزل بنية البناء التحتية.
عناصر تحكم أخرى للحزم
الحزم الأصلية
استخدم os.packages للحزم التي توفّرها التوزيعة المختارة أصلا أو مستودع مضبوط صراحة:
{
"os": {
"packages": ["curl", "jq"]
}
}تجاوزات الحزم
يمكن لـ os.package_overrides أن يعلن قصد add أو remove أو replace:
{
"os": {
"package_overrides": [
{"name": "nano", "action": "replace", "replacement": "neovim"},
{"name": "telnet", "action": "remove"}
]
}
}التجاوز ليس إثباتا أن حل التبعيات احترمه. تحقق من جرد الحزم النهائي وتحققات الغياب/الحضور.
مستودعات إضافية
os.extra_repos مدخل متقدم. لا تضف مستودع HTTP غير موقّع كما في الأمثلة الأقدم. يحتاج تكامل مستودع معتمد نقل HTTPS، ومفتاح توقيع مثبت، وفرض التوقيع، وبيانات إصدار تناسب مدير الحزم، وسياسة ملكية وتحديث موثقة. إذا تعذر تمثيل عناصر الثقة تلك عبر البنّاء الحالي، لا تستخدم المستودع.
أدلة القبول
لكل حزمة مخصصة، احتفظ بـ:
- عنوان URL للمستودع والـ commit المحلول؛
- مراجعة المصدر والترخيص المعلن؛
- لقطة بيئة البناء والتبعيات؛
- سجلات البناء واسم/إصدار/معمارية الحزمة الناتجة؛
- بصمة الحزمة وأدلة توقيع المستودع حيث ينطبق؛
- جرد الصورة النهائي الذي يظهر الحزمة مثبتة؛
- اختبارات دخان للخدمة أو البرنامج التنفيذي؛ و
- سلوك الإزالة والترقية.
مرحلة حزمة مصدر ناجحة لا تكفي. يمكن أن يفشل بناء الصورة لاحقا في استهلاك الحزمة، ويمكن أن تبقى حزمة مثبتة غير قابلة للاستخدام.
استكشاف الأخطاء
- رُفضت بيانات التعبئة: تحقق من الحزمة الأصلية محليا بنفس إصدار التوزيعة والمعمارية.
- تبعية بناء ناقصة: استخدم تبعيات متاحة من مستودعات معتمدة لذلك الهدف؛ لا تجلب بصمت ثنائيات اعتباطية في سكربت مشرف.
- الحزمة غائبة عن الصورة: قارن اسم الحزمة الثنائية الناتجة بطلب التثبيت المطبّع والجرد النهائي.
- لم يتغير الإصدار: حدّث بيانات الإصدار الأصلية وأكد أن commit المصدر الجديد حُلّ.
- فشلت الخدمة: افحص وحدتها، وتبعيات التشغيل، والأذونات، وسجلات الضيف؛ أضف تحققا على مستوى السلوك قبل إعادة البناء.