Docker · 13 минут

Как выбрать VPS для Docker и не потерять данные в контейнерах

Docker упрощает доставку приложения, но не отменяет выбор CPU, RAM, диска и сети. Хороший VPS для контейнеров должен выдерживать рабочую нагрузку, хранить volumes вне временного слоя и позволять безопасно обновлять образы.

Обновлено 9 августа 2026От Compose до backup

Какая виртуализация подходит Docker

Для универсального рабочего окружения проще выбирать VPS на KVM. Виртуальная машина получает собственное ядро и предсказуемый доступ к системным функциям. Docker может работать и внутри некоторых контейнерных платформ, но провайдер должен разрешать nesting, namespaces, cgroups и нужные модули ядра. Ограничение иногда проявляется только при запуске конкретного storage или network driver, поэтому самый дешёвый контейнерный VPS способен потребовать больше времени на диагностику, чем сэкономит денег.

Проверьте архитектуру процессора: большинство публичных образов доступны для amd64, многие — для arm64, но не все сторонние компоненты собираются под обе архитектуры. ARM-тариф может быть выгодным, если весь стек имеет совместимые образы. Иначе придётся собирать их самостоятельно или использовать медленную эмуляцию.

Доступ к root или sudo необходим для установки Docker Engine и настройки сети. Уточните, входит ли IPv4 в цену, разрешены ли необходимые входящие порты и нет ли ограничений на исходящий трафик к registry. Для первичного отбора используйте VPS с KVM, а общие критерии сравните с руководством по выбору виртуального сервера.

Сколько ресурсов нужно контейнерам

Считайте не число контейнеров, а сумму их реального потребления. Десять небольших служебных контейнеров могут быть легче одного приложения с тяжёлой базой или сборкой. Кроме процессов приложения память нужна ядру, Docker daemon, файловому кэшу, reverse proxy, агенту мониторинга и обновлениям.

Оставляйте запас хотя бы 20–30% RAM. Если память закончится, Linux может завершить один из процессов, а Docker затем перезапустит контейнер без объяснения первопричины на уровне приложения. Следите за OOM events, swap и пиковым потреблением, а не только за средним значением. Таблица в статье «Сколько CPU и RAM нужно для VPS» поможет задать первый фильтр.

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

Почему Docker незаметно заполняет диск

Место занимают не только данные приложения. На VPS остаются слои старых образов, остановленные контейнеры, build cache, volumes и JSON-логи. Команда очистки освобождает ресурсы, но при неосторожном использовании может удалить нужный volume или образ для быстрого отката. Автоматическую очистку следует запускать только с понятными правилами хранения.

Для базы данных, registry и большого числа мелких файлов NVMe обычно предпочтительнее SATA SSD. Однако важны реальные latency и IOPS, а не только слово в названии тарифа. Не запускайте разрушительные дисковые benchmarks на рабочей базе и сначала прочитайте ограничения провайдера. Различия подробно разобраны в статье про NVMe и SSD для VPS.

• Храните изменяемые данные в named volumes или bind mounts, а не внутри writable layer контейнера.
• Настройте ротацию stdout/stderr логов и лимит размера.
• Проверяйте свободные inode: множество мелких файлов может исчерпать их раньше гигабайтов.
• Учитывайте временное место на одновременное хранение старого и нового образа при обновлении.
• Выносите большие артефакты, media и backup во внешнее хранилище.

Практическая схема развёртывания

Для одного VPS Docker Compose обычно проще полноценного Kubernetes. Храните compose-файл и конфигурацию в системе контроля версий, а секреты — отдельно: в защищённом env-файле, secret manager или механизме оркестратора. Не записывайте пароли и токены внутрь Dockerfile или публичного образа — удалить секрет из уже опубликованного слоя трудно.

1. Установите поддерживаемый Linux и Docker из доверенного репозитория.
2. Создайте отдельного пользователя для развёртывания и ограничьте SSH ключами.
3. Подготовьте каталоги или named volumes с нужными владельцами и правами.
4. Запустите reverse proxy, приложение и базу в отдельных сервисах.
5. Открывайте наружу только HTTP/HTTPS и действительно нужные служебные порты.
6. Добавьте healthchecks, restart policy, лимиты и ротацию логов.
7. Настройте monitoring и backup до первого рабочего релиза.

Не публикуйте порт базы данных в интернет без необходимости. Внутри Compose сервисы общаются по отдельной сети и DNS-именам. Для доступа администратора безопаснее SSH tunnel или VPN с ограниченным кругом пользователей. Если приложение принимает файлы, проверьте максимальный размер запроса одновременно в proxy и самом сервисе.

Обновления без сюрпризов

Тег `latest` удобен для эксперимента, но не фиксирует версию. Рабочие образы лучше закреплять конкретным тегом или digest, а обновление сначала проверять на тестовом окружении. Перед миграцией базы изучите release notes и совместимость: откат контейнера не откатывает уже изменённую схему данных.

Для короткого простоя можно скачать новый образ, остановить старый контейнер, выполнить миграции и запустить новую версию. Если требуется более плавное переключение, поднимите второй экземпляр на другом порту и перенаправьте reverse proxy после healthcheck. Это требует дополнительной RAM и осторожности с конкурентными миграциями.

Резервные копии volumes и баз данных

Копирование каталога работающей базы не всегда создаёт согласованный backup. Используйте штатный dump или механизм физической копии конкретной СУБД. Для файлов приложения можно применять snapshot или файловую синхронизацию, но нужно понимать порядок: база и связанные с ней uploads должны относиться к совместимому моменту.

Храните backup вне VPS и шифруйте его, если там есть персональные данные или секреты. Зафиксируйте retention: например, несколько ежедневных и более редкие недельные копии. Периодически разворачивайте восстановление в отдельном Compose-проекте. Такой тест проверяет не только архив, но и документацию, версии образов и наличие ключей дешифрования.

Сеть и безопасность Docker-хоста

Членство пользователя в группе `docker` фактически даёт широкие права на хосте, поэтому добавляйте туда только доверенные учётные записи. Не открывайте Docker API по TCP без взаимной аутентификации. Образы берите из известных registry, фиксируйте версии и удаляйте ненужные capabilities. Запуск приложения не от root внутри контейнера уменьшает последствия части уязвимостей, хотя не заменяет обновлений.

Firewall на хосте нужно проверять вместе с правилами, которые создаёт Docker. После публикации порта убедитесь внешним сканированием, что он действительно закрыт или доступен только нужным адресам. Защита провайдера от DDoS полезна для публичного сервиса, но она не исправляет слабый пароль, открытый dashboard или уязвимый образ.

Частые ошибки

• Все данные остаются внутри контейнера. После пересоздания writable layer пропадает вместе с ними.
• Нет лимита логов. Один цикл ошибок заполняет диск за ночь.
• Используется только `latest`. Невозможно точно повторить релиз или откат.
• База опубликована на `0.0.0.0`. Сервис становится целью автоматических атак.
• Один backup находится на том же сервере. Отказ диска или блокировка аккаунта уничтожает обе копии.
• Контейнеры считаются мониторингом. Статус running не означает, что приложение отвечает корректно.
• На маленьком VPS запускают тяжёлую панель. Служебные компоненты отнимают память у приложения.

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

Хватит ли 1 ГБ RAM для Docker?

Для одного очень лёгкого сервиса без базы — иногда да, но запас будет мал. Docker daemon, ОС и обновления тоже потребляют память. Практичный минимум для рабочего веб-приложения обычно начинается с 2 ГБ, а решение подтверждается измерениями.

Нужен ли Docker отдельный IPv4?

Обычно достаточно одного адреса VPS: reverse proxy распределяет запросы по доменам и контейнерам. Дополнительные адреса нужны только для специальных сетевых сценариев.

Стоит ли ставить Kubernetes на один VPS?

Для одного узла он часто добавляет сложность без отказоустойчивости. Docker Compose проще сопровождать. Kubernetes оправдан, когда нужны несколько узлов, единая модель deployment и команда умеет его обслуживать.

Можно ли хранить PostgreSQL в Docker?

Да, если данные находятся в постоянном volume, версия зафиксирована, backup согласован и восстановление проверено. Сам контейнер не делает базу временной или ненадёжной; проблемы обычно связаны с хранением и эксплуатацией.

Как понять, что пора увеличить VPS?

Смотрите на CPU throttling, OOM, swap, disk latency, заполнение диска и время ответа. Увеличивайте ресурс, который стабильно исчерпывается, после проверки утечек и ошибочных запросов.

Для базы данных внутри стека полезна отдельная подборка серверов для БД.