.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
كم دقيقة تحتاج لتسليم سيرفر لزبون الآن؟ إن كان الجواب «أنصّب النظام، ثم أحدّثه، ثم أضبط الشبكة والمستخدم والجدار، ثم أرسل البيانات» فأنت تدفع نصف ساعة من وقتك في كل طلب — وتكرّر العمل نفسه في كل مرّة بنتائج مختلفة قليلاً.
البديل: تبني الجهاز مرّة واحدة بإتقان، وتحوّله قالباً، ثم يصبح كل تسليم لاحق أمراً واحداً ينتهي في 2.6 ثانية.
كل رقم في هذه السلسلة مقيس لا مقدَّر. نفّذنا كل أمر على سيرفر Proxmox VE 9.2 حقيقي
بمعالج EPYC وتخزين LVM-thin على NVMe، وأخذنا الأزمنة من مخرجات time نفسها.
وقد استبدلنا العناوين العامة الحقيقية بعناوين التوثيق المخصّصة لهذا الغرض (RFC 5737) حفاظاً على أمان السيرفر.
الخطوة 1: ابنِ الجهاز الذهبي
هذا هو العمل الحقيقي، وتفعله مرّة واحدة لكل نظام تشغيل تبيعه. أنشئ جهازاً عادياً، نصّب النظام، ثم اضبط فيه:
# تحديث كامل
apt update && apt full-upgrade -y
# وكيل الضيف — بدونه لا يرى بروكسموكس داخل الجهاز
apt install -y qemu-guest-agent
systemctl enable --now qemu-guest-agent
# cloud-init — هو ما يجعل القالب قابلاً للتخصيص
apt install -y cloud-init
# منفذ SSH غير الافتراضي + جدار ناري
sed -i 's/^#\?Port .*/Port 2026/' /etc/ssh/sshd_config
ufw allow 2026/tcp && ufw --force enableما تضعه هنا تحصل عليه مجاناً في كل جهاز لاحقاً. منفذ SSH مغيَّر وجدار ناري مفعَّل في القالب يعنيان أن كل زبون يستلم جهازاً محصّناً من اللحظة الأولى — بلا أن تفعل شيئاً، وبلا أن تعتمد على أن يفعله هو.
الخطوة 2: نظّف قبل التحويل
هذه الخطوة يتجاهلها كثيرون فتخرج لهم أجهزة بمعرّفات متطابقة أو مفاتيح مكرّرة:
# مفاتيح SSH للمضيف — يجب أن تتولّد جديدة في كل نسخة
rm -f /etc/ssh/ssh_host_*
# سجلّ cloud-init حتى يعمل من جديد
cloud-init clean --logs
# معرّف الجهاز — لولا هذا لأخذت كل النسخ نفس عنوان DHCP
truncate -s 0 /etc/machine-id
rm -f /var/lib/dbus/machine-id
# التاريخ والملفات المؤقتة
history -c; rm -rf /tmp/* /var/tmp/*نسيان machine-id هو أشهر خطأ في القوالب. النتيجة أن كل الأجهزة المستنسخة تطلب العنوان نفسه من DHCP، فيظهر العطل كأنه «تعارض عناوين عشوائي» ويأخذ ساعات قبل أن يُكتشف سببه. والأسوأ أنه لا يظهر مع جهاز أو جهازين — بل حين يصير عندك خمسة.
الخطوة 3: أضف قرص cloud-init وحوّل
qm set 5002 --ide2 thinnvme:cloudinit
qm set 5002 --boot order=scsi0
qm set 5002 --agent enabled=1
qm set 5002 --serial0 socket --vga serial0 # للكونسول في نظم لينكس
qm template 5002بعد qm template يصبح الجهاز للقراءة فقط ولا يُشغَّل بعدها. وهذا مقصود: القالب مرجع لا خادم.
الخطوة 4: استنسخ — والفرق بين طريقتين
# نسخة مرتبطة — 2.6 ثانية، ولا تأكل مساحة تُذكر
qm clone 5002 8801 --name web-01
# نسخة كاملة — 72 ثانية، وتأكل مساحتها
qm clone 5002 8802 --name web-02 --full 1أيّهما تختار؟
| مرتبطة | كاملة | |
|---|---|---|
| الزمن المقيس | 2.6 ثانية | 72 ثانية |
| المساحة الجديدة | لا شيء يُذكر | ~3 غيغابايت |
| تعتمد على القالب | نعم — لا يُحذف أبداً | لا |
| تنتقل إلى سيرفر آخر | لا مباشرةً | نعم |
| الاستعمال المناسب | تجارب · بيئات مؤقتة · أعداد كبيرة | أجهزة زبائن دائمة |
لا تحذف قالباً له نسخ مرتبطة. بروكسموكس سيمنعك، لكن الخطر الحقيقي أن تنسى أيّ القوالب مستعمَل بعد سنة. اكتب في وصف كل قالب متى أُنشئ وما الذي فيه — ولا تنظّف القوالب القديمة قبل أن تتحقّق من lvs -o lv_name,origin.
الخطوة 5: أعطِ النسخة موارِدها
qm set 8801 --cores 2 --memory 2048 \
--net0 virtio,bridge=vmbr1,tag=2040 \
--cpu x86-64-v2-AES
qm resize 8801 scsi0 +20G # توسيع القرص إن لزمعن نوع المعالج: cpu: host يعطي أفضل أداء لكنه يمنع الترحيل بين سيرفرات مختلفة العتاد، وقد يسبّب أعطالاً في بعض تركيبات المعالج والنواة. إن كان عندك أكثر من سيرفر، اختر نوعاً موحّداً مثل x86-64-v2-AES وستوفّر على نفسك مشاكل يوم الترحيل.
قالب واحد أم قالب لكل منتج؟
ابدأ بقالب لكل نظام تشغيل تبيعه (أوبونتو، دبيان، ألما…) — لا أكثر. وحين تجد نفسك تكرّر نفس التعديلات بعد كل استنساخ، حينها فقط اصنع قالباً متخصّصاً.
والقاعدة العملية: القوالب الكثيرة عبء صيانة. كل قالب يحتاج تحديثاً دورياً، وقالب قديم يعني تسليم جهاز بثغرات مرقّعة منذ أشهر.
تحديث القوالب — لا تؤجّله
# كل شهر: استنسخ القالب، حدّثه، نظّفه، حوّله قالباً جديداً
qm clone 5002 5099 --name ubuntu-24-new --full 1
qm start 5099
# ... حدّث ونظّف بالخطوات أعلاه ...
qm template 5099ثم استعمل الجديد في التسليمات القادمة واحتفظ بالقديم حتى تتأكّد. والبديل — قالب لم يُحدَّث منذ سنة — يعني أن كل زبون جديد يبدأ بعشرات التحديثات الأمنية المعلّقة.
أخطاء شائعة وحلولها
| العَرَض | السبب | الحل |
|---|---|---|
| كل النسخ تأخذ نفس العنوان | machine-id لم يُفرَّغ | فرّغه في القالب وأعد بناءه |
| cloud-init لا يعمل في النسخ | لم يُنظَّف قبل التحويل | cloud-init clean --logs |
| qm guest exec لا يعمل | الوكيل غير مثبَّت أو غير مفعَّل | الاثنان معاً: الحزمة و--agent enabled=1 |
| النسخة لا تقلع | ترتيب الإقلاع لم يُضبط | qm set --boot order=scsi0 |
| القرص لم يكبر بعد resize | النظام لم يوسّع القسم | growpart ثم resize2fs — أو دع cloud-init يفعلها |
| كل الأجهزة بنفس مفتاح SSH | مفاتيح المضيف لم تُحذف | rm /etc/ssh/ssh_host_* في القالب |
أسئلة شائعة
هل النسخة المرتبطة أبطأ في التشغيل؟
لا فرق يُلاحَظ في الاستعمال العادي: القراءات المشتركة تأتي من الأصل والكتابات تذهب إلى طبقة النسخة. الفرق يظهر فقط تحت كتابة عشوائية كثيفة جداً.
أستطيع تحويل النسخة المرتبطة إلى كاملة لاحقاً؟
نعم — qm full-clone أو من الواجهة. مفيد حين يتحوّل جهاز تجريبي إلى إنتاجي.
هل يعمل هذا مع ويندوز؟
نعم، بالمنطق نفسه: تنصيب، وتعريفات VirtIO، ووكيل الضيف، ثم sysprep بدل الأوامر أعلاه. وsysprep ليس اختيارياً هناك.
كم قالباً أحتفظ به؟
بقدر ما تستطيع تحديثه شهرياً. عملياً: من ثلاثة إلى ستة.
وهل أربط هذا بنظام الطلبات عندي؟
نعم، وهو المكسب الأكبر: أنظمة الفوترة مثل WHMCS تستدعي هذه الأوامر نفسها عبر واجهة بروكسموكس البرمجية، فيتحوّل التسليم من نصف ساعة عمل إلى صفر تدخّل.
الخطوة التالية
القالب جاهز والاستنساخ صار ثوانيَ. بقي أن يستلم الزبون جهازاً بمستخدمه وكلمة مروره وعنوانه بلا أن تفتح كونسولاً: هذا ما يفعله Cloud-Init في الجزء الثالث.
هذه المقالة من سلسلة «بروكسموكس كمصنع سيرفرات» — من سيرفر واحد إلى تسليم آليّ لأجهزة زبائنك: ١. الشبكة والجسور والـVLAN · ٢. القوالب · ٣. Cloud-Init · ٤. اللقطات والاستنساخ · ٥. النسخ الاحتياطي واختبار الاسترجاع
