استضافة WordPress للمواقع التي تتحرك خارج RunCloud.
RunCloud هي لوحة تحكم على خادم تستأجره وتملكه. الانتقال أقل هجرة من التغيير في من يكون مسؤولا عندما تحتاج النواة إلى التصحيح في الساعة الثانية صباحًا.
ما الذي يتغير عندما تختفي اللوحة.
RunCloud تكوين Nginx ، PHP-FPM والكرون على VPS الخاص بك. التكوين يأتي عبر ؛ ملكية الجهاز لا تأتي معها.
توقف التصحيح كونه عنصر التقويم الخاص بك
تخبرك لوحة بالتحديث متاح. لا يزال يتعين على شخص ما تطبيقه واختباره والاستيقاظ إذا حدث خطأ. هنا هذه ليست مهمة على جانبك على الإطلاق.
قواعد Nginx قراءة قبل أن يتم إسقاطها
كتل الموقع المخصصة ، حدود المعدل وإعادة كتابة القواعد تتراكم في لوحة على مر السنين. نقرأها ونعيد إنتاج السلوك بدلاً من افتراض أن التخلف عن السداد لم يتم لمسه أبدًا.
استبدال نظام كرون عمدا
عادةً ما يتم تشغيل RunCloud wp-cron من كرون النظام. هذا هو القرار الصحيح ، ويجب إعادة إنشائه هنا بدلاً من العودة بصمت إلى كرون الزائر.
ضبط قاعدة البيانات التي جاءت من حجم VPS الخاص بك
يتم قياس حدود تجمع التخزين المؤقت والاتصال على مربع المدارة ذاتيا إلى هذا المربع. يتم نقلها عبر غير المفحوص فهي إما مسرفة أو عنق الزجاجة.
مواقع متعددة غير متشابكة
تشجع اللوحات العديد من المواقع على خادم واحد يشارك عمال PHP. عادة ما يكون فصلها أكبر تغيير في الأداء الفردي لهذه الخطوة.
خطط للأجزاء التي لا يمكن أن تحضرها نسخة.
الملفات وقاعدة البيانات هي النصف السهل. النصف الذي يكسر المواقع هو كل ما كان RunCloud يفعله خارج تثبيت WordPress.
- تم جرد تخصيصات Nginx قبل هذه الخطوة
- وظائف نظام كرون إعادة إنشاء
- SSL و DNS قطع مع TTL خفضت أولا
- استعادة أي نسخ احتياطية يومية من لوحة التحكم
ثلاثة مواقع كانت تتشارك في بركة واحدة
يضع إعداد RunCloud المشترك عدة مواقع على أحد VPS يشارك عمال PHP ، لذلك فإن أكثرها ازدحامًا يحدد وقت الاستجابة لهم جميعًا.
ما نغيره يتحرك من RunCloud
تختلف هذه عن موقع WordPress القياسي في نفس الخطة ، وكل منها يتبع من حيث يترك VPS المدارة بواسطة لوحة الأشياء.
| الإعداد | ما نضبطه | السبب |
|---|---|---|
| تخصيصات Nginx | مخترع من الفريق ومستنسخة صراحة | تكون كتل الموقع وإعادة كتابة القواعد المضافة إلى لوحة على مدى عدة سنوات غير مرئية في نسخة من ملف وقاعدة بيانات ، ويتصرف الموقع بشكل مختلف لحظة رحيلهم. |
| مصدر كرون | جدولة منصة، مع WP-Cron اليسار تعطيل كما كان بالفعل | عادة ما يتم تشغيل خادم تديره لوحة wp-cron من كرون النظام ، لذلك فإن الترحيل الذي يعيد تمكين cron الذي يثيره الزائر بهدوء يجعل العمل المجدول غير موثوق به لأول مرة منذ سنوات. |
| تخصيص العمال | تجمع واحد لكل موقع بدلا من تجمع واحد مشترك بين جميع المواقع | تشترك العديد من المواقع على VPS في مجموعة PHP-FPM ، مما يعني أن أكثرها ازدحامًا يحدد مدى بطء الشخص الهادئ. |
| تحجيم قاعدة البيانات | مشتقة من عبء العمل بدلاً من نقلها من VPS القديم | تم قياس إعدادات تجمع التخزين المؤقت والاتصال في صندوق مدار ذاتيًا إلى ذاكرة هذا الصندوق ، لذا فإن استيرادها إما يهدر سعة أو يخنق الموقع. |
| مسؤولية نظام التشغيل | تم نقله بالكامل بدلاً من إخطاره | لوحة التحكم تطفو على التحديث ولا تزال تترك الشخص مسؤولا عن تطبيقه، وهي التكلفة الفعلية للناس الإدارة الذاتية التقليل من شأن. |
أسعار واضحة وبسيطة.
تتضمن كل خطة نقلًا مجانيًا ونسخًا احتياطيًا يوميًا وشهادة SSL ودعمًا على مدار الساعة.
- موقع ووردبريس واحد
- 10 غيغابايت من تخزين NVMe
- شهادة SSL مجانية
- نسخ احتياطي يومي
- نشر بنقرة واحدة
- الدعم عبر التذاكر
- 5 مواقع ووردبريس
- 50 غيغابايت من تخزين NVMe
- شهادة SSL مجانية
- نسخ احتياطي يومي
- نشر بنقرة واحدة
- تذاكر دعم ذات أولوية
- 20 مواقع ووردبريس
- 200 غيغابايت من تخزين NVMe
- شهادة SSL مجانية
- نسخ احتياطي يومي
- نشر بنقرة واحدة
- دعم مخصص
الأسئلة الشائعة.
هل أحتفظ بـ VPS بعد الانتقال؟
هل ستنجو قواعد Nginx المخصصة الخاصة بي؟
أدير عدة مواقع على خادم RunCloud واحد. هل هذا جيد هنا؟
ماذا يحدث لوظائفي الكرون؟
هل هذا تخفيض في السيطرة؟
قم بإيقاف تشغيل RunCloud وتوقف عن الحفاظ على الخادم.
الهجرة الحرة، وتكاثر سلوك Nginx الخاص بك، ولا أحد على الجانب الخاص بك صفحة لتحديث النواة.