Настоящий вопрос — не про цену
Сравнение счёта за VPS с подпиской на платформу отвечает не на тот вопрос. Ваш контейнер может запустить любой из вариантов; различается то, сколько вашего внимания он продолжит требовать после первого деплоя.
Контейнеру в продакшене нужны домен и сертификат, который сам продлевается, способ перезапуститься при падении, место, куда идут логи, сценарий обновления без простоя и база данных, которая бэкапится. Ничего из этого не входит в задачи Docker. Тот, кто всем этим занимается, и есть предмет вашего выбора — а честное сравнение учитывает стоимость ваших часов, а не только сервера.
Вариант 1 — VPS, которым управляете вы
Арендуйте виртуальную машину, установите Docker, запустите контейнер. Это самый прямой путь, и он действительно работает: полный root-доступ и никакой абстракции между вами и машиной.
А дальше начинается постоянная работа: обновления безопасности ОС, обратный прокси спереди, сертификаты, которые нужно продлевать, политика перезапуска на случай, когда контейнер упадёт в четыре утра, диск, забивающийся логами и образами, которые никто не подчистил, и бэкапы, которые вы настраиваете и — что критично — проверяете. Деплой — это ваш собственный скрипт, а нулевой простой вы строите сами.
Выбирайте этот вариант, когда вам нужен root, когда вы разбираетесь, как всё устроено, или когда вы уже держите серверы и ещё один погоды не сделает. Избегайте его, когда ваш продукт — это приложение, а не инфраструктура под ним.
Вариант 2 — Kubernetes
Kubernetes решает реальные задачи: множество сервисов, плавные выкатки, самовосстановление, автомасштабирование. Если вы эксплуатируете десятки сервисов силами команды, он окупает свою сложность.
Ниже этого масштаба соотношение переворачивается. Вы поддерживаете кластер, его обновления, его ingress, его сертификаты и его YAML ради того, чтобы запустить горстку контейнеров, — и кластер сам становится системой, требующей отдельной экспертизы. Управляемый Kubernetes снимает часть этого, но не концептуальную тяжесть.
Выбирайте его, когда ваш масштаб или ваша команда этого уже требуют. Не выбирайте его потому, что «так делают серьёзные компании»: серьёзность в том, чтобы соотнести инструмент с размером задачи.
Вариант 3 — управляемая контейнерная платформа
Здесь вы передаёте контейнер, и платформа его запускает: домен с автоматическим HTTPS, перезапуски, логи, выкатка с проверкой healthcheck, а также управляемые Postgres, Redis или S3-совместимое хранилище, подключаемые по мере необходимости.
На cdn.com.tr деплой запускает новый контейнер, дожидается, пока ваш путь healthcheck сообщит о готовности, затем переводит трафик и выводит из работы старый — так что сломанная сборка никогда не уронит сервис, потому что трафик просто остаётся на версии, которая по-прежнему работает. Перед всем этим стоит edge CDN с WAF и защитой от DDoS в комплекте.
Компромисс реален, и о нём стоит сказать прямо: нет root на хосте, нет установки пакетов на уровне ОС, а публичный доступ идёт по HTTP(S), а не через произвольные TCP-порты. Если вашему приложению нужно то, чего платформа не предоставляет, честный ответ — VPS.
Три пути внутрь — в зависимости от того, что у вас есть
Правильный путь зависит от того, откуда берётся ваш образ.
Если вы уже собираете образы и пушите их в реестр, используйте Container Apps: укажите ссылку на образ и порт — и он развернётся. В вашем пайплайне ничего больше не меняется.
Если вы хотите push-to-deploy из исходного кода, используйте GitHub Deploy. Шаг сборки он берёт на себя: ваш Dockerfile собирается в изолированном билдере и пушится в наш приватный реестр, так что собственный аккаунт в реестре не нужен. Пушите в свою ветку — и новая версия выкатывается за healthcheck.
Если ваше приложение состоит из нескольких сервисов, используйте Docker Compose Instant Deploy. Сервисы с секцией build: собираются из своего Dockerfile; сервисы, ссылающиеся на публичный image: (базы данных, кэши, очереди), подключаются как управляемые дополнения или приложения. Многоэтапные сборки, target: и build.args учитываются. Сначала посмотрите план, прежде чем что-либо будет создано, а затем примените его.
Посмотрите, во что превратится compose-файл, затем примените план
# see the plan first — nothing is created
cdnctl container compose preview --account <uuid> --file docker-compose.yml
# apply it when the plan looks right
cdnctl container compose apply --account <uuid> --file docker-compose.ymlЧто проверить, прежде чем решиться
Каким бы путём вы ни пошли, стоит задать одни и те же вопросы. Как проходит выкатка деплоя — уронит ли неудачная сборка сайт или трафик останется на последней рабочей версии? Куда идут логи и можно ли их читать без SSH? Что происходит с вашими данными: база данных управляемая и бэкапится или это контейнер на диске, за который отвечаете вы? Можете ли вы уйти — ваш образ переносимый или вас переписали под что-то проприетарное?
Последний вопрос люди чаще всего пропускают и потом жалеют. Docker-образ, собранный из вашего собственного Dockerfile, переносим по определению: он одинаково работает на VPS, в Kubernetes и на управляемой платформе. Сохранять это свойство — то, что делает ваш выбор обратимым.
Частые вопросы
Нужно ли мне собирать образ самому?
Только если вы этого хотите. Container Apps разворачивает готовый образ, который вы запушили в реестр. GitHub Deploy и Docker Compose Instant Deploy собирают его из вашего Dockerfile в изолированном билдере и пушат в наш приватный реестр, так что аккаунт в реестре вам не нужен.
Можно ли здесь запустить базу данных в контейнере?
Можно, но для всего, что вам важно, используйте управляемые дополнения Postgres или Redis — их эксплуатируют и бэкапят за вас. База данных в обычном контейнере — это диск, за который отвечаете лично вы, и именно это потом больнее всего.
А если моему приложению нужен SSH или свой системный пакет?
Системные пакеты кладите в свой Dockerfile — образы ровно для этого и нужны. Если вам нужен SSH на хост, установка пакетов на уровне ОС во время работы или публичные «сырые» TCP-порты, управляемая платформа не подходит, и честный ответ — VPS.
Управляемая платформа медленнее собственного сервера?
По своей природе нет, а на практике обычно получается быстрее, потому что перед ней кэширует глобальный edge. Сам контейнер работает на таком же оборудовании; вы теряете root-доступ, а не скорость.