Flask را برای هر پروژه در محیط مجازی مستقل نصب کنید و برای سرویس عمومی از سرور توسعه داخلی آن استفاده نکنید. این راهنما یک برنامه کوچک و اجرای WSGI روی loopback می‌سازد. اگر میزبان شما CentOS Linux 7 یا 8 است، ابتدا برنامه انتقال به توزیع فعال را انجام دهید؛ تغییر نام بسته‌ها به‌تنهایی محیط قدیمی را پشتیبانی‌شده نمی‌کند.
آماده‌سازی محیط پروژه
روی توزیع فعال خانواده RHEL، Python سازگار را از مخزن همان انتشار نصب کنید و مفسر سیستم را جایگزین نکنید. سپس با کاربر عادی در پوشه تازه اجرا کنید.
mkdir flask-demo
cd flask-demo
python3 -m venv .venv
source .venv/bin/activate
python -m pip install Flask gunicornنسخه Python و وابستگی‌ها را با نیاز برنامه تطبیق دهید. این نصب بسته از اینترنت است؛ نام و منبع بسته را بررسی و برای استقرار واقعی نسخه‌های وابستگی را ثبت کنید.
ساخت برنامه حداقلی
فایل تازه app.py را در همین پوشه با محتوای زیر بسازید. آن را روی فایل موجود پروژه بدون بکاپ جایگزین نکنید.
from flask import Flask
app = Flask(__name__)
@app.get("/")
def index():
return {"status": "ok"}برای آزمون محلی، فرمان زیر را اجرا کنید و در ترمینال دوم پاسخ را بررسی کنید. حالت debug را روی نشانی عمومی فعال نکنید.
flask --app app run --host 127.0.0.1
# in another terminal:
curl http://127.0.0.1:5000/اجرای WSGI با Gunicorn
ابتدا سرور توسعه را با Ctrl+C متوقف کنید. نام app:app یعنی متغیر app از ماژول app.py بارگذاری شود. اگر پروژه شما factory دارد، نقطه ورود متفاوت است.
gunicorn --bind 127.0.0.1:8000 --workers 2 --access-logfile - app:appدو worker فقط نقطه شروع نمونه است، نه فرمول قطعی برای هر VPS. مصرف RAM، نوع درخواست و تعداد اتصال را اندازه بگیرید. Gunicorn را با root اجرا نکنید و در معماری دارای reverse proxy، پورت داخلی را عمومی باز نگذارید.
برای استقرار پایدار چه چیزهایی باقی می‌ماند؟
- برنامه را با حساب سرویس محدود و مدیر فرایند مانند systemd اجرا کنید؛ مسیر مطلق مفسر، WorkingDirectory و متغیرها را صریح تعیین کنید.
- Nginx یا پراکسی مناسب را برای HTTPS و انتقال درخواست به loopback تنظیم کنید؛ اعتماد به header پراکسی باید فقط برای پراکسی شناخته‌شده باشد.
- کلید نشست، رمز دیتابیس و تنظیمات حساس را خارج از مخزن و document root نگه دارید.
- در firewalld فقط مسیر عمومی موردنیاز را مجاز کنید و اگر SELinux ارتباط پراکسی را محدود کرد، سیاست همان سرویس را بررسی کنید؛ خاموش‌کردن سراسری راه‌حل عمومی نیست.
آزمون پیش از تحویل
- پاسخ صفحه، خطای 404 و رفتار ورودی نامعتبر را بررسی کنید.
- قطع و راه‌اندازی فرایند، reboot برنامه‌ریزی‌شده و ثبت لاگ باید کنترل شوند.
- عملیات طولانی را از درخواست هم‌زمان جدا کنید؛ افزایش timeout جای صف و طراحی مناسب را نمی‌گیرد.
- پیش از انتقال داده، بکاپ و روش بازگشت نسخه برنامه و schema را هماهنگ کنید.
مطالعه مرتبط
منابع و مستندات
بازبینی محتوا و منابع: ۲۶ مهر ۱۴۰۵. دستورهای نمونه برای محیط مشخص‌شده‌اند؛ پیش از استفاده روی سرویس عملیاتی، سازگاری محیط و نسخه پشتیبان را بررسی کنید.
