Loading...

Apprendre / Déploiement

Déployer une application multi-services avec Docker Compose

Vous avez un docker-compose.yml avec un service web, un worker et une base de données ? cdn.com.tr le transforme en container apps managées et en add-ons — prévisualisez le plan, puis appliquez-le en une seule commande. Aucun cluster à faire tourner, aucune base de données à surveiller.

8 min de lecture Intermédiaire Updated

Déployer une application multi-services avec Docker Compose

Ce dont vous avez besoin

Vous avez besoin d'une application décrite par un docker-compose.yml — généralement un service web, peut-être un worker en arrière-plan, et des services de support comme une base de données et Redis — ainsi que d'un compte cdn.com.tr. Vous n'exécuterez pas de cluster Kubernetes, ne gérerez pas de serveur de base de données et ne câblerez pas TLS à la main. cdn.com.tr lit votre fichier compose et associe chaque élément à une brique managée : les services applicatifs deviennent des container apps, et les services avec état comme Postgres, MySQL ou Redis deviennent des add-ons managés, sauvegardés et injectés dans vos apps sous forme de variables d'environnement.

Comment votre fichier compose est associé

L'idée est simple : tout ce qui sert du trafic ou exécute du code devient une container app, et tout ce qui stocke des données devient un add-on managé. Un service « web » devient une app avec un domaine ; un « worker » devient une app sans port public ; un « db » utilisant une image Postgres ou MySQL devient une base de données managée ; un service « redis » devient du Redis managé. Vos services continuent de communiquer entre eux par leur nom, et les informations de connexion des add-ons managés sont fournies automatiquement à vos apps — vous supprimez ainsi le conteneur de base de données auto-hébergé et risqué, et laissez la plateforme s'en charger.

Un exemple de fichier compose

Voici une petite application multi-services : une API web, un worker en arrière-plan, une base de données Postgres et Redis. Ajoutez-la à votre dépôt sous le nom docker-compose.yml.

docker-compose.yml

services:
  web:
    build: .
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: postgres://app:secret@db:5432/app
      REDIS_URL: redis://redis:6379
    depends_on: [db, redis]

  worker:
    build: .
    command: ["python", "worker.py"]
    depends_on: [db, redis]

  db:
    image: postgres:16
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: app

  redis:
    image: redis:7

Prévisualisez d'abord le plan

Avant de rien changer, demandez à cdn.com.tr ce qu'il créerait. La prévisualisation lit votre fichier compose et affiche le plan : quels services deviennent des container apps, lesquels deviennent des add-ons managés, et comment ils se connectent. Rien n'est encore créé — vous voyez simplement ce qui va se passer.

cdnctl — aperçu
cdnctl login
cdnctl accounts use <account_uuid>

cdnctl container compose preview --file docker-compose.yml
# web, worker  -> container apps
# db           -> base de données managée (postgres)
# redis        -> redis managé

Appliquez-le

Le plan vous convient ? Appliquez-le. cdn.com.tr crée les container apps et les add-ons, câble les chaînes de connexion dans vos apps, et démarre le tout. Vous pouvez aussi le faire depuis le panneau — importez le fichier compose, vérifiez le plan, et confirmez — mais une seule commande le garde dans votre CI ou un script.

cdnctl — appliquer
cdnctl container compose apply --file docker-compose.yml --yes

# ensuite, à tout moment :
cdnctl container apps list
cdnctl container apps logs --app <web_app_uuid> --tail 100

Domaine, HTTPS et l'edge

Pointez votre domaine vers l'app web et cdn.com.tr délivre et renouvelle le SSL automatiquement. Vos services tournent désormais comme des apps managées derrière l'edge du CDN, avec un WAF devant et les pics de trafic absorbés en périphérie ; la base de données et Redis sont managés et sauvegardés. Pour livrer une mise à jour, reconstruisez votre image et appliquez à nouveau — une mauvaise build laisse la version précédente continuer à servir. Vous obtenez un déploiement de production multi-services sans exploiter de cluster ni de base de données en dessous.

Bien adapté pour

Apps web + worker + file d'attente

Les applications avec un niveau web, des workers en arrière-plan et une base de données s'associent proprement à des apps plus des add-ons managés.

Reprendre une stack existante

Vous avez déjà un docker-compose.yml qui fonctionne ? Importez-le tel quel au lieu de reconstruire votre déploiement de zéro.

Prévisualiser puis appliquer les changements

La prévisualisation montre exactement ce qui va changer avant que rien ne s'exécute — sûr à utiliser depuis la CI ou un script.

FAQ déploiement Docker Compose

Est-ce que ça exécute docker-compose tel quel sur une VM ?

Non — cela convertit votre fichier compose en ressources managées : les services deviennent des container apps et les services avec état deviennent des add-ons managés. Cela signifie aucune VM à corriger et une base de données sauvegardée et opérée pour vous, tandis que votre app garde la même forme.

Que deviennent mes services de base de données et Redis ?

Un service Postgres, MySQL ou Redis est transformé en add-on managé. Le conteneur de votre fichier compose n'est pas exécuté tel quel ; l'add-on managé fournit à la place les informations de connexion à vos apps sous forme de variables d'environnement.

Puis-je voir ce qui va se passer avant d'appliquer ?

Oui. « cdnctl container compose preview » affiche le plan complet — quels services deviennent des apps, lesquels deviennent des add-ons, et comment ils se connectent — sans rien créer. N'appliquez que lorsque le plan vous convient.