Esposizione delle informazioni mediante output

Quando crei un deployment, potresti voler esporre le proprietà chiave delle tue configurazioni o dei tuoi modelli in modo che altri modelli o utenti possano utilizzarli. Ad esempio, potresti voler esporre l'indirizzo IP di un database creato in un modello in modo che gli utenti possano farvi riferimento facilmente quando configurano i 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 outputs, definisci chiavi arbitrarie e imposta il valore delle chiavi su un riferimento, una proprietà del modello, o una variabile di ambiente. Gli utenti possono utilizzare gli output per accedere alle informazioni chiave 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 a questo output in altri modelli nello stesso deployment.

Prima di iniziare

• Se vuoi utilizzare gli esempi di riga di comando in questa guida, installa lo strumento a riga di comando `gcloud`.
• Se vuoi utilizzare gli esempi di API in questa guida, configura l'accesso alle API.
• Scopri come creare una configurazione di base.

Esempio

Ecco un modello di esempio 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 outputs dichiara due proprietà: databaseIp e databasePort. databaseIp utilizza un riferimento che si risolve nell'indirizzo IP di rete della risorsa principale, 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)

Dichiarare 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 essere simile alla seguente:

...
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:

{#
Copyright 2016 Google Inc. All rights reserved.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
    http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
#}

resources:
- name: my-first-vm
  type: compute.v1.instance
  properties:
    zone: us-central1-a
    machineType: zones/us-central1-a/machineTypes/{{ properties['machineType'] }}
    disks:
    - deviceName: boot
      type: PERSISTENT
      boot: true
      autoDelete: true
      initializeParams:
        sourceImage: projects/debian-cloud/global/images/family/debian-11
    networkInterfaces:
    - network: global/networks/default
      accessConfigs:
      - name: External NAT
        type: ONE_TO_ONE_NAT

# Declare outputs here
outputs:
- name: databaseIp
  value: $(ref.my-first-vm.networkInterfaces[0].accessConfigs[0].natIP)
- name: machineType
  value: {{ properties['machineType'] }}
- name: databasePort
  value: 88

I valori di output possono essere:

• Una stringa statica
• Un riferimento a una proprietà
• Una proprietà del modello
• Una variabile di ambiente

Utilizzare gli 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 denominato template_with_outputs.jinja, è necessario importarlo e utilizzarlo per creare una risorsa:

# Copyright 2016 Google Inc. All rights reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
imports:
- path: template_with_outputs.jinja
  name: template.jinja

resources:
- name: my-first-vm
  type: template.jinja
  properties:
    machineType: n1-standard-1

outputs:
- name: databaseIp
  value: $(ref.my-first-vm.databaseIp)
- name: machineType
  value: $(ref.my-first-vm.machineType)
- name: databasePort
  value: $(ref.my-first-vm.databasePort)

Per chiamare un output, utilizza il seguente formato:

$(ref.RESOURCE.OUTPUT)

• RESOURCE è il nome della risorsa creata dal modello. Nell'esempio precedente, è my-first-vm.

• OUTPUT è l'output dichiarato nel modello. Nell'esempio precedente, sarebbero databaseIp e databasePort. Si tratta della stessa sintassi utilizzata per dichiarare i riferimenti. Puoi fare riferimento anche agli elementi dell'elenco, ad esempio: $ref.template.property[0].

Quando esegui il deployment della configurazione, Deployment Manager espande la configurazione e poi sostituisce i riferimenti agli output con i valori di output.

Descrivere gli output negli schemi

Per i modelli con schemi di accompagnamento, puoi descrivere le proprietà di output in modo più dettagliato. Deployment Manager non applica né convalida alcuna informazione nella sezione outputs, ma può essere utile utilizzare questa sezione per fornire maggiori informazioni sugli output pertinenti, a vantaggio degli utenti che utilizzano i tuoi modelli.

Nel file dello schema, fornisci una sezione outputs 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 dello schema per comprendere l'utilizzo e il tipo di output.

Cercare i valori di output finali

Dopo aver eseguito il deployment dei modelli che utilizzano gli output, visualizza i valori di output finali 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 i valori di output dei 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

Evitare le dipendenze circolari

Fai attenzione quando crei modelli in cui due o più risorse si basano sugli output l'una dell'altra. Deployment Manager non impedisce questa struttura, ma se gli output causano una dipendenza circolare, il deployment non verrà eseguito correttamente. Ad esempio, il seguente snippet è accettato da Deployment Manager, ma se i contenuti dei modelli causano una dipendenza circolare, il deployment non verrà eseguito:

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 viene eseguito, supponiamo che sia frontend.jinja sia backend.jinja siano simili a quanto segue:

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 utilizzavano 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 funzionerebbe se:

1. frontend.jinja ha creato due istanze di macchine virtuali, vm-1 e vm-2.
2. backend.jinja ha creato vm-3 e vm-4.
3. vm-1 ha esposto il suo IP esterno come output e vm-4 ha utilizzato questo output.
4. vm-3 ha esposto un IP esterno come output, vm-2 ha utilizzato questo output.

Passaggi successivi

• Creazione di un deployment.
• Scopri di più informazioni sui modelli.