المسار الأساسي في تكوين المقرب

Question

أحاول نشر بعض التعليمات البرمجية الهرمية على dotcloud.لسوء الحظ، لا يتم تعيين بعض المسارات بنفس الطريقة كما في نشر المُلصق المحلي.عندما أقوم بتشغيل تكوين التطوير مع الخادم المحلي من خلال paster serve ..., ، يمكنني الوصول إلى الملفات الثابتة التي تم تكوينها في:

config.add_static_view('static', 'appname:static')

ولكن على خوادم dotcloud، عندما يتم تشغيل البرامج النصية عبر ما يلي wsgi.py:

import os, sys
from paste.deploy import loadapp
current_dir = os.path.dirname(__file__)
application = loadapp('config:production.ini', relative_to=current_dir)

يتم البحث عن محتوى ثابت في دليل خاطئ.بدلاً من /home/dotcloud/current/static/pylons.css, ، ينبغي أن ننظر في /home/dotcloud/current/appname/static/pylons.css

هل هناك جزء من تكوين wsgi يمكنه تحديد الدليل الأساسي؟ماذا ينقصني؟يتم تشغيل التطبيق عبر nginx / uwsgi.

حاولت التحميل config:../production.ini, relative_to=current_dir + '/appname' لكن هذا لم يغير شيئا.

Answer 1

على DotCloud، تبدأ عناوين URL بـ /static يتم التعامل معها مباشرة بواسطة nginx، وليس بواسطة uwsgi.وهذا يعني أن الكود الخاص بك لن يرى هذه الطلبات أبدًا:سيتم تقديمهم مباشرة من static/ الدليل الفرعي للتطبيق الخاص بك.

أحد الحلول الممكنة هو إعداد رابط رمزي من static ل appname/static.

إذا كنت لا ترغب في ازدحام مستودعك بمثل هذا الرابط الرمزي، فيمكنك استخدام ملف postinstall البرنامج النصي بدلاً من ذلك:

#!/bin/sh
# This creates the symlink required by DotCloud to serve static content from nginx
ln -s ~/current/appname/static ~/current/static

الرابط الرمزي أنيق، ولكن postinstall تمنحك البرامج النصية الفرصة لإسقاط تعليق في الملف لشرح الغرض منه :-)

قد توفر الإصدارات المستقبلية من DotCloud تبديل "التكوين المجرد"، حيث لن يتضمن تكوين nginx أي معالجة خاصة للمسار، فقط في حالة عدم رغبتك في ذلك.

وفي الوقت نفسه، إذا كنت تريد رؤية التكوين الافتراضي لـ nginx لخدمة DotCloud، فيمكنك فقط dotcloud ssh لخدمتك، والتفتيش /etc/nginx/sites-enabled/default.