Aide CDN.com.tr
Exécutez vos services d'origine sur cdn.com.tr Platforms pendant que votre site continue de servir via Pull CDN : activez les applications en parallèle de votre diffusion actuelle, construisez et validez tout sur des sous-domaines ca-*, puis basculez le domaine principal uniquement lorsque vous êtes prêt — totalement réversible.
Plateformes et modules gérés
Exécutez vos services d'origine sur cdn.com.tr Platforms pendant que votre site continue de servir via Pull CDN : activez les applications en parallèle de votre diffusion actuelle, construisez et validez tout sur des sous-domaines ca-*, puis basculez le domaine principal uniquement lorsque vous êtes prêt — totalement réversible.
Sur l'onglet Platforms d'un compte Pull CDN (ou Push CDN), cliquez sur « Enable apps alongside current delivery ». C'est additif : votre domaine principal continue de servir en production et n'est pas redéployé.
Une fois les applications activées, vous les construisez sur des sous-domaines ca-*. Quand tout est validé, l'action distincte « Cut over main domain to app » déplace le domaine principal — votre ancienne origine reste joignable pour permettre un retour en arrière.
Un site est en production sur Pull CDN (sa propre origine) et le propriétaire souhaite déplacer toute la pile (web, API, workers, Redis, file d'attente, etc.) vers la plateforme sans coupure.
Non. Activer Managed Container Apps en parallèle de Pull CDN est additif — cela ne change jamais la diffusion de votre domaine principal. Votre site continue de servir depuis son origine actuelle pendant tout ce temps ; seule l'étape explicite de basculement change la diffusion.
Chaque application est exposée sur son propre sous-domaine ca-*.cdn.com.tr (et joignable en interne par nom de service). Validez toute la pile à cet endroit. Le domaine principal ne bouge qu'au moment du basculement.
Oui. Gardez l'ancienne origine active ; si quelque chose ne va pas après le basculement, repointez le domaine principal vers elle. Ne mettez hors service l'ancienne origine que lorsque vous êtes confiant.
Tous, en tant qu'images de conteneur ou services compose. Utilisez les modules gérés pour Redis/PostgreSQL/MySQL/NATS. RabbitMQ et Valkey s'exécutent comme applications conteneurisées (Valkey est compatible Redis, donc le module Redis le remplace souvent). Jenkins s'exécute comme une application mais ne peut pas construire d'images à l'intérieur du conteneur (pas de socket Docker / Docker-in-Docker).
Exécuter plusieurs applications + points de terminaison nécessite un forfait Enterprise. Vérifiez vos droits avant d'importer un fichier compose volumineux.
Choisissez WordPress, PHP, IA, Knight Online, ou Managed Container selon la charge de travail.
Créez une application conteneurisée, un identifiant de registre, des variables d'environnement/secrets, des importations, des tâches, un déploiement, un statut et des journaux depuis les surfaces client.
Créez des buckets, faites tourner les clés d'accès, liez des buckets à des applications, et vérifiez avec le point de terminaison compatible S3.
Une plateforme conteneurisée gérée (Kubernetes en dessous), pas une VM ou un serveur shell : vous apportez des images de conteneur ou un docker-compose.yml et la plateforme les exécute, avec des modules gérés Redis/PostgreSQL/MySQL/NATS, des volumes persistants, un DNS de service interne, et une exposition HTTP(S) via le nœud périphérique du CDN.
Donnez à une application conteneurisée un volume persistant pour que ses données survivent aux redémarrages et redéploiements : activez le stockage, définissez le chemin de montage dans le conteneur et la taille. Un volume par application, monté sur un chemin, sur CephFS.