Quando crei un deployment, potresti voler esporre le proprietà della chiave delle tue configurazioni o modelli per altri modelli o utenti da utilizzare. Ad esempio, potresti voler esporre l'indirizzo IP di un database creato in un modello, in modo che gli utenti possano fare facilmente riferimento all'IP durante la configurazione dei propri modelli.
Puoi utilizzare la sezione outputs nel modello o nella configurazione per definire un elenco di coppie chiave-valore che gli utenti possono chiamare. Nella sezione degli output, puoi definire chiavi arbitrarie e impostare il valore delle chiavi su un riferimento, una proprietà modello o una variabile di ambiente.
Gli utenti possono utilizzare gli output per accedere alle informazioni delle chiavi sulle risorse create dal modello. Ad esempio, puoi dichiarare un output denominato databaseIP
che fa riferimento all'indirizzo IP di un'istanza che ospita un database e gli utenti possono fare riferimento all'output in altri modelli nello stesso deployment.
Prima di iniziare
- Se vuoi utilizzare gli esempi di riga di comando di questa guida, installa lo strumento a riga di comando "gcloud".
- Se vuoi utilizzare gli esempi di API riportati in questa guida, configura l'accesso API.
- Scopri come creare una configurazione di base.
Esempio
Ecco un esempio di modello con output:
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 sezione degli output dichiara due proprietà: databaseIp
e databasePort
.
databaseIp
utilizza un riferimento che si risolve nell'indirizzo IP di rete della risorsa master, mentre databasePort
è un valore statico. In un altro modello, puoi importare mongodb.jinja
, utilizzare il modello come tipo e chiamare gli output. Ad esempio:
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)
Dichiarazione di un output
Dichiara un output in un modello o in una configurazione definendo una sezione outputs:
allo stesso livello della sezione resources:
. Le chiavi di output
devono essere univoche all'interno del modello o della configurazione.
Ad esempio, una sezione outputs:
di esempio potrebbe avere il seguente aspetto:
... outputs: - name: databaseIp value: $(ref.my-first-vm.networkInterfaces[0].accessConfigs[0].natIP) - name: machineType value: {{ properties['machineType'] }} - name: databasePort value: 88
Ecco come potrebbero apparire gli output in un modello completo:
I valori di output possono essere:
- Una stringa statica
- Un riferimento a una proprietà
- Una proprietà modello
- Una variabile di ambiente.
Utilizzo degli output dei modelli
Per utilizzare un output definito in un modello, importa e utilizza il modello contenente l'output come tipo. Ad esempio, per utilizzare gli output definiti in un modello chiamato template_with_outputs.jinja
, devi importarlo e utilizzarlo per creare una risorsa:
Per chiamare un output, utilizza il seguente formato:
$(ref.RESOURCE.OUTPUT)
RESOURCE
è il nome della risorsa creata dal modello. Nell'esempio riportato sopra, èmy-first-vm
.OUTPUT
è l'output dichiarato nel modello. Nell'esempio precedente, sonodatabaseIp
edatabasePort
. È la stessa sintassi che usi per dichiarare i riferimenti. Puoi anche fare riferimento agli elementi dell'elenco, ad esempio:$ref.template.property[0]
.
Quando esegui il deployment della configurazione, Deployment Manager espande la configurazione, quindi sostituisce i riferimenti agli output con i valori di output.
Descrizione degli output negli schemi
Per i modelli con schemi associati, puoi descrivere le proprietà dell'output in modo più dettagliato. Deployment Manager non applica né convalida alcuna informazione nella sezione degli output, ma è potenzialmente utile utilizzare questa sezione per fornire ulteriori informazioni sugli output pertinenti, a vantaggio degli utenti che utilizzano i tuoi modelli.
Nel file dello schema, fornisci una sezione degli output che corrisponda all'output nel modello. Ad esempio:
...
outputs:
databaseIp:
description: Reference to ip address of your new cluster
type: string
databasePort:
description: Port to talk on
type: integer
Gli utenti possono fare riferimento al file di schema per comprendere l'utilizzo e il tipo degli output.
Ricerca dei valori di output finali
Dopo aver eseguito il deployment di modelli che utilizzano output, visualizza i valori dell'output finale visualizzando il layout di configurazione del deployment. I valori di output finali sono indicati dalla proprietà finalValue
. Tutti i valori di output sono inclusi in questo campo, inclusi quelli di modelli nidificati. Ad esempio:
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
Evita dipendenze circolari
Fai attenzione quando crei modelli in cui due o più risorse si basano su output l'uno dall'altro. Deployment Manager non impedisce questa struttura, ma se gli output hanno causato una dipendenza circolare, il deployment non verrà eseguito correttamente. Ad esempio, il seguente snippet viene accettato da Deployment Manager, ma se i contenuti dei modelli causano una dipendenza circolare, il deployment non riesce:
resources:
- name: frontend
type: frontend.jinja
properties:
ip: $(ref.backend.ip)
- name: backend
type: backend.jinja
properties:
ip: $(ref.frontend.ip)
Come esempio di dipendenza circolare in cui il deployment non riesce, supponiamo che frontend.jinja e backend.jinja avessero il seguente aspetto:
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)
Ricorda che entrambe le risorse hanno utilizzato la proprietà di output IP della risorsa opposta:
resources:
- name: frontend
type: frontend.jinja
properties:
ip: $(ref.backend.ip)
- name: backend
type: backend.jinja
properties:
ip: $(ref.frontend.ip)
Tuttavia, nessuno dei due valori IP può essere compilato perché entrambe le proprietà si basano sull'esistenza dell'altra risorsa, creando una dipendenza circolare. Ecco lo stesso modello completamente espanso:
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 restituisce un errore se provi a eseguire la configurazione:
code: u'CONDITION_NOT_MET'
message: u'A dependency cycle was found amongst backend, frontend.'>]>
Tuttavia, questo modello funziona se:
- frontend.jinja ha creato due istanze di macchina virtuale, vm-1 e vm-2.
- backend.jinja ha creato vm-3 e vm-4.
- vm-1 ha esposto il suo IP esterno come output e vm-4 lo ha utilizzato.
- vm-3 ha esposto un IP esterno come output, vm-2 ha usato quell'output.
Passaggi successivi
- Crea un deployment.
- Scopri di più sui modelli.