デプロイを作成するときに、他のテンプレートまたはユーザーが使用できるように、構成またはテンプレートの主要なプロパティの公開が必要になる場合があります。たとえば、テンプレート内に作成されたデータベースの IP アドレスを公開することで、各ユーザーが自身のテンプレートを構成するときに、その IP を簡単に参照できるようになります。
ユーザーが呼び出すことができる Key-Value ペアのリストを定義するには、テンプレートまたは構成の outputs セクションを使用します。outputs セクションで、任意のキーを定義し、キーの値を参照、テンプレート プロパティ、環境変数に設定します。ユーザーは出力を使用して、テンプレートで作成されたリソースの主要な情報にアクセスできます。たとえば、データベースをホストするインスタンスの IP アドレスを参照する databaseIP という出力を宣言すると、ユーザーは同じデプロイメントの他のテンプレートでこの出力を参照できます。
始める前に
- このガイドのコマンドラインの例を使用する場合、gcloud コマンドライン ツールをインストールします。
- このガイドの API の例を使用する場合は、API アクセスを設定します。
- 基本的な構成の作成方法を理解しておきます。
例
出力を指定したサンプル テンプレートを以下に示します。
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
outputs セクションは、databaseIp と databasePort という 2 つのプロパティを宣言しています。databaseIp は、マスター リソースのネットワーク IP アドレスに変換される参照を使用しています。databasePort は静的な値です。別のテンプレートでは、mongodb.jinja をインポートし、そのテンプレートをタイプとして使用して、出力を呼び出すことができます。例:
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)
出力の宣言
outputs: セクションを resources: セクションと同じレベルで定義すれば、テンプレートまたは構成で出力の宣言を行うことができます。出力キーは、テンプレートまたは構成内で一意である必要があります。
outputs: セクションのサンプルを以下に示します。
...
outputs:
- name: databaseIp
value: $(ref.my-first-vm.networkInterfaces[0].accessConfigs[0].natIP)
- name: machineType
value: {{ properties['machineType'] }}
- name: databasePort
value: 88
完全なテンプレートでは、outputs は次のようになります。
次の値が出力可能です。
- 静的文字列
- プロパティへの参照
- テンプレート プロパティ
- 環境変数
テンプレートからの出力を使用する
テンプレートで定義されている出力を使用するには、その出力がタイプとして含まれているテンプレートをインポートして使用します。たとえば、template_with_outputs.jinja という名前のテンプレートに定義されている出力を使用する場合、そのテンプレートをインポートし、それを使用してリソースを作成します。
出力を呼び出すには、次のフォーマットを使用します。
$(ref.RESOURCE.OUTPUT)
RESOURCEは、テンプレートによって作成されるリソースの名前です。上記の例では、my-first-vmとなります。OUTPUTは、テンプレートで宣言されている出力です。上記の例では、databaseIpおよびdatabasePortとなります。これは、参照を宣言する場合と同じ構文です。たとえば$ref.template.property[0]のようにして、リストアイテムを参照することもできます。
構成をデプロイすると、Deployment Manager によって構成が展開されて、出力への参照が出力値で置き換えられます。
スキーマで出力を記述する
付属スキーマのあるテンプレートの場合は、出力プロパティを詳細に記述できます。Deployment Manager は、outputs セクションの情報に関して適用や検証を行いません。しかし、このセクションを使用して出力に関する詳細情報を提供することは、テンプレートを使用するユーザーのメリットになるため意味があります。
スキーマ ファイルで、テンプレートの出力と合致する outputs セクションを指定します。例:
...
outputs:
databaseIp:
description: Reference to ip address of your new cluster
type: string
databasePort:
description: Port to talk on
type: integer
ユーザーは、このスキーマ ファイルを参照することで、出力の使用方法とタイプについて理解できます。
最終出力値を検索する
出力を使用するテンプレートをデプロイした後、デプロイの構成レイアウトを表示することで、最終出力値を表示できます。最終出力値は、finalValue プロパティで示されます。ネストされたテンプレートの出力を含め、すべての出力値がこのフィールドに含まれます。例:
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
循環依存関係を回避する
複数のリソースが互いの出力に依存するテンプレートを作成する際は、注意が必要です。Deployment Manager はこの構造を拒否しませんが、出力が循環依存関係を生み出すと、正常にデプロイできなくなります。たとえば、次のスニペットの場合、Deployment Manager は受け入れますが、テンプレートのコンテンツが循環依存関係を引き起こすと、デプロイは失敗します。
resources:
- name: frontend
type: frontend.jinja
properties:
ip: $(ref.backend.ip)
- name: backend
type: backend.jinja
properties:
ip: $(ref.frontend.ip)
デプロイが失敗する循環依存関係の例として、frontend.jinja と backend.jinja が次のようになっているとします。
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)
両方のリソースが互いのリソースの IP 出力プロパティを使用している点に注意してください。
resources:
- name: frontend
type: frontend.jinja
properties:
ip: $(ref.backend.ip)
- name: backend
type: backend.jinja
properties:
ip: $(ref.frontend.ip)
どちらの IP 値も入力されることはありません。どちらのプロパティも互いのリソースの存在に依存しているため、循環依存関係が生まれています。テンプレートを完全に展開すると次のようになります。
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 はエラーを返します。
code: u'CONDITION_NOT_MET'
message: u'A dependency cycle was found amongst backend, frontend.'>]>
なお、このテンプレートは次のようにすれば機能します。
- frontend.jinja は vm-1 と vm-2 という 2 つの仮想マシン インスタンスを作成する。
- backend.jinja は vm-3 と vm-4 を作成する。
- vm-1 がその外部 IP を出力として公開し、vm-4 がその出力を使用する。
- vm-3 が外部 IP を出力として公開し、vm-2 がその出力を使用する。