هاست ربات روبیکا؛ راهنمای اجرای دائمی، امن و پایدار روی سرور

ربات روبیکا تا زمانی که روی لپ‌تاپ شخصی اجرا می‌شود، ممکن است کاملاً سالم به نظر برسد؛ اما کافی است اینترنت قطع شود، سیستم خاموش بماند یا برنامه با یک خطای پیش‌بینی‌نشده متوقف شود تا پاسخ‌گویی ربات هم از کار بیفتد. برای تبدیل یک پروژه آزمایشی به سرویس قابل اعتماد، باید آن را روی زیرساختی قرار دهید که شبانه‌روزی روشن بماند، اتصال پایدار داشته باشد و در صورت بروز خطا بتواند برنامه را دوباره اجرا کند.

انتخاب هاست ربات روبیکا فقط مقایسه قیمت چند سرویس نیست. نوع اجرای ربات، تعداد کاربران، روش دریافت پیام، نیاز به دیتابیس، سطح دسترسی و توان شما برای مدیریت سرور همگی در تصمیم نقش دارند. در این راهنما از انتخاب میان هاست پایتون و سرور مجازی تا اجرای دائمی با systemd، تنظیم وب‌هوک، امنیت و مانیتورینگ را قدم‌به‌قدم بررسی می‌کنیم.

اگر هنوز سورس ربات را آماده نکرده‌اید، ابتدا مقاله آموزش ساخت سورس ربات روبیکا را مطالعه کنید. این مقاله روی مرحله بعد تمرکز دارد: چگونه همان سورس را به شکلی پایدار و قابل نگهداری روی اینترنت اجرا کنیم.

یک هاست مناسب ربات روبیکا چه ویژگی‌هایی دارد؟

ربات معمولاً برنامه‌ای سبک است، اما «سبک‌بودن» به معنی بی‌اهمیت‌بودن زیرساخت نیست. یک ربات ساده شاید تنها چند ده مگابایت حافظه مصرف کند، ولی کیفیت شبکه، محدودیت اجرای پردازش دائمی و امکان بازیابی پس از خطا مهم‌تر از مقدار RAM هستند.

پیش از خرید سرویس، این موارد را بررسی کنید:

• امکان اجرای دائمی پردازش Python یا زبان مورد استفاده
• دسترسی پایدار به اینترنت و مقصدهای لازم برای ارتباط ربات
• قابلیت تنظیم متغیرهای محیطی و نگهداری امن توکن
• امکان مشاهده لاگ و بررسی خطاها
• راه‌اندازی خودکار برنامه پس از ری‌استارت سرور
• فضای پایدار برای دیتابیس و فایل‌های موردنیاز
• پشتیبان‌گیری، مانیتورینگ و امکان ارتقای منابع

وجود کنترل‌پنل زیبا به‌تنهایی نشانه مناسب‌بودن هاست نیست. بعضی هاست‌ها اجازه اجرای اسکریپت پایتون را می‌دهند، اما پردازش را پس از چند دقیقه می‌بندند یا برای برنامه دائمی محدودیت دارند. باید صریحاً مطمئن شوید سرویس برای اجرای ربات طولانی‌مدت طراحی شده است.

هاست پایتون یا سرور مجازی؟

هاست پایتون؛ ساده‌تر برای پروژه کوچک

در هاست پایتون معمولاً بخشی از تنظیمات سرور از قبل انجام شده است. فایل‌ها را بارگذاری می‌کنید، محیط مجازی می‌سازید، کتابخانه‌ها را نصب می‌کنید و فرمان اجرای برنامه را در پنل قرار می‌دهید. برای یک ربات شخصی، نمونه اولیه یا پروژه‌ای با کاربران محدود، این مسیر هزینه و پیچیدگی کمتری دارد.

در مقابل، دسترسی شما محدود است. شاید نتوانید سرویس سیستمی بسازید، نسخه دلخواه Python را نصب کنید یا تنظیمات شبکه را تغییر دهید. محدودیت CPU و تعداد پردازش نیز معمولاً سخت‌گیرانه‌تر است. پیش از خرید بپرسید آیا اجرای worker دائمی مجاز است و برنامه پس از خطا یا ری‌استارت میزبان چگونه دوباره اجرا می‌شود.

سرور مجازی؛ کنترل کامل و مسئولیت بیشتر

VPS یک سیستم‌عامل مستقل در اختیار شما می‌گذارد. می‌توانید نسخه Python، وب‌سرور، دیتابیس، فایروال و سرویس‌های مانیتورینگ را مطابق نیاز نصب کنید. اجرای چند ربات، ساخت پنل مدیریت یا استفاده از PostgreSQL روی سرور مجازی بسیار منعطف‌تر است.

این آزادی با مسئولیت همراه است. به‌روزرسانی امنیتی، تنظیم SSH، پشتیبان‌گیری و بررسی مصرف منابع بر عهده شماست. اگر فرمان‌های لینوکس و مدیریت سرویس برایتان ناآشناست، هاست مدیریت‌شده یا کمک فنی می‌تواند ریسک را کاهش دهد.

چه زمانی هرکدام را انتخاب کنیم؟

برای یک ربات کم‌ترافیک بدون پنل پیچیده، هاست پایتونِ معتبر کافی است. اگر چند worker دارید، وب‌هوک اختصاصی می‌خواهید، دیتابیس مستقل دارید یا قرار است سرویس توسعه پیدا کند، VPS انتخاب آینده‌دارتری است. در پروژه تجاری، هزینه کمی بالاتر سرور در برابر امکان کنترل، لاگ‌گیری و بازیابی سریع معمولاً منطقی است.

حداقل منابع لازم چقدر است؟

برای ربات ساده پایتونی با تعداد درخواست محدود، یک هسته پردازنده، یک گیگابایت RAM و فضای ذخیره‌سازی کم می‌تواند کافی باشد. با اضافه‌شدن دیتابیس، پنل وب، پردازش فایل یا چند ربات، بهتر است حداقل دو گیگابایت RAM در نظر بگیرید. پردازش تصویر، تبدیل ویدئو یا کارهای هوش مصنوعی به منابع بسیار بیشتری نیاز دارند و نباید با معیار یک ربات متنی سنجیده شوند.

به جای خرید منابع زیاد از ابتدا، مصرف واقعی را اندازه بگیرید. میانگین و اوج CPU، حافظه، فضای دیسک و تعداد درخواست‌ها را ثبت کنید. اگر مصرف دائماً به سقف نزدیک است یا سیستم به‌دلیل کمبود حافظه پردازش را می‌بندد، ارتقا لازم است. منابع آزاد برای جهش‌های کوتاه ترافیک نیز در نظر بگیرید.

آماده‌سازی سرور Ubuntu برای ربات

پس از تهیه VPS، با کاربر دارای دسترسی مدیریتی وارد شوید، بسته‌ها را به‌روزرسانی کنید و ابزارهای اصلی را نصب کنید. بهتر است برنامه با کاربر عادی اجرا شود، نه با root.

sudo apt update
sudo apt upgrade -y
sudo apt install -y python3 python3-venv python3-pip git

sudo adduser --disabled-password --gecos "" rubika
sudo mkdir -p /opt/rubika-bot
sudo chown -R rubika:rubika /opt/rubika-bot

سپس سورس را داخل مسیر پروژه قرار دهید، محیط مجازی بسازید و وابستگی‌ها را نصب کنید:

sudo -u rubika python3 -m venv /opt/rubika-bot/venv
sudo -u rubika /opt/rubika-bot/venv/bin/pip install --upgrade pip
sudo -u rubika /opt/rubika-bot/venv/bin/pip install -r /opt/rubika-bot/requirements.txt

فایل requirements.txt باید نسخه کتابخانه‌ها را مشخص کند تا نصب بعدی نتیجه متفاوتی ایجاد نکند. پیش از ساخت سرویس دائمی، برنامه را یک بار با همان کاربر عادی اجرا کنید و مطمئن شوید اتصال و دریافت پیام درست انجام می‌شود.

توکن را داخل سورس قرار ندهید

توکن ربات کلید کنترل آن است. قراردادن توکن در فایل اصلی، مخزن Git یا پیام پشتیبانی می‌تواند به افشای دسترسی منجر شود. آن را در فایل محیطی با مجوز محدود یا سامانه مدیریت رازها نگه دارید.

sudo install -o root -g rubika -m 640 /dev/null /etc/rubika-bot.env
sudo nano /etc/rubika-bot.env

محتوای فایل محیطی می‌تواند به این شکل باشد:

BOT_TOKEN=your-private-token
DATABASE_URL=sqlite:////opt/rubika-bot/data/bot.db
LOG_LEVEL=INFO

این فایل را وارد Git نکنید. اگر احتمال می‌دهید توکن جایی منتشر شده، فقط حذف پیام کافی نیست؛ توکن را از مسیر رسمی باطل و مقدار جدید دریافت کنید.

اجرای دائمی با systemd

اجرای برنامه در ترمینال یا با دستور ساده پس‌زمینه، برای سرویس واقعی قابل اعتماد نیست. با بسته‌شدن نشست SSH یا ری‌استارت سرور ممکن است ربات متوقف شود. systemd برنامه را هنگام روشن‌شدن سیستم اجرا می‌کند و در صورت خروج ناگهانی دوباره بالا می‌آورد.

[Unit]
Description=Rubika Bot
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=rubika
Group=rubika
WorkingDirectory=/opt/rubika-bot
EnvironmentFile=/etc/rubika-bot.env
ExecStart=/opt/rubika-bot/venv/bin/python /opt/rubika-bot/main.py
Restart=on-failure
RestartSec=5
TimeoutStopSec=20

[Install]
WantedBy=multi-user.target

فایل را با نام /etc/systemd/system/rubika-bot.service ذخیره و سرویس را فعال کنید:

sudo systemctl daemon-reload
sudo systemctl enable --now rubika-bot
sudo systemctl status rubika-bot

گزینه Restart=on-failure برنامه را بعد از خطا دوباره اجرا می‌کند، اما درمان خطا نیست. اگر سرویس دائماً متوقف و شروع شود، باید علت را در لاگ پیدا کنید؛ ری‌استارت بی‌پایان ممکن است مشکل شبکه یا باگ برنامه را پنهان کند.

بررسی لاگ‌ها و پیدا کردن علت قطعی

لاگ خوب باید زمان رخداد، سطح خطا و بخش درگیر را نشان دهد، اما نباید توکن، رمز دیتابیس یا متن حساس کاربران را چاپ کند. برای مشاهده خروجی سرویس از journalctl استفاده کنید:

sudo journalctl -u rubika-bot -n 100 --no-pager
sudo journalctl -u rubika-bot -f

فرمان اول صد خط آخر را نمایش می‌دهد و فرمان دوم رخدادها را زنده دنبال می‌کند. هنگام قطعی، فقط آخرین خط را نگاه نکنید؛ چند خط قبل از traceback معمولاً زمینه واقعی خطا را نشان می‌دهد.

خطاهای رایج بعد از انتقال به سرور

• متغیر محیطی توکن خوانده نمی‌شود یا نام آن اشتباه است.
• کتابخانه‌ای در محیط مجازی نصب نشده است.
• مسیر فایل یا دیتابیس به مسیر نسبی وابسته مانده است.
• کاربر سرویس اجازه نوشتن در پوشه داده را ندارد.
• فایروال یا محدودیت شبکه ارتباط خروجی را مسدود کرده است.
• دو نسخه ربات هم‌زمان یک صف یا دیتابیس را پردازش می‌کنند.

برای سورسی که پس از انتقال دچار خطا شده، خدمت رفع باگ ربات می‌تواند در بررسی لاگ، وابستگی‌ها و فرایند اجرا کمک کند.

Polling یا Webhook روی سرور؟

در روش polling برنامه به‌طور دوره‌ای برای دریافت رویداد جدید درخواست می‌فرستد. راه‌اندازی آن ساده‌تر است و برای ربات کم‌ترافیک یا محیط آزمایشی مناسب است. در روش webhook، رویدادها به نشانی HTTPS شما ارسال می‌شوند؛ این روش برای معماری وب و چند سرویس منظم‌تر است، اما به دامنه، گواهی SSL و وب‌سرور نیاز دارد.

اگر API و کتابخانه مورد استفاده شما webhook را پشتیبانی می‌کند، Nginx می‌تواند درخواست HTTPS را به برنامه داخلی منتقل کند. برنامه را مستقیم با پورت توسعه روی اینترنت منتشر نکنید. وب‌سرور، TLS، محدودیت اندازه درخواست و زمان انتظار را مدیریت می‌کند.

server {
    listen 443 ssl;
    server_name bot.example.com;

    ssl_certificate /etc/letsencrypt/live/bot.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/bot.example.com/privkey.pem;

    location /webhook/ {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_connect_timeout 10s;
        proxy_read_timeout 30s;
    }
}

نشانی webhook باید غیرقابل حدس یا با امضای درخواست محافظت شود. هر درخواست ورودی را معتبر فرض نکنید و قبل از پردازش، ساختار و منبع آن را بررسی کنید.

دیتابیس روی همان سرور یا سرویس جدا؟

برای ربات کوچک، SQLite روی همان VPS ساده و کم‌هزینه است. فایل دیتابیس باید در مسیری پایدار باشد و نسخه پشتیبان منظم داشته باشد. برای چند worker، پنل وب یا تراکنش‌های هم‌زمان، PostgreSQL انتخاب مناسب‌تری است. مقاله مقایسه SQLite و PostgreSQL برای ربات پیام‌رسان معیارهای این تصمیم را با نمونه‌کد توضیح می‌دهد.

در پروژه مهم بهتر است دیتابیس و ربات دست‌کم از نظر دسترسی تفکیک شوند. حتی اگر هر دو روی یک VPS هستند، کاربر دیتابیس فقط مجوزهای لازم را داشته باشد و پورت آن برای عموم باز نباشد. انتقال دیتابیس به سرویس مدیریت‌شده زمانی مفید است که پشتیبان‌گیری و دسترس‌پذیری اهمیت بیشتری از کمترین هزینه دارند.

امن‌سازی ابتدایی VPS

سروری که روی اینترنت قرار دارد دائماً توسط ربات‌های اسکن‌کننده بررسی می‌شود. چند اقدام پایه، بخش بزرگی از خطر را کاهش می‌دهد:

• ورود SSH با کلید را فعال و ورود مستقیم root را غیرفعال کنید.
• فایروال را طوری تنظیم کنید که فقط پورت‌های موردنیاز باز باشند.
• سیستم‌عامل و کتابخانه‌ها را منظم به‌روزرسانی کنید.
• برای هر سرویس کاربر جداگانه و بدون دسترسی اضافی بسازید.
• فایل توکن و تنظیمات را با مجوز محدود نگه دارید.
• پشتیبان‌ها را رمزنگاری و خارج از همان سرور ذخیره کنید.
• برای ورودهای ناموفق و مصرف غیرعادی هشدار تعریف کنید.

اگر سرور علاوه بر ربات، سایت یا پنل مدیریت را هم میزبانی می‌کند، سخت‌گیری بیشتری لازم است. خدمت افزایش امنیت سرور و سایت برای پروژه‌هایی که نیاز به بررسی حرفه‌ای تنظیمات دارند در دسترس است.

مانیتورینگ؛ چگونه قبل از کاربر از قطعی باخبر شویم؟

بررسی دستی ربات کافی نیست. یک health check ساده بسازید که سلامت پردازش، اتصال دیتابیس و زمان آخرین رویداد را گزارش دهد. سرویس مانیتورینگ می‌تواند هر چند دقیقه این نشانی را بررسی کند و در صورت خطا هشدار بفرستد.

موارد زیر را زیر نظر بگیرید:

• فعال‌بودن پردازش ربات
• نرخ خطا و تعداد ری‌استارت‌ها
• مصرف CPU، RAM و فضای دیسک
• زمان پاسخ API و دیتابیس
• زمان آخرین پیام یا رویداد موفق
• تاریخ انقضای دامنه و گواهی SSL

فقط آنلاین‌بودن پورت نشانه سلامت کامل نیست. ممکن است برنامه روشن باشد ولی نتواند پیام دریافت کند یا دیتابیس قفل شده باشد. health check باید یک مسیر واقعی و کم‌خطر از منطق سرویس را آزمایش کند.

روش امن به‌روزرسانی سورس

ویرایش مستقیم فایل‌های سرور بدون نسخه پشتیبان، ریسک توقف طولانی را بالا می‌برد. نسخه جدید را ابتدا در محیط آزمایشی اجرا کنید، تغییرات دیتابیس را مشخص کنید و سپس در زمان کم‌ترافیک منتشر کنید. یک نسخه سالم قبلی و روش بازگشت سریع داشته باشید.

cd /opt/rubika-bot
sudo systemctl stop rubika-bot
sudo -u rubika git pull --ff-only
sudo -u rubika ./venv/bin/pip install -r requirements.txt
sudo systemctl start rubika-bot
sudo systemctl status rubika-bot

این نمونه برای همه پروژه‌ها کافی نیست، اما ترتیب درست را نشان می‌دهد: توقف کنترل‌شده، دریافت نسخه معتبر، نصب وابستگی و بررسی وضعیت. اگر migration دیتابیس دارید، نسخه پشتیبان و روش بازگشت را پیش از اجرا آماده کنید.

چه زمانی پشتیبانی مدیریت‌شده ارزش دارد؟

اگر ربات بخشی از فروش، پشتیبانی یا ارتباط روزانه کسب‌وکار است، نگهداری آن نباید به حضور یک نفر وابسته باشد. مانیتورینگ، به‌روزرسانی، نسخه پشتیبان و پاسخ به خطا کارهای پیوسته‌اند. در چنین شرایطی، پشتیبانی ماهانه ربات می‌تواند زمان توقف و ریسک فراموش‌شدن نگهداری را کاهش دهد.

برای پروژه کوچک شخصی شاید مدیریت مستقیم کافی باشد. معیار تصمیم این است که هر ساعت قطعی چه اثری دارد و آیا فردی برای رسیدگی سریع در دسترس است یا نه.

پرسش‌های متداول

آیا هاست اشتراکی معمولی برای ربات روبیکا مناسب است؟

فقط اگر میزبان صریحاً اجرای پردازش دائمی را مجاز بداند. بسیاری از هاست‌های معمولی پردازش طولانی را متوقف می‌کنند. هاست پایتون یا VPS معمولاً انتخاب مطمئن‌تری است.

برای یک ربات ساده چقدر RAM لازم است؟

اغلب یک گیگابایت برای ربات متنی سبک کافی است، اما دیتابیس، پنل وب، تعداد workerها و پردازش فایل می‌تواند نیاز را افزایش دهد. مصرف واقعی را اندازه‌گیری کنید.

چرا ربات بعد از بستن SSH خاموش می‌شود؟

زیرا برنامه به نشست ترمینال وابسته اجرا شده است. آن را با systemd یا مدیر پردازش مناسب به‌صورت سرویس اجرا کنید تا با خروج از SSH متوقف نشود.

آیا می‌توان چند ربات را روی یک VPS اجرا کرد؟

بله. برای هر ربات کاربر، پوشه، محیط مجازی، فایل تنظیمات و سرویس جدا بسازید. مجموع مصرف منابع و اتصال‌های دیتابیس را نیز کنترل کنید.

Polling بهتر است یا Webhook؟

برای شروع و ترافیک کم، polling ساده‌تر است. برای معماری وب، مقیاس بالاتر یا پردازش چندسرویسی، webhook مناسب‌تر است؛ البته به HTTPS و پیکربندی دقیق نیاز دارد.

چگونه بفهمیم ربات متوقف شده است؟

علاوه بر وضعیت systemd، health check و مانیتور خارجی تنظیم کنید. هشدار باید پیش از گزارش کاربران به مدیر برسد.

جمع‌بندی

هاست مناسب ربات روبیکا سرویسی است که اجرای دائمی، لاگ قابل دسترس، نگهداری امن توکن، بازیابی پس از خطا و امکان پشتیبان‌گیری را فراهم کند. برای پروژه کوچک، هاست پایتون می‌تواند مسیر ساده‌ای باشد؛ برای ربات تجاری، چندپردازشی یا دارای پنل و دیتابیس مستقل، VPS انعطاف و کنترل بیشتری می‌دهد.

پس از انتخاب زیرساخت، برنامه را با کاربر محدود اجرا کنید، از systemd برای راه‌اندازی خودکار بهره ببرید، لاگ‌ها را بدون اطلاعات حساس ثبت کنید و مانیتورینگ واقعی داشته باشید. پایداری نتیجه خرید یک سرور قدرتمند نیست؛ حاصل مجموعه‌ای از تنظیمات درست، آزمون بازیابی و نگهداری منظم است.