Skip to main content

Config

The Config custom resource can be provided by a vendor to specify a configuration screen in the Replicated admin console for collecting customer supplied values and template function rendering.

The settings that appear on the admin console configuration screen are specified as an array configuration groups and items.

Groups

Groups are comprised of a name, title, description and an array of items.

spec:
  groups:
  - name: authentication
    title: Authentication
    description: Configure application authentication below.

Note: description is only supported in groups, see help_text property for items. Markdown syntax is supported in this property.

A group can be hidden from customer view and made optional by setting the when property on the group to false.

Items

Items map to input fields and belong to a single group. All items should have name, title and type properties. Specific item types can including new types.

Available Item Types

  • bool
  • file
  • heading
  • label
  • password
  • select_one
  • text
  • textarea

Examples

bool

The bool input type should use a "0" or "1" to set the value

    - name: toggles
      items:
      - name: http_enabled
        title: HTTP Enabled
        type: bool
        default: "0"

file

A file is a special type of form field that renders an <input type="file" /> HTML element. Only the contents of the file, not the name, are captured. See the ConfigOptionData template function for examples on how to use the file contents in your application.

    - name: certs
      title: TLS Configuration
      items:
      - name: tls_private_key_file
        title: Private Key
        type: file
      - name: tls_certificate_file
        title: Certificate
        type: file

heading

The heading type allows you to display a group heading as a subelement within a group. This is useful when you would like to group items all in one config group but would like to separate the items visually, for instance when using a config group test proc.

Note: The heading item type is not supported.

    - name: ldap_settings
      title: LDAP Server Settings
      items:
      ...
      - name: ldap_schema
        type: heading
        title: LDAP schema
      ...

label

The label type allows you to display an input label.

    - name: Email
      items:
      - name: email-address
        title: Email Address
        type: text
      - name: description
        type: label
        title: "Note: The system will send you an email every hour."

password

The password type is a text field that hides the character input.

    - name: password_text
      title: Password Text
      type: password
      value: "{{repl RandomString 10}}"

select_one

The select_one type is a special case. This type must have nested items that act as options. This type is displayed as radio buttons in the admin console.

    - name: authentication
      title: Authentication
      description: ""
      items:
      - name: authentication_type
        default: authentication_type_anonymous
        type: select_one
        items:
        - name: authentication_type_anonymous
          title: Anonymous
        - name: authentication_type_password
          title: Password

text

A text input field allows users to enter a string value. Optionally, all additional properties are available for this input type.

    - name: example_text_input
      title: Example Text Input
      type: text

textarea

A textarea can specify a props that will map into the HTML element directly. Examples of available properties are rows, cols and wrap. For more information, see HTML <textarea/> Tag.

    - name: custom_key
      title: Set your secret key for your app
      description: Paste in your Custom Key
      items:
      - name: key
        title: Key
        type: textarea
        props:
          rows: 8
      - name: hostname
        title: Hostname
        type: text

Properties

default and value

A default value will be applied to the ConfigOption template function when no value is specified. If default value is not a password field, it will appear as placeholder text in the settings section of the admin console. Default values are treated as ephemeral, which is the same behavior as the readonly property. Configuration changes will re-evaluate the template expressions.

A value is data that will be overwritten by user input on non-readonly fields.
It will appear as the HTML input value in the settings section of the admin console.

    - name: custom_key
      title: Set your secret key for your app
      description: Paste in your Custom Key
      items:
      - name: key
        title: Key
        type: text
        value: ""
        default: change me

required

A required field will prevent the application from starting until it has a value.

        required: true

when

The when value is used to denote conditional inputs that are only visible (or required) when the condition evaluates to true. The when item can be used on groups, items and select_one options.

The settings UI will update right away when a field used in a when clause is updated (no need to save) and can be used to used to show optional config sections. The equality check should match exactly without quotes.

    - name: database_settings_group
      items:
      - name: db_type
        type: select_one
        default: external
        items:
        - name: external
          title: External
        - name: embedded
          title: Embedded DB
      - name: database_host
        title: Database Hostname
        type: text
        when: '{{repl (ConfigOptionEquals "db_type" "external")}}'
      - name: database_password
        title: Database Password
        type: password
        when: '{{repl (ConfigOptionEquals "db_type" "external")}}'

An item can be recommended. This item will bear the tag "recommended" in the admin console.

Note: Only works for boolean and text field types.

    - name: toggles
      items:
      - name: http_enabled
        title: HTTP Enabled
        type: bool
        default: "0"
        recommended: true

hidden

Items can be hidden. They will not be visible if hidden.

        - name: secret_key
          title: Secret Key
          type: password
          hidden: true
          value: "{{repl RandomString 40}}"

When used in conjunction with a function that generates a value, for example RandomString

  • If set to true, the value is persistent between Config changes but it cannot be modified because its not visible in HTML.
  • If not set or set to false, the value is persistent between Config changes. It can be modified because it is visible in HTML.

readonly

Items can be readonly.

        - name: unique_id
          title: Unique ID
          type: text
          value: "{{repl RandomString 20}}"
          readonly: true

When used in conjunction with a function that generates value, for example RandomString

  • If set to true, the value is ephemeral between Config changes. It cannot be modified because it is greyed out in HTML.
  • If not set or set to false, the value is persistent between Config changes. It can be modified because it is not greyed out in HTML.

affix

Items can be affixed left or right. These items will appear in the admin console on the same line.

    affix: left

help_text

This is similar to description but for items. This property can show a helpful message below title. Markdown syntax is supported.

    - name: toggles
      items:
      - name: http_enabled
        title: HTTP Enabled
        help_text: Check to enable the HTTP listener
        type: bool

Repeatable Items

A repeatable config item copies a YAML array entry or YAML document for as many values as are provided. Any number of values can be added to a repeatable item to generate additional copies.

Note: Repeatable Items only work for text, textarea, and file types.

To make an item repeatable, set repeatable to true

    - name: ports
      items:
      - name: service_port
        title: Service Port
        type: text
        repeatable: true

Repeatable items do not use the default or value fields, but instead a valuesByGroup field. valuesByGroup should have an entry for the parent Config Group name, with all default key:value pairs nested in the group. At least one default entry is required for the repeatable item.

    valuesByGroup:
      ports:
        port-default-1: "80"

Template Targets

Repeatable items require at least 1 template to be provided. The template defines a YAML target in the manifest to duplicate for each repeatable item.

Required fields for a template target are apiVersion, kind, and name.

namespace is an optional template target field to match a yaml document's metadata.namespace property, in case the same filename is used across multiple namespaces.

The entire YAML node at the target will be duplicated, including nested fields.

The yamlPath field of the template must denote index position for arrays using square brackets. For example, spec.ports[0] to select the first port entry for duplication. All duplicate YAML will be appended to the final array in the yamlPath.

yamlPath must end with an array.

    templates:
    - apiVersion: v1
      kind: Service
      name: my-service
      namespace: my-app
      yamlPath: 'spec.ports[0]'

If the yamlPath field is not present, the entire YAML document matching the template will be replaced with a copy for each of the repeatable item entries. The metadata.name field of the new doc will reflect the repeatable item key.

Templating

The repeat items are called with the delimeters repl[[ .itemName ]] or [[repl .itemName ]]. These delimiters can be placed anywhere inside of the yamlPath target node.

    - port: repl{{ ConfigOption "[[repl .service_port ]]" | ParseInt }}
      name: '[[repl .service_port ]]'

This repeatable templating is not compatible with sprig templating functions. It is designed for inserting repeatable keys into the manifest. Repeatable templating can be placed inside of Replicated config templating.

Ordering

Repeatable templates are processed before config template rendering.

Repeatable items are processed in order of the template targets in the Config Spec file. Effectively, this ordering is from the top of the Config Spec, by Config Group, by Config Item, and then by template target.

    - name: ports
      items:
      - name: service_port
        title: Service Port
        type: text
        repeatable: true
        templates:
        - apiVersion: v1 #processed first
          kind: Service
          name: my-service
          namespace: my-app
          yamlPath: 'spec.ports[0]'
        - apiVersion: v1 #processed second
          kind: Service
          name: my-service
          namespace: my-app
        {other item properties ...}
      - name: other_ports
        title: Other Service Port
        type: text
        repeatable: true
        templates:
        - apiVersion: v1 #processed third
          kind: Service
          name: my-other-service
          namespace: my-app
        {other item properties ...}
    - name: deployments
      items:
      - name: deployment-name
        title: Deployment Names
        type: text
        repeatable: true
        templates:
        - apiVersion: apps/v1 #processed fourth
          kind: Deployment
          name: my-deployment
          namespace: my-app
        {other item properties ...}

Repeatable Examples

In these examples, the default service port of "80" is included with the release. Port 443 is added as an additional port on the admin console configuration page, which is stored in the ConfigValues file.

Repeatable Item Example for a YamlPath

Config custom resource manifest file

    - name: ports
      items:
      - name: service_port
        title: Service Port
        type: text
        repeatable: true
        templates:
        - apiVersion: v1
          kind: Service
          name: my-service
          namespace: my-app
          yamlPath: spec.ports[0]
        valuesByGroup:
          ports:
            port-default-1: "80"

Config values

apiVersion: kots.io/v1beta1
kind: ConfigValues
metadata:
  name: example_app
spec:
  values:
    port-default-1:
      repeatableItem: service_port
      value: "80"
    service_port-8jdn2bgd:
      repeatableItem: service_port
      value: "443"

Template manifest

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: my-app
spec:
  type: NodePort
  ports:
  - port: repl{{ ConfigOption "[[repl .service_port ]]" | ParseInt }}
    name: '[[repl .service_port ]]'
  selector:
    app: repeat_example
    component: my-deployment

After repeatable config processing

Note: this phase is internal to configuration rendering for the app manager. This example is only provided to further explain the templating process.*

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: my-app
spec:
  type: NodePort
  ports:
  - port: repl{{ ConfigOption "port-default-1" | ParseInt }}
    name: 'port-default-1'
  - port: repl{{ ConfigOption "service_port-8jdn2bgd" | ParseInt }}
    name: 'service_port-8jdn2bgd'
  selector:
    app: repeat_example
    component: my-deployment

Resulting manifest

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: my-app
spec:
  type: NodePort
  ports:
  - port: 80
    name: port-default-1
  - port: 443
    name: service_port-8jdn2bgd
  selector:
    app: repeat_example
    component: my-deployment

Repeatable Item Example for an Entire Document

Config spec

    - name: ports
      items:
      - name: service_port
        title: Service Port
        type: text
        repeatable: true
        templates:
        - apiVersion: v1
          kind: Service
          name: my-service
          namespace: my-app
        valuesByGroup:
          ports:
            port-default-1: "80"

Config values

apiVersion: kots.io/v1beta1
kind: ConfigValues
metadata:
  name: example_app
spec:
  values:
    port-default-1:
      repeatableItem: service_port
      value: "80"
    service_port-8jdn2bgd:
      repeatableItem: service_port
      value: "443"

Template manifest

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: my-app
spec:
  type: NodePort
  ports:
  - port: repl{{ ConfigOption "[[repl .service_port ]]" | ParseInt }}
  selector:
    app: repeat_example
    component: repl[[ .service_port ]]

After repeatable config processing

Note: this phase is internal to configuration rendering for the app manager. This example is only provided to further explain the templating process.*

apiVersion: v1
kind: Service
metadata:
  name: port-default-1
  namespace: my-app
spec:
  type: NodePort
  ports:
  - port: repl{{ ConfigOption "port-default-1" | ParseInt }}
  selector:
    app: repeat_example
    component: port-default-1
---
apiVersion: v1
kind: Service
metadata:
  name: service_port-8jdn2bgd
  namespace: my-app
spec:
  type: NodePort
  ports:
  - port: repl{{ ConfigOption "service_port-8jdn2bgd" | ParseInt }}
  selector:
    app: repeat_example
    component: service_port-8jdn2bgd

Resulting manifest

apiVersion: v1
kind: Service
metadata:
  name: port-default-1
  namespace: my-app
spec:
  type: NodePort
  ports:
  - port: 80
  selector:
    app: repeat_example
    component: port-default-1
---
apiVersion: v1
kind: Service
metadata:
  name: service_port-8jdn2bgd
  namespace: my-app
spec:
  type: NodePort
  ports:
  - port: 443
  selector:
    app: repeat_example
    component: service_port-8jdn2bgd