اعتذار إذا تم طرح هذا السؤال من قبل، لقد بحثت ولكن لم أر السيناريو المحدد الذي أخطط له (أو فاتني، ولكني أريد التأكد من أنني فهمته بشكل صحيح نظرًا لأنني لم أقم به من قبل).
ما زلت على 18 (وهو المكان الذي بدأت منه؛ لم أقم بترقية نظام تشغيل لينكس من قبل سوى تحديثات الأمان) لذا في وقت ما قريبًا سأنتقل إلى 22. كل ما قرأته هنا يشير إلى أن الانتقال إلى تثبيت جديد أذكى بكثير من ترقية تثبيتك الحالي لأنه من المحتمل أن يكون هناك عدد لا يحصى من المشكلات العشوائية التي قد تحدث أو لا تحدث، ولكن الأمر لا يستحق المخاطرة لأنه إذا حدثت فإنها مجرد متاعب غير مجدية.
لقد قرأت هذا الدليل Move your Discourse Instance to a Different Server ولكنه يشير إلى الانتقال من خادم ما إلى DigitalOcean (أو العكس) مما يجعل اللقطة غير قابلة للتطبيق، بينما أخطط للانتقال من DigitalOcean Droplet الحالي إلى واحد جديد (والذي رأيت إشارات متعددة إليه يعمل بشكل جيد ومثالي للترقية).
لذا سؤالي لنقل من DO إلى DO هو هل يمكنني فقط إيقاف تشغيل الـ droplet الخاص بي، وأخذ لقطة، وتشغيل Droplet جديد على أوبونتو المحدث الذي أريده، وتحميل اللقطة، وفويلا (تعديل سجل DNS للمجال وما إلى ذلك)؟ أساسًا التحايل على “إعادة تثبيت Discourse بالكامل” الذي يفصله الدليل. فهمي للقطات هو أنها يفترض أن تكون نسخة متطابقة 1:1 للتثبيت على الـ Droplet مقابل النسخ الاحتياطي وهو خاص بإعداد Discourse الخاص بك والذي يتطلب تثبيتًا كاملاً للاستفادة منه فعليًا. هل أفهم هذا بشكل صحيح؟ أي سلبيات لهذا بخلاف زيادة فترة التوقف؟
باختصار: هل يمكنني فقط أخذ لقطة، وإنشاء droplet محدث جديد، وتحميل اللقطة والانتهاء؟
آمل ألا أكون مخطئًا تمامًا، ولكن استعادة لقطة من الإصدار 18 على الإصدار 22 ستعيدك إلى الإصدار 18، لأن اللقطة هي نسخة طبق الأصل 1:1 من القطرة بأكملها.
بالنسبة لي، فإن إنشاء قطرة جديدة تمامًا هو دائمًا الخيار الأخير، لأنني بحاجة إلى تثبيت كل ما يحتاجه نظام Ubuntu (أو أي نظام تشغيل آخر)، بما في ذلك نظام البريد وما إلى ذلك.
أنا متأكد تمامًا من أن هذه مجرد مهمة تافهة أخرى لمن يستطيعون القيام بها، ولكن بعد 10 سنوات لم أتعلم أبدًا كيفية بدء قطرة وظيفية جديدة بسهولة.
فقط قم بعمل نسخة احتياطية من موقعك وملف app.yml، وأنشئ قطرة جديدة على إصدار نظام التشغيل الجديد، وأعد تعيين عنوان IP إلى القطرة الجديدة (بحيث يشير النطاق إلى المكان الصحيح والجديد)، وقم بتثبيت Discourse (يمكنك إلغاء المعالج وتحديث app.yml، ثم إعادة البناء) واستيراد النسخة الاحتياطية الخاصة بك.
يجب أن تستغرق هذه العملية برمتها أقل من ساعة.
هذه العملية لا تلمس القطرة الموجودة لديك أبدًا، لذلك إذا فشل كل شيء آخر، فمن السهل التراجع؟
إذا انتقلت من إصدار LTS لنظام التشغيل إلى الإصدار التالي، أتوقع عملية سلسة إلى حد ما. لذا، قد أقوم بعمل نسخة احتياطية - بالطبع - وأقوم بتنزيلها للأمان - بالطبع - ثم أجرب تحديث نظام التشغيل. إذا لم ينجح الأمر، يمكنني حينئذٍ تجربة نظام تشغيل جديد.
ولكن عند القيام بذلك، سأواجه وقت تعطل أطول للمنتدى.
أنا متردد قليلاً في الانتقال إلى نسخة جديدة بشكل أساسي لأنني سأحتاج إلى تحديث نظام أسماء النطاقات (DNS) والانتظار حتى ينتشر. على الرغم من أنني أرى أن المنشور أعلاه يقول إنه يمكنني أخذ عنوان IP الخاص بي معي، وهو أمر لطيف، وهذا يزيل هذا التردد.
في الواقع، بتغيير إجابتي بالكامل، إذا كان بإمكاني أخذ عنوان IP الخاص بي إلى نسخة جديدة، فسيكون ذلك مفضلاً. ربما لا تسمح جميع مقدمي الخدمة بذلك. ربما بالنسبة لبعض مقدمي الخدمة، سيفقد المرء عنوان IP مجاني ويبدأ في الدفع مقابل عنوان IP، لأنه تم نقله على الرغم من أنه لم يتغير.
التخفيف السهل للغاية لهذا هو ببساطة تعيين قيمة TTL منخفضة جدًا (أو تبديل خوادم الأسماء إلى خادم يدعم ذلك). بهذه الطريقة تنتهي صلاحية السجلات في وقت أقل من وقت إعادة البناء.
يمكنك استخدام عنوان IP ثابت (لا أتذكر ما الذي تسميه DigitalOcean الآن). في الشبكات، يمكنك الحصول على عنوان IP جديد ثم ربطه بـ Droplet القديم. ثم تقوم بتغيير نظام أسماء النطاقات (DNS) وتتركه ينتشر. عندما تكون جاهزًا للانتقال إلى الخادم الجديد، يمكنك ببساطة تبديل عنوان IP للإشارة إلى الخادم الجديد. يحدث هذا على الفور وإذا حدث خطأ ما، يمكنك التبديل مرة أخرى.
سيكون بدء قطرة جديدة هو خياري الأخير أيضًا لأنني لم أنقل القطرات من قبل (هذه هي الأولى التي لدي) ولم أقم بترقية نظام التشغيل من قبل، ولكن جميع الأدلة التي أراها هنا تبدو توصي بشكل عام بالقيام بذلك بهذه الطريقة مقابل مجرد ترقية القطرة التي أنت عليها، لذلك اعتقدت أنه من الأفضل اتباع الأغلبية إذا كان كلا الطريقين ينطويان على مخاطر ولم أقم بأي منهما.
تفكيري أيضًا هو أنه إذا فشلت الترقية تمامًا بطريقة ما الآن، فسيكون لديك وقت تعطل من المحاولة، ووقت تعطل أثناء إجبارك على محاولة إصلاحها (أو الاستسلام وإنشاء واحدة جديدة)، مقابل أن القطرة الجديدة قد لا تعمل بينما تظل الأصلية قيد التشغيل وسليمة. لا أعرف لماذا قد تفشل، ولكن البحث في meta هنا يظهر أن الكثير من الأشخاص يقولون إنها فشلت، أو روابط تقول إنهم لن يوصوا بذلك أبدًا (بالإضافة إلى الأدلة الرسمية هنا و DigitalOcean تقترح ذلك).
أعتقد أنني سأجربها في نهاية هذا الأسبوع.
عناوين IP المحجوزة (المعروفة سابقًا باسم عناوين IP العائمة على ما يبدو)
صحيح: إذا قمت بإنشاء ملف app.yml فارغ (عن طريق، على سبيل المثال، touch app.yml في دليل الحاويات) ولصقت فيه (بحذر!) محتويات من خادمك الآخر، فلن تحتاج إلى تشغيل ./discourse-setup على الإطلاق.
إحدى المشكلات التي واجهتني هذا الأسبوع كانت إعداد البريد الإلكتروني الخاص بي: تأكد من أن خدمة البريد الإلكتروني الخاصة بك لا تتطلب عنوان IP الدقيق الذي تتصل منه. إذا كانت تفعل ذلك، فتأكد من تحديث هذا التكوين (لدى مزود الخدمة الخاص بك).
إنه الخيار الأكثر أمانًا على الرغم من ذلك. إذا قمت بتعطيله، فسيستمر موقعك القديم في العمل. لا يوجد أي خطر على الإطلاق.
هناك موضوع حول ذلك. يمكنك نسخ ملف yml الخاص بك وملفات التشفير الخاصة بـ Let’s Encrypt وحتى رؤية أنه يعمل عن طريق تغيير نظام أسماء النطاقات المحلي الخاص بك للإشارة إلى الخادم الجديد.
وإذا كانت لديك نسخ احتياطية على S3، فيمكنك النوم بشكل أفضل مع العلم أنه إذا حدث خطأ فادح، يمكنك تشغيل خادم جديد واستعادة نسخة احتياطية في حوالي 30 دقيقة.
كان قلقي الوحيد في الواقع ليس مجرد نقله، بل المرور بكل الإعدادات وبشكل ما إفساد بعض الإعدادات سواء كانت خدمة البريد الإلكتروني أو Let’s Encrypt أو ما شابه ذلك، وإدراك ذلك فقط لاحقًا بمجرد انهيار كل شيء. وهو بالطبع ليس مشكلة إذا كان بإمكانه فقط قراءة ملف app.yml القديم الخاص بي، لذا لا بأس بذلك.
لست متأكدًا تمامًا مما يعنيه هذا ولكني لا أعتقد أنه كذلك… لدي Mailgun وأتحقق من جميع السجلات هناك/نظام أسماء النطاقات في GoDaddy، لا يبدو أن أي شيء مرتبط بأي عنوان IP محدد.
حسنًا، يبدو الأمر سهلاً بما يكفي، سأجربه هذا الأسبوع. ربما أقوم بالترقية إلى Droplet أفضل في نفس الوقت.
لا يمكنني العثور على الموضوع الذي أشعر باليقين بوجوده. باختصار، قم بتكوين النسخ الاحتياطي على s3 في إعدادات البيئة الخاصة بك، وقم بتشغيل rsync فوق /var/discourse أو ربما فقط مجلدات ssl و letsencrypt والحاويات، ثم أعد البناء.