أعتقد أنهم كذلك 
انتظر حتى يتم دمج طلب السحب (PR) هذا، ثم اتبع الخطوات المذكورة في الرابط أدناه:
حوالي 100 جيجابايت 
سأفعل ذلك
لذا، بينما أفكر في أتمتة هذه الترقية، يتبادر إلى ذهني أن معرفة الوقت المناسب لتخطي ما بعد النشر أمر معقد إلى حد ما.
بالنسبة للتثبيتات ذات الحاوية الواحدة، ما لم تكن هناك عملية هجرة غريبة (هذه هي المرة الأولى التي أسمع بها عنها خلال 4 سنوات من عملي)، فلا توجد أي فائدة في القيام بذلك بهذه الطريقة. فمعظم الترقيات تتضمن هجرات قليلة، وربما لا توجد أي منها تستهلك موارد حاسوبية كبيرة.
أما بالنسبة للتثبيتات ذات الحاويتين، فمن الجيد دائمًا استخدام SKIP_POST_DEPLOYMENT_MIGRATIONS، حيث يمكنك تعطيل موقعك إذا تسببت الهجرات في تعطل الحاوية النشطة، مما يقلل من ميزة القدرة على بدء تشغيل الحاوية الجديدة بينما تستمر الحاوية القديمة في العمل. ومع ذلك، حتى في هذه الحالة، لا تتضمن كل ترقيات هجرات تسبب مشاكل، لذا فإن حل إعادة التشغيل مرتين المقدم في هذا الالتزام (الذي نرحب به بشدة) من المرجح أن يؤدي إلى توقف أطول (دورتين لإعادة التشغيل) مقارنة بالاستمرار في استخدام النسخة التجريبية.
رأيي الحالي هو أن الحل الأفضل سيكون جعل عملية البدء (bootstrap) تقوم دائمًا بالهجرات مع تعيين SKIP_POST_DEPLOYMENT_MIGRATIONS=1، ثم تنفيذ الهجرة عند أول تشغيل. ومع ذلك، لا أملك حلاً أنيقًا لكيفية تنفيذ ذلك بالضبط. هل توجد طريقة سريعة لمعرفة ما إذا كانت هناك هجرات معلقة؟ أعتقد أن سكريبت التشغيل يمكن أن يحتوي على شرط مثل “إذا كانت هناك هجرات معلقة، قم بتشغيل الهجرة” مباشرة بعد بدء تشغيل unicorn؟ لكن هذا معقد بعض الشيء، ومن المرجح أنه لا يستحق الجهد في معظم حالات التثبيت وفي معظم الأوقات.
بالتأكيد لا يستحق الأمر القيام به في معظم الأوقات، لكن إذا كانت ترقيات برنامجك تستغرق نادرًا (ولكن أحيانًا) وقتًا أطول بـ 10 أضعاف من المعتاد، فهذا يمثل مشكلة حقيقية لكثير من المستخدمين.
بعد هذا لن أقوم بتشغيل ترقيات Discourse إلا بعد مرور أسبوع على الأقل من إصدارها. بالطبع يمكنك القول إنني أحمق لعدم الانتظار من البداية، فقد جلبت ذلك على نفسي، وكان يجب أن أعرف أفضل، وكل ذلك صحيح تمامًا! ومع ذلك، فإن جعل أوقات الترقية أكثر اتساقًا وقابلية للتنبؤ بها سيكون خدمة عظيمة لجميع الحمقى الآخرين هناك.
بدلاً من ذلك، يعالج الترقية عبر واجهة المستخدم في docker_manager هذه العملية تلقائيًا.
هذا رائع! أنا نادرًا ما أقوم بالترقية بهذه الطريقة، لذا لم يكن ليخطر ببالي ذلك أبدًا. شكرًا لك.
عذراً، للتوضيح، إذا أضفنا متغير البيئة هذا إلى حاوية تطبيقنا:
إما:
SKIP_POST_DEPLOYMENT_MIGRATIONS: true
أو
SKIP_POST_DEPLOYMENT_MIGRATIONS: 1
عند تشغيل launcher، هل سيتجاوز جميع هجرات قاعدة البيانات عند إعادة البناء؟
هل هذا هو الفهم الصحيح؟
ليس تماماً. راجع Introducing Post Deployment Migration
مرحباً، لقد تمكنت من تحديث كل شيء باستخدام هذه الطريقة (أي عبر واجهة المستخدم)، لكن بعد ذلك يبدأ في تنفيذ عملية النشر مع تعليمات الترحيل (التي تم تخطيها من البداية) وما إلى ذلك، ثم يتعطل بعد فترة، موضحاً أن الترقية لم تنجح. ومع ذلك، يعمل المنتدى كما ينبغي، وتعرض لوحة تحكم المسؤول أن كل شيء محدث.
سؤالي هو: هل يجب أن أفعل شيئاً آخر؟ وتحديداً بشأن عملية النشر هذه، هل أحتاج إلى تشغيلها عبر سطر الأوامر (لتجنب التعطل)؟ هل هناك أوامر محددة لها، وهل سيتعطل المنتدى أثناء تشغيلها؟
هل لا تزال تملك سجلات السجلات ذات الصلة؟ يجب عليك تشغيل عمليات الترحيل، وإلا فإن البحث سيتعطل في الموقع.
./launcher enter app
bundle exec rails db:migrate
لا توجد سجلات، لكن كانت الاستعلامات المذكورة سابقًا في هذا الموضوع هي نفسها.
قبل أن أبدأ هذه العملية وأتركها تعمل، هل سيؤدي ذلك إلى تعطيل الموقع مؤقتًا (مثل إعادة البناء) أم أنه “آمن”؟ آسف للإصرار على هذه النقطة المحددة، لكن هذا موقع إنتاجي، والتوقف لمدة 10-15 دقيقة مقبول، أما التوقف ليوم أو يومين فهو غير مقبول ويجب دراسته بعناية إذا لم تكن هناك خيارات أخرى متاحة.
إذا قمت بالفعل بالترقية إلى أحدث إصدار، فإن تشغيل عمليات الترحيل لن يتسبب في أي توقف لموقعك. والمقصود بالترقية هنا هو نشر الإصدار الجديد، لكن عملية الترحيل بعد النشر المذكورة في هذا الموضوع فشلت.
شكرًا لك. في النهاية عدت إلى التحديثات عبر واجهة المستخدم، وحاولت مرة أخرى، فتمت فعليًا عمليات ترحيل قاعدة البيانات بعد النشر. استغرق الأمر عدة ساعات (وكمية كبيرة من وحدة المعالجة المركزية 
)، لكنها اكتملت، وأصبح كل شيء محدثًا بالكامل الآن! 