Beispiel für einen Antwortprozessor für einen virtuellen Server

  • Freigeben Version: Xanadu
  • Aktualisiert 1. August 2024
  • 2 Minuten Lesedauer
  • Das Skript Create_Virtual_Server_Response_Processor, das standardmäßig in Cloud Provisioning and Governance verfügbar ist, ist der Antwortprozessor, der die Erstellung von AWS-VM-CIs verarbeitet.

    Virtuellen Server erstellen

    Das Ressourcenprozessorskript „Create_Virtual_Server_Response_Processor“ ist standardmäßig im Ressourcenblock „Virtueller Server“ verfügbar. Seine Aufgabe besteht darin, einen Datensatz für einen virtuellen Server in der Tabelle „VM-Instanz“ [cmdb_ci_vm_instance] zu erstellen, wenn ein neuer virtueller Server bereitgestellt wird.

    Alle Antwortprozessoren haben diese erste Zeile mit diesen allgemeinen Parametern:
    function processResponse(response, cloudServiceAccountId, ldc, correlationId,step, requestorContext) {
    

    Dadurch werden die Antwort des Cloud-Providers und die wichtigen Informationen, wie z. B. die Konto-ID, abgerufen, die erforderlich sind, damit das System das neue CI erstellen kann. Alle diese Parameter sind für alle Antwortprozessoren erforderlich.

    Zeile 10 wandelt die Antwort in JSON um, damit sie vom System verarbeitet werden kann. Die Informationen werden in der Variablen „vmResponse“ gespeichert:

    
    var vmResponse = global.JSON.parse(response);
    

    Immer wenn Sie einen Antwortprozessor erstellen oder bearbeiten, müssen Sie wissen, welche Eingaben für den CI-Typ erforderlich sind. Zeile 11 verarbeitet eine der erforderlichen Eingaben, die Hardware-ID, die für den CMDB-Datensatz erforderlich ist:

    
    var hardwareId = vmResponse.hardwareId;
    

    Zeile 39 zeigt die Informationen an, die das System benötigt, um den neuen virtuellen Server und zugehörige CIs zu identifizieren, damit die Informationen in der CMDB abgelegt werden können. In diesem Fall identifiziert die Objekt-ID des Servicekontos das dem virtuellen Server zugeordnete Konto, die Objekt-ID des Rechenzentrums das Rechenzentrum, in dem der virtuelle Server ausgeführt wird, und die Objekt-ID der VM-Instanz den virtuellen Server selbst. Dieser Block mit Identifizierungscode verhindert die Erstellung doppelter CIs.

    
    var vmInfo = {
        "cmdb_ci_vm_instance": {
          "validator": "virtual_machine_create_update_validator",
          "validator_overrides": {},
          "identification": {
            "cmdb_ci_cloud_service_account": {
              "criterion": {
                "object_id": cloudServiceAccountId
              }
            },
            "cmdb_ci_aws_datacenter": {
              "criterion": {
                "object_id": ldc
              }
            },
            "cmdb_ci_vm_instance": {
              "criterion": {
                "object_id": vmResponse.nodeId
              }
            }
          },

    Attribute werden in die Felder in der Tabelle „cmdb_ci_vm_instance“ eingetragen. Diese Attribute werden in Zeile 61 definiert:

    
    "attributes": {
      "name": vmResponse.nodeName,
      "object_id": vmResponse.nodeId,
      "state": status_map[vmResponse.state],
      "dns_suffix": vmResponse.dnsSuffix,
      "cpus": vmCPUs,
      "memory": vmMemory,
      "disks": vmResponse.volumes.length,
      "disks_size": "",
      "nics": vmResponse.networkInterfaces.length,
      "terminated_on": "",
      "termination_protection": "",
      "ip_address": vmPubIPAddr,
      "assigned_to": reqContext.userId,
      "assignment_group": reqContext.groupId
    },
    

    Auch Verweise auf andere CIs können im Antwortprozessor enthalten sein. In diesem Fall wird die BS-Vorlage, auf der der virtuelle Server basiert, identifiziert, indem zuerst die Objekt-ID des Servicekontos, dann die des Rechenzentrums und schließlich die der tatsächlichen BS-Vorlage identifiziert wird.

    
    "references": {
      "cmdb_ci_os_template": {
        "identification": {
          "cmdb_ci_cloud_service_account": {
            "criterion": {
              "object_id": cloudServiceAccountId
            }
          },
          "cmdb_ci_aws_datacenter": {
            "criterion": {
              "object_id": ldc
            }
          },
          "cmdb_ci_os_template": {
            "criterion": {
              "object_id": imageIdTrim
            }
          }
        },

    Der folgende Codeblock fügt die Objekt-ID des BS-Images der Attributliste hinzu, damit diese Informationen in den CMDB-Datensatz des virtuellen Servers eingefügt werden können.

    
    "attributes": {
      "object_id": imageIdTrim
    }
    

    Dieser Codeblock führt eine zusätzliche Identifizierung für die Computing-Vorlage (den Hardwaretyp) durch und fügt das Ergebnis dann den Attributen hinzu:

    
    "cmdb_ci_compute_template": {
      "identification": {
        "cmdb_ci_cloud_service_account": {
          "criterion": {
            "object_id": cloudServiceAccountId
          }
        },
        "cmdb_ci_aws_datacenter": {
          "criterion": {
            "object_id": ldc
          }
        },
        "cmdb_ci_compute_template": {
          "criterion": {
            "object_id": vmResponse.hardwareId
          }
        }
      },
      "attributes": {
        "object_id": vmResponse.hardwareId,
        "name": vmResponse.hardwareId
      }
    }

    Zusätzliche Codeabschnitte stellen die Beziehung zu Netzwerkschnittstellen her und identifizieren jeden an den virtuellen Server angehängten Speicher.

    Dieser obligatorische Codeblock verschiebt die Daten in die CMDB und gibt die JSON-Zeichenfolge zurück:

    
    cloudModelString.push(vmInfo);
    return global.JSON.stringify(cloudModelString);