Loading...

CONTAINER APPS · РУКОВОДСТВО

Deploy from Git

Укажите нам git-репозиторий с файлом docker-compose.yml. Мы клонируем его, собираем образ каждого сервиса на своей инфраструктуре — вам не нужен container registry — и разворачиваем весь стек, связанный воедино, на управляемой контейнерной платформе CDN.com.tr. Это самый быстрый путь от «моего репозитория» до «работает в production».

Что вам нужно

Репозиторий с файлом docker-compose.yml. Сервисы с секцией build: собираются из их Dockerfile; сервисы, ссылающиеся на публичный image: (базы данных, кеши, очереди), используются как есть и подключаются как управляемые аддоны или приложения. Это всё — не нужен ни аккаунт registry, ни push образов, ни настройка CI.

1 · Откройте «Deploy from Git»

В своём аккаунте CDN откройте Platforms → Container Apps, разверните App creation и нажмите Deploy from Git (рядом с Import from Docker Compose).

Панель Deploy from Git с полями репозитория, ветки, пути к compose-файлу и токена доступа для приватного репозитория
Панель Deploy from Git: URL репозитория, ветка, путь к compose-файлу и — для приватных репозиториев — поле токена доступа «только для записи» с рекомендациями по минимальным привилегиям.

2 · Укажите ваш репозиторий

  • URL репозитория — адрес клонирования https://, напр. https://github.com/your-org/your-app.git.
  • Ветка — ветка для деплоя (по умолчанию main).
  • Compose-файл — путь к compose-файлу внутри репозитория (по умолчанию docker-compose.yml). Build-контексты разрешаются относительно этого файла, так что compose, хранящийся в подпапке, тоже работает нормально.

3 · Приватные репозитории и доступ

GitHub (рекомендуется): нажмите «Connect GitHub». Установка GitHub App в один клик позволяет выбирать репозитории из выпадающего списка — не нужно создавать, копировать или ротировать токены, а также это обеспечивает работу веб-хуков авто-деплоя (шаг 5). Вы сами выбираете, какие репозитории увидит приложение, и можете отозвать доступ на GitHub в любой момент.

В качестве альтернативы — или для GitLab — отметьте This is a private repository и вставьте токен доступа. Дайте ему минимально необходимый доступ:

  • GitHubfine-grained Personal Access Token, ограниченный этим одним репозиторием, с правом Contents: Read-only.
  • GitLab — токен проекта или личный токен доступа с областью read_repository.

Вставленный токен используется только для клонирования вашего репозитория во время сборки. Он хранится в режиме «только для записи» на протяжении сборки и никогда не отображается обратно и не используется повторно — вы можете отозвать его в любой момент.

4 · Build & deploy

Нажмите Build & deploy. Индикатор прогресса в реальном времени показывает каждый шаг:

  • Reading compose — мы клонируем ваш репозиторий и разбираем compose-файл.
  • Building <service> — образ каждого сервиса с build: собирается из его Dockerfile в изолированной среде сборки и отправляется в наш приватный registry.
  • Deploying — каждый сервис становится container app, связанным с остальными по имени сервиса (в точности как в docker-compose), с подключёнными базами данных/кешами.

По завершении веб-сервисы автоматически публикуются на мгновенном субдомене <uid>.cdn.com.tr (собственный домен можно подключить в любой момент) — откройте Your apps, чтобы увидеть их работающими.

5 · Оставайтесь подключёнными — авто-деплой и конвейер развёртывания

Перед деплоем отметьте «Keep connected — auto-deploy on every push to this branch». С этого момента каждый push в ветку автоматически пересобирает и передеплоивает — и на Container Apps появляется карточка Deployment pipeline:

  • Включив Enable staging на карточке, push будет деплоить тестовую копию Staging (на собственном тестовом URL) вместо production — production изменится только по нажатию Promote, с откатом в один клик.
  • Это рекомендуемый способ работы с подключённым репозиторием: больше никаких «каждый коммит передеплоивает production».

Полное описание: Deployment pipeline — push → Staging, Promote → Production.

Как это работает (и почему это безопасно)

  • Мы собираем ваши образы из ваших Dockerfile — аккаунт registry не нужен. Поддерживаются multi-stage сборки, target: и build.args.
  • Изолированные сборка и выполнение. И сборка, и запущенные контейнеры выполняются в защищённой песочнице gVisor, изолированной от других клиентов и от хоста.
  • Service discovery — приложения в вашем аккаунте обращаются друг к другу по имени сервиса, точно как в compose. Базы данных, Redis и NATS предоставляются как управляемые аддоны.
  • Публикуйте безопасно. Сочетайте это с Blue/Green preprod, чтобы протестировать копию на собственном URL перед выводом в прод.