Terraform部署服务器后触发Jira Assets资产创建的方案咨询

核心问题分析 #

你用external数据源的问题在于：Terraform的数据源会在plan和apply阶段都执行，而且数据源设计初衷是读取数据而非执行写操作，这就导致了每次plan都会触发Jira资产创建，不符合你的需求。下面是几个可行的解决思路：

方案1：用null_resource配合触发器（推荐） #

null_resource是Terraform专门用来执行无状态操作的资源，通过triggers参数可以控制只有当关联的服务器资源发生变化（比如新创建、销毁）时，才执行后续的脚本。

修改你的服务器模块，添加以下代码：

resource "oci_core_instance" "server" {
  # 原有的服务器配置保持不变
  availability_domain = var.availability_domain
  compartment_id      = var.compartment_id
  display_name        = "${var.display_prefix}-${var.name}"

  source_details {
    source_type = "image"
    source_id   = var.server_image
  }
  shape = var.server_shape
  create_vnic_details {
    subnet_id              = var.network_subnet
    assign_public_ip       = false
    private_ip             = var.private_ip
    hostname_label         = var.name
    nsg_ids                = var.network_securitygroups
    skip_source_dest_check = var.skip_source_dest_check
  }
  metadata = {
    user_data = base64encode(file(var.server_template))
  }
  timeouts {
    create = "10m"
  }
}

# 仅在服务器创建/销毁时触发Jira资产创建
resource "null_resource" "jira_asset_provision" {
  # 触发器绑定服务器ID：只有服务器ID变化（新创建或销毁）时，才执行provisioner
  triggers = {
    server_unique_id = oci_core_instance.server.id
  }

  provisioner "local-exec" {
    # 直接传递服务器的实际属性，不用硬编码
    command = "bash ./CreateAsset.sh ${oci_core_instance.server.display_name} ${oci_core_instance.server.private_ip}"

    # 可选：如果CMDB创建失败不影响基础设施，设置为continue避免整个apply失败
    on_failure = "continue"
  }
}

关键说明：

• triggers里用server.id：服务器创建完成后才会生成唯一ID，只有新服务器创建或旧服务器销毁时，这个值才会变化，确保local-exec仅在apply阶段的服务器变更时执行。
• 直接引用服务器属性：避免硬编码，保证脚本使用的是Terraform实际创建的服务器数据。

方案2：在服务器资源内直接添加provisioner #

如果不需要单独管理CMDB创建操作的生命周期，可以直接在oci_core_instance资源里加入local-exec provisioner，并指定执行时机为create：

resource "oci_core_instance" "server" {
  # 原有的服务器配置不变...

  # 仅在服务器首次创建时执行
  provisioner "local-exec" {
    command = "bash ./CreateAsset.sh ${self.display_name} ${self.private_ip}"
    when    = "create" # 仅在资源创建时执行，更新或销毁时不触发
    on_failure = "continue"
  }
}

方案3：脚本层面保证幂等性（必做补充） #

无论用哪种方案，都要给你的CreateAsset.sh添加幂等逻辑——先检查Jira Assets中是否已存在该服务器资产，不存在再执行创建：

#!/bin/bash
SERVER_NAME=$1
SERVER_IP=$2

# 替换为你的Jira实例地址、认证信息和资产类型ID
JIRA_URL="https://your-jira-domain.atlassian.net"
AUTH_TOKEN="Basic $(echo -n "your-email:your-api-token" | base64)"
SERVER_OBJECT_TYPE_ID="your-server-object-type-id"
NAME_ATTR_ID="your-name-attribute-id"
IP_ATTR_ID="your-ip-attribute-id"

# 先查询是否已存在同名服务器
EXISTS=$(curl -s -X GET "${JIRA_URL}/rest/assets/1.0/object/search" \
  -H "Authorization: ${AUTH_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "query": {
      "filter": [
        {
          "objectTypeId": "'"${SERVER_OBJECT_TYPE_ID}"'",
          "attributes": [
            {
              "name": "Name",
              "operator": "EQUALS",
              "value": "'"${SERVER_NAME}"'"
            }
          ]
        }
      ]
    }
  }' | jq '.objects | length')

if [ $EXISTS -eq 0 ]; then
  # 不存在则创建资产
  curl -X POST "${JIRA_URL}/rest/assets/1.0/object" \
    -H "Authorization: ${AUTH_TOKEN}" \
    -H "Content-Type: application/json" \
    -d '{
      "objectTypeId": "'"${SERVER_OBJECT_TYPE_ID}"'",
      "attributes": [
        {
          "objectTypeAttributeId": "'"${NAME_ATTR_ID}"'",
          "value": "'"${SERVER_NAME}"'"
        },
        {
          "objectTypeAttributeId": "'"${IP_ATTR_ID}"'",
          "value": "'"${SERVER_IP}"'"
        }
      ]
    }'
  echo "Created Jira asset for server: ${SERVER_NAME}"
else
  echo "Jira asset for ${SERVER_NAME} already exists, skipping creation."
fi

基础设施即代码后CMDB同步的通用实践 #

1. 优先使用原生Provider：如果工具（如Jira Assets）有官方或社区维护的Terraform Provider，优先用资源式管理，这是最符合Terraform声明式模型的方式，能保证CMDB资产与基础设施生命周期一致。
2. 用Provisioner控制执行时机：对于无Provider的场景，用null_resource+triggers或资源内的provisioner，通过when = "create"或触发器绑定资源唯一标识，避免无意义的重复执行。
3. 强制幂等性：所有外部写操作必须保证幂等，避免重复创建、更新资源，这是自动化操作的核心要求。
4. 错误隔离：如果CMDB同步不是强依赖业务，设置on_failure = "continue"，避免CMDB操作失败导致整个基础设施部署中断。

内容的提问来源于stack exchange，提问作者Jeroen G