如何从Deployment Manager获取特定部署会话的实例主机名、IP及Jinja相关操作

我来一步步帮你解决这两个问题，结合Deployment Manager的特性和实践方案来梳理：

1. 获取特定部署会话下实例的主机名和IP地址 #

快速方式：用gcloud命令直接提取 #

如果只是临时查询，gcloud命令可以直接过滤出你需要的信息：

# 获取所有实例的主机名和内网IP
gcloud deployment-manager deployments describe YOUR_DEPLOYMENT_NAME --format="value(targets.instances[].properties.hostname, targets.instances[].properties.networkInterfaces[0].networkIP)"

# 更易读的YAML格式输出
gcloud deployment-manager deployments describe YOUR_DEPLOYMENT_NAME --format=yaml | grep -A3 -B1 "hostname\|networkIP"

持久化方案：通过Jinja模板捕获并导出到文件 #

你可以在Jinja模板中定义输出变量，把实例的关键信息暴露出来，部署完成后再导出到本地文件。

比如在你的实例模板（centos-instances.jinja）中添加输出配置：

resources:
{% for i in range(4) %}
- name: centos-instance-{{ i }}
  type: compute.v1.instance
  properties:
    zone: us-central1-a
    machineType: n1-standard-1
    hostname: centos-node-{{ i }}
    networkInterfaces:
    - network: projects/YOUR_PROJECT_ID/global/networks/default
      accessConfigs:
      - name: External NAT
        type: ONE_TO_ONE_NAT
    # 其他实例配置（比如启动盘、启动脚本）...
{% endfor %}

# 定义输出变量，捕获所有实例的主机名和IP
outputs:
- name: all_hostnames
  value: "{{ [resource.properties.hostname for resource in resources if resource.type == 'compute.v1.instance'] }}"
- name: internal_ips
  value: "{{ [resource.properties.networkInterfaces[0].networkIP for resource in resources if resource.type == 'compute.v1.instance'] }}"
- name: external_ips
  value: "{{ [resource.properties.networkInterfaces[0].accessConfigs[0].natIP for resource in resources if resource.type == 'compute.v1.instance'] }}"

部署完成后，用以下命令把输出导出到文件：

# 保存主机名到文件
gcloud deployment-manager deployments describe YOUR_DEPLOYMENT_NAME --format="value(outputs.all_hostnames)" > hostnames.txt

# 保存IP信息为JSON格式（方便后续脚本处理）
gcloud deployment-manager deployments describe YOUR_DEPLOYMENT_NAME --format=json | jq '.outputs' > instance-info.json

2. Jinja模板保存操作与Deployment Manager后置脚本支持 #

Jinja模板能直接保存文件吗？ #

Jinja模板的核心作用是生成Deployment Manager的资源配置文件（YAML/JSON），它本身不能直接在本地或实例上生成文件。不过结合上面的输出变量+gcloud导出，就能实现把实例信息保存到本地文件的需求，这是最常用的实践方案。

Deployment Manager的"后置脚本"替代方案 #

DM本身没有原生的"部署完成后在控制端执行脚本"的功能，但有几种方式可以实现部署后配置实例、启动服务的需求，解决你提到的启动脚本局限性：

方案一：增强启动脚本（跨实例信息同步）

如果启动脚本无法满足需求，通常是因为需要依赖其他实例的信息。你可以让实例从DM的输出中拉取其他节点的信息，再完成配置：

#!/bin/bash
# 安装依赖工具
yum install -y curl jq google-cloud-sdk

# 从元数据服务器获取当前部署名称和项目ID
DEPLOYMENT_NAME=$(curl -s http://metadata.google.internal/computeMetadata/v1/instance/attributes/deployment-name -H "Metadata-Flavor: Google")
PROJECT_ID=$(curl -s http://metadata.google.internal/computeMetadata/v1/project/project-id -H "Metadata-Flavor: Google")

# 获取所有实例的内网IP（需要实例的服务账号有DM查看权限）
PEER_IPS=$(gcloud deployment-manager deployments describe $DEPLOYMENT_NAME --project $PROJECT_ID --format="value(outputs.internal_ips)")

# 生成服务配置文件
echo "peers: $PEER_IPS" > /etc/my-service/config.conf

# 安装并启动服务
yum install -y my-service
systemctl enable --now my-service

注意：要给实例的服务账号添加roles/deploymentmanager.viewer权限，这样实例才能调用gcloud命令获取部署信息。

方案二：使用自定义类型（Custom Type）执行部署后操作

你可以创建一个Python自定义类型，让DM在所有实例部署完成后，远程执行配置命令：

import json
from googleapiclient import discovery

def GenerateConfig(context):
    instances = context.properties['instances']
    resources = []
    
    for instance in instances:
        # 定义远程执行的配置脚本
        script = f'''#!/bin/bash
yum update -y
yum install -y my-service
echo "{instance['internal_ip']}" >> /etc/my-service/peer-list.conf
systemctl start my-service
systemctl enable my-service
'''
        # 添加一个远程执行资源，依赖于实例部署完成
        resources.append({
            'name': f'configure-{instance["name"]}',
            'type': 'gcp-types/compute-v1:compute.instances.setMetadata',
            'properties': {
                'instance': instance['self_link'],
                'metadata': {
                    'items': [{
                        'key': 'startup-script',
                        'value': script
                    }]
                }
            },
            'metadata': {
                'dependsOn': [instance['name']]
            }
        })
    
    return {'resources': resources}

然后在你的Jinja模板中引用这个自定义类型，传入所有实例的信息，确保配置操作在实例部署完成后执行。

方案三：用Cloud Build编排完整工作流

如果你的部署后操作比较复杂，推荐用Cloud Build来串联整个流程：

1. 第一步：执行gcloud deployment-manager deployments create命令部署实例
2. 第二步：调用gcloud获取实例信息并保存到文件
3. 第三步：通过gcloud compute ssh或Ansible远程登录到每个实例，执行配置和服务启动命令

这种方式灵活性最高，适合需要多步骤、多工具集成的场景。

内容的提问来源于stack exchange，提问作者Suhasini Subramaniam