Wenn Sie eine Bereitstellung erstellen, möchten Sie möglicherweise die wichtigsten Attribute Ihrer Konfigurationen oder Vorlagen für andere Vorlagen oder Nutzer zugänglich machen. Angenommen, Sie möchten die IP-Adresse einer Datenbank, die in einer Vorlage erstellt wurde, bereitstellen, damit Nutzer einfach auf die IP verweisen können, wenn sie ihre eigenen Vorlagen erstellen.
Sie können den Abschnitt Ausgabe in Ihrer Vorlage oder Konfiguration verwenden, um eine Liste von Schlüssel/Wert-Paaren zu definieren, die Nutzer aufrufen können. Im Abschnitt "outputs" definieren Sie beliebige Schlüssel und legen den Wert eines Schlüssels auf einen Verweis, ein Vorlagenattribut oder eine Umgebungsvariable fest.
Nutzer können die Ausgaben dann dazu verwenden, um auf die Schlüsselinformationen zu den von der Vorlage erstellten Ressourcen zuzugreifen. Sie können z. B. eine Ausgabe namens databaseIP
deklarieren, die auf die IP-Adresse einer Instanz verweist, die eine Datenbank hostet. Nutzer können dann in anderen Vorlagen in derselben Bereitstellung auf diese Ausgabe verweisen.
Hinweis
- Wenn Sie die Befehlszeilenbeispiele in dieser Anleitung verwenden möchten, installieren Sie das gcloud-Befehlszeilentool.
- Wenn Sie die API-Beispiele in dieser Anleitung verwenden möchten, richten Sie den API-Zugriff ein.
- Informieren Sie sich über das Erstellen einer grundlegenden Konfiguration.
Beispiel
Hier eine Beispielvorlage mit Ausgaben:
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
Im Abschnitt "outputs" werden zwei Attribute deklariert: databaseIp
und databasePort
.
databaseIp
nutzt einen Verweis, der zur Netzwerk-IP-Adresse der Master-Ressource aufgelöst wird, während databasePort
ein statischer Wert ist. In einer anderen Vorlage können Sie mongodb.jinja
importieren, die Vorlage als Typ verwenden und die Ausgaben aufrufen. Beispiel:
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)
Ausgabe deklarieren
Sie können eine Ausgabe entweder in einer Vorlage oder in einer Konfiguration deklarieren, indem Sie einen Abschnitt outputs:
auf der Ebene des Abschnitts resources:
definieren. Ausgabeschlüssel müssen innerhalb der Vorlage oder Konfiguration eindeutig sein.
Ein Beispielabschnitt outputs:
könnte beispielsweise so aussehen:
... outputs: - name: databaseIp value: $(ref.my-first-vm.networkInterfaces[0].accessConfigs[0].natIP) - name: machineType value: {{ properties['machineType'] }} - name: databasePort value: 88
So könnten die Ausgaben in einer vollständigen Vorlage aussehen:
Mögliche Ausgabewerte sind:
- Ein statischer String
- Ein Verweis auf ein Attribut
- Ein Vorlagenattribut
- Eine Umgebungsvariable
Ausgaben von Vorlagen verwenden
Wenn Sie eine Ausgabe verwenden möchten, die in einer Vorlage definiert wurde, importieren und verwenden Sie die Vorlage, die diese Ausgabe enthält, als Typ. Wenn Sie beispielsweise Ausgaben verwenden möchten, die in einer Vorlage namens template_with_outputs.jinja
definiert sind, muss diese importiert und zum Erstellen einer Ressource verwendet werden:
Verwenden Sie das folgende Format, um eine Ausgabe aufzurufen:
$(ref.RESOURCE.OUTPUT)
RESOURCE
ist der Name der Ressource, die von der Vorlage erstellt wurde. Im obigen Beispiel ist diesmy-first-vm
.OUTPUT
ist die in der Vorlage angegebene Ausgabe. Im obigen Beispiel wären diesdatabaseIp
unddatabasePort
. Die Syntax entspricht der zur Deklaration von Referenzen. Sie können auch auf Listenelemente verweisen, zum Beispiel$ref.template.property[0]
.
Wenn Sie die Konfiguration bereitstellen, wird von Deployment Manager die Konfiguration erweitert. Anschließend werden die Verweise auf Ausgaben durch die Ausgabewerte ersetzt.
Ausgaben in Schemas beschreiben
Für Vorlagen, die begleitende Schemas haben, können Sie Ausgabeeigenschaften detaillierter angeben. Deployment Manager verschafft sich keine Informationen in dem Bereich "Ausgaben" und validiert diese nicht, kann aber dabei helfen, dass dieser Bereich mehr Informationen über relevante Ausgaben liefert, damit Nutzer Ihre Vorlagen besser verwenden können.
Geben Sie in Ihrer Schemadatei einen Bereich "Ausgaben" an, der zur Ausgabe in Ihrer Vorlage passt. Beispiel:
...
outputs:
databaseIp:
description: Reference to ip address of your new cluster
type: string
databasePort:
description: Port to talk on
type: integer
Nutzer können auf Ihre Schemadatei verweisen, um die Nutzung und den Typ der Ausgaben zu verstehen.
Endgültige Ausgabewerte anzeigen
Nachdem Sie Ihre Vorlagen, die Ausgaben verwenden, bereitgestellt haben, sehen Sie sich die endgültigen Ausgabewerte an, indem Sie sich das Konfigurationslayout der Bereitstellung anzeigen lassen. Die endgültigen Ausgabewerte sind an dem Attribut finalValue
erkennbar. Alle Ausgabewerte sind in diesem Feld enthalten, einschließlich der Ausgabewerte von verschachtelten Vorlagen. Beispiel:
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
Zirkuläre Abhängigkeiten vermeiden
Seien Sie vorsichtig, wenn Sie Vorlagen erstellen, bei denen zwei oder mehr Ressourcen wechselseitig von Ausgaben der jeweils anderen abhängig sind. Deployment Manager verhindert diese Struktur nicht, aber wenn die Ausgaben eine zirkuläre Abhängigkeit verursachen, kann die Bereitstellung nicht erfolgreich implementiert werden. Beispielsweise wird das folgende Snippet von Deployment Manager akzeptiert, aber wenn die Inhalte der Vorlagen zirkuläre Abhängigkeiten verursachen, würde die Bereitstellung fehlschlagen:
resources:
- name: frontend
type: frontend.jinja
properties:
ip: $(ref.backend.ip)
- name: backend
type: backend.jinja
properties:
ip: $(ref.frontend.ip)
Als Beispiel einer zirkulären Abhängigkeit, bei der die Bereitstellung fehlschlägt, nehmen wir an, dass sowohl "frontend.jinja" und "backend.jinja" so aussehen:
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)
Denken Sie daran, dass beide Ressourcen das IP-Ausgabe-Attribut der jeweils anderen Ressource verwendet haben:
resources:
- name: frontend
type: frontend.jinja
properties:
ip: $(ref.backend.ip)
- name: backend
type: backend.jinja
properties:
ip: $(ref.frontend.ip)
Die IP-Werte können aber nicht ausgefüllt werden, da beide Attribute auf die Existenz der anderen Ressource angewiesen sind und somit eine zirkuläre Abhängigkeit besteht. Hier ist die gleiche vollständig expandierte Vorlage:
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 gibt einen Fehler zurück, wenn Sie versuchen, die Konfiguration auszuführen:
code: u'CONDITION_NOT_MET'
message: u'A dependency cycle was found amongst backend, frontend.'>]>
Die Vorlage würde jedoch funktionieren, wenn:
- "frontend.jinja" zwei VM-Instanzen, "vm-1" und "vm-2", erstellen würde.
- "backend.jinja" "vm-3" und "vm-4" erstellen würde.
- "vm-1" ihre externe IP als Ausgabe freigibt und "vm-4" diese Ausgabe verwendet.
- "vm-3" eine externe IP als Ausgabe freigibt und "vm-2" diese Ausgabe verwendet.
Weitere Informationen
- Bereitstellung erstellen
- Mehr über Vorlagen erfahren