Где хостить парсер, чтобы он работал без вашего компьютера

Парсер написан и уже приносит пользу: раз в час обходит список страниц, складывает цены в таблицу и присылает разницу в чат. Ровно до тех пор, пока включён ваш компьютер: закрыли ноутбук, он ушёл в спящий режим, на минуту пропал Wi-Fi — сбор встал, а заметили вы это через неделю по дырке в данных. Разбираем, где поселить парсер, чтобы он работал без вашего участия, и что решить заранее: расписание, хранение результатов, лимиты и прокси.

Почему парсер останавливается вместе с компьютером

Парсер — это фоновый скрипт, а не сайт: у него нет публичной ссылки, его никто не открывает в браузере и не присылает ему входящих запросов. Он должен просто работать всё время, и в этом его главная особенность.

Ноутбук для этого не предназначен. Он обновляется и перезагружается, уходит в сон при закрытии крышки, теряет сеть в дороге. Каждый такой разрыв — пропущенный проход, а узнаёте вы о нём по отсутствующим строкам в результатах.

Нужно не запустить, а поддерживать. Скрипт достаточно запустить руками один раз, а парсеру — держать процесс живым, поднимать его после падения и следить за окружением. Именно эта часть съедает больше всего времени, если делать её на своём сервере.

Где парсеру жить: три варианта

Свой VPS. Вы арендуете виртуальный сервер, ставите Python или Node.js, настраиваете автозапуск через systemd и следите, чтобы процесс не падал. Контроль полный, но и ответственность целиком на вас: упало ночью — поднимаете сами.

Домашний компьютер. Годится только для отладки: пока ПК включён, парсер живёт, дальше — нет.

Платформа для деплоя. Вы загружаете код, платформа сама собирает окружение, запускает процесс и перезапускает его после сбоя. Так работает Dockbox: код из Git или архива превращается в Docker-контейнер и работает на серверах платформы постоянно, пока ваш компьютер выключен.

Расписание живёт внутри кода

Скрипт, который отработал один раз и завершился, считается законченным — если его никто не разбудит, следующего прохода не будет. В Docker это заметно сразу: контейнер живёт ровно столько, сколько живёт его главный процесс, и вышедший скрипт останавливает контейнер.

Держите расписание внутри парсера — бесконечный цикл с паузой либо библиотека планирования: schedule или APScheduler в Python, node-cron в Node.js. Процесс не завершается, а сам просыпается к следующему запуску.

import time
from schedule import every, run_pending
def collect():
    for url in fetch_list():
        save(parse(url))
        time.sleep(2)
every(60).minutes.do(collect)
while True:
    run_pending()
    time.sleep(1)

Интервал выбирайте по данным, а не по привычке: если цены меняются раз в день, незачем ходить на страницу каждый час — это лишние запросы и лишний риск блокировки.

Куда сохранять собранные данные

Файлы рядом с кодом живут только до следующего деплоя: при обновлении образ собирается заново, и CSV-таблица или файл SQLite создаются с нуля. Всё, что должно накапливаться, кладите в постоянный том (volume) — он переживает и пересборку, и перезапуск:

services:
  scraper:
    build: .
    volumes:
      - scraper-data:/data
volumes:
  scraper-data:

Или база данных. Если данных много или их читает другое приложение, поднимите базу вторым сервисом в том же проекте или подключитесь к внешней. Файл SQLite тоже должен лежать на томе, иначе он обнулится при первом же обновлении кода.

Задержки, robots.txt и прокси: как не получить блокировку

Парсер без пауз бьёт по чужому сайту десятками запросов в секунду — это самый быстрый путь к бану и лишним проблемам с владельцем ресурса.

Пауза между запросами. Несколько сотен миллисекунд снимают большинство блокировок, а спокойный парсер, который обходит список раз в час, живёт куда дольше жадного.

Уважайте правила сайта. Проверьте robots.txt и условия использования: не все страницы открыты для сбора, и лучше знать это заранее.

Прокси — когда блокируют по адресу. Если запросы режут по IP, подключите прокси-сервис, а его ключ держите в секретах. Платформа адреса не подменяет, так что ротация — задача вашего кода.

Секреты и деплой: от кода до первого прохода

Всё, что даёт доступ наружу — API-ключи, пароль от стороннего сервиса, строку подключения к базе, ключ прокси — читайте из переменных окружения. Плохой вариант, который модель пишет по умолчанию, и хороший:

PROXY_KEY = "sk-live-1234567890"
import os
PROXY_KEY = os.environ["PROXY_KEY"]

При настройке проекта Dockbox спросит эти значения отдельно и подставит зашифрованными: ни в архиве, ни в репозитории их не окажется.

Загрузите код из Git или архивом: платформа определит язык, установит зависимости и запустит парсер — ставить Python на сервер и писать автозапуск не нужно.

Публичной ссылки у парсера нет и быть не должно — поэтому смотрите логи в панели в реальном времени: там видно, что проект собрался, стартовал и первый проход записал данные. Если процесс упал, платформа поднимет его сама.

requests==2.32.3
beautifulsoup4==4.12.3
APScheduler==3.10.4

Браузер нужен не всегда. Если страница отдаёт нужное в HTML, хватит запроса и HTML-парсера — он легче, быстрее и стабильнее. Selenium или Playwright нужны только для контента, который рисуется скриптами на странице, и тогда понадобится свой Dockerfile с браузером.

Что нужно от хостинга и сколько это стоит

Критично одно: контейнер работает постоянно, без ограничений по часам — фоновый скрипт не умеет просыпаться по запросу, как сайт, он занят всё время.

Ресурсов нужно немного. Парсер не обслуживает входящие запросы, так что узкое место — память и место на диске, если результаты копятся локально. Тарифы Dockbox указаны в рублях:

Starter    990 ₽/мес    1 vCPU, 2 GB RAM, 20 GB SSD
Pro      2 490 ₽/мес    2 vCPU, 4 GB RAM, 5 проектов
Team     4 990 ₽/мес    запас ресурсов для команд

Первый месяц на Starter бесплатный. Этого хватает, чтобы подключить Git, дождаться сборки контейнера, вынести ключи в секреты и убедиться, что парсер пишет данные куда нужно, — до первого платежа.

Итог

Чтобы парсер работал без вашего компьютера, нужны три решения: расписание внутри кода, результаты — в постоянном хранилище или базе, ключи — в секретах. Дальше платформа держит процесс и перезапускает его при сбое, а вы только заглядываете в логи и забираете данные. Загрузите код в Dockbox — и сбор не остановится, когда вы закроете ноутбук. Похожие разборы: круглосуточный Telegram-бот и перенос проекта с VPS.

Частые вопросы

Можно ли настроить cron, чтобы парсер запускался раз в час?

Отдельного расписания снаружи лучше не ждать: надёжнее держать его внутри скрипта — бесконечный цикл с паузой или библиотека вроде schedule, APScheduler, node-cron. Тогда процесс не завершается, а сам просыпается к нужному времени, и контейнер остаётся живым.

Куда сохранять собранные данные?

В постоянное хранилище: том (volume), смонтированный в папку с данными, переживает и пересборку, и перезапуск. Файлы рядом с кодом создаются заново при каждом деплое. Если данных много или их читает другое приложение — поднимайте базу вторым сервисом в том же проекте или подключайте внешнюю.

Что делать, если сайт блокирует парсер?

Сначала замедлиться: пауза между запросами и разумная частота снимают большинство блокировок. Проверьте, не нарушаете ли правила сайта и не тянете ли закрытые страницы. Если блокируют по адресу — подключайте прокси-сервис, а его ключ держите в секретах.

Нужен ли Selenium или настоящий браузер?

Обычно нет. Если страница отдаёт нужное в HTML, достаточно запроса и HTML-парсера — это легче, быстрее и стабильнее. Браузер нужен только для контента, который рисуется скриптами на странице; тогда собирайте проект со своим Dockerfile, куда установлен браузер.

Нужен ли свой сервер или VPS?

Нет. Dockbox разворачивает проект на своих серверах: арендовать VPS, настраивать systemd и nginx и продлевать сертификаты не нужно. Контейнеры работают постоянно, а платформа перезапускает упавший процесс сама.