Concepts

Modèle de données

const, var, in : trois documents YAML aux règles de surcharge distinctes.

Le modèle de données d’un pack repose sur trois propriétés, chacune un document YAML avec ses propres règles de surcharge.

Les valeurs de in ne sont disponibles pour le pack que dans son usage via un environnement : elles n’existent pas lors de la création de l’image du pack.

Propriétés xbee réservées

const porte des métadonnées ajoutées automatiquement par xbee :

const:
  xbee:
    name:     # short name du pack
    commit:
    ref:
    origin:

var porte des valeurs par défaut réutilisées dans les templates :

var:
  xbee:
    app: /xbee/app
    user: default
    group: default
    templates: templates
    resources: resources
    install: /xbee/install
    instance: /xbee/instance

Ces éléments sous xbee restent des feuilles de var comme les autres : posés par défaut par xbee, ils suivent les mêmes règles de surcharge — un pack ou un projet peut les redéfinir, exactement comme var.node.version dans le tutoriel Pack Node.js.

Accès dans les templates

Le manifeste d’un pack interpole un modèle unique, résultat de la fusion de ses propriétés — jamais via un préfixe const., var. ou in. : on écrit {{ .node.version }}, pas {{ .var.node.version }}.

• Lors de la création de l’image (provision, build, deploy), ce modèle est la fusion de const et var.
• in vient enrichir ce même modèle en dehors du mécanisme de packaging, lorsque le pack applicatif est référencé par un hôte. Les valeurs peuvent être fournies dans host.<nom>.in ou dans l’objet pack, et sont disponibles pour les commandes ainsi que les actions configure, up et down.
• .xbee n’est pas un espace de noms au même niveau que const, var ou in : c’est la clé réservée xbee, présente à la fois sous const et sous var (voir plus haut), qui se retrouve fusionnée dans le modèle final sous .xbee. Tout ce qui est sous xbee est piloté par xbee : immuable sous const.xbee, surchargeable — par rapport aux valeurs par défaut posées par xbee — sous var.xbee.

Surcharger le modèle d’une dépendance

L’attribut var d’une dépendance surcharge le modèle du pack dépendant, via une map chemin → valeur :

# xbee-test dépend de tomcat, qui dépend de aws-jdk
dependency:
  origin: ./tomcat
  var:
    jdk.xbee.version: 21

La résolution des variables se fait le plus tard possible : dès que le ProductGraph (et, pour les containers, le ProductGraph système) sont construits, la résolution peut avoir lieu.

Secrets

Dans un environnement, xbee lit, s’il existe, un fichier xbee-secret.yaml qui vient surcharger le modèle de données de l’environnement. Ce fichier n’est volontairement pas placé sous gestion de configuration.