واجهت بعض المشاكل مع الترقية - فشل المنتدى الأول في المحاولة الأولى (عبر لوحة التحكم)، ثم فشل مرة أخرى عبر إعادة البناء، لكنه بدا أنه نجح في محاولة إعادة البناء الثانية، رغم أنني اضطررت بعد ذلك لإعادة البناء مرة إضافية. هذا ذكّرني بضرورة إيقاف جميع مثيلات Discourse عند إجراء الترقية مع تحديث PG12 (هناك ثلاثة منتديات Discourse على هذا الخادم، كل منها في حاوية منفصلة)، وبالتالي نجح ما يلي للمنتديين الآخرين:
لكن لسبب ما، لم يعد المنتدى الأول قابلاً للوصول، حيث تشير رسالة Safari إلى أن الخادم قطع الاتصال بشكل مفاجئ. يبدو أن إعادة البناء تتم بنجاح، لكن المنتدى غير قابل للوصول، رغم أنني أستطيع الدخول إلى وحدة تحكم التطبيق ووحدة تحكم Rails، ويبدو أن قاعدة البيانات سليمة.
الإنذارات الوحيدة التي أراها أثناء إعادة البناء والتي قد تكون ذات صلة:
168:M 31 Jan 2021 21:39:22.459 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
168:M 31 Jan 2021 21:39:22.459 # Server initialized
168:M 31 Jan 2021 21:39:22.459 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
168:M 31 Jan 2021 21:39:22.459 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo madvise > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled (set to 'madvise' or 'never').
168:M 31 Jan 2021 21:39:22.459 * Loading RDB produced by version 6.0.9
168:M 31 Jan 2021 21:39:22.459 * RDB age 21 seconds
168:M 31 Jan 2021 21:39:22.459 * RDB memory usage when created 4.03 Mb
168:M 31 Jan 2021 21:39:22.466 * DB loaded from disk: 0.006 seconds
168:M 31 Jan 2021 21:39:22.466 * Ready to accept connections
سجل الإنتاج (production.log):
Job exception: Error connecting to Redis on localhost:6379 (Errno::ENETUNREACH)
Error connecting to Redis on localhost:6379 (Errno::ENETUNREACH) subscribe failed, reconnecting in 1 second. Call stack /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.5/lib/redis/client.rb:367:in `rescue in establish_connection'
تظهر رسائل مماثلة في unicorn.stderr.log و unicorn.stdout.log.
عند الدخول إلى الحاوية وتنفيذ الأمر redis-cli ping، أحصل على استجابة PONG. يعمل Redis على الخادم (ولكن ليس داخل الحاويات الفردية - وهذا كان الحال دائمًا حسب علمي).
هل لديك أي أفكار حول ما قد يكون يحدث؟
(لقد قمت أيضًا بإعادة تشغيل الخادم، وأنشأت شهادة letsencrypt جديدة لهذا النطاق احتياطًا - لكن النتيجة لا تزال نفسها.)
بعض الأمور التي قد تكون سببًا في خطأ الاستجابة الفارغة:
الخادم متصل بشبكة VPN ولا توجد إمكانية للوصول إلى المنفذ.
إذا كان لديك عدة نسخ من Discourse على نفس الخادم، فمن المفترض وجود وكيل عكسي أمامها. تأكد من أنه يشير إلى حاوية Discourse (قد تحتاج إلى إعادة تشغيلها).
لا يوجد مساحة كافية على الخادم (يمكنك تشغيل الأمر df -hT /).
أنصحك بالبدء بفحص المساحة الحرة على القرص أولاً (3).
كان استخدام القرص يُظهر 31%، لكنني قمت بتشغيل أمر ./launcher cleanup على أي حال:
docker container ls
(للتأكد من تشغيل جميع حاويات المنتدى الثلاثة)
./launcher cleanup
تحذير! سيؤدي هذا إلى إزالة جميع الحاويات المتوقفة.
هل أنت متأكد من المتابعة؟ [y/N] y
إجمالي المساحة المستعادة: 0 بايت
تحذير! سيؤدي هذا إلى إزالة جميع الصور التي لا ترتبط بها حاوية واحدة على الأقل.
هل أنت متأكد من المتابعة؟ [y/N] y
الصور المحذوفة:
...
إجمالي المساحة المستعادة: 32.56 جيجابايت
نحن نستخدم HAProxy، وقد تفقدت ذلك (وأعدت تشغيله) وهو يعمل بشكل صحيح (كما أننا نقوم بإعادة التوجيه من HTTP إلى HTTPS عبره، وهذا يعمل بشكل جيد أيضًا للنطاق، لذا لا أعتقد أن المشكلة هناك - بالإضافة إلى أنه كان يعمل حتى هذا التحديث).
ما زلت قادرًا على الدخول إلى الحاوية والوصول إلى وحدة تحكم Rails، وقاعدة البيانات لا تزال موجودة/متصلة بالحاوية - لذا فإن هذا غريب للغاية - هل لدى أي شخص أفكار أخرى أو خطوات أخرى لاستكشاف المشكلة وحلها؟
إذا لم تتمكن من استكشاف المشكلة التي تواجهها وتصحيحها، فقد يكون أحد الخيارات هو إنشاء نسخة احتياطية من سطر الأوامر، ثم استعادتها على موقع جديد ونظيف يعمل على PG13. وبديلًا عن ذلك، إذا كنت بحاجة إلى إعادة موقعك إلى العمل، فيمكنك التراجع عن الإصدار إلى PG12، وإعادة المجلد الحالي shared/postgres_data_old إلى shared/postgres_data، ثم إعادة البناء. ومع ذلك، فإنني أنصح بمحاولة طريقة النسخ الاحتياطي والاستعادة بدلاً من ذلك، حيث لا يبدو أن المشكلة مرتبطة بترقية قاعدة البيانات نفسها.
إذا كانت لديك أي أفكار أخرى للتحقيق في هذا الأمر، فسأكون سعيدًا بتجربتها يا مايكل - لحسن الحظ، ليس الأمر كبيرًا لأن هذا المنتدى غير متصل بالإنترنت، حيث كان في وضع القراءة فقط على أي حال (بعد أن تم استبداله بمنتدى آخر).
إذا لم تعد لديك أفكار، فسأقوم بمحاولة استعادة النسخة الاحتياطية، ولكن إذا أمكن، فأتفضّل تشخيص المشكلة لأنني مهتم بمعرفة سبب حدوث ذلك (وكما أعتقد أنك مهتم أيضًا) - لذا فأنا بالتأكيد مستعد لاستكشاف الأمر بشكل أعمق إذا كنت كذلك.
بكل صراحة، جعلني هذا قليل القلق بشأن تحويل بعض منتدياتي الأخرى إلى Discourse، ومعرفة ما حدث بشكل خاطئ قد يكون مفيدًا لنا جميعًا.
إنها تثبيت قياسي متعدد الحاويات حيث يحتوي كل منتدى على ملف app.yml خاص به، وإعداد حاويات قائم على host: discourse/shared-site-name/standalone و host: discourse/shared-site-name/standalone/log/var-log (كما هو موضح في الأسئلة التي طرحتها والمشاركات في هذا المنتدى).
عند الدخول إلى كل حاوية وتشغيل psql (sudo -u postgres psql discourse) ثم \l+، يظهر فقط قاعدة بيانات واحدة باسم discourse لكل حاوية (وتختلف أحجامها)، لذا أفترض أن هذه حالات Discourse مستقلة.
هل لديك رابط للطريقة “القياسية” لتشغيل منتديات Discourse مستقلة متعددة على خادم؟ يمكنني التحقق لمعرفة ما إذا كان ذلك مطابقًا لما لدي هنا، على الرغم من أنني متأكد إلى حد كبير أن ما لدي مبني على منشورات وتوجيهات من فريق Discourse.
هل تقوم بتشغيل nginx داخل الحاوية؟ الخطوة التالية التي سأحاول اتباعها هي معرفة أين تنتهي الطلبات. إذن، كما أفهم، لديك HAProxy يقوم بإنهاء SSL ثم يقوم بتمرير الطلبات إلى الحاويات المعنية؟
بقدر ما أعلم، فإن الحاويات نفسها جميعها “قياسية” (لذا أستنتج أن كل منها يعمل nginx) ونعم، يتولى HAProxy معالجة جميع شهادات SSL ويوجه الطلبات إلى كل حاوية.
backend main_apache_sites
server server1 127.0.0.1:8080 cookie A check
cookie JSESSIONID prefix nocache
backend discourse_docker
server server2 127.0.0.1:8888 cookie A check
cookie JSESSIONID prefix nocache
backend discourse_docker_2
server server2 127.0.0.1:8889 cookie A check
cookie JSESSIONID prefix nocache
backend discourse_docker_3
server server2 127.0.0.1:8890 cookie A check
cookie JSESSIONID prefix nocache
backend letsencrypt-backend
server letsencrypt 127.0.0.1:54321
حيث كان السبب غير معروف أن جميع خوادم Discourse الخلفية تحتوي على server2 في السطر الثاني - قمت بتغييرها إلى server2، server3، إلخ، أمس، لكن هذا لم يحدث أي فرق (وكان يعمل بشكل صحيح بهذا الشكل سابقًا).
هل توجد ملفات سجل محددة يمكنني الاطلاع عليها قد توفر مزيدًا من التلميحات؟ ربما ملفات سجل Docker؟
نعم، هذه معطلة:
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## قم بإلغاء التعليق عن هذين السطرين إذا كنت ترغب في إضافة Lets Encrypt (https)
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"
يجب أن تكون سجلات nginx داخل حاويات التطبيق قادرة على تأكيد وصول الطلبات إلى التطبيق، هل يمكنك التحقق منها؟ يقوم nginx داخل الحاوية بتوجيه الطلبات إلى 127.0.0.1:3000 وهو ما يشير إلى عملية unicorn.
عند البحث في /var/log/nginx و /shared/log/rails، لا يبدو أن هناك شيئًا بارزًا، بل إن معظم السجلات لم يتم تحديثها اليوم (الـ 4) باستثناء /shared/log/rails/production.log الذي يحتوي فقط على عدد قليل من المهام مثل هذا:
كما قمت بتغيير المنفذ في HAProxy وحصلت على خطأ “لم يتم العثور على الخادم” كما هو متوقع، ثم قمت بتحديث الحاوية لاستخدام نفس المنفذ وعادت السلوكيات إلى ما كانت عليه (لذلك أعتقد أن هذا يستبعد مشكلة في HAProxy).
هل توجد أي سجلات Docker يمكنني الاطلاع عليها؟ أو هل يمكنني حفظ/تصدير هذه الحاوية وإرسالها إليك لتتمكن من فحصها؟ أظن أنك تتساءل عما حدث خطأ بقدر ما أتساءل أنا
لم يتم تعديل أي سجلات nginx اليوم، رغم أن آخر سجل في 30 يناير يُظهر: 7: limiting requests by zone “flood” client: my.ip.address, POST /mini-profiler-resources نوع خطأ.
تعديل: لست متأكدًا مما إذا كان هذا مفيدًا، ولكن عند تشغيل docker logs APP:
# docker logs f2
run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
run-parts: executing /etc/runit/1.d/anacron
run-parts: executing /etc/runit/1.d/cleanup-pids
Cleaning stale PID files
run-parts: executing /etc/runit/1.d/copy-env
Started runsvdir, PID is 42
ok: run: redis: (pid 55) 0s
ok: run: postgres: (pid 54) 0s
chgrp: invalid group: 'syslog'
supervisor pid: 51 unicorn pid: 82
(51) Reopening logs
(51) Reopening logs
(51) Reopening logs
(51) Stopping Sidekiq
(51) Reloading unicorn (82)
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid... 22039
(51) Old pid is: 82 New pid is: 22039
(51) Stopping Sidekiq
(51) Reloading unicorn (22039)
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid... 23358
(51) Old pid is: 22039 New pid is: 23358
(51) Reopening logs
(51) Reopening logs
عند فحص السجلات ومراجعة ردودك السابقة، يبدو أن التطبيق يحاول الوصول إلى ريدز عبر localhost:6379 داخل الحاوية، ويبدو أن ريدز يبدأ بشكل صحيح أيضًا، ومع ذلك لا يمكنه الاتصال لسبب ما (محير). ومع ذلك، من الممكن أن تكون رسائل الخطأ هذه قد ظهرت عندما يحاول message_bus الاتصال قبل بدء ريدز، أو بعد إيقافه في حالة إعادة التشغيل.
لقد ذكرت أن ريدز يعمل على الخادم ولكن ليس داخل الحاويات الفردية - هل يمكنك التوسع في ذلك؟
مع هذا الإعداد، سيعمل ريدز داخل الحاوية (كما يمكن رؤيته في مخرجات سجلات Docker).
من ناحية أخرى، عند التنقل إلى عنوان URL للموقع الذي لا يعمل، ماذا يظهر في سجلات nginx؟ يجب أن يكون ملف error.log فارغًا، بينما يجب أن يحتوي ملف access.log على طلبات HTTP متنوعة. فقط نحاول تحديد النقطة التي يحدث فيها الخطأ.
آسف، لقد خلطت الأمور. في الواقع، يعمل Redis داخل كل حاوية، وتم التحقق من ذلك بتشغيل الأوامر التالية على الخادم نفسه، ثم في كل من حاويات Discourse الثلاث، مع الحصول على نفس المخرجات في كل حالة:
$ redis-cli ping
PONG
$ redis-server
# Creating Server TCP listening socket *:6379: bind: Address already in use (means it's already started)
$ redis-cli
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> get mykey
(nil)
127.0.0.1:6379> set mykey somevalue
OK
127.0.0.1:6379> get mykey
"somevalue"
ينطبق نفس الشيء على الحاويات الثلاث (من الجدير بالذكر أن أمر get mykey الأول يعيد دائمًا nil)، وبالتالي يمكن القول بثقة أن Redis يعمل بشكل مستقل في جميع الحاويات.
الملف فارغ ولم يتم كتابة أي شيء في هذا المجلد اليوم:
drwxr-xr-x 2 www-data www-data 4096 Feb 4 21:26 .
drwxrwxr-x 9 root root 4096 Feb 2 08:03 ..
-rw-r--r-- 1 www-data www-data 0 Feb 3 07:38 access.log
-rw-r--r-- 1 www-data www-data 0 Feb 2 08:03 access.log.1
-rw-r--r-- 1 www-data www-data 294 Feb 1 09:43 access.log.2.gz
-rw-r--r-- 1 www-data www-data 37598 Jan 30 23:56 access.log.3.gz
-rw-r--r-- 1 www-data www-data 58059 Jan 30 07:36 access.log.4.gz
-rw-r--r-- 1 www-data www-data 55988 Jan 29 07:34 access.log.5.gz
-rw-r--r-- 1 www-data www-data 73964 Jan 28 07:49 access.log.6.gz
-rw-r--r-- 1 www-data www-data 78069 Jan 27 07:53 access.log.7.gz
-rw-r--r-- 1 www-data www-data 0 Feb 3 07:38 error.log
-rw-r--r-- 1 www-data www-data 0 Feb 2 08:03 error.log.1
-rw-r--r-- 1 www-data www-data 20 Feb 1 00:31 error.log.2.gz
-rw-r--r-- 1 www-data www-data 632 Jan 30 23:46 error.log.3.gz
-rw-r--r-- 1 www-data www-data 265 Jan 29 09:07 error.log.4.gz
-rw-r--r-- 1 www-data www-data 20 Jan 28 07:50 error.log.5.gz
-rw-r--r-- 1 www-data www-data 3107 Jan 28 07:41 error.log.6.gz
-rw-r--r-- 1 www-data www-data 20 Jan 26 07:53 error.log.7.gz
لقد تحققت من سجلات الوصول لحاوية أخرى وهي تعمل بشكل صحيح، إذن المشكلة تقتصر على هذه الحاوية فقط.
يبدو أن HAProxy يقوم بإرسال الطلب، لكن الحاوية غير قادرة على معالجته أو قبوله — أتساءل إذا كان هناك أي شيء يمكن إعادة تعيينه هناك؟ (وهو ما كنت أظن أن إعادة بناء الحاوية ستقوم به تلقائيًا؟)
IMAGE COMMAND CREATED STATUS PORTS
local_discourse/1 "/sbin/boot" منذ 20 ساعة قيد التشغيل منذ 20 ساعة 0.0.0.0:2225->22/tcp, 0.0.0.0:8892->80/tcp
local_discourse/2 "/sbin/boot" منذ 4 أيام قيد التشغيل منذ 4 أيام 0.0.0.0:2223->22/tcp, 0.0.0.0:8889->80/tcp
local_discourse/3 "/sbin/boot" منذ 4 أيام قيد التشغيل منذ 4 أيام 0.0.0.0:2224->22/tcp, 0.0.0.0:8890->80/tcp
رأيي الغريزي يقول إن الأمر يتعلق بالمحاولة الفاشلة عبر لوحة التحكم — فعادةً، عند تحديثات PostgreSQL أو التحديثات الرئيسية، تشير لوحة التحكم إلى ضرورة إجراء إعادة بناء، وأن التحديث معطل عبر لوحة التحكم، لكن لسبب ما لم يحدث ذلك (ربما لأنني لم أقم بتحديث ذلك المنتدى منذ فترة، لذا ظننت أنه يجب عليّ البدء بلوحة التحكم أولاً)، أو من الممكن أن النظام لم يُغلق أو يُشغّل بشكل صحيح قبل إجراء إعادة البناء
في ملف تكوين HAProxy، يمكنني رؤية أن الخوادم الخلفية مُهيأة للتوجيه إلى المنافذ 8888، 8889، و8890:
ومع ذلك، فإن حاويات التطبيق تستمع إلى المنافذ 8892، 8889، و8890 - يبدو أن هناك تناقضًا في backend discourse_docker. هل قمت بتحديث هذا في التكوين منذ نشر ذلك؟
نعم، تتطابق منافذ HAProxy مع منافذ الحاوية الصحيحة أنا متأكد تقريبًا من أن الأمر لا علاقة له بهذا، حيث كان يعمل بشكل صحيح - لقد حدث هذا فقط بعد الترقية/إعادة البناء تلك.
الدخول إلى الحاوية وفتح إحصائيات Top، ثم الانتقال إلى الموقع لا يبدو أنه يحدث أي فرق أيضًا. في حال كان ذلك مفيدًا، إليك لقطة شاشة:
أنا متأكد تقريبًا من أن الأمر لا علاقة له بهذا، حيث كان يعمل بشكل صحيح - لقد حدث هذا فقط بعد الترقية/إعادة البناء تلك.