Source Deploy : comment un simple dossier devient une app en production

Architecture : que se passe-t-il après cdnctl deploy

De votre côté, ni dépôt git ni registre de conteneurs. Le pipeline :

• cdnctl empaquette le dossier en tar.gz (128 Mo max) et l'envoie au panneau sous votre compte.
• Le panneau émet une URL de téléchargement signée valable 30 minutes — le seul moyen pour l'environnement de build de récupérer votre source.
• Un sandbox isolé (Kaniko dans un pod protégé par gVisor) récupère l'archive, la déballe et construit le Dockerfile. Les builds se terminent généralement en une minute environ.
• L'image est poussée dans l'espace de registre privé de votre compte (registry.cdn.com.tr/<compte>/<app>) — jamais vers un registre partagé ou public.
• L'app est créée ou mise à jour, exposée sur son sous-domaine avec SSL, puis déployée. cdnctl attend et affiche l'URL en ligne.

cdnctl.yaml : les champs qui comptent

cdnctl init écrit ce fichier ; vous l'éditez, cdnctl le lit à chaque déploiement.

• name — le nom de l'app ; aussi la graine du sous-domaine au premier déploiement.
• port — le port du conteneur sur lequel votre serveur écoute (toutes interfaces, pas localhost).
• healthcheck — le chemin HTTP sondé par la plateforme ; le déploiement attend qu'il passe.
• method — auto, source, git ou compose ; source est la voie par dossier décrite ici.
• Le manifeste lui-même est exclu du scan de cdnctl check : ses valeurs ne réduisent jamais au silence un avertissement sur votre code.

# cdnctl.yaml minimal
name: task-tracker
port: 3000
healthcheck: /health
method: source

Limites — les petites lignes honnêtes

• Archive source : 128 Mo max. Les projets Node tiennent largement une fois node_modules exclu (init écrit le .dockerignore).
• Durée de build : environ une minute pour des apps Node/Python typiques ; les builds natifs lourds prennent plus.
• Le modèle de Dockerfile couvre Node, Python, PHP et les sites statiques ; le reste demande un Dockerfile écrit à la main (deploy l'utilise tel quel).
• Le paiement reste dans le panneau : sans forfait plateforme, deploy s'arrête avec le lien d'achat et cdnctl init --wait reprend après paiement.

Dépannage : les pannes réellement rencontrées

Chaque ligne est une panne réelle issue d'exécutions en production, avec le correctif qui a fonctionné.

• Le conteneur boucle en crash avec ERR_DLOPEN_FAILED juste après le déploiement — l'image contient node_modules copié depuis votre machine (modules natifs compilés pour la mauvaise plateforme). Correctif : ajoutez node_modules au .dockerignore et laissez npm install tourner dans le build. cdnctl check le signale avant l'envoi.
• Build failed au premier déploiement — lisez le log de build affiché par cdnctl deploy ; après node_modules, la cause la plus fréquente est une dépendance présente en local mais absente de package.json/requirements.
• L'app apparaît stopped après un create — relancez cdnctl deploy (0.18.0+ déclenche le rollout lui-même ; les versions antérieures exigeaient un deploy explicite).
• Le site ne répond pas malgré un build réussi — le serveur écoute sur 127.0.0.1 ou sur un port différent de cdnctl.yaml. Écoutez sur 0.0.0.0 et le port déclaré ; check détecte le lien localhost.
• Le healthcheck ne passe jamais — le chemin ne renvoie pas 200 ou l'app met du temps à démarrer ; vérifiez d'abord le chemin en local.

Les commandes, de bout en bout

cdnctl init          # détecter le projet, écrire cdnctl.yaml + Dockerfile
cdnctl check         # pré-vol local : les erreurs bloquent, les avertissements informent
cdnctl deploy        # empaqueter → envoyer → build → URL en ligne
cdnctl container apps logs --app <app_uuid> --tail 100   # logs d'exécution
cdnctl deploy-token create --name "agent"   # token restreint pour agents IA