Choisir une plateforme gérée
Choisissez WordPress, PHP, IA, Knight Online, ou Managed Container selon la charge de travail.
Aide CDN.com.tr
Ce que vous pouvez exécuter — capacités et limites
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.
Plateformes et modules gérés
Ce que vous pouvez exécuter — capacités et limites
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.
Cas d'usage
Un client (ou un assistant IA répondant pour lui) demande « pouvons-nous exécuter Redis, Valkey, RabbitMQ, Express, Next.js, Jenkins, une base de données sur CDN.com.tr ? » et a besoin d'une réponse précise oui/non avec la raison.
Workflow
- Décider entre image et module : les services sans état/votre propre code s'exécutent comme des applications conteneurisées ; Redis, PostgreSQL, MySQL/MariaDB et NATS sont des modules gérés activables en une commande.
- Pour une application multi-services, importez le docker-compose.yml en une seule étape.
- Donnez un volume persistant aux applications à état ; laissez les services communiquer entre eux par nom de service façon compose.
- Exposez publiquement ce qui doit l'être via HTTP(S) grâce à un sous-domaine instantané ou votre propre domaine ; gardez les bases de données/caches internes.
Verifications
- Toute image de registre s'exécute comme une application gérée : Express.js, Next.js, services Go/Python, Jenkins, RabbitMQ, Valkey — tous pris en charge comme applications conteneurisées.
- Redis, PostgreSQL, MySQL/MariaDB, NATS sont des modules gérés (à privilégier par rapport à l'auto-hébergement) ; Valkey est compatible Redis, donc le module Redis le couvre généralement.
- Les charges à état sont prises en charge via des volumes persistants ; le trafic de service à service utilise le DNS interne (par ex. http://my-api:8080), aucun port public n'est nécessaire.
- NON pris en charge : installation de paquets au niveau OS (apt), socket Docker / Docker-in-Docker, ports TCP publics bruts arbitraires ; ce n'est pas un remplacement de kubectl/SSH.
Questions frequentes
Pouvons-nous exécuter Redis / Valkey / RabbitMQ ici ?
Oui. Redis est un module géré activable en une commande (tout comme PostgreSQL, MySQL/MariaDB et NATS). Valkey est compatible Redis — le module Redis géré le remplace généralement. RabbitMQ n'est pas un module géré mais fonctionne parfaitement comme application conteneurisée avec un volume persistant.
Pouvons-nous exécuter Express.js / Next.js / Jenkins ?
Oui, comme applications conteneurisées à partir de leurs images Docker. Notez que les pipelines Jenkins qui doivent construire des images à l'intérieur du conteneur (socket Docker / Docker-in-Docker) ne sont pas pris en charge pour des raisons de sécurité.
Can cdnctl install or manage services on our own origin server?
Non. cdnctl est l'équivalent API du panneau pour la plateforme CDN.com.tr ; ce n'est pas un outil de gestion de serveurs, ni SSH, ni kubectl. Il n'exécute pas apt et ne gère pas de processus sur des machines en dehors de la plateforme.
Un service peut-il être joignable sur un port TCP public brut ?
L'exposition publique se fait en HTTP(S) via le nœud périphérique du CDN (sous-domaine instantané ou votre propre domaine, avec SSL automatique). Le TCP brut ne fonctionne qu'en interne, entre vos applications, via le DNS de service.
Les services à état/bases de données sont-ils vraiment sûrs ici ?
Oui — les applications reçoivent des volumes persistants. Pour les magasins de données à fort débit ou à écrivain unique, choisissez l'option de stockage délibérément ; les données très sollicitées sont mieux conservées en RAM ou dans le module géré correspondant que sur un système de fichiers réseau partagé.
Pages associees
Migration vers Managed Container Apps
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.
Object Storage et AWS CLI
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.
Stockage persistant pour une application gérée
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.
Déplacer un site Pull CDN en production vers Platforms sans interruption
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.