Розгортання Production

Конфігурація

Тепер, коли всі компоненти встановлені, приступимо до їх налаштування.

1. Код Telegram-бота

Створимо простий файл bot.py у директорії ~/my_telegram_bot. Цей файл міститиме логіку нашого бота.

nano ~/my_telegram_bot/bot.py

Вміст bot.py:

import os
from dotenv import load_dotenv
from aiogram import Bot, Dispatcher, types
from aiogram.enums import ParseMode
from aiogram.webhook.aiohttp_server import Simple
from aiohttp import web

# Завантажуємо змінні оточення з .env файлу
load_dotenv()

# Отримуємо токен бота зі змінних оточення
BOT_TOKEN = os.getenv("BOT_TOKEN")
WEBHOOK_HOST = os.getenv("WEBHOOK_HOST")
WEBHOOK_PATH = os.getenv("WEBHOOK_PATH")
WEB_SERVER_HOST = os.getenv("WEB_SERVER_HOST", "127.0.0.1")
WEB_SERVER_PORT = int(os.getenv("WEB_SERVER_PORT", 8000))

if not BOT_TOKEN:
    raise ValueError("BOT_TOKEN environment variable not set.")
if not WEBHOOK_HOST:
    raise ValueError("WEBHOOK_HOST environment variable not set.")
if not WEBHOOK_PATH:
    raise ValueError("WEBHOOK_PATH environment variable not set.")

WEBHOOK_URL = f"https://{WEBHOOK_HOST}{WEBHOOK_PATH}"

# Ініціалізація бота та диспетчера
bot = Bot(token=BOT_TOKEN, parse_mode=ParseMode.HTML)
dp = Dispatcher()

# Обробник команди /start
@dp.message(commands=["start"])
async def handle_start(message: types.Message):
    await message.reply(f"Привіт, {message.from_user.full_name}! Я твій новий бот.")

# Обробник текстових повідомлень
@dp.message()
async def handle_message(message: types.Message):
    await message.reply(f"Ви сказали: {message.text}")

async def on_startup(dispatcher: Dispatcher, bot: Bot):
    # Встановлюємо вебхук під час запуску
    await bot.set_webhook(WEBHOOK_URL)
    print(f"Вебхук встановлено на: {WEBHOOK_URL}")

async def on_shutdown(dispatcher: Dispatcher, bot: Bot):
    # Видаляємо вебхук після завершення роботи
    await bot.delete_webhook()
    print("Вебхук видалено.")

def main():
    # Створюємо AioHTTP веб-застосунок для вебхуків
    app = web.Application()
    webhook_requests_handler = Simple(dispatcher=dp, bot=bot, path=WEBHOOK_PATH)
    webhook_requests_handler.register(app, path=WEBHOOK_PATH)

    # Реєструємо функції запуску та зупинки
    app.on_startup.append(lambda app: on_startup(dp, bot))
    app.on_shutdown.append(lambda app: on_shutdown(dp, bot))

    # Запускаємо веб-сервер
    web.run_app(app, host=WEB_SERVER_HOST, port=WEB_SERVER_PORT)

if __name__ == "__main__":
    main()

2. Налаштування змінних оточення (.env)

Ніколи не зберігайте конфіденційні дані (токени, паролі) безпосередньо в коді. Використовуйте змінні оточення. Створіть файл .env у кореневій директорії проєкту.

nano ~/my_telegram_bot/.env

Вміст .env:

BOT_TOKEN="ВАШ_ТОКЕН_БОТА" # Отримайте його у @BotFather
WEBHOOK_HOST="ВАШ_ДОМЕН_АБО_IP" # Наприклад, example.com
WEBHOOK_PATH="/webhook/bot" # Унікальний шлях для вебхука
WEB_SERVER_HOST="127.0.0.1" # Gunicorn слухатиме лише локально
WEB_SERVER_PORT=8000 # Порт, на якому працюватиме Gunicorn

Замініть ВАШ_ТОКЕН_БОТА на реальний токен, отриманий від @BotFather, і ВАШ_ДОМЕН_АБО_IP на ваш домен або публічну IP-адресу VPS.

3. Налаштування Systemd-сервісу для бота

Systemd дозволить нам запускати бота як системну службу, автоматично перезапускати його у випадку збоїв та керувати ним.

sudo nano /etc/systemd/system/telegram-bot.service

Вміст telegram-bot.service:

[Unit]
Description=Telegram Bot Service
After=network.target

[Service]
User=botuser # Користувач, під яким запускатиметься бот
Group=www-data # Група, якщо потрібна для доступу до файлів Nginx
WorkingDirectory=/home/botuser/my_telegram_bot # Робоча директорія проєкту
EnvironmentFile=/home/botuser/my_telegram_bot/.env # Шлях до файлу зі змінними оточення
ExecStart=/home/botuser/my_telegram_bot/.venv/bin/gunicorn --workers 1 --bind 127.0.0.1:8000 bot:app # Запуск Gunicorn
Restart=always
RestartSec=5 # Перезапускати через 5 секунд після збою
StandardOutput=journal
StandardError=journal
SyslogIdentifier=telegram-bot

[Install]
WantedBy=multi-user.target

Важливе зауваження: У aiogram 3.x вебхуки налаштовуються через aiohttp.web.Application. Gunicorn може запускати aiohttp застосунки. Рядок ExecStart вказує Gunicorn, що потрібно запустити застосунок app з модуля bot. У нашому bot.py ми запускаємо web.run_app всередині main(). Для Gunicorn нам потрібно експортувати app з bot.py. Змінимо bot.py так, щоб app був доступний для Gunicorn:

# ... (початок файлу bot.py) ...

# Створюємо AioHTTP веб-застосунок для вебхуків
app = web.Application()
webhook_requests_handler = Simple(dispatcher=dp, bot=bot, path=WEBHOOK_PATH)
webhook_requests_handler.register(app, path=WEBHOOK_PATH)

# Реєструємо функції запуску та зупинки
app.on_startup.append(lambda app_instance: on_startup(dp, bot))
app.on_shutdown.append(lambda app_instance: on_shutdown(dp, bot))

# ... (кінець файлу bot.py) ...

# Видаліть або закоментуйте блок if __name__ == "__main__":
# if __name__ == "__main__":
#     main()

Тепер Gunicorn зможе знайти та запустити app. Після редагування файлу сервісу, перезавантажте systemd та запустіть бота:

sudo systemctl daemon-reload # Перезавантажуємо systemd, щоб він побачив новий сервіс
sudo systemctl enable telegram-bot # Вмикаємо автозапуск бота під час завантаження
sudo systemctl start telegram-bot # Запускаємо сервіс бота
sudo systemctl status telegram-bot # Перевіряємо статус бота

Переконайтеся, що сервіс запущено і він не містить помилок. Логи можна переглянути командою: sudo journalctl -u telegram-bot -f.

4. Налаштування Nginx як зворотного проксі

Створимо конфігураційний файл Nginx для нашого бота. Замініть example.com на ваш домен.

sudo nano /etc/nginx/sites-available/telegram-bot

Вміст telegram-bot:

server {
    listen 80;
    server_name ВАШ_ДОМЕН_АБО_IP; # Наприклад, example.com

    location / {
        return 301 https://$host$request_uri; # Перенаправляємо весь HTTP-трафік на HTTPS
    }
}

server {
    listen 443 ssl;
    server_name ВАШ_ДОМЕН_АБО_IP; # Наприклад, example.com

    ssl_certificate /etc/letsencrypt/live/ВАШ_ДОМЕН_АБО_IP/fullchain.pem; # Буде створено Certbot
    ssl_certificate_key /etc/letsencrypt/live/ВАШ_ДОМЕН_АБО_IP/privkey.pem; # Буде створено Certbot
    ssl_protocols TLSv1.2 TLSv1.3; # Рекомендовані протоколи
    ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;

    location /webhook/bot { # Повинен збігатися з WEBHOOK_PATH у .env
        proxy_pass http://127.0.0.1:8000; # Проксіюємо запити на Gunicorn
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_redirect off;
        proxy_buffering off; # Вимикаємо буферизацію для вебхуків
    }

    # Якщо бот віддаватиме статику або матиме інші HTTP-ендпоінти
    # location / {
    #    root /var/www/html;
    #    index index.html;
    # }
}

Створіть символічне посилання на цей файл з sites-enabled та перевірте конфігурацію Nginx:

sudo ln -s /etc/nginx/sites-available/telegram-bot /etc/nginx/sites-enabled/ # Створюємо симлінк
sudo nginx -t # Перевіряємо синтаксис конфігурації Nginx
sudo systemctl restart nginx # Перезапускаємо Nginx

5. Отримання SSL-сертифіката за допомогою Certbot

Тепер, коли Nginx налаштовано, отримаємо SSL-сертифікат. Переконайтеся, що ваш домен вже вказує на IP-адресу вашого VPS.

sudo certbot --nginx -d ВАШ_ДОМЕН_АБО_IP # Запустіть Certbot, замінивши на ваш домен

Certbot поставить кілька запитань (email, згода з умовами). Він автоматично змінить конфігурацію Nginx, додавши ssl_certificate та ssl_certificate_key. Після успішного отримання сертифіката Nginx автоматично перезапуститься.

Перевірте, що Certbot налаштував автоматичне продовження сертифіката:

sudo systemctl status certbot.timer # Перевіряємо статус таймера для автопродовження

Certbot зазвичай створює cron-завдання або systemd-таймер для автоматичного продовження сертифікатів. Це відбувається двічі на день, і сертифікат продовжується, якщо термін його дії закінчується протягом 30 днів.

6. Перевірка працездатності

Після всіх налаштувань переконайтеся, що бот працює та доступний:

• Перевірка Nginx: Відкрийте в браузері https://ВАШ_ДОМЕН_АБО_IP/. Якщо ви бачите сторінку привітання Nginx або перенаправлення, значить Nginx працює.
• Перевірка вебхука: Спробуйте надіслати повідомлення вашому боту в Telegram. Він повинен відповісти.
• Перевірка systemd-сервісу:

  
  sudo systemctl status telegram-bot
  sudo journalctl -u telegram-bot -f # Перегляд логів бота в реальному часі
              

  Ви повинні побачити повідомлення про запуск бота та встановлення вебхука.

• Перевірка порту Gunicorn: З сервера можна перевірити, чи слухає Gunicorn на локальному порту:

  
  ss -ltn | grep 8000
              

  Ви повинні побачити рядок, що вказує, що 127.0.0.1:8000 знаходиться у стані LISTEN.

Резервне копіювання та обслуговування

Надійна стратегія резервного копіювання та регулярне обслуговування є критично важливими для будь-якого production-сервісу.

1. Що резервувати

• Код бота: Директорія ~/my_telegram_bot/ (без .venv).
• Конфігураційні файли: .env, /etc/systemd/system/telegram-bot.service, /etc/nginx/sites-available/telegram-bot, /etc/nginx/sites-enabled/telegram-bot.
• Дані бота: Якщо бот використовує базу даних (SQLite, PostgreSQL, MongoDB), необхідно регулярно створювати резервні копії даних цієї бази. Для SQLite це просто файл, для PostgreSQL/MongoDB — дамп бази.
• SSH-ключі: (необов'язково, але корисно) ~/.ssh/.

2. Простий скрипт авторезервування

Використовуємо rsync для створення копій файлів та pg_dump (якщо у вас PostgreSQL) для бази даних.

nano ~/backup_script.sh

Вміст backup_script.sh:

#!/bin/bash

# Директорія для резервних копій
BACKUP_DIR="/var/backups/telegram_bot"
# Директорія з кодом бота
BOT_CODE_DIR="/home/botuser/my_telegram_bot"
# Ім'я файлу бази даних SQLite (якщо використовується)
SQLITE_DB_NAME="bot_database.db"
# Ім'я бази даних PostgreSQL (якщо використовується)
POSTGRES_DB_NAME="telegram_bot_db"
# Користувач PostgreSQL
POSTGRES_USER="botuser"

# Створюємо директорію для резервних копій, якщо її немає
mkdir -p "$BACKUP_DIR"

# 1. Резервна копія коду бота та .env
echo "Починаємо резервне копіювання коду та .env..."
rsync -avz --exclude '.venv/' "$BOT_CODE_DIR/" "$BACKUP_DIR/code_$(date +%Y%m%d_%H%M%S)/"
cp "$BOT_CODE_DIR/.env" "$BACKUP_DIR/config_$(date +%Y%m%d_%H%M%S)/.env"

# 2. Резервна копія конфігураційних файлів Nginx та Systemd
echo "Починаємо резервне копіювання конфігураційних файлів..."
cp /etc/systemd/system/telegram-bot.service "$BACKUP_DIR/config_$(date +%Y%m%d_%H%M%S)/telegram-bot.service"
cp /etc/nginx/sites-available/telegram-bot "$BACKUP_DIR/config_$(date +%Y%m%d_%H%M%S)/nginx_telegram-bot"

# 3. Резервна копія бази даних (виберіть відповідний варіант)
# Для SQLite:
if [ -f "$BOT_CODE_DIR/$SQLITE_DB_NAME" ]; then
    echo "Починаємо резервне копіювання бази даних SQLite..."
    cp "$BOT_CODE_DIR/$SQLITE_DB_NAME" "$BACKUP_DIR/db_sqlite_$(date +%Y%m%d_%H%M%S).db"
fi

# Для PostgreSQL (розкоментувати, якщо використовується)
# echo "Починаємо резервне копіювання бази даних PostgreSQL..."
# PGPASSWORD="ВАШ_ПАРОЛЬ_POSTGRES" pg_dump -U "$POSTGRES_USER" -Fc "$POSTGRES_DB_NAME" > "$BACKUP_DIR/db_pg_$(date +%Y%m%d_%H%M%S).dump"

echo "Резервне копіювання завершено."

# Очищення старих резервних копій (зберігаємо останні 7 днів)
find "$BACKUP_DIR" -type d -name "code_*" -mtime +7 -exec rm -rf {} \;
find "$BACKUP_DIR" -type d -name "config_*" -mtime +7 -exec rm -rf {} \;
find "$BACKUP_DIR" -type f -name "db_sqlite_*.db" -mtime +7 -delete
find "$BACKUP_DIR" -type f -name "db_pg_*.dump" -mtime +7 -delete

Зробіть скрипт виконуваним:

chmod +x ~/backup_script.sh

Додайте скрипт у cron для щоденного запуску. Відкрийте crontab для користувача botuser:

crontab -e

Додайте рядок у кінці файлу для запуску скрипта, наприклад, щодня о 3:00 ночі:

0 3 * * * /home/botuser/backup_script.sh >> /var/log/telegram_bot_backup.log 2>&1

3. Куди зберігати резервні копії

Зберігати резервні копії на тому ж сервері, що й основний сервіс, небезпечно. У разі виходу з ладу сервера або диска ви втратите і сервіс, і резервні копії. Рекомендується:

• Зовнішнє S3-сумісне об'єктне сховище: AWS S3, DigitalOcean Spaces, Backblaze B2, MinIO. Це надійне та масштабоване рішення. Для автоматичної відправки можна використовувати rclone.
• Окремий VPS: Недорогий VPS в іншому дата-центрі, куди ви будете копіювати резервні копії по SSH/rsync.
• Локальне сховище із синхронізацією: Наприклад, Google Drive/Dropbox через rclone.

Для більш просунутих резервних копій розгляньте borgbackup або restic, які підтримують дедуплікацію, шифрування та інкрементальні резервні копії.

4. Оновлення: Rolling vs. Maintenance Window

Регулярно оновлюйте ОС та ПЗ для безпеки та стабільності. Є два основні підходи:

• Maintenance Window (Вікно обслуговування): Запланований час, коли ви зупиняєте сервіс, оновлюєте ОС та ПЗ, тестуєте та знову запускаєте.
  • Переваги: Контрольований процес, менший ризик несподіваних проблем.
  • Недоліки: Сервіс буде недоступний під час оновлення.

  
  sudo systemctl stop telegram-bot  # Зупиняємо бота
  sudo apt update && sudo apt upgrade -y # Оновлюємо систему
  # ... (оновлюємо залежності Python, якщо потрібно)
  sudo systemctl start telegram-bot # Запускаємо бота
              

• Rolling Updates (Поступові оновлення): Застосовується для кластерів або систем з кількома екземплярами сервісу, коли ви оновлюєте по одному екземпляру, не перериваючи роботу всього сервісу. Для одного VPS це неактуально, але концептуально важливо.

Для більшості Telegram-ботів достатньо вікна обслуговування раз на 1-2 місяці. Важливо завжди перевіряти логи після оновлень.

Вирішення проблем + FAQ

Тут зібрані типові проблеми та питання, які можуть виникнути при розгортанні та експлуатації бота.

Nginx видає 502 Bad Gateway

Це означає, що Nginx не може зв'язатися з вашим Gunicorn-сервером.
Що перевірити:

1. Переконайтеся, що сервіс бота (telegram-bot.service) запущений: sudo systemctl status telegram-bot.
2. Перевірте логи бота: sudo journalctl -u telegram-bot -f. Можливо, бот не зміг запуститися через помилку в коді або відсутність змінних оточення.
3. Переконайтеся, що Gunicorn слухає на правильному порту (127.0.0.1:8000 у нашому випадку): ss -ltn | grep 8000.
4. Перевірте файл конфігурації Nginx (/etc/nginx/sites-available/telegram-bot) на предмет помилок у proxy_pass.

Бот не відповідає на повідомлення в Telegram

Якщо бот не відповідає, але Nginx працює (немає 502), проблема може бути у вебхуку або в логіці бота.
Що перевірити:

1. Перевірте логи бота (sudo journalctl -u telegram-bot -f). Можливо, є помилки в обробниках повідомлень.
2. Переконайтеся, що Telegram API зміг встановити вебхук: у логах бота під час запуску має бути рядок Вебхук встановлено на: https://ВАШ_ДОМЕН/webhook/bot.
3. Перевірте, що ваш домен коректно резолвиться в IP-адресу вашого VPS (використовуйте dig ВАШ_ДОМЕН).
4. Переконайтеся, що файрвол (UFW) дозволяє вхідні з'єднання на порти 80 і 443 (sudo ufw status verbose).
5. Використовуйте Telegram Bot API метод getWebhookInfo, щоб перевірити статус вебхука: https://api.telegram.org/botВАШ_ТОКЕН_БОТА/getWebhookInfo. Переконайтеся, що url правильний і last_error_message пустий.

Certbot не може отримати сертифікат

Це зазвичай пов'язано з проблемами доступності вашого домену.
Що перевірити:

1. Переконайтеся, що ваш домен (або піддомен) коректно вказує на IP-адресу вашого VPS у DNS-записах. Використовуйте dig ВАШ_ДОМЕН.
2. Перевірте, що Nginx запущений і коректно слухає на порту 80 (sudo systemctl status nginx).
3. Переконайтеся, що файрвол (UFW) дозволяє вхідні з'єднання на порт 80 (sudo ufw status verbose). Certbot використовує порт 80 для HTTP-01 challenge.
4. Тимчасово вимкніть Nginx-конфігурацію бота, якщо вона заважає Certbot.

Який VPS-конфіг мінімально підійде?

Для простого Telegram-бота з невеликою аудиторією (до 1000 активних користувачів) мінімально підійде VPS з 1 CPU-ядром, 1-2 GB RAM та 25-50 GB SSD. Цього буде достатньо для операційної системи, Python-оточення, бота, Nginx та невеликого обсягу логів. Для більш складних ботів з активною базою даних або інтенсивними обчисленнями знадобиться більше ресурсів.

Що вибрати — VPS чи dedicated для цього завдання?

Для переважної більшості Telegram-ботів VPS є оптимальним вибором. Він пропонує достатню продуктивність, гнучкість та економічність. Dedicated server потрібен лише для дуже масштабних проєктів з десятками тисяч одночасних користувачів, специфічними апаратними вимогами (наприклад, GPU) або за необхідності максимальної ізоляції та гарантованої продуктивності. Почніть з VPS і масштабуйтеся до dedicated, якщо виникне реальна необхідність.

Як оновити залежності Python (aiogram, gunicorn)?

Для оновлення Python-залежностей активуйте віртуальне оточення та використовуйте pip.
Кроки:

1. Перейдіть до директорії проєкту: cd ~/my_telegram_bot
2. Активуйте віртуальне оточення: source .venv/bin/activate
3. Оновіть пакети: pip install --upgrade aiogram gunicorn python-dotenv
4. Деактивуйте оточення: deactivate
5. Перезапустіть сервіс бота: sudo systemctl restart telegram-bot

Висновки та наступні кроки

Ми успішно розгорнули production-готову інфраструктуру для Telegram-бота на VPS, використовуючи aiogram, systemd та Nginx. Ваш бот тепер працює як надійний системний сервіс, автоматично запускається при перезавантаженні сервера, обробляє запити через захищене HTTPS-з'єднання та має базову систему резервного копіювання.

Для подальшого розвитку та оптимізації вашого проєкту розгляньте наступні кроки:

• Моніторинг: Впровадьте систему моніторингу (наприклад, Prometheus + Grafana або Datadog) для відстеження завантаження CPU, RAM, диска, мережевого трафіку та стану самого бота.
• База даних: Якщо бот зберігатиме багато даних, перенесіть їх з SQLite у повноцінну СУБД, таку як PostgreSQL або MongoDB, можливо, на окремому сервері або в керованому хмарному сервісі.
• CI/CD: Налаштуйте пайплайн безперервної інтеграції та доставки (CI/CD) за допомогою GitHub Actions, GitLab CI або Jenkins для автоматизації розгортання нових версій коду бота.