CONTAINER APPS · GUÍA

Deploy desde Git

Indíquenos un repositorio de git que contenga un docker-compose.yml. Lo clonamos, compilamos la imagen de cada servicio en nuestra propia infraestructura —no necesita un registro de contenedores— y desplegamos todo el stack, interconectado, en la plataforma de contenedores gestionados de CDN.com.tr. Es el camino más rápido de “mi repo” a “funcionando en producción”.

Qué necesita

Un repositorio con un docker-compose.yml. Los servicios con una sección build: se compilan a partir de su Dockerfile; los servicios que referencian una image: pública (bases de datos, cachés, colas) se usan tal cual y se conectan como complementos gestionados o apps. Eso es todo — sin cuenta de registro, sin subir imágenes, sin configurar CI.

1 · Abra “Deploy from Git”

En su cuenta CDN abra Platforms → Container Apps, expanda App creation y haga clic en Deploy from Git (junto a Import from Docker Compose).

El panel Deploy from Git con repositorio, branch, ruta del compose y un campo de token de acceso para repositorios privados — El panel Deploy from Git: URL del repositorio, branch, la ruta del archivo compose y —para repositorios privados— un campo de token de acceso de solo escritura con indicaciones de mínimo privilegio.

2 · Complete los datos de su repositorio

Repository URL — la URL de clonado https://, p. ej. https://github.com/su-org/su-app.git.
Branch — el branch a desplegar (por defecto main).
Compose file — ruta del archivo compose dentro del repositorio (por defecto docker-compose.yml). Los contextos de build se resuelven en relación a este archivo, así que un compose ubicado en una subcarpeta funciona sin problema.

3 · Repositorios privados y acceso

GitHub (recomendado): haga clic en “Connect GitHub”. Una instalación de la GitHub App con un clic le permite elegir repositorios de una lista desplegable — sin tokens que crear, copiar o rotar, y también habilita los webhooks de auto-deploy (paso 5). Usted elige exactamente qué repositorios puede ver la app, y puede revocarla en GitHub en cualquier momento.

Alternativamente —o para GitLab— marque This is a private repository y pegue un token de acceso. Otórguele el mínimo acceso necesario:

GitHub — un Personal Access Token fine-grained con alcance limitado a este único repositorio y permiso Contents: Read-only.
GitLab — un token de acceso de proyecto o personal con el alcance read_repository.

Un token pegado se usa únicamente para clonar su repositorio durante el build. Se almacena en modo solo escritura durante la duración del build y nunca se vuelve a mostrar ni se reutiliza — revóquelo cuando quiera.

4 · Build & deploy

Haga clic en Build & deploy. Una barra de progreso en vivo muestra cada paso:

Leyendo compose — clonamos su repositorio y analizamos el archivo compose.
Compilando <servicio> — la imagen de cada servicio con build: se compila desde su Dockerfile en un compilador aislado y se sube a nuestro registro privado.
Desplegando — cada servicio se convierte en una container app, interconectada con las demás por nombre de servicio (igual que en docker-compose), con bases de datos/cachés conectadas.

Al finalizar, los servicios de cara web se exponen automáticamente en un subdominio instantáneo <uid>.cdn.com.tr (puede vincular su propio dominio cuando quiera) — abra Your apps para verlos en ejecución.

5 · Manténgase conectado — auto-deploy y el flujo de despliegue

Marque “Keep connected — auto-deploy on every push to this branch” antes de desplegar. A partir de ahí, cada push a ese branch se recompila y redespliega automáticamente — y la tarjeta Flujo de despliegue aparece en Container Apps:

Active Enable staging en la tarjeta y los push despliegan una copia de prueba Staging (en su propia URL de prueba) en lugar de production — production solo cambia cuando hace clic en Promote, con reversión de un clic.
Esta es la forma recomendada de operar un repositorio conectado: se acabó eso de “cada commit redespliega production”.

Guía completa: Flujo de despliegue — push → Staging, Promote → Production.

Cómo funciona (y por qué es seguro)

Compilamos sus imágenes a partir de sus Dockerfiles — no necesita cuenta de registro. Se respetan los builds multietapa, target: y build.args.
Builds y runtime en sandbox. Tanto el build como sus contenedores en ejecución se ejecutan bajo un sandbox gVisor reforzado, aislado de otros inquilinos y del host.
Service discovery — las apps de su cuenta se comunican entre sí por nombre de servicio, igual que en compose. Las bases de datos, Redis y NATS se aprovisionan como complementos gestionados.
Publique con seguridad. Combine esto con Blue/Green preprod para probar una copia en su propia URL antes de ponerla en vivo.