Concepts

Provider interne Docker

Créer des environnements locaux multi-hôtes sans provider externe.

Docker est le provider interne et par défaut de xbee. Lorsqu’un xbee-env.yaml ne contient pas de bloc provider, xbee matérialise chaque hôte sous forme de container local. Aucun plugin xbee-<provider>, compte cloud ou configuration d’infrastructure supplémentaire n’est nécessaire.

default:
  host:
    system: ubuntu:24.04
    net: application

host:
  frontend:
    pack: ./frontend
  backend:
    pack: ./backend
  database:
    pack: ./database

xbee up       # construit les images et démarre/configure les hôtes
xbee enter backend
xbee down     # exécute les actions down
xbee delete   # supprime les containers de l'environnement

Cette boucle locale utilise le même modèle que les environnements VM. Pour passer au cloud, on ajoute un bloc provider et ses paramètres sans réécrire les packs ni leurs actions.

Ce que le provider crée

Pour chaque environnement, xbee :

1. résout le graphe des packs système, applicatifs et de leurs dépendances ;
2. construit ou réutilise les images OCI nécessaires ;
3. exécute le conteneur d’initialisation éphémère, lorsqu’un bloc init est déclaré ;
4. crée les réseaux Docker déclarés par net ;
5. démarre un container par instance d’hôte ;
6. monte le projet, les binds et les volumes persistants nécessaires ;
7. exécute configure, up, down, les commandes de pack et les opérations dans le bon container.

Un hôte avec count: 3 produit trois instances adressables séparément. Les directives d’environnement permettent de les exécuter en série ou en parallèle comme des VM.

Configuration minimale

L’absence de provider est intentionnelle :

default:
  host:
    system: ubuntu:24.04

host:
  app:
    pack: ./app

Le système définit la base du container. Le pack applicatif apporte son modèle, ses dépendances et son cycle de vie. xbee up construit l’image finale puis lance l’hôte app localement.

Pour publier un port, utilisez la propriété port de l’hôte :

host:
  app:
    pack: ./app
    port: 8080:8080

Les ports peuvent aussi provenir du pack système avec expose-ports: true.

Xbee et Docker Compose

Xbee et Docker Compose répondent tous les deux au besoin de décrire et démarrer une application locale composée de plusieurs containers. Ils ne placent cependant pas l’abstraction au même endroit.

Pour une application exclusivement Docker, déjà structurée autour de Dockerfiles et de l’écosystème Compose, Docker Compose reste souvent le choix le plus direct. Xbee devient particulièrement intéressant lorsque :

• les mêmes briques doivent être réutilisées entre plusieurs environnements ;
• le provisioning dépasse le simple démarrage d’une image ;
• l’ordre, le parallélisme et les opérations multi-hôtes font partie du modèle ;
• le même environnement doit être validé localement puis déployé sur des VM ;
• les secrets doivent être récupérés à la demande et limités à chaque action.

Le provider Docker interne fait ainsi de xbee une alternative à Compose pour l’orchestration locale, tout en conservant une trajectoire vers les providers VM.

Développement local

Le répertoire du projet est monté dans le container, ce qui permet de modifier les sources sur l’hôte et de les utiliser immédiatement dans les commandes du pack. Les images et artefacts inchangés sont réutilisés depuis le cache.

# Démarrer tout l'environnement
xbee up

# Entrer dans un hôte précis
xbee enter frontend

# Exécuter une opération `operate.smoke-test` déclarée par l'environnement
xbee smoke-test

# Arrêter puis supprimer les containers
xbee down
xbee delete

Les commandes et actions restent décrites dans les packs : le poste de développement et les VM distantes exécutent donc la même logique plutôt que deux scripts divergents.

Passer du local à une VM

Cet environnement local :

default:
  host:
    system: ubuntu:24.04

host:
  app:
    pack: ./app

devient par exemple un environnement Scaleway en ajoutant le provider et les paramètres de l’hôte :

provider:
  name: scaleway
  region: fr-par
  projectId: <project-id>

default:
  host:
    system: ubuntu:24.04
    provider:
      instanceType: DEV1-S
      size: 20

host:
  app:
    pack: ./app

Les différences de runtime restent importantes : un container partage le noyau du poste Docker, tandis qu’une VM possède son propre système, son démarrage et ses volumes bloc. Validez donc sur le provider cible les comportements dépendant du noyau, de systemd, du stockage ou du réseau.

Limites et choix du provider

Choisissez le provider interne pour le développement, les tests d’intégration, les démonstrations et les environnements éphémères. Choisissez un provider VM lorsque vous avez besoin d’isolation machine, d’adresses cloud, de volumes bloc, d’images système ou de services d’infrastructure propres au fournisseur.

Les conteneurs et volumes créés par les versions actuelles portent des labels de propriété versionnés. Si xbee plan --state trouve une ancienne ressource homonyme sans ces labels, il la signale mais ne l’adopte et ne la supprime jamais automatiquement. Docker ne permettant pas de labelliser sûrement un conteneur existant, sauvegardez les données puis recréez le conteneur avec XBee. Pour un volume, migrez les données vers un nouveau volume labellisé avant toute suppression manuelle.

À lire ensuite : Environnements, Packs, Gestion des secrets et Cycle de vie et adoption.