إذا كان Frigate وOllama يعملان في حاويتَي Docker منفصلتين على مضيف ZimaOS نفسه، فإن localhost:11434 داخل Frigate يشير إلى حاوية Frigate، وليس إلى Ollama. ضع الخدمتين على شبكة Docker مشتركة واستخدم اسم خدمة Ollama، أو انشر Ollama على عنوان مضيف يمكن لـ Frigate الوصول إليه.
لم يصل موضوع النقاش الأصلي إلى إعداد نهائي تم التحقق منه، لكنه حدّد مسار التشخيص الصحيح: تحقّق أولًا من إمكانية الوصول إلى الشبكة من حاوية Frigate، ثم استكمل استكشاف أخطاء إعداد genai: في Frigate. تتطلب وثائق Frigate الحالية أيضًا نموذجًا قادرًا على الرؤية لإنشاء أوصاف الصور والأحداث.
لماذا يفشل localhost بين الحاويات؟
لكل حاوية Docker عادية مساحة أسماء شبكة خاصة بها. داخل Frigate:
http://localhost:11434
يعني «المنفذ 11434 داخل حاوية Frigate». ولا يعني مضيف ZimaOS، كما أنه لا يُحوَّل تلقائيًا إلى حاوية Ollama.
الإعداد الأفضل: شبكة Docker مشتركة
ضع Frigate وOllama على شبكة Docker مخصّصة للمستخدم نفسه، واستخدم اسم خدمة أو حاوية ثابتًا مثل:
genai:
provider: ollama
base_url: http://ollama:11434
model: qwen3-vl:4b
يوثّق دليل Frigate للذكاء الاصطناعي التوليدي موفر Ollama، ويتطلب نموذج رؤية مناسبًا لأوصاف الذكاء الاصطناعي التوليدي.
الخطوة 1: التحقق من الحاويات والشبكات من مضيف ZimaOS
شغّل هذا الأمر من الوحدة الطرفية لمضيف ZimaOS، وليس من داخل Frigate:
docker ps --format 'table {.Names} {.Image} {.Networks}' | grep -Ei 'NAMES|frigate|ollama'
شغّل المستخدم في المصدر أمر Docker بالخطأ داخل حاوية Frigate، فتلقى الرسالة docker: not found. وهذا متوقع، إذ لا تحتوي الحاويات عادةً على واجهة سطر أوامر Docker الخاصة بالمضيف ولا تتحكم فيها.
الخطوة 2: اختبار Ollama من داخل Frigate
بعد معرفة أسماء الحاويات والشبكات، اختبر مسار HTTP الفعلي. من المضيف:
docker exec -it frigate sh
wget -qO- http://ollama:11434/api/tags
إذا أدرجت الاستجابة نماذج Ollama، فالشبكة تعمل. وإذا تعذّر حل الاسم ollama، فمن المحتمل ألا تكون الحاويتان على الشبكة نفسها. وإذا أمكن حل الاسم ولكن رُفض الاتصال، فتحقّق من استماع Ollama وربطه وحالة المنفذ.
البديل: استخدام عنوان IP لمضيف ZimaOS
إذا نشرت Ollama المنفذ 11434 على المضيف، فيمكن لـ Frigate استخدام عنوان مضيف يمكن الوصول إليه عبر الشبكة المحلية، مثل:
base_url: http://192.168.1.20:11434
هذا الخيار بسيط، لكنه يمرّر حركة المرور عبر المضيف بدلًا من استخدام اكتشاف خدمات Docker. تأكد من أن Ollama يستمع فعلًا على واجهة يمكن الوصول إليها من حاوية Frigate.
استخدم نموذج Ollama قادرًا على الرؤية
لا يكفي اتصال الشبكة وحده. ترسل ميزة الذكاء الاصطناعي التوليدي الحالية في Frigate سياقًا بصريًا، لذلك يجب أن يدعم النموذج المُعدّ الرؤية. قد يستجيب نموذج Ollama النصي فقط لاختبارات واجهة برمجة التطبيقات، لكنه يظل غير مناسب لأوصاف أحداث الكاميرا.
لا تستخدم host.docker.internal في كل مكان
يُعد host.docker.internal مريحًا على Docker Desktop، لكنه ليس مضمونًا أن يعمل بالطريقة نفسها على كل مضيف Docker يعمل بنظام Linux. عادةً ما تكون الشبكة المخصّصة للمستخدم مع اسم الخدمة أكثر قابلية للنقل على ZimaOS.
تحقّق من إعداد Frigate بعد نجاح الشبكة
بعد نجاح /api/tags فقط، ركّز على المسافات البادئة في YAML، واسم الموفر، واسم النموذج، وإعدادات ميزة الذكاء الاصطناعي التوليدي. أعد تشغيل Frigate وافحص السجلات بحثًا عن تهيئة الموفر.
يوفّر دليل شبكات Docker النموذج الأوسع لشبكات الحاويات.
الأسئلة الشائعة
لماذا لا يعمل localhost:11434 من Frigate؟
لأن localhost داخل Frigate يشير إلى حاوية Frigate نفسها، وليس إلى حاوية Ollama.
ما عنوان Ollama الأفضل؟
على شبكة Docker مشتركة، استخدم اسم خدمة أو حاوية Ollama، مثل http://ollama:11434.
لماذا تظهر رسالة docker is not found عند استخدام docker exec؟
من المحتمل أنك شغّلت واجهة سطر أوامر Docker داخل حاوية. شغّل أوامر إدارة Docker من الوحدة الطرفية لمضيف ZimaOS.
هل يمكن استخدام أي نموذج Ollama مع الذكاء الاصطناعي التوليدي في Frigate؟
لا. توضح وثائق Frigate الحالية أن سير عمل الذكاء الاصطناعي التوليدي يحتاج إلى نموذج قادر على الرؤية.
