Сутки на эвакуацию: как перенести 40 роутов с serverless на собственный VPS в аварийном режиме

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

Именно в такой аварийный шторм в октябре 2026 года попал независимый разработчик студии TempApp под ником RentCeisy. После сбоев в инфраструктуре дата-центров Сасово, Калужской области и Владимира облачная среда перешла в статус «неустойчивая конфигурация», а критические функции приложений («Копилка Отказов», «Судоку Арена») оказались под угрозой полного отказа. На спасение продакшена оставались ровно сутки. Этот кейс интересен тем, что показывает реальные скрытые грабли, о которых молчат учебники по DevOps.

Давай разберем ключевые инженерные выводы и ловушки этого экстренного переезда на автономный VPS.

Ловушка №0: Проверь тип виртуализации до настройки софта

Когда время идет на часы, первой реакцией бывает схватить самый дешевый сервер у ближайшего хостера. Разработчик так и поступил — и немедленно напоролся на стену: в системе отказывался подключаться файл подкачки (swap), фаервол ufw при старте намертво ронял сетевые интерфейсы, а демон Docker падал с ошибками инициализации iptables.

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

# Первое, что нужно выполнить на новом сервере:
systemd-detect-virt

Если команда возвращает openvz или lxc — не пытайся бороться с системой, немедленно меняй тариф на полноценную аппаратную виртуализацию kvm. Как мы не раз подчеркивали, когда рассматривали ИИ-агенты на VPS: как развернуть автономного помощника за $15 в месяц и перестать разряжать ноутбук, чистый KVM избавляет от десятков необъяснимых системных сбоев.

Ловушка №1: Docker тихо игнорирует правила ufw

Ты настроил фаервол ufw default deny incoming, открыл только порт 443 и спокоен за периметр безопасности? Вынужден тебя расстроить: Docker по умолчанию модифицирует таблицы iptables в обход цепочек ufw.

Если в docker-compose.yml ты пробросил порт сервиса (ports: ["3001:3001"]), Docker пропишет правила в цепочку DOCKER-USER, которая обрабатывается ядром Linux до правил ufw. В результате твой внутренний микросервис или база данных окажутся открытыми всему интернету!

Чтобы закрыть порт от внешнего мира и разрешить доступ только с доверенного IP-адреса, необходимо добавить прямое правило в цепочку DOCKER-USER:

# Блокируем доступ к порту 3001 со всех адресов, кроме доверенного
iptables -I DOCKER-USER -p tcp --dport 3001 ! -s <IP_ДОВЕРЕННОГО_СЕРВЕРА> -j DROP

Ловушка №2: Перезапуск Docker Compose и старый .env

Еще одна классическая ошибка: ты поменял секретный токен или адрес базы данных в файле .env и выполняешь команду docker compose restart. Контейнер перезапускается, но приложение продолжает падать со старой ошибкой.

Почему? Команда restart просто перезапускает существующий контейнер в его текущем состоянии. Она не перечитывает переменные окружения! Чтобы применить изменения из .env, всегда используй пересоздание контейнеров: docker compose up -d.

Целевой стек: Caddy, Hono и SQLite вместо облачных комбайнов

Итоговое решение оказалось предельно элегантным и надежным:

• Веб-сервер Caddy с автоматическим получением сертификатов Let's Encrypt и обратным проксированием.
• Бэкенд на Node.js 22 с микрофреймворком Hono.js.
• Локальная база данных SQLite (better-sqlite3) с включенным режимом WAL (Write-Ahead Logging) вместо тяжелой распределенной YDB.

version: '3.8'
services:
  caddy:
    image: caddy:2-alpine
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data

  api:
    build: ./services/api
    restart: always
    environment:
      - DATABASE_URL=/data/production.db
    volumes:
      - api_data:/data

volumes:
  caddy_data:
  api_data: