Un fichier Docker Compose ? Votre projet est en ligne en quelques secondes, en une seule commande sur cdn.com.tr. Voir comment Votre code sur GitHub ? Chaque push se déploie tout seul sur cdn.com.tr — connectez votre dépôt. Voir comment

Aide CDN.com.tr

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.

Plateformes et modules gérés

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.

Chemin dans le panneau

  1. Management Panel
  2. Platforms tab
  3. Managed Container Apps
  4. Open the app
  5. Persistent storage: on
  6. Mount path + size
  7. Save
  8. Deploy

Cas d'usage

Une application doit conserver des fichiers entre les déploiements — uploads, un fichier SQLite, des données Prometheus, un répertoire de cache — au lieu de les perdre à chaque redémarrage.

Workflow

  1. Dans le panneau : ouvrez l'application sous l'onglet Platforms → Managed Container Apps, activez le stockage persistant, définissez le chemin de montage (par défaut `/app/data`) et la taille en Go, enregistrez, puis déployez.
  2. Ou avec cdnctl à la création : `cdnctl container apps create … --persistent-mount-path /app/data --persistent-storage-gb 5` (indiquer un chemin de montage active le volume).
  3. Ou activez/agrandissez plus tard : `cdnctl container apps update --account <uuid> --app <app_uuid> --persistent-mount-path /app/data --persistent-storage-gb 10`, puis déployez.
  4. Amorcez les données initiales si nécessaire : `cdnctl container imports files --account <uuid> --app <app_uuid> --file data.tar.gz --target-path /app/data`.

Verifications

  • Un volume par application sur un seul chemin de montage ; pointez-le vers le répertoire où votre application écrit réellement (par défaut `/app/data`).
  • La taille ne peut que croître — un volume CephFS peut être agrandi (jusqu'à 100 Go) mais pas réduit ; choisissez une taille de départ raisonnable.
  • Les modifications de stockage prennent effet au prochain déploiement.
  • Les applications persistantes se déploient avec une stratégie Recreate : l'ancienne instance s'arrête avant que la nouvelle ne démarre, donc chaque déploiement entraîne une courte interruption (cela évite les blocages par verrou de fichier à écrivain unique).
  • Les images non-root peuvent écrire sur le volume (la plateforme définit automatiquement le fsGroup du pod).

Questions frequentes

Quand utiliser un volume persistant plutôt qu'un module géré ?

Utilisez un module géré (Redis, PostgreSQL, MySQL/MariaDB, NATS) pour les bases de données, caches et files d'attente — ils sont provisionnés et réglés pour vous. Utilisez un volume persistant pour les fichiers propres à votre application : uploads, ressources générées, un petit fichier SQLite, TSDB Prometheus, etc. Règle pratique : stockage de données structurées → module géré ; fichiers d'application → volume.

Le volume convient-il à une base de données à fort trafic ?

C'est du CephFS — un système de fichiers réseau répliqué, excellent pour la durabilité et l'accès partagé mais pas pour des données très sollicitées en E/S ou à écrivain unique. Pour les bases de données lourdes, utilisez le module géré ; pour les données très sollicitées, privilégiez la RAM. Un « magasin actif » sur un volume réseau devient un goulot d'étranglement.

Puis-je monter plus d'un volume, ou changer le chemin de montage plus tard ?

Un seul volume persistant par application sur un chemin de montage unique. Vous pouvez changer le chemin ou agrandir la taille, mais chaque modification nécessite un déploiement, et déplacer le chemin ne copie pas les anciennes données — planifiez le chemin de montage à l'avance.

Mes données survivent-elles à un redéploiement ou à une nouvelle version d'image ?

Oui. Le volume est indépendant de l'image du conteneur, donc les déploiements et mises à niveau d'image conservent les données. Il n'est supprimé que lorsque vous désactivez le stockage ou supprimez l'application.

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.

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.

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.