Cloud-Init في بروكسموكس: سلّم سيرفراً جاهزاً بلا فتح كونسول

الاستنساخ أعطاك جهازاً في ثانيتين. لكنه جهاز بلا مستخدم يخصّ الزبون، وبلا عنوان، وبلا كلمة مرور. وإن كنت تفتح كونسولاً بعد كل استنساخ لتضبط هذه الثلاثة، فأنت لم تؤتمت شيئاً — نقلت العمل اليدوي من مكان إلى آخر.

Cloud-Init هو ما يكمل الطريق: تصف ما تريده بأمر واحد، ويتولّى الجهاز تنفيذه على نفسه في أول إقلاع.

كيف يعمل؟

بروكسموكس يولّد قرصاً صغيراً افتراضياً فيه إعداداتك، ويربطه بالجهاز. وعند أول إقلاع يقرأ cloud-init داخل النظام ذلك القرص وينفّذ ما فيه: ينشئ المستخدم، ويضبط العنوان، ويضع المفاتيح، ويوسّع القرص. ثم يسجّل أنه انتهى فلا يعيدها.

الأمر الكامل

qm set 8801 \
    --ciuser maram \
    --cipassword 'كلمة-مرور-قوية' \
    --ipconfig0 ip=10.10.10.71/24,gw=10.10.10.1 \
    --nameserver 1.1.1.1 \
    --searchdomain lab.local \
    --sshkeys ~/.ssh/authorized_keys \
    --ciupgrade 0

qm start 8801

وبعد نحو نصف دقيقة يكون الجهاز يستجيب، ويستطيع الزبون الدخول إليه بالبيانات التي أرسلتها له.

ما يفعله كل خيار

تحقّق أنه اشتغل فعلاً

qm guest exec 8801 -- /bin/bash -c 'hostname; id maram; ip -4 -br a; cloud-init status'

الجواب الذي تريده هو status: done. وإن رأيت error فالسجلّ هنا:

cat /var/log/cloud-init-output.log

نقطة تربك كثيرين: القالب يجب أن يكون نظيفاً

cloud-init clean --logs
truncate -s 0 /etc/machine-id

تخصيص أعمق بـ cicustom

الخيارات الجاهزة تغطّي أغلب الحالات. وحين تحتاج أكثر — تثبيت حزم، أو كتابة ملفات، أو تشغيل أوامر — اكتب ملفاً:

# /var/lib/vz/snippets/web.yaml
#cloud-config
package_update: true
packages:
  - nginx
  - fail2ban
write_files:
  - path: /etc/motd
    content: |
      هذا السيرفر مُدار من مرام هوست
runcmd:
  - systemctl enable --now nginx fail2ban
  - ufw allow 80,443/tcp

qm set 8801 --cicustom "user=local:snippets/web.yaml"

وبهذا تسلّم للزبون سيرفر ويب جاهزاً يعمل — لا نظاماً فارغاً عليه أن يبنيه بنفسه.

التوسيع التلقائي للقرص

حين تبيع باقة بقرص أكبر من القالب:

qm resize 8801 scsi0 +40G

وcloud-init يوسّع القسم ونظام الملفات تلقائياً عند الإقلاع. إن لم يفعل، فذلك لأن growpart غير مثبَّت في القالب — أضفه هناك، لا في كل نسخة.

الربط بنظام الطلبات

هنا يصبح كل ما سبق منتجاً لا إجراءً. أنظمة الفوترة تستدعي واجهة بروكسموكس البرمجية بالتسلسل نفسه:

POST /nodes/{node}/qemu/{template}/clone   →  استنساخ
PUT  /nodes/{node}/qemu/{vmid}/config      →  ciuser · cipassword · ipconfig0
POST /nodes/{node}/qemu/{vmid}/status/start →  تشغيل

ثلاثة نداءات، والنتيجة أن الزبون يدفع ويستلم بيانات سيرفره في دقيقتين بلا تدخّل منك. وهذا هو الفرق بين «أبيع سيرفرات» و«أشغّل مزوّد استضافة».

أخطاء شائعة وحلولها

أسئلة شائعة

هل يعمل cloud-init مع ويندوز؟

جزئياً وبأدوات مختلفة (Cloudbase-Init). الطريق المعتاد في ويندوز هو sysprep مع ملف إجابات.

أين تُخزَّن كلمة المرور؟

مُعمّاة داخل إعداد الجهاز في /etc/pve/qemu-server/. وهي متاحة لمن يملك root على السيرفر — أي أنها ليست سرّاً أمامك، وهذا سبب إضافي لتفضيل المفاتيح.

هل أستطيع تغيير العنوان بعد التسليم؟

نعم: عدّل ipconfig0 ثم أعد تشغيل الجهاز كاملاً — والجهاز سيأخذ العنوان الجديد.

ولماذا لا يعمل cloud-init مرّة ثانية؟

لأنه مصمَّم كذلك: هو للتهيئة الأولى لا للإدارة المستمرّة. ما بعد التسليم مكانه أدوات الإدارة أو سكربتاتك.

ما أفضل ممارسة لتسليم الزبون؟

مفتاح SSH إن كان الزبون تقنياً، وكلمة مرور قوية مؤقّتة مع إلزامه بتغييرها إن لم يكن. ولا ترسل كلمة المرور في نفس الرسالة التي فيها عنوان السيرفر.

الخطوة التالية

التسليم صار آلياً. بقي أن تستطيع أنت أن تجرّب أي شيء على هذه الأجهزة بلا خوف: في الجزء الرابع نكسر خدمة قصداً ونعيدها كما كانت في 49 ثانية.