وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

برنامه پایتون در Passenger بالا نمی‌آید؛ فایل WSGI و مسیر شروع را درست کنیم

راهنمای تشخیص خطای Passenger در هاست پایتون، بررسی Application root، محیط مجازی و فایل passenger_wsgi.py برای جنگو و فلسک.

انتشار:
توسط تیم فنی نت‌آرام
۶ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله برنامه پایتون در Passenger بالا نمی‌آید؛ فایل WSGI و مسیر شروع را درست کنیم در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
پروژه پایتون روی رایانه کار می‌کند، اما پس از انتقال به هاست صفحه خطا می‌دهد و در گزارش نام Passenger، WSGI یا فایل شروع برنامه دیده می‌شود. وب‌سرور برای رساندن درخواست به برنامه نیاز دارد نقطه ورود درست را پیدا کند. اگر پوشه برنامه اشتباه باشد، پکیج در محیط دیگری نصب شده باشد یا شیء برنامه با نام مورد انتظار معرفی نشود، شروع برنامه شکست می‌خورد.
در این راهنما ابتدا خطای واقعی را پیدا می‌کنیم، سپس مسیر و محیط برنامه را با فایل WSGI تطبیق می‌دهیم. نمونه‌ها برای هاست لینوکسی دارای پنل برنامه پایتون و Passenger هستند. اگر سرویس شما از روش دیگری استفاده می‌کند، نام گزینه‌ها و محل فایل ورود می‌تواند متفاوت باشد. این راهنما برنامه ASGI را خودبه‌خود به یک برنامه WSGI تبدیل نمی‌کند.

۱. پیام خطا و برنامه درست را پیدا کنید

در cPanel، بخش Setup Python App یا ابزار معادل را باز کنید. دامنه برنامه، Application root، نسخه پایتون، نام فایل شروع و در صورت نمایش، نام Application entry point را یادداشت کنید. اگر چند برنامه دارید، هر بار بررسی کنید همان برنامه مربوط به دامنه مشکل‌دار را انتخاب کرده باشید.
صفحه ۵۰۰ یا پیام عمومی Passenger به‌تنهایی علت را نشان نمی‌دهد. گزارش مربوط به همان برنامه را در پنل یا مسیری که سرویس معرفی کرده پیدا کنید و خطای ثبت‌شده نزدیک زمان آزمایش را بخوانید. برای نمونه، ModuleNotFoundError به پیدا نشدن ماژول اشاره می‌کند، خطای نبود فایل به مسیر و مجوز، و خطای داخل تنظیمات Django به خود پروژه مربوط است. از فرستادن رمز، کلید یا کوکی همراه گزارش خودداری کنید.
برای مشاهده انتهای یک فایل گزارش مشخص، اگر مسیر واقعی آن را می‌دانید:
کد / دستورtail -n 100 ~/myproject/logs/app.log
این مسیر فقط نمونه است. نبودن فایل در این محل ثابت نمی‌کند گزارشی وجود ندارد؛ مسیر صحیح را از تنظیمات برنامه بگیرید. Debug را برای نمایش خطا به عموم روشن نکنید.

۲. پوشه و محیط مجازی درست را فعال کنید

در Terminal یا SSH حساب، فرمان فعال‌سازی اختصاصی محیط را از پنل برنامه کپی کنید. سپس به Application root واقعی بروید. مثال زیر فرضی است:
کد / دستورcd ~/myproject pwd ls -la python --version python -c 'import sys; print(sys.executable)'
مسیر چاپ‌شده باید با برنامه موردنظر شما بخواند. در پروژه Django به دنبال manage.py و پوشه تنظیمات باشید. اگر فایل‌ها در یک زیرپوشه اضافی، مثلاً myproject/myproject/، آپلود شده‌اند، مسیر پنل و فایل شروع ممکن است اشتباه باشند. تغییر مسیر را ابتدا در نسخه آزمایشی و با حفظ نسخه قبلی انجام دهید.
اگر python متعلق به محیط دیگری است، فرمان محیط را دوباره از پنل بگیرید. نصب بسته با pip سیستم، بدون ورود به محیط برنامه، الزاماً چیزی به محیط Passenger اضافه نمی‌کند. راهنمای ماژول پیدانشده در پایتون این مسئله را با مثال توضیح می‌دهد.

۳. WSGI و نام application را بشناسید

WSGI روشی است که وب‌سرور و برنامه پایتون برای ردوبدل‌کردن درخواست و پاسخ از آن استفاده می‌کنند. در یک تنظیم رایج Passenger، فایل شروعی به نام passenger_wsgi.py یک شیء قابل فراخوانی به نام application را در اختیار سرور می‌گذارد. پنل شما ممکن است نام دیگری برای فایل یا entry point نشان دهد؛ همیشه مقدار واقعی همان برنامه را ملاک بگذارید.
برای روشن شدن مسیر، فرض کنید ساختار نمونه Django چنین است:
کد / دستورmyproject/ manage.py passenger_wsgi.py project/ __init__.py settings.py wsgi.py
نام project در مثال، نام پوشه پایتونی حاوی settings.py و wsgi.py است و باید با پروژه شما عوض شود. نمونه ساده فایل passenger_wsgi.py برای همین ساختار:
کد / دستورimport os import sys project_root = os.path.dirname(os.path.abspath(__file__)) if project_root not in sys.path: sys.path.insert(0, project_root) from project.wsgi import application
این فایل از WSGI خود پروژه استفاده می‌کند؛ فایل project/wsgi.py باید تنظیمات درست Django را بارگذاری کند. آن را جایگزین فایل موجود نکنید مگر ساختار واقعی و روش سرویس خودتان را شناخته و از نسخه قبلی پشتیبان گرفته باشید. ساختار پروژه، مسیر واقعی و نحوه انتخاب تنظیمات می‌تواند متفاوت باشد.
در یک پروژه Flask، شیء برنامه ممکن است در ماژول دیگری و با نام دیگری ساخته شود. برای پروژه ساده‌ای که فایل app.py یک شیء به نام app دارد، یک ورودی نمونه می‌تواند چنین باشد:
کد / دستورfrom app import app as application
اگر پروژه Flask از application factory استفاده می‌کند، این نمونه لزوماً مناسب نیست و باید طبق ساختار همان پروژه شیء ساخته شود. در فایل WSGI، توسعه‌دهنده نباید برای سایت عمومی سرور آزمایشی app.run() را به‌عنوان روش استقرار فرض کند.

۴. import را در نسخه آزمایشی بررسی کنید

در محیط مجازی و پوشه پروژه آزمایشی، پس از اطمینان از تنظیمات و وابستگی‌ها می‌توانید بررسی کنید فایل ورود بارگذاری می‌شود و شیء قابل فراخوانی دارد:
کد / دستورpython -c 'from passenger_wsgi import application; print("callable:", callable(application))'
اگر نام فایل یا entry point در پنل شما متفاوت است، فرمان باید مطابق همان نام اصلاح شود. callable: True یک بررسی اولیه است؛ ثابت نمی‌کند مسیرهای وب، دیتابیس یا همه تنظیمات درست‌اند. وارد کردن یک ماژول ممکن است کد آغازین برنامه را اجرا کند، به همین دلیل ابتدا آن را روی نسخه آزمایشی و با تنظیمات امن انجام دهید.
اگر ModuleNotFoundError ظاهر شد، نام ماژول، حروف بزرگ و کوچک و محیط پایتون را بررسی کنید. اگر خطا می‌گوید تنظیمات Django یافت نمی‌شود، نام پکیج و مقدار تنظیم‌شده در فایل WSGI پروژه را با ساختار واقعی مقایسه کنید. هر فایل خطایی را با sys.path گسترده یا نصب تصادفی بسته‌ها دور نزنید.
برای یک پروژه Django، بررسی خود جنگو در همان محیط آزمایشی نیز می‌تواند سرنخ بدهد:
کد / دستورpython manage.py check python -m pip check
فرمان اول بررسی‌های شناخته‌شده پروژه و دومی سازگاری وابستگی‌های نصب‌شده را گزارش می‌کند؛ هیچ‌کدام تست کامل همه درخواست‌ها نیستند. اگر تنظیمات پروژه به متغیر محیطی نیاز دارند، حضور آن‌ها را بدون چاپ مقدار محرمانه تأیید کنید.

۵. پنل را با فایل واقعی هماهنگ و نتیجه را آزمون کنید

پس از بررسی نسخه آزمایشی، مسیر Application root، فایل شروع و entry point در پنل را با فایل‌های واقعی نسخه تأییدشده هماهنگ کنید. نام و قابلیت ویرایش این گزینه‌ها در سرویس‌های مختلف فرق دارد. تغییرات را ذخیره و با دکمه Restart همان برنامه را دوباره اجرا کنید.
صفحه یا مسیر سلامت واقعی را باز کنید و گزارش جدید را با زمان همین درخواست مقایسه کنید. اگر خطا عوض شده، خطای تازه را جدا بررسی کنید: مثلاً رفع import، تنظیمات دیتابیس یا ALLOWED_HOSTS را به‌تنهایی درست نمی‌کند. برای خطای میزبان، راهنمای رفع DisallowedHost مسیر مناسب را توضیح می‌دهد.
اگر برنامه FastAPI یا برنامه دیگری با ASGI و اتصال‌های طولانی است، ابتدا از سازگاری روش اجرای سرویس با نیاز آن مطمئن شوید؛ جایگزین‌کردن تصادفی یک فایل WSGI، پشتیبانی ASGI را تضمین نمی‌کند. برای آشنایی با سرویس، هاست پایتون نت‌آرام و برای نمونه سازوکار Passenger، مستندات رسمی cPanel درباره برنامه WSGI را ببینید.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام