VPS под Docker: как развернуть контейнеры на своём сервере

Docker стал стандартом для запуска приложений: он упаковывает сервис со всеми зависимостями в контейнер, который одинаково работает где угодно. Разбираем, какой VPS нужен под Docker, как его подготовить и развернуть контейнеры.

Почему Docker удобно запускать на VPS

Docker упаковывает приложение и все его зависимости в изолированный контейнер. Это избавляет от классической проблемы «на моём компьютере работает, а на сервере нет»: контейнер ведёт себя одинаково в любой среде. Для развёртывания сервисов это огромное удобство.

VPS с полным root-доступом — идеальная площадка для Docker: вы сами ставите Docker Engine, поднимаете любые контейнеры, управляете сетями, томами и портами без ограничений, характерных для «управляемых» хостингов. Один сервер может держать сразу несколько контейнеров: базу данных, веб-приложение, кэш, очередь и вспомогательные сервисы.

Какой VPS выбрать под Docker

Требования зависят от того, что вы упаковываете в контейнеры:

• Пара лёгких сервисов (небольшое приложение + база) — 2 vCPU, 2–4 ГБ RAM, NVMe-диск.
• Полноценный стек (веб-приложение, база, кэш, очередь) — 4 vCPU, 4–8 ГБ RAM.
• Множество контейнеров или тяжёлые базы данных — 8+ vCPU, 8–16 ГБ RAM.

Docker и особенно сборка образов активно используют диск, поэтому NVMe здесь заметно ускоряет работу. Оперативную память берите с запасом: каждый контейнер потребляет свою долю, и на слабом тарифе стек быстро упрётся в потолок. Честные ресурсы без oversell (как на AMD EPYC у MAATRIX) дают предсказуемую производительность контейнеров.

Установка Docker и docker-compose

На чистом Ubuntu или Debian Docker ставится в несколько команд. Проще всего использовать официальный скрипт установки:

curl -fsSL https://get.docker.com | sh
docker --version
docker compose version

После установки Docker Engine и плагин Compose готовы к работе. Проверить, что всё запускается, можно классическим тестовым контейнером: docker run hello-world. Если вы увидели приветственное сообщение — движок работает корректно.

Запуск сервисов через docker-compose

Для нескольких связанных контейнеров удобно описать всё в одном файле docker-compose.yml. Пример стека «веб-приложение + база данных»:

services:
  app:
    image: myapp:latest
    ports:
      - "80:8080"
    restart: always
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - dbdata:/var/lib/postgresql/data
    restart: always

volumes:
  dbdata:

Запуск всего стека одной командой: docker compose up -d. Параметр restart: always поднимет контейнеры после перезагрузки сервера, а именованный том dbdata сохранит данные базы между перезапусками.

Тома, сети и сохранность данных

Данные контейнера по умолчанию исчезают вместе с ним. Чтобы этого не произошло, используйте тома (volumes) — они хранят данные отдельно от жизненного цикла контейнера. Базы данных, загруженные файлы и конфиги всегда держите в томах.

Для связи контейнеров между собой Docker создаёт изолированные сети: сервисы из одного docker-compose видят друг друга по имени (в примере выше приложение обращается к базе по хосту db). Наружу открывайте только нужные порты, а внутренние сервисы держите в приватной сети.

Не забывайте про бэкапы томов: на тарифах MAATRIX ежедневная копия VM уходит на отдельный backup-узел, но для критичных баз стоит настроить и собственные регулярные дампы.

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

Резонный вопрос: зачем контейнеры, если можно поставить приложение прямо на сервер? У Docker есть несколько практических преимуществ, из-за которых он и стал стандартом.

• Изоляция. Каждый сервис живёт в своём контейнере со своими версиями библиотек. Обновление одного не ломает другой, а конфликты зависимостей исчезают как класс.
• Воспроизводимость. Один и тот же образ одинаково запускается на сервере, у коллеги и в проде. Настройка окружения описана в Dockerfile, а не хранится «в голове».
• Быстрое развёртывание. Новый сервис поднимается одной командой, а перенос на другой сервер сводится к копированию файла compose и запуску.
• Чистота системы. Вы не засоряете хост десятками пакетов — всё внутри контейнеров, а удаление сервиса не оставляет следов.

Обратная сторона — небольшой overhead и необходимость освоить базовые команды. Но для большинства проектов выгода от предсказуемости и изоляции многократно перевешивает эти издержки.

Масштабирование: от одного контейнера к стеку

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

Когда приложению перестаёт хватать ресурсов, есть два пути. Вертикальное масштабирование — увеличить тариф VPS (больше vCPU и RAM); контейнеры автоматически получат больше ресурсов. Горизонтальное — запустить несколько экземпляров сервиса и распределять нагрузку через обратный прокси (nginx, Traefik) или встроенный балансировщик.

Для более сложных сценариев с автоматическим восстановлением и распределением по нескольким серверам существуют оркестраторы — Docker Swarm (проще) и Kubernetes (мощнее, но сложнее). Большинству проектов на старте они не нужны: одного VPS с docker-compose хватает надолго, а перейти к оркестрации можно позже, уже понимая реальную нагрузку.

Безопасность и обслуживание

• Обновляйте образы — используйте свежие версии базовых образов, чтобы получать патчи безопасности.
• Не запускайте лишнее от root внутри контейнеров и не открывайте наружу порты баз данных.
• Настройте фаервол на уровне сервера и оставляйте открытыми только нужные порты.
• Делайте снапшоты перед крупными обновлениями стека — при необходимости легко откатиться.
• Следите за местом на диске: старые образы и тома накапливаются, периодически чистите их командой docker system prune.
• Ограничивайте ресурсы контейнеров (лимиты CPU и памяти в compose), чтобы один сервис не «съел» весь сервер.

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