لم يصل موضوع المصدر لعام 2025 إلى تثبيت مؤكد وفعّال لـ AdventureLog. فقد تم تحميل الواجهة الأمامية، لكن بدا أن إنشاء الحساب لا يفعل شيئًا. وأظهرت السجلات اللاحقة دليلين أقوى: إذ أفادت الواجهة الأمامية بشكل متكرر أن فشل الجلب مع مهلات اتصال، بينما كانت الواجهة الخلفية تقول بشكل متكرر PostgreSQL غير متاحة - جارٍ الانتظار. وقد تمت تهيئة حاوية قاعدة البيانات نفسها في النهاية وبدأت الاستماع بصورة طبيعية.
تشير هذه الأدلة إلى مشكلة في الاتصال أو الإعداد بين خدمات متعددة، بدلًا من استنتاج بسيط مفاده أن «AdventureLog لا يعمل على ZimaOS». كما تغيّر النشر الحالي للمشروع الأساسي الذي يديره AdventureLog: إذ يستخدم Compose المُصان حاليًا .env الملف، وإصدارًا أحدث من PostGIS، وصورًا حالية للواجهة الأمامية والخلفية، ومثبّتًا مخصصًا يطلب عناوين URL الخارجية للواجهة الأمامية والخلفية.
استخدم المصدر حزمة Compose مكوّنة من ثلاث خدمات
تضمّن Compose لعام 2025:
- واجهة أمامية مبنية على SvelteKit تُسمى
web; - خدمة Django/الواجهة الخلفية تُسمى
server; - قاعدة بيانات PostGIS/PostgreSQL تُسمى
db.
كشفت الواجهة الأمامية المنفذ المضيف 8015، وكشفت الواجهة الخلفية منفذًا مضيفًا آخر، بينما خزّنت أحجام Docker المسماة بيانات قاعدة البيانات والوسائط.
كان العَرَض الظاهر هو أن شاشة إنشاء الحساب لم تفعل شيئًا
بدا أن التطبيق ثُبّت بنجاح من تطبيق ZimaOS المخصص، لكن المستخدم لم يتمكن من متابعة تسجيل الدخول أو إنشاء الحساب. ويمكن أن ينتج هذا النوع من أعراض الواجهة الأمامية عن:
- فشل الواجهة الأمامية في الوصول إلى الواجهة الخلفية؛
- فشل الواجهة الخلفية في الوصول إلى PostgreSQL؛
- عناوين URL غير صحيحة للمصدر أو CSRF؛
- ترتيب بدء الخدمة أو حالتها الصحية؛
- وكيل عكسي يغيّر عنوان URL الخارجي الفعلي.
احتوت سجلات المصدر على أدلة تخص الطبقتين الأوليين، لكنها لم تثبت سببًا جذريًا نهائيًا واحدًا.
انتهت مهلة الواجهة الأمامية بشكل متكرر أثناء الجلب
أفاد سجل الواجهة الأمامية TypeError: fetch failed و ETIMEDOUT. وهذا يعني أن عملية الواجهة الأمامية لم تتمكن من إكمال طلب شبكة كانت تتوقع نجاحه.
استخدم Compose الأصلي PUBLIC_SERVER_URL=http://server:8000، وهذا صحيح من الناحية المفاهيمية للاتصال بين الخدمات داخل مشروع Compose واحد. ومع ذلك، فإن تغيير متغيرات URL الأخرى إلى عناوين الشبكة المحلية أو نطاقات الوكيل قد يؤدي إلى عدم تطابق بين المصدر والمتصفح والواجهة الخلفية.
تعذّر على الواجهة الخلفية الوصول إلى PostgreSQL في البداية
كان سجل الواجهة الخلفية يعرض بشكل متكرر PostgreSQL غير متاحة - جارٍ الانتظار. في الوقت نفسه، أظهر سجل قاعدة البيانات تهيئة PostGIS ثم أصبحت جاهزة في النهاية.
يتوافق ذلك مع بدء تشغيل الواجهة الخلفية قبل جاهزية قاعدة البيانات، أو وجود إعداد اتصال غير صحيح بقاعدة البيانات، أو مشكلة في شبكة الخدمات. ولا يحتوي المصدر على أدلة كافية للتمييز conclusively بين هذه الاحتمالات.
إضافة نفق Cloudflare لم تُصلح المشكلة الأصلية
حاول المستخدم استخدام نفق Cloudflare بعد فشل التثبيت الأول، لكن التطبيق ظل لا يعمل. وهذا متوقع إذا كان المسار الأساسي بين الواجهة الأمامية ↔ الخلفية ↔ قاعدة البيانات معطّلًا: يمكن للنفق العام إتاحة الوصول إلى خدمة، لكنه لا يصلح شبكة Compose الداخلية.
يستخدم AdventureLog حاليًا تخطيط Compose أبسط ومُصانًا
يستخدم Compose الحالي في المنبع لـ AdventureLog الآن:
-
ghcr.io/seanmorley15/adventurelog-frontend:latest; -
ghcr.io/seanmorley15/adventurelog-backend:latest; -
postgis/postgis:16-3.5; - مشترك
.envملف - الدائمة
postgres_dataوadventurelog_mediaوحدات التخزين.
راجع تعريف Compose الحالي لـ AdventureLog بدلًا من نسخ ملف YAML المنشور في المنتدى عام 2025 حرفيًا.
اضبط عناوين URL للواجهة الأمامية والواجهة الخلفية بعناية
يطلب مُثبّت AdventureLog الحالي عنوان URL للواجهة الأمامية وعنوان URL للواجهة الخلفية، ويستمد إعداد المنافذ منهما. وهذه إشارة قوية إلى أن قيم عناوين URL/المصدر جزء من عقد التطبيق وليست مجرد تسميات شكلية.
بالنسبة إلى إعداد يقتصر على الشبكة المحلية، استخدم عنوان IP أو اسم المضيف الفعلي لـ ZimaOS والمنافذ المختارة بشكل متسق. وبالنسبة إلى وكيل عكسي، اضبط عناوين HTTPS العامة بشكل متسق وتجنّب خلط localhostوعناوين الشبكة المحلية والنطاقات العامة دون فهم العملية التي ترى كل قيمة.
لا تُبقِ كلمات المرور المصدرية وSECRET_KEY
تضمّن ملف Compose في المنتدى قيمًا نائبة مثل changeme123 لقيم أسرار PostgreSQL وDjango. هذه أمثلة وليست بيانات اعتماد آمنة للإنتاج.
أنشئ بيانات اعتماد فريدة لقاعدة البيانات وسرًا قويًا للتطبيق. وإذا سبق نشر سر حقيقي علنًا، فغيّره.
الحفاظ على قاعدة البيانات والوسائط قبل استكشاف مشكلات إعادة التثبيت وإصلاحها
قد يؤدي إلغاء تثبيت الحزمة وإعادة تثبيتها مرارًا إلى إنشاء حالة مربكة إذا بقيت وحدات التخزين المُسمّاة أو حُذفت بشكل غير متوقع. حدّد ما إذا كان الهدف هو:
- إعادة استخدام قاعدة البيانات والوسائط الحالية؛
- ابدأ بمثيل اختبار نظيف تمامًا.
انسخ احتياطيًا كل ما هو مهم قبل حذف وحدات تخزين Docker.
يتعامل ZimaOS الحالي مع Compose القياسي مباشرةً
يعتمد متجر تطبيقات ZimaOS 2.0 الحالي وتدفقات عمل التطبيقات المخصصة على Docker Compose القياسي بالإضافة إلى بيانات ZimaOS الوصفية. ولا يزال سلوك تشغيل التطبيق—التبعيات ومتغيرات البيئة والمنافذ ووحدات التخزين والصحة والشبكات—يُحدَّد في Compose.
استخدم نموذج Compose الحالي في ZimaOS عند تهيئة AdventureLog.
الأسئلة الشائعة حول AdventureLog على ZimaOS
هل أكّد موضوع المصدر لعام 2025 نجاح حل عملي؟
لا. انتهى الموضوع بعد أن نشر المستخدم سجلات الواجهة الأمامية والواجهة الخلفية وقاعدة البيانات.
ما أقوى الأدلة الواردة في المصدر؟
انتهاء مهلة جلب الواجهة الأمامية وانتظار متكرر من الواجهة الخلفية لـ PostgreSQL.
هل ينبغي إعادة استخدام ملف Compose القديم لعام 2025 دون تغيير؟
لا. لقد تغيّر ملف Compose المُصان لـ AdventureLog، وكذلك الصور وإصدار PostGIS ونموذج الإعداد.
