Проблема: работающий образ — ещё не работающий сервис
Собрать API чисто в образ контейнера — лёгкие 20 процентов; довести его до продакшна — остальные 80. Традиционно это означает аренду VM, установку runtime, настройку reverse proxy, получение и продление TLS-сертификатов, открытие нужных портов, добавление менеджера процессов, чтобы приложение перезапускалось при падении, настройку сбора логов и охрану от атакующих, которые находят машину в течение часов после выхода в онлайн. Каждый из этих шагов — неспецифичная инфраструктурная работа, не имеющая ничего общего с реальной задачей вашего API, и каждый — место, где можно тонко ошибиться в безопасности или надёжности. Container Apps существует, чтобы свернуть весь этот чек-лист в несколько полей.
Как cdn.com.tr это решает: управляемые контейнеры за edge
Вы даёте платформе образ, порт и healthcheck, а она запускает контейнер, маршрутизирует к нему трафик через edge и поддерживает его живым. TLS обрабатывается Auto SSL, публичная точка входа — edge-маршрут, а не сырой контейнер, а WAF фильтрует вредоносный трафик до того, как он достигнет вашего сервиса. Конфигурация приходит как переменные окружения и секреты, внедряемые во время выполнения, масштабирование — это количество реплик, которое вы задаёте, а логи и статус видны в панели. В результате единственное, за что вы отвечаете — ваш образ приложения; вопросы сервера, прокси, сертификата и файрвола берёт на себя платформа.
Healthcheck'и: страховочная сетка деплоя
Healthcheck — это то, что превращает деплой из надежды в контролируемую операцию. Когда вы выкатываете новую версию, платформа запускает контейнер и опрашивает ваш эндпоинт здоровья, и только направляет трафик на новый экземпляр, когда этот эндпоинт сообщает о здоровье. Сборка, которая падает при загрузке, не может достучаться до своей базы данных или не имеет нужного секрета, проваливает проверку и не включается в ротацию, так что плохой деплой перехватывается на раскатке, а не пользователями. Именно поэтому healthcheck должен проверять реальную готовность — доступность зависимостей, наличие конфигурации, — а не просто безусловно возвращать 200. Осмысленный healthcheck — разница между безопасными передеплоями и тихими сбоями.
Окружение против секретов: конфигурация без утечек
API нужна конфигурация — URL баз данных, ключи третьих сторон, feature-флаги, — и неправильный способ её предоставить — зашить в образ или закоммитить в репозиторий, где она живёт вечно в слоях и истории. Платформа разделяет обычные переменные окружения и секреты: нечувствительные настройки идут как окружение, а пароли, токены и ключи API хранятся как секреты и внедряются во время выполнения по ключу, никогда не отображаясь обратно и не записываясь в вашу сборку. Это значит, что один и тот же образ может перемещаться между окружениями с разной конфигурацией, ваши учётные данные остаются вне контроля версий, а ротация секрета — действие платформы, а не аврал пересборки-и-передеплоя.
Масштабирование, логи и операционный цикл
Как только API живой, управление им — вопрос нескольких элементов управления, а не администрирования сервера. Вы выбираете план ресурсов и задаёте, сколько реплик запускать, масштабируясь вверх для запуска или всплеска трафика и обратно вниз после. Логи транслируются в панели, так что вы можете проследить запрос, отладить 500-ю ошибку или подтвердить, что деплой действительно применился, а статус показывает, здоров ли сервис и когда он в последний раз перезапускался. Каждый повторный деплой проходит через один и тот же контроль healthcheck, так что выпуск новой сборки — повторяемое, наблюдаемое действие: вы отправляете образ, наблюдаете прохождение проверки и подтверждаете в логах, никогда никуда не подключаясь по SSH.
Подключение хранилища и данных
Большинству API нужно где-то хранить состояние, и сервис чисто сочетается с остальной платформой для этого. Вы можете привязать бакет Object Storage к контейнеру как переменные окружения, чтобы он напрямую читал и писал медиа или документы, и можете подключить управляемую базу данных или Redis, чтобы у сервиса были персистентность и кэширование, тоже без того, чтобы вам их администрировать. Поскольку они подключаются через платформу и доставляются как внедрённая конфигурация, API остаётся stateless-образом, который можно свободно масштабировать и передеплоивать, пока его данные живут в управляемых сервисах рядом с ним.
Как настроить, шаг за шагом
Укажите на свой образ
В панели создайте Container App и укажите ссылку на ваш готовый образ (например myorg/api:1.4) из публичного или приватного реестра. Для приватных образов один раз добавьте учётные данные реестра, чтобы платформа могла его подтягивать. Задайте порт, который слушает ваш API, чтобы edge знал, куда направлять трафик.
Определите healthcheck
Задайте приложению путь healthcheck, например /health или /ready, который возвращает 200 только когда сервис действительно способен обслуживать запросы. Именно это использует платформа, чтобы решить, здоров ли новый деплой, прежде чем он получит трафик, поэтому убедитесь, что он проверяет то, что действительно важно, например доступность базы данных.
Настройте окружение и секреты
Добавьте нечувствительную конфигурацию как переменные окружения и чувствительные значения — ключи API, пароли баз данных, токены — как секреты, чтобы они внедрялись во время выполнения, а не зашивались в образ или коммитились в репозиторий. Значения секретов хранятся безопасно и указываются по ключу, а не выводятся обратно.
Задеплойте и следите за healthcheck
Запустите деплой из панели или через cdnctl. Контейнер запускается, healthcheck опрашивается, и сервис отмечается готовым — и только тогда включается в ротацию — как только проходит проверку, так что сломанная сборка молча не получает трафик.
Подключите домен с Auto SSL и WAF
Опубликуйте сервис, чтобы получить бесплатный URL name.cdn.com.tr с автоматическим HTTPS, или подключите собственный домен и дайте Auto SSL выпустить сертификат. Включите WAF, чтобы API находился за edge-фильтрацией, а origin-контейнер был доступен только через этот edge-маршрут.
Масштабируйте и наблюдайте
Скорректируйте план ресурсов и количество реплик под ожидаемую нагрузку и используйте логи и статус, чтобы наблюдать за деплоями, перезапусками и поведением во время выполнения. Повторные деплои проходят тот же путь, контролируемый healthcheck'ом, так что выпуск новой версии — рутинная, наблюдаемая операция.
Примеры сценариев
JSON API публикуется из своего образа за доменом с Auto SSL и WAF, давая фронтенду стабильный, защищённый HTTPS-эндпоинт без единого сервера для обслуживания.
Приёмник webhook, обработчик изображений или сервис аутентификации работает изолированно со своим собственным масштабированием и секретами, деплоится и передеплоивается независимо от всего остального.
Продуктовая команда поднимает контейнер из помеченного образа, чтобы получить URL для демо, которым можно поделиться по HTTPS, затем сносит его или передеплоивает по мере продвижения сборки.
Часто задаваемые вопросы
Собирает ли платформа мой образ, или я приношу свой?
Вы приносите готовый образ из реестра. Container Apps запускает и маршрутизирует предоставленный вами образ; если он приватный, вы один раз добавляете учётные данные реестра, чтобы платформа могла его подтянуть во время деплоя.
Что происходит, если мой новый деплой сломан?
Он проваливает healthcheck и не включается в ротацию, так что трафик продолжает идти на рабочую версию. Контейнер, который падает при загрузке или не может достучаться до своих зависимостей, перехватывается на раскатке, а не обслуживает ошибки вашим пользователям.
Как удержать ключи API и пароли баз данных вне моего кода?
Храните их как секреты, которые внедряются в контейнер во время выполнения по ключу и никогда не зашиваются в образ и не коммитятся в репозиторий. Нечувствительные настройки идут как обычные переменные окружения, так что один и тот же образ работает в разных окружениях с разной конфигурацией.
Может ли мой API обращаться к базе данных или бакету Object Storage?
Да. Вы можете привязать бакет Object Storage к контейнеру как переменные окружения и подключить управляемую базу данных или Redis, так что у сервиса есть хранилище, персистентность и кэширование, при этом он остаётся stateless, передеплоиваемым образом.
Как обработать всплеск трафика?
Увеличьте количество реплик и, если нужно, план ресурсов приложения. Поскольку трафик входит через edge, а контейнеры находятся за ним, вы масштабируете количество экземпляров под нагрузку и уменьшаете масштаб после.
Могу ли я деплоить из командной строки вместо панели?
Да. cdnctl выполняет те же операции с контейнерами из вашего терминала — деплой, повторный деплой, масштабирование и инспекцию, — так что вы можете скриптовать деплои или запускать их из CI, получая то же поведение, контролируемое healthcheck'ом, что и в панели.