От образа к публичному URL — без запуска серверов
Обычно вывести один контейнер в интернет означает развернуть хост, установить контейнерный runtime, подключить reverse proxy, получить сертификат и открыть порты файрвола — много неспецифичной работы ради одного API. Container Apps сворачивает всё это: вы даёте ему образ и порт, а он возвращает живой, защищённый HTTPS URL name.cdn.com.tr. Нет хоста для патчей, нет nginx для настройки и нет cron certbot для присмотра, потому что edge и TLS — часть платформы.
Healthcheck'и и раскатки без простоя
Деплой, который меняет контейнеры в момент запуска процесса, будет терять запросы, пока приложение ещё прогревается. Платформа использует ваш путь healthcheck, чтобы решить о готовности: при новом деплое она поднимает новый контейнер, ждёт прохождения healthcheck, переключает трафик и только потом выводит старую версию из эксплуатации. Это значит, что плохой образ, который так и не станет здоровым, не роняет сервис — предыдущая версия продолжает обслуживать трафик, пока новая не докажет свою работоспособность.
Окружение и секреты, сделанные правильно
Приложения по принципу twelve-factor читают конфигурацию из окружения, и контейнеры не исключение. Обычные настройки идут как переменные окружения; всё чувствительное — пароли баз данных, ключи API третьих сторон, секреты подписи — идёт как секрет, хранящийся зашифрованным и показываемый только по имени ключа, никогда по значению, после сохранения. Когда вы подключаете объектное хранилище или управляемую базу данных, их учётные данные внедряются тем же способом, так что ничего чувствительного не оказывается зашитым в образ или напечатанным в логе сборки.
Масштабирование и планы ресурсов, соответствующие реальной нагрузке
Вы выбираете план ресурсов (CPU и память) для каждого приложения и количество реплик, так что малонагруженный внутренний инструмент и публичный API не обязаны делить один и тот же объём ресурсов. Запуск нескольких реплик также даёт устойчивость: если один контейнер перезапускается, остальные продолжают обслуживать трафик. Поскольку раскатки проверяются по здоровью, увеличение масштаба или деплой новой версии не создаёт момента, когда приложение недоступно.
Edge-маршрут, Auto SSL и WAF перед вашим API
Каждое опубликованное контейнерное приложение доступно через edge cdn.com.tr, так что те же средства защиты, что получают ваши сайты, применяются и к вашим API. Auto SSL предоставляет и продлевает сертификат, WAF фильтрует вредоносный и сканерский трафик до того, как он попадёт в ваш сервис, а вы можете кэшировать безопасные GET-ответы на edge, снимая нагрузку чтения с контейнера. К вашему origin-контейнеру публика никогда не обращается напрямую — он получает только трафик, пересланный edge.
Панель или cdnctl, и это сочетается с вашим стеком
Всё, что можно сделать в панели — деплой, настройка env и секретов, масштабирование, чтение логов, перезапуск — также доступно через инструмент командной строки cdnctl, так что операции с контейнерами вписываются в скрипты и CI. Container Apps также является целью для Docker Compose Instant Deploy: compose-файл с несколькими сервисами превращается в несколько контейнерных приложений плюс управляемые дополнения за одно применение, что является самым быстрым способом поднять существующий стек, а не воссоздавать каждый сервис вручную.
Как развернуть, шаг за шагом
Создайте контейнерное приложение
В панели откройте Container Apps и создайте приложение из готового образа, например myorg/api:1.4 из Docker Hub или приватного реестра. Укажите порт контейнера, который слушает ваш сервис, чтобы платформа знала, куда направлять трафик.
Добавьте учётные данные приватного реестра (если нужно)
Если образ приватный, добавьте имя пользователя реестра и access token в разделе Container Apps → registry credentials один раз, чтобы платформа могла подтягивать его при каждом деплое. Для публичных образов этот шаг вообще пропускается.
Настройте окружение, секреты и healthcheck
Добавьте обычную конфигурацию как переменные окружения, а чувствительные значения — ключи API, пароли баз данных, токены — как секреты, которые хранятся зашифрованными и никогда не отображаются обратно. Определите путь healthcheck, чтобы платформа знала, когда новый контейнер действительно готов обслуживать трафик, а не просто запущен.
Деплойте и опубликуйте
Разверните приложение, затем откройте веб-порт, чтобы получить бесплатный URL name.cdn.com.tr с автоматическим HTTPS, или подключите собственный домен. Теперь трафик течёт через edge cdn.com.tr к вашему контейнеру, а SSL терминируется на edge.
Масштабируйте, смотрите логи и раскатывайте обновления
Задайте количество реплик и план ресурсов под ожидаемую нагрузку, транслируйте логи из панели для отладки и отправляйте новый тег образа, чтобы запустить раскатку без простоя. Предпочитаете терминал? cdnctl выполняет те же операции деплоя, масштабирования и логов из вашей оболочки.
Примеры сценариев
API на Node или Go деплоится из образа, публикуется на домене с Auto SSL и защищается WAF, а безопасные GET-ответы кэшируются на edge.
Отдельный сервис работает со своим собственным планом ресурсов и секретами, масштабируется до нескольких реплик ради устойчивости, не разделяя хост с остальной частью стека.
Продуктовая команда поднимает одноразовое окружение из тега образа на URL name.cdn.com.tr, а затем сносит его после завершения ревью.
Часто задаваемые вопросы
Собирает ли Container Apps мой образ из Dockerfile?
Нет — она деплоит готовые образы. Вы собираете и отправляете образ в реестр (Docker Hub или приватный) и даёте платформе ссылку на образ и порт. Если хотите push-to-deploy из исходников, сочетайте это с GitHub Deploy, который берёт на себя шаг сборки, или используйте Docker Compose Instant Deploy для многосервисного стека готовых образов.
Как здесь реально работает деплой без простоя?
При новом деплое платформа запускает новый контейнер, ждёт, пока ваш путь healthcheck сообщит о готовности, затем переключает на него трафик и выводит старый контейнер из эксплуатации. Если новый контейнер так и не проходит healthcheck, трафик остаётся на предыдущей версии, так что сломанная сборка не выводит сервис офлайн.
Видны ли мои секреты после сохранения?
Нет. Секреты хранятся зашифрованными и после сохранения отображаются только по имени ключа — значения не показываются обратно в панели, в логах или в предпросмотрах. Это позволяет ротировать секрет из панели без утечки в запись экрана, сессию поддержки или лог сборки.
Может ли мой контейнер обращаться к управляемой базе данных или объектному хранилищу?
Да. Вы привязываете управляемую базу данных, Redis или бакет объектного хранилища к приложению, а реквизиты подключения и ключи доступа внедряются как переменные окружения или секреты. Контейнер читает их из своего окружения, так что учётные данные никогда не приходится зашивать в образ.
Как запустить больше одного экземпляра и зачем это нужно?
Задайте количество реплик у приложения. Несколько реплик дают устойчивость — если одна перезапускается или нездорова, остальные продолжают обслуживать трафик — и позволяют приложению обрабатывать больше одновременного трафика. В сочетании с раскатками, проверяемыми по здоровью, увеличение масштаба не создаёт окна недоступности сервиса.
Могу ли я управлять контейнерными приложениями из командной строки и CI?
Да. Инструмент cdnctl выполняет те же операции деплоя, масштабирования, логов, перезапуска и настройки, что и панель, так что вы можете скриптовать операции с контейнерами или запускать их из пайплайна CI, вместо того чтобы кликать по интерфейсу. Также через него вы предпросматриваете и применяете импорт Docker Compose из терминала.