CONTAINER APPS · GUIDE

Déployer depuis Git

Indiquez-nous un dépôt Git contenant un docker-compose.yml. Nous le clonons, générons l'image de chaque service sur notre propre infrastructure — vous n'avez pas besoin de registre de conteneurs — et déployons l'ensemble de la stack, interconnectée, sur la plateforme de conteneurs managés CDN.com.tr. C'est le chemin le plus rapide entre « mon dépôt » et « en production ».

Ce qu'il vous faut

Un dépôt contenant un docker-compose.yml — ou simplement un Dockerfile. Les services dotés d'une section build: sont générés à partir de leur Dockerfile ; les services qui référencent une image: publique (bases de données, caches, files d'attente) sont utilisés tels quels et connectés en tant qu'add-ons managés ou applications. Un dépôt sans fichier compose mais avec un Dockerfile (à la racine, ou dans le dossier du chemin compose indiqué) est déployé comme une seule application générée à partir de celui-ci, qui écoute sur le port de sa ligne EXPOSE (8080 s'il n'y en a pas). C'est tout — pas de compte de registre, pas de push d'image, pas de configuration CI.

1 · Ouvrir « Deploy from Git »

Dans votre compte CDN, ouvrez Platforms → Container Apps, développez App creation, puis cliquez sur Deploy from Git (à côté de Import from Docker Compose).

Le panneau Deploy from Git avec le dépôt, la branche, le chemin du compose et un champ de jeton d'accès pour dépôt privé — Le panneau Deploy from Git : URL du dépôt, branche, chemin du fichier compose et — pour les dépôts privés — un champ de jeton d'accès en écriture seule, avec des recommandations de moindre privilège.

2 · Renseignez votre dépôt

URL du dépôt — l'URL de clonage en https://, par ex. https://github.com/votre-org/votre-app.git.
Branche — la branche à déployer (par défaut main).
Fichier compose — chemin du fichier compose dans le dépôt (par défaut docker-compose.yml). Les contextes de build sont résolus par rapport à ce fichier ; un compose situé dans un sous-dossier fonctionne donc parfaitement. Pas de fichier compose à cet endroit ? Le Dockerfile de ce dossier, ou celui de la racine du dépôt, est utilisé à la place.

3 · Dépôts privés et accès

GitHub (recommandé) : cliquez sur « Connect GitHub ». L'installation en un clic de l'application GitHub vous permet de choisir vos dépôts dans une liste déroulante — aucun jeton à créer, copier ou faire tourner — et elle alimente aussi les webhooks de déploiement automatique (étape 5). Vous choisissez exactement les dépôts que l'application peut voir, et pouvez la révoquer sur GitHub à tout moment.

Autrement — ou pour GitLab — cochez This is a private repository et collez un jeton d'accès. Accordez-lui le minimum d'accès nécessaire :

GitHub — un Personal Access Token fine-grained, limité à ce seul dépôt, avec la permission Contents: Read-only.
GitLab — un jeton d'accès de projet ou personnel avec le scope read_repository.

Un jeton collé n'est utilisé que pour cloner votre dépôt pendant le build. Il est stocké en écriture seule le temps du build et n'est jamais réaffiché ni réutilisé — révoquez-le à tout moment.

4 · Générer et déployer

Cliquez sur Build & deploy. Une barre de progression en direct affiche chaque étape :

Lecture du compose — nous clonons votre dépôt et analysons le fichier compose.
Génération de <service> — l'image de chaque service build: est générée à partir de son Dockerfile dans un builder isolé (sandbox), puis poussée vers notre registre privé.
Déploiement — chaque service devient une container app, connectée aux autres par son nom de service (exactement comme avec docker-compose), avec les bases de données/caches rattachés.

Une fois terminé, les services orientés web sont exposés automatiquement sur un sous-domaine instantané <uid>.cdn.com.tr (vous pouvez rattacher votre propre domaine à tout moment) — ouvrez Your apps pour les voir en cours d'exécution.

5 · Restez connecté — déploiement automatique et pipeline de déploiement

Cochez « Keep connected — auto-deploy on every push to this branch » avant de déployer. Dès lors, chaque push sur la branche régénère et redéploie automatiquement — et la carte Deployment pipeline apparaît sur Container Apps :

Enable staging sur la carte, et les push déploient une copie de test Staging (sur sa propre URL de test) au lieu de la production — la production ne change que lorsque vous cliquez sur Promote, avec un rollback en un clic.
C'est la manière recommandée de faire fonctionner un dépôt connecté : fini le « chaque commit redéploie la production ».

Tutoriel complet : Deployment pipeline — push → Staging, Promote → Production.

Comment ça marche (et pourquoi c'est sûr)

Nous générons vos images à partir de vos Dockerfiles — aucun compte de registre requis. Les builds multi-étapes, target: et build.args sont respectés ; les ${VAR} de build.args sont remplis à partir des variables d'environnement de l'application, et toutes les variables NEXT_PUBLIC_* sont transmises au build : une application Next.js les reçoit au moment de next build. Les secrets ne sont jamais transmis à un build — les arguments de build restent dans l'image.
Builds et exécution sandboxés. Le build comme vos conteneurs en cours d'exécution s'exécutent dans un sandbox gVisor durci, isolé des autres locataires et de l'hôte.
Service discovery — les applications de votre compte se joignent entre elles par leur nom de service, exactement comme avec compose. Les bases de données, Redis et NATS sont provisionnés en tant qu'add-ons managés.
Publiez en toute sécurité. Combinez ceci avec Blue/Green preprod pour tester une copie sur sa propre URL avant de la mettre en ligne.