Docker нередко становится причиной первой аренды VPS. Пока проект состоит из обычного сайта, возможностей виртуального хостинга может хватать годами. Но затем появляется приложение на Node.js или Python, база данных, Redis, фоновый worker, reverse proxy, и привычная панель хостинга начинает скорее мешать, чем помогать.
Кажется, решение очевидно — взять VPS, установить Docker и запустить весь стек через Compose. Сложнее ответить на следующий вопрос: какой именно сервер покупать?
Количество контейнеров здесь почти бесполезно. Пять небольших сервисов могут потреблять меньше ресурсов, чем одна активно работающая база данных. Поэтому выбирать нужно не «VPS на десять контейнеров», а сервер под конкретные приложения, которые окажутся внутри них.
Docker не создает отдельные ресурсы для каждого контейнера
Контейнеры используют ресурсы хостовой системы. В случае обычного VPS этой системой является ваша виртуальная машина с выделенными ей vCPU, RAM, диском и сетью.
Если оперативная память VPS закончилась, Docker не найдет дополнительную память где-то внутри контейнера. Если один процесс загрузил доступный процессор, остальные сервисы тоже почувствуют нехватку CPU.
Docker позволяет задавать ограничения процессора и памяти для контейнеров. Это полезно, чтобы один сервис не забрал все ресурсы машины. Но лимиты только распределяют то, что уже есть у VPS. Они не компенсируют недостаточную конфигурацию сервера.
Поэтому перед выбором тарифа выпишите состав проекта. Например, веб-приложение, PostgreSQL, Redis, Nginx, несколько workers и система мониторинга. Затем оценивайте потребление каждого компонента и их совместную работу.
RAM лучше считать снизу вверх
Самая частая ошибка — посмотреть, сколько памяти использует контейнер приложения, и подобрать VPS почти впритык к этой цифре.
На сервере кроме приложения работает Linux. Память нужна Docker Engine, базе данных, кэшу, reverse proxy и другим службам. Операционная система использует свободную RAM для файлового кэша, что тоже является нормальной и полезной работой.
Отдельного внимания заслуживает база. PostgreSQL или MySQL используют память для буферов, соединений, сортировок и других операций. При росте нагрузки ее потребление может вести себя совсем не так, как у небольшого stateless-приложения.
Есть еще кратковременные пики. Сборка образа, миграция, импорт данных или параллельная работа нескольких workers способны на время потребовать заметно больше ресурсов, чем проект использует в спокойном состоянии.
Если приложение уже существует, лучший источник цифр — не статья в интернете, а собственные измерения. Запустите стек, создайте нагрузку, посмотрите статистику контейнеров и оставьте запас для пиков.
Универсальной формулы вида «один контейнер равен одному гигабайту RAM» не существует.
Количество vCPU тоже не определяется числом контейнеров
Небольшой API большую часть времени может ждать запросов и почти не использовать процессор. В соседнем контейнере worker обрабатывает изображения и способен занять все доступные ядра. Еще рядом база выполняет тяжелый запрос.
Формально контейнеров всего три, но характер нагрузки у каждого совершенно разный.
Docker умеет ограничивать доступ контейнера к CPU. Это помогает управлять конкуренцией между сервисами. Например, можно не позволить фоновой задаче полностью вытеснить веб-приложение во время пика.
Но прежде чем покупать больше vCPU, полезно выяснить, что именно загружает процессор. Иногда проблема решается ограничением количества одновременно работающих workers или изменением расписания тяжелых задач.
Для нового проекта особенно удобен VPS, ресурсы которого можно увеличить без сложной миграции. Угадать идеальную конфигурацию до появления реальной нагрузки значительно труднее, чем скорректировать ее после запуска.
Какой диск нужен контейнерам
Docker активно работает с образами, слоями, volumes и журналами, но основные требования к накопителю снова задает приложение.
Небольшой веб-сервис без большого объема локальных данных может почти не нагружать диск. База данных, система аналитики, поисковый движок или постоянная обработка файлов создают совсем другой профиль ввода-вывода.
NVMe для такого VPS выглядит логичным выбором. Особенно если на одной машине одновременно работают база, приложение и фоновые процессы. Но само слово NVMe в тарифе не гарантирует конкретной производительности виртуального диска.
Хостер может ограничивать IOPS и пропускную способность на уровне виртуальной инфраструктуры. Для дискоемкого проекта эти ограничения иногда важнее названия физического накопителя.
Есть и более бытовая проблема — свободное место. Старые образы, неиспользуемые volumes и разросшиеся журналы постепенно занимают диск. Если за ними никто не следит, большой накопитель просто позволит проблеме проявиться позже.
База данных должна пережить пересоздание контейнера
Контейнер удобно удалить и создать заново. Для приложения это нормальная операция. Для базы данных потеря файлов при таком действии была бы катастрофой.
Постоянные данные нужно хранить отдельно от изменяемого слоя контейнера, например в Docker volumes или другой подходящей системе хранения.
Но здесь появляется важное различие между постоянным хранилищем и резервной копией.
Volume на диске того же VPS позволяет данным пережить пересоздание контейнера. Он не защищает от потери самой виртуальной машины, повреждения файловой системы или ошибочного удаления данных.
Резервные копии критичных данных должны храниться отдельно от рабочего VPS. Если провайдер предлагает автоматические бэкапы или снапшоты, выясните, где они находятся и что именно можно восстановить.
Нужна ли специальная виртуализация
Для Docker удобнее полноценная виртуальная машина с современным Linux. В российском сегменте VPS часто используется KVM. Такая виртуализация дает гостевой системе собственное ядро и хорошо подходит для сценариев, где нужен обычный Linux-сервер с root-доступом.
С контейнерными типами VPS ситуация может зависеть от ограничений хостовой системы. Некоторые функции ядра и сетевые возможности контролируются провайдером.
Поэтому если Docker является основной задачей, до оплаты стоит проверить не только наличие root-доступа, но и прямое разрешение провайдера на контейнеризацию выбранного типа.
Готовый образ с Docker в панели удобен, но не обязателен. На поддерживаемой Linux-системе Docker Engine можно установить самостоятельно. Гораздо важнее, чтобы VPS не накладывал неожиданных ограничений на нужные возможности ядра и сети.
Сеть Docker может неожиданно открыть лишнее
В Compose очень легко опубликовать порт наружу. Для тестирования это удобно, но на рабочем сервере такая мелочь способна превратиться в проблему безопасности.
База данных, Redis и внутренние сервисы обычно не должны быть доступны всему интернету только потому, что разработчику однажды понадобилось подключиться к ним с ноутбука.
Для типичного веб-приложения наружу можно вывести reverse proxy, который принимает HTTP и HTTPS, а остальные контейнеры оставить во внутренней сети Docker.
При выборе VPS поэтому стоит смотреть и на сетевые возможности провайдера. Внешний firewall в панели позволяет дополнительно ограничить трафик еще до виртуальной машины. Приватная сеть пригодится, если позже база или другой компонент переедет на отдельный VPS.
Последнее особенно интересно для растущего проекта. Хороший сервер нужно оценивать не только по тому, что он умеет сегодня, но и по тому, насколько легко рядом с ним появится второй.
Нужна ли панель управления для Docker
Классическая хостинговая панель для Docker-сервера требуется далеко не всегда.
Если инфраструктура описана в Compose, конфигурация хранится в Git, а деплой автоматизирован, дополнительная панель с управлением PHP-сайтами, почтой и FTP может только расходовать ресурсы и усложнять систему.
Другое дело, если на одном VPS нужно одновременно обслуживать обычные сайты и контейнерные приложения. Тогда подходящая панель может упростить рутинное управление доменами, сертификатами и базами.
Важно заранее проверить, как конкретная панель работает с Docker. Не стоит вручную менять конфигурационные файлы, которыми она сама управляет, а затем удивляться, что изменения исчезли после обновления.
Если сервер создается исключительно как Docker host, чистая Linux-система часто оказывается самым понятным вариантом.
Когда Docker Compose на одном VPS вполне достаточно
Слово «контейнеры» иногда слишком быстро приводит владельца проекта к Kubernetes.
Для небольшого приложения это может быть огромным усложнением без практической пользы.
Если несколько сервисов спокойно помещаются на одной виртуальной машине, Docker Compose дает простой способ описать их конфигурацию, сети, volumes и зависимости. Один VPS легко резервировать, мониторить и переносить.
Проблема начинается не после появления какого-то магического десятого контейнера.
Она начинается, когда компоненты требуют независимого масштабирования. Например, веб-приложению не хватает CPU, база становится критичной, workers создают пики, а любое обслуживание единственного VPS останавливает весь сервис.
Тогда можно разделить систему. Базу вынести на отдельную машину, workers на другую, перед несколькими экземплярами приложения поставить балансировщик.
Именно на этом этапе облачная инфраструктура становится особенно удобной. Не потому, что Docker в облаке работает иначе, а потому что несколько виртуальных машин, сетей, дисков и дополнительных сервисов проще собирать в единую изменяемую архитектуру.
Что я бы проверила у хостера перед покупкой
Специальная надпись «VPS для Docker» сама по себе мало что дает. Часто за ней находится обычный виртуальный сервер с уже установленным Docker.
Полезнее проверить несколько вещей:
- какая виртуализация используется;
- можно ли установить нужный Linux и Docker;
- как увеличиваются vCPU и RAM;
- можно ли расширить диск без переезда;
- есть ли ограничения IOPS и пропускной способности диска;
- как устроены снапшоты и резервное копирование;
- есть ли внешний firewall;
- можно ли объединить несколько VPS приватной сетью;
- предоставляет ли провайдер API для автоматизации.
Не все пункты нужны небольшому проекту в первый день. Но возможность масштабировать сервер и добавить второй узел без перестройки всего окружения дает хороший запас на будущее.
Стоит посмотреть и на модель поддержки. Если VPS неуправляемый, специалисты провайдера могут отвечать за виртуальную машину и сеть, но не за ваш Docker, Compose и приложение. Если администрирование требуется, это лучше выяснить до возникновения первой аварии.
Как не переплатить за первый VPS
Самый надежный способ — перестать угадывать по количеству контейнеров.
Если проект можно запустить локально или в тестовой среде, измерьте его. Посмотрите память каждого сервиса, нагрузку CPU, размер постоянных данных и поведение под нагрузкой. Отдельно проверьте тяжелые операции, которые выполняются редко.
После этого выбирайте сервер с разумным запасом и возможностью увеличения ресурсов.
Для нового проекта без статистики такой подход тоже работает. Начните с конфигурации, которая покрывает ожидаемую нагрузку, включите мониторинг и наблюдайте. Если память постоянно близка к пределу, CPU упирается в максимум или дисковая очередь растет, у вас появится конкретная причина масштабирования.
Это намного полезнее, чем заранее покупать огромный VPS «на будущее».
Docker хорош как раз тем, что делает окружение воспроизводимым. Если сервер действительно станет мал, приложение не должно быть навсегда привязано к одной виртуальной машине. Подготовленный Compose, резервные копии и понятная конфигурация значительно упрощают переезд.
Поэтому хороший VPS для Docker — не тот, у которого больше всего ядер в карточке тарифа. Это сервер, ресурсов которого хватает вашему стеку сегодня и который не мешает проекту вырасти завтра.
