Lorsque vous créez un déploiement, vous pouvez exposer les propriétés clés de vos configurations ou modèles pour que d'autres modèles ou d'autres utilisateurs aient accès à ces informations. Par exemple, vous pouvez exposer l'adresse IP d'une base de données créée dans un modèle afin que les utilisateurs puissent facilement référencer cette adresse IP lorsqu'ils configurent leurs propres modèles.
Vous pouvez utiliser la section Résultats de votre modèle ou configuration pour définir la liste des paires valeur/clé que les utilisateurs peuvent appeler. Dans la section des résultats, créez des clés arbitraires et définissez la valeur de ces clés sur une référence, une propriété de modèle ou une variable d'environnement.
Les utilisateurs peuvent consulter les sorties pour accéder aux informations clés sur les ressources créées par le modèle. Par exemple, vous pouvez déclarer une sortie appelée databaseIP
qui référence l'adresse IP d'une instance hébergeant une base de données, ce qui permet aux utilisateurs de référencer cette sortie dans d'autres modèles du même déploiement.
Avant de commencer
- Si vous voulez vous servir des exemples de ligne de commande de ce guide, installez l'outil de ligne de commande gcloud.
- Si vous voulez utiliser les exemples d'API de ce guide, configurez l'accès aux API.
- Assurez-vous d'avoir bien compris comment créer une configuration de base.
Exemple
Voici un exemple de modèle avec des sorties :
mongodb.jinja {% set MASTER = env["name"] + "-" + env["deployment"] + "-mongodb" %} resources: - name: {{ MASTER }} type: instance ... outputs: - name: databaseIp value: $(ref.{{ MASTER }}.network[0].ip) # Treated as a string during expansion - name: databasePort value: 88
La section des sorties déclare deux propriétés : databaseIp
et databasePort
.
La propriété databaseIp
utilise une référence qui résout l'adresse IP réseau de la ressource principale, tandis que databasePort
est une valeur statique. Un autre modèle vous permet d'importer mongodb.jinja
, de l'utiliser en tant que type et d'appeler les sorties. Exemple :
imports:
- path: example/path/to/mongodb.jinja
name: mongodb.jinja
resources:
- name: my_mongo
type: mongodb.jinja
properties:
size: 100
- name: my_instance
type: compute.v1.instance
properties:
…
databaseIp: $(ref.my_mongo.databaseIp)
databasePort: $(ref.my_mongo.databasePort)
Déclarer une sortie
Vous pouvez déclarer une sortie dans un modèle ou une configuration en définissant une section outputs:
au même niveau que la section resources:
. Les clés de sortie doivent être uniques dans le modèle ou la configuration.
Une section outputs:
pourrait par exemple ressembler à ceci :
... outputs: - name: databaseIp value: $(ref.my-first-vm.networkInterfaces[0].accessConfigs[0].natIP) - name: machineType value: {{ properties['machineType'] }} - name: databasePort value: 88
Dans un modèle complet, la section outputs pourrait ressembler à cela :
Les valeurs de sortie peuvent se présenter sous différentes formes :
- Une chaîne statique
- Une référence à une propriété
- Une propriété de modèle
- Une variable d'environnement
Utiliser les sorties des modèles
Pour utiliser une sortie définie dans un modèle, importez le modèle contenant la sortie en tant que type. Par exemple, pour utiliser les sorties définies dans un modèle appelé template_with_outputs.jinja
, vous devez importer le modèle et créer une ressource sur cette base :
Pour appeler une sortie, utilisez le format suivant :
$(ref.RESOURCE.OUTPUT)
RESOURCE
correspond au nom de la ressource créée par le modèle. Dans l'exemple ci-dessus, il s'agit demy-first-vm
.OUTPUT
correspond à la sortie déclarée dans le modèle. Dans l'exemple ci-dessus, vous devriez utiliserdatabaseIp
etdatabasePort
. Il s'agit de la même syntaxe que vous utilisez pour déclarer des références. Vous pouvez également référencer des éléments de liste (par exemple,$ref.template.property[0]
)
Lorsque vous déployez la configuration, Deployment Manager développe la configuration, puis remplace les références aux sorties par les valeurs de sortie.
Décrire les résultats dans des schémas
Pour les modèles dotés de schémas d'accompagnement, vous pouvez décrire les propriétés de sortie plus en détail. Deployment Manager n'applique ni ne valide aucune information présente dans la section des sorties. Il peut toutefois être utile de fournir des informations complémentaires sur les sorties pertinentes dans cette section afin d'aider les utilisateurs qui s'appuient sur vos modèles.
Dans votre fichier de schéma, fournissez une section outputs correspondant à la sortie de votre modèle. Exemple :
...
outputs:
databaseIp:
description: Reference to ip address of your new cluster
type: string
databasePort:
description: Port to talk on
type: integer
Les utilisateurs peuvent se référer à votre fichier de schéma pour comprendre comment utiliser vos sorties et connaître leur type.
Rechercher les valeurs de sortie finales
Une fois que vous avez déployé des modèles utilisant des sorties, vous pouvez visualiser les valeurs de sortie finales en affichant le schéma de configuration du déploiement. Les valeurs de sortie finales sont indiquées par la propriété finalValue
. Toutes les valeurs de sortie sont incluses dans ce champ, y compris les valeurs de sortie des modèles imbriqués. Exemple :
layout: |
resources:
- name: vm_template
outputs:
- finalValue: 104.197.69.69
name: databaseIp
value: $(ref.vm-test.networkInterfaces[0].accessConfigs[0].natIP)
properties:
zone: us-central1-a
resources:
- name: datadisk-example-instance
type: compute.v1.disk
- name: vm-test
type: compute.v1.instance
type: vm_template.jinja
name: manifest-1455057116997
Éviter les dépendances circulaires
Soyez prudent lorsque vous créez des modèles dans lesquels deux ou plusieurs ressources s'appuient sur les sorties respectives des autres ressources. Deployment Manager n'empêche pas ce type de structure, mais si les sorties ont provoqué une dépendance circulaire, le déploiement ne s'effectuera pas correctement. Par exemple, le fragment de code suivant est accepté par Deployment Manager, mais si le contenu des modèles entraîne une dépendance circulaire, le déploiement échoue :
resources:
- name: frontend
type: frontend.jinja
properties:
ip: $(ref.backend.ip)
- name: backend
type: backend.jinja
properties:
ip: $(ref.frontend.ip)
Voyons maintenant un exemple de dépendance circulaire entraînant l'échec du déploiement. Supposons que frontend.jinja et backend.jinja ressemblent à ceci :
resources: - name: {{ env['name'] }} type: compute.v1.instance properties: zone: us-central1-f ... networkInterfaces: - network: global/networks/default accessConfigs: - name: External NAT type: ONE_TO_ONE_NAT metadata: items: - key: startup-script value: | #!/bin/bash export IP={{ properties["ip"] }} ... outputs: - name: ip value: $(ref.{{ env['name'] }}.networkInterfaces[0].accessConfigs[0].natIP)
Rappelez-vous que chacune des deux ressources a utilisé la propriété de sortie IP de l'autre ressource :
resources:
- name: frontend
type: frontend.jinja
properties:
ip: $(ref.backend.ip)
- name: backend
type: backend.jinja
properties:
ip: $(ref.frontend.ip)
Mais aucun champ de valeur IP ne peut être peuplé car chacune des deux propriétés dépend de l'existence de l'autre ressource, ce qui crée une dépendance circulaire. Voici le même modèle, entièrement développé :
resources:
- name: frontend
type: compute.v1.instance
properties:
zone: us-central1-f
...
networkInterfaces:
- network: global/networks/default
accessConfigs:
- name: External NAT
type: ONE_TO_ONE_NAT
metadata:
items:
- key: startup-script
value: |
#!/bin/bash
export IP=$(ref.backend.networkInterfaces[0].accessConfigs[0].natIP)
- name: backend
type: compute.v1.instance
properties:
zone: us-central1-f
...
networkInterfaces:
- network: global/networks/default
accessConfigs:
- name: External NAT
type: ONE_TO_ONE_NAT
metadata:
items:
- key: startup-script
value: |
#!/bin/bash
export IP=$(ref.frontend.networkInterfaces[0].accessConfigs[0].natIP)
Deployment Manager renvoie une erreur si vous essayez d'exécuter la configuration :
code: u'CONDITION_NOT_MET'
message: u'A dependency cycle was found amongst backend, frontend.'>]>
Notez toutefois que ce modèle pourrait fonctionner si :
- frontend.jinja créait deux instances de machines virtuelles, vm-1 et vm-2 ;
- backend.jinja créait vm-3 et vm-4 ;
- vm-1 exposait son adresse IP externe en tant que sortie et que vm-4 utilisait cette sortie ;
- vm-3 exposait une adresse IP externe en tant que sortie et que vm-2 utilisait cette sortie.
Étapes suivantes
- Créer un déploiement
- En savoir plus sur les modèles