Freigeben über

Konfigurationsschema für die Workload-Orchestrierung

Das Konfigurationsschema ist eine YAML-Datei, die die Struktur und Regeln für die Konfiguration einer Lösungsvorlage definiert. Es gibt die Eigenschaften, Typen und Validierungsregeln für die Konfigurationswerte an, die Benutzer beim Bereitstellen der Lösungsvorlage bereitstellen können. Eine Konfigurationsvorlage kann auf ein einzelnes Schema oder keines verweisen.

Das Schema wird verwendet, um die von Benutzern bereitgestellten Konfigurationswerte zu überprüfen und sicherzustellen, dass sie dem erwarteten Format und den Einschränkungen entsprechen. Außerdem bietet sie eine Möglichkeit, die für die Lösungsvorlage verfügbaren Konfigurationsoptionen zu dokumentieren.

In diesem Artikel werden die Struktur und Regeln zum Erstellen eines Konfigurationsschemas für die Workload-Orchestrierung beschrieben.

Konfigurationsschemastruktur

Das Konfigurationsschema besteht aus zwei Hauptabschnitten: rules und validations. Der rules Abschnitt definiert die Konfigurationsschlüssel und deren Eigenschaften, während im validations Abschnitt alle benutzerdefinierten Gültigkeitsprüfungsregeln definiert werden, die für das gesamte Schema gelten.

Hier ist ein Beispiel für ein Konfigurationsschema:


rules:
  configs:
    key: # name of the configuration key. this can be a string
      type: #string|boolean|int|float|object|array[int|string|float|object]  
      required: # boolean  
      pattern: # regex pattern (optional)
      allowedValues: #array applicable for string, int, float (optional)
      disallowedValues: #array applicable for string, int, float (optional)
      expression: # any valid expression. should be wrapped in expression template like: "${{ expression }}"
      editableAt: #array of levels ex: Line, Factory where value can be edited at (optional)
      editableBy: # array of personas Ex: IT, OT who can edit the value. (optional)
      minValue: # minimum number  (optional)
      maxValue: # maximum number (optional)
      defaultValue: # default value applicable for primitive types i.e. int, string, boolen, float (optional) 
      description: # string (optional)
      placeHolder: # place holder value applicable for string, int, float, boolean. (optional)
      label: # string to be displayed on the UI (optional)
      disabled: # boolean disable for edit (optional)
  validations:
    # one or more validation expressions are supported
    - expression: # any valid expression. should be wrapped in expression template like: "${{ expression }}"
    - expression: # any valid expression. should be wrapped in expression template like: "${{ expression }}"

Einschränkungen für Regeln

Die folgenden Einschränkungen gelten für die im Konfigurationsschema definierten Regeln:

  • Der config Schlüssel ist optional. Wenn ein Schlüssel über eine Regel verfügt, ist die type Eigenschaft obligatorisch.
  • Die minValue Eigenschaften und maxValue Eigenschaften werden nur für numerische Typen (int, float) unterstützt.
  • Der minValue Wert muss größer sein als der maxValue.
  • Die allowedValues Eigenschaft gilt nur für string, intund float Typen.
  • Die disallowedValues Eigenschaft gilt nur für string, intund float Typen.
  • Die defaultValue Eigenschaft gilt nicht für den object Typ.
  • Die editableBy Eigenschaft akzeptiert entweder IT-, OT- oder beide Werte. Wenn die IT festgelegt ist, wird dieser Parameter nicht im Workload-Orchestrierungsportal angezeigt und muss über CLI konfiguriert werden. Wenn OT festgelegt ist, ist dieser Parameter im Workload-Orchestrierungsportal sichtbar und kann auch über CLI festgelegt werden.
  • Der editableAt Parameter akzeptiert einen beliebigen Wert auf Hierarchieebene, wie er während der Kontexterstellung definiert ist, Linez. B. , , Factoryoder Region.

Einschließen und Verweisen auf Regeln aus einem anderen Schema

Wenn Sie einen bestimmten Satz von Schemaregeln wiederverwenden möchten, können Sie diese Funktion erreichen.

Sie möchten beispielsweise ein LogSettingsSchema mit Version 1.0.0 wie folgt definieren:

rules:
    configs:
      LogSettings:
        type: object
        required: true
      LogSettings.LogOutput:
        type: object
        required: true
      LogSettings.LogOutput.EnableConsole:
        type: boolean
        required: true
        editableAt:
        - Line
      SupportedHttpMethods:
        type: array[string]
        required: true
        editableAt:
        - Factory

Szenario 1

Wenn Sie den vollständigen Inhalt von LogSettingsSchema bevorzugen, verwenden Sie die include Funktion wie definiert. Stellen Sie sicher, dass Sie mit ":" enden, damit die YAML-Datei gültig ist. Benennen Sie das folgende Schema als SampleSchema mit Version 1.0.0:

rules:
    configs:
      ${{$include(LogSettingsSchema/1.0.0)}}:
      TempSettings:
        type: object
        required: true
      TempSettings.Threshold:
        type: int
        required: true
        editableAt:
          - Line

Das endgültige Schema wird wie folgt generiert. Der Inhalt von LogSettingsSchema ist im endgültigen Schema enthalten:

rules:
    configs:
      LogSettings:
        type: object
        required: true
      LogSettings.LogOutput:
        type: object
        required: true
      LogSettings.LogOutput.EnableConsole:
        type: boolean
        required: true
        editableAt:
        - Line
      SupportedHttpMethods:
        type: array[string]
        required: true
        editableAt:
        - Factory
      TempSettings:
        type: object
        required: true
      TempSettings.Threshold:
        type: int
        required: true
        editableAt:
          - Line

Szenario 2

Wenn Sie nur einen bestimmten Abschnitt oder ein bestimmtes geschachteltes Objekt und dessen untergeordnete Objekte einschließen möchten, können Sie folgende Aktionen ausführen:

rules:
    configs:
      ${{$include(LogSettingsSchema/1.0.0, LogSettings)}}:
      TempSettings:
        type: object
        required: true
      TempSettings.Threshold:
        type: int
        required: true
        editableAt:
          - Line

Das endgültige Schema wird wie folgt generiert. Nur LogSettings und seine Kinder sind enthalten. SupportedHttpMethods wird übersprungen , da die Syntax ein bestimmtes Objekt enthält - LogSettings.

rules:
    configs:
      LogSettings:
        type: object
        required: true
      LogSettings.LogOutput:
        type: object
        required: true
      LogSettings.LogOutput.EnableConsole:
        type: boolean
        required: true
        editableAt:
        - Line
      TempSettings:
        type: object
        required: true
      TempSettings.Threshold:
        type: int
        required: true
        editableAt:
          - Line

Benutzerdefinierte Überprüfung mithilfe von Ausdrücken

Benutzerdefinierte Überprüfung wird mit benutzerdefinierten Ausdrücken auf zwei Ebenen unterstützt:

  1. Gültigkeitsprüfung pro Regel: Verwenden des Ausdrucks (optionaler Eigenschaft) innerhalb jeder Regel.
    • Geeignet für Überprüfungen, die auf einen einzelnen Konfigurationsschlüssel beschränkt sind.
  2. Pro Schemaüberprüfung: Verwenden der Eigenschaft "validations", die eine Liste von Ausdrücken akzeptiert.
    • Geeignet für Validierungen, die sich über mehrere Konfigurationsschlüssel erstrecken.
    • Geeignet für die Überprüfung der generierten Konfiguration als einzelne Einheit.

Diese Ausdrücke müssen "true" (als boolescher Wert oder eine Zeichenfolge) zurückgeben, um den Erfolg bei der Überprüfung anzugeben.

Beispiel 1: Per-Rule Validierung

Erzwingen Sie den frequency Konfigurationsschlüssel, um einen ganzzahligen Wert kleiner oder gleich 120 zu haben.

rules:
    configs:
      frequency:
        type: int
        expression: ${{ $le($val(frequency)), 120}}

Beispiel 2: Per-Rule Validierung mit querverweisenden Verweisen auf andere Configs

Erzwingen Sie den frequency Konfigurationsschlüssel, um einen ganzzahligen Wert kleiner oder gleich zu frequencyLimithaben.

rules:
    configs:
      frequency:
        type: int
        expression: ${{ $le($val(frequency), $val(frequencyLimit))}}
      frequencyLimit:
         type: int

Beispiel 3: Per-Schema Validierung

Erzwingen Sie den service_ip Konfigurationsschlüssel, bei dem es sich um eine IP-Adresse handelt, um sich in einem CIDR-Bereich zu befinden.

rules:
    configs:
      service_ip:
        type: string
        expression: ${{ $cidr_contains("192.168.1.0/24", $val(service_ip))}}

Beispiel 4: Per-Schema Validierung

Erzwingen Sie, dass mindestens einer von OptionA, OptionBoder OptionC muss .false

rules:
    configs:
      OptionA:
        type: boolean
        expression: ${{ $le($val(frequency), $val(frequencyLimit))}}
      OptionB:
        type: boolean
      OptionC:
        type: boolean

validations:
   expression: ${{ $any($not($val(OptionA)), $not($val(OptionB)), $not($val(OptionC)))}}

Verwandte Inhalte