لماذا لم يعد Oracle Always Free أساسًا موثوقًا
أعلنت Oracle عن تقليص عرض Always Free ARM ابتداءً من 18 أغسطس 2026: تنخفض الموارد من 4 vCPU و24 غيغابايت إلى 2 vCPU و12 غيغابايت. علاوة على ذلك، ظلّ العرض المجاني من Oracle يحمل دائمًا مخاطر هيكلية يعرفها مستخدموه جيدًا: إعادة تشغيل غير مخطط لها للنسخ، وانقطاعات خلال فترات صيانة المناطق، وغياب أي اتفاقية مستوى خدمة على الموارد المخصصة. تستطيع Oracle استرداد الطاقة غير المستخدمة دون إشعار مسبق. بالنسبة لخدمة إنتاجية — سواء كانت لوحة n8n أو نسخة Nextcloud مشتركة عائليًا أو لوحة Coolify تدير عمليات نشرك — يمثّل هذا الغموض خطرًا تشغيليًا حقيقيًا. يقدّم VPS المدفوع شهريًا رسومًا ثابتة قابلة للتوقع وعنوان IPv4 مخصصًا ووصولًا كاملًا كـ root وموارد غير قابلة لإعادة التوزيع على مستأجر آخر. التكلفة ليست صفرًا، لكنّها معروفة مسبقًا ولا تعتمد على سياسة يمكن للمورد تغييرها من جانب واحد.
ما يقدّمه VPS المدفوع مقارنةً بالمستوى المجاني
- موارد مضمونة — vCPU وذاكرة رام محجوزة لنسختك حصريًا، غير مشتركة مع مستأجرين آخرين ولا قابلة للاسترداد من قِبل المزوّد.
- عنوان IPv4 مخصص — عنوان عام ثابت دون NAT مشترك، ضروري لسجلات DNS مستقرة وخطافات الويب الواردة.
- وصول root كامل — تثبّت وتضبط ما تشاء دون قائمة بيضاء للمنافذ أو قيود على البروتوكولات.
- نطاق ترددي قابل للتوقع — حجم شهري محدد بوضوح، دون فواتير مفاجئة لكل غيغابايت تتجاوز حدًا مخفيًا.
- اتفاقية مستوى خدمة ودعم — في حال عطل عتادي، تلتزم الشركة المزوّدة بإعادة الخدمة خلال مهلة تعاقدية.
- تكلفة ثابتة — ابتداءً من 99 درهم/شهر شهريًا، الميزانية معروفة مسبقًا ولا تتغيّر بحسب الاستخدام الفعلي.
- بدون التزام طويل الأمد — لا توقيع على عقد سنوي: يمكن إلغاء عروض VPS السحابي في أي وقت.
التطبيقات المتأثرة بالتقليص
مع 2 vCPU و12 غيغابايت بعد 18 أغسطس 2026، قد تبدو الحدود الجديدة لـ Oracle مريحة على الورق. في الواقع، أكثر التطبيقات المستضافة ذاتيًا شيوعًا لها متطلبات دنيا تتراكم فور دمج عدة تطبيقات. يتطلّب Coolify على الأقل 2 vCPU و2 غيغابايت لعمليات البناء والنشر الخاصة به. توصي n8n بـ 2 vCPU و2 غيغابايت للعمل باستقرار تحت الحمل. يكتفي Nextcloud بـ 2 غيغابايت لأقل من 50 مستخدمًا، لكن عمليات مزامنة الملفات جائعة للمعالج والإدخال/الإخراج مع ازدياد العملاء النشطين. أما Immich مدير الصور فيوصي بـ 4 غيغابايت فقط لخط أنابيب التعلّم الآلي للتعرف على الصور — دون ذلك يتوقف عمال الذكاء الاصطناعي أو ينهار صامتًا. إذا شغّلت اثنين أو ثلاثة من هذه الخدمات على نسخة Oracle نفسها، تضيق الهامش، وأي ذروة استخدام تتسبب في إيقاف بسبب نقص الذاكرة.
المتطلبات الأساسية قبل الهجرة
تُعدّ الهجرة الناجحة قبل الاقتراب من إعدادات DNS أو إيقاف أي شيء. ابدأ بإعداد قائمة دقيقة بالخدمات التي تعمل على نسخة Oracle: اسم الخدمة، منفذ الاستماع، مجلد Docker المرتبط، النطاق أو النطاق الفرعي المستخدم. التقط لقطة كاملة للنسخة عبر وحدة تحكّم Oracle Cloud — هذه شبكة الأمان في حالة وقوع مشكلة غير متوقعة. صدّر أيضًا جميع مجلدات Docker إلى أرشيفات tar قابلة للنقل بصورة مستقلة. قلّص TTL لسجلات A إلى 300 ثانية قبل 24 ساعة على الأقل من الهجرة. حدّد مهام cron والخطافات الواردة والخدمات الخارجية التي تستخدم عنوان IP Oracle الحالي. تحقّق أخيرًا من أن شهادات TLS تُدار عبر Let's Encrypt مع التجديد التلقائي.
تصدير حزمة Docker وإعادة إنشائها
استعراض الحاويات والمجلدات النشطة
على نسخة Oracle، اعرض جميع الحاويات: docker ps -a --format 'table {{.Names}}\t{{.Image}}\t{{.Mounts}}'. واعرض المجلدات: docker volume ls. دوّن الارتباطات بين أسماء الحاويات والمجلدات.
نسخ احتياطي لكل مجلد في أرشيف tar
لكل مجلد مهم مثل n8n_data أو nextcloud_data، صدّر باستخدام: docker run --rm -v n8n_data:/data -v $(pwd):/backup alpine tar czf /backup/n8n_data.tar.gz -C /data .. كرّر لكل مجلد.
حفظ الصور المخصصة
إذا كانت لديك صور مبنية محليًا، صدّرها: docker save image-name:tag | gzip > image-name.tar.gz. للصور العامة مثل n8n وNextcloud وImmich، قائمة بالأسماء تكفي.
نقل الأرشيفات إلى VPS الجديد
من جهازك المحلي أو مباشرة بين الخادمين: rsync -avz --progress *.tar.gz root@vps-ip:/opt/restore/. تحقّق من مجاميع التدقيق: sha256sum *.tar.gz > checksums.txt.
تثبيت Docker على VPS الجديد
على VPS عبر SSH: curl -fsSL https://get.docker.com | sh && systemctl enable --now docker. تحقّق: docker compose version. أنشئ بنية المجلدات: mkdir -p /opt/{coolify,n8n,nextcloud,immich}.
استعادة مجلدات Docker
لكل مجلد محفوظ: docker volume create n8n_data && docker run --rm -v n8n_data:/data -v /opt/restore:/backup alpine tar xzf /backup/n8n_data.tar.gz -C /data. تحقّق من المحتوى: docker run --rm -v n8n_data:/data alpine ls -la /data.
إعادة إنشاء ملفات docker-compose.yml
انسخ ملفات docker-compose.yml من Oracle أو استرجعها من مستودع Git. شغّل كل حزمة بـ docker compose up -d وتحقّق من السجلات: docker compose logs -f --tail=50.
التحقّق من الاشتغال قبل تحويل DNS
اختبر كل خدمة عبر عنوان IP للـ VPS مباشرة بإضافة إدخال مؤقت في /etc/hosts على جهازك: curl -H 'Host: n8n.your-domain.com' http://vps-ip/healthz. تأكّد من وجود البيانات قبل تعديل DNS.
إعادة نشر Coolify على VPS الجديد
تثبيت Coolify
على VPS الجديد عبر SSH: curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash. انتظر اكتمال التثبيت (نحو 2-3 دقائق)، ثم افتح http://vps-ip:8000.
إنشاء حساب المدير
عند الفتح الأول، يطلب Coolify إنشاء حساب مدير بالبريد الإلكتروني وكلمة المرور. هذا الحساب محلي ولا يعتمد على نسختك القديمة. استخدم كلمة مرور قوية.
إعداد النطاق والشهادات
في إعدادات Coolify (Settings → Instance)، أدخل نطاق Coolify مثل coolify.your-domain.com وفعّل إنشاء شهادات Let's Encrypt تلقائيًا. يدير Coolify وكيل Traefik داخليًا.
إعادة ربط مصادر Git
في Sources، أعد ربط حساب GitHub أو GitLab أو Gitea. إذا استخدمت GitHub Apps أو مفاتيح النشر على النسخة القديمة، أعد إنشاءها.
استيراد المشاريع والخدمات
أعد إنشاء المشاريع وأضف الخدمات الموجودة. للقواعد البيانات، أعد إنشاءها في Coolify واستعد النسخ الاحتياطية: docker exec -i <postgres_container> psql -U user db < dump.sql.
مراجعة متغيرات البيئة
يحتاج كل خدمة منقولة إلى متغيرات بيئتها. في Coolify، افتح كل خدمة → Environment Variables وقارن مع ملفات .env المصدّرة من Oracle.
نقاط الانتباه بعد الهجرة
بعد تشغيل الخدمات على VPS، يأتي تحويل DNS. عدّل سجلات A لكل نطاق فرعي لتشير إلى عنوان IP الجديد. بفضل TTL المخفَّض إلى 300 ثانية مسبقًا، يتم الانتشار عادةً في أقل من عشر دقائق. راقب سجلات Traefik أو Caddy خلال الساعات الأولى للكشف عن أي طلبات لا تزال تصل إلى IP Oracle القديم. يجب إعادة توليد شهادات Let's Encrypt على IP الجديد. مهام cron الداخلية لـ n8n أو Nextcloud تبقى بعد الهجرة، لكن مهام cron النظامية لنسخة Oracle يجب إعادة إنشاءها يدويًا على VPS. أخيرًا، أخبر الخدمات الخارجية التي استخدمت IP Oracle القديم في قوائم IP المسموح بها.
أعدّ نسخًا احتياطية تلقائية لمجلدات Docker منذ اليوم الأول على VPS الجديد. سكريبت cron يومي يصدّر كل مجلد حيوي إلى تخزين كائنات (Backblaze B2 أو ما يتوافق مع S3) يحميك من أعطال القرص والحذف العرضي. على نسخة ServOrbit، يُثبَّت restic أو borgbackup في دقائق ويوفّران نسخًا احتياطية تدريجية مشفّرة مع احتفاظ قابل للتخصيص.
استكشاف الأخطاء الشائعة
خلال هجرة Docker، تظهر أخطاء متكررة. الأول هو مشكلة الأذونات على المجلدات المستعادة: إذا بدأت الحاوية بـ UID مختلف عمّا أنشأ الملفات على Oracle، ستظهر أخطاء permission denied. أصلحها بـ docker run --rm -v volume:/data alpine chown -R uid:gid /data. الخطأ الثاني هو حاوية تبدأ ثم تتوقف بكود الخروج 137: هذا قتل بسبب نقص الذاكرة. تحقّق بـ dmesg | grep -i oom. يخصّ الخطأ الثالث Let's Encrypt: إذا لم تُولَّد الشهادة، تأكّد من فتح المنفذ 80 وأن DNS يشير إلى IP الجديد بـ dig +short your-domain.com. أخيرًا، إذا أظهر Coolify الخدمات كـ offline رغم تشغيل حاويات Docker، تحقّق بـ docker network inspect coolify.
Oracle Always Free ARM مقابل VPS المدفوع: مقارنة
| Oracle Always Free ARM (بعد 18/08/2026) | ServOrbit Cloud VPS | |
|---|---|---|
| vCPU | 2 (مشتركة، قابلة للاسترداد) | مخصصة، مضمونة تعاقديًا |
| الذاكرة | 12 غيغابايت (مخفّضة من 24) | ابتداءً من 2 غيغابايت، قابلة للتوسّع |
| IPv4 | عنوان عام واحد (قابل لإعادة التخصيص) | عنوان IPv4 ثابت مخصص مُدرَج |
| النطاق الترددي | 10 تيرابايت/شهر صادر (حصة منطقة مشتركة) | حجم شهري مُدرَج، قابل للتوقع |
| وصول root | نعم، لكن المنافذ والبروتوكولات مُفلتَرة | وصول root كامل، بدون قيود |
| SLA | لا يوجد على المستوى المجاني | اتفاقية مستوى خدمة شبكية مُدرَجة |
| إعادة تشغيل غير مخطط | نعم (صيانة Oracle، استرداد الطاقة) | لا (هجرات مباشرة، بدون إيقاف قسري) |
| التكلفة الشهرية | 0 يورو (مع خطر القطع أو الفوترة عند التجاوز) | ابتداءً من 99 درهم/شهر/شهر، سعر ثابت |
