User Community Service Desk Downloads
If you can't find the product or version you're looking for, visit support.ataccama.com/downloads

Working with Deployments

Deployments are used to manage configuration properties for a specific module and are linked to a particular environment. Each deployment has its own set of application properties and, optionally, a Logback configuration. In addition, each deployment has another set of properties describing the deployment itself, such as the security key, roles, and more. The unique identity of a deployment is defined by a JWT key or a certificate.

Configuration properties defined in a deployment are then distributed to replicas, which are running instances of the selected module. A new replica is created each time the module is started and an identifier is automatically generated if it is not provided otherwise. This means that one deployment can have multiple replicas that all share the same configuration and logging properties. However, the Configuration Service is not intended to and cannot be used as a management or monitoring tool as it provides only a basic overview of the replica state and tracks only those replicas that are alive. If no heartbeat is detected from a replica, it is removed from the deployment’s list of replicas.

On startup, replicas retrieve the latest configuration from the deployment based on the updated timestamp and periodically check for a newer version during runtime. However, unless refreshable properties are used, replicas cannot retrieve the latest configuration while running. If the latest configuration is not used, the status of the replica changes to Outdated.

Properties are defined as key value strings with no metadata and can be refreshable or non-refreshable. Refreshable properties can be reloaded during runtime. This trait is specified for each property in the corresponding module and cannot be modified.

Take note of the following:

  • If you update both refreshable and non-refreshable properties, no changes are propagated to modules during runtime. This is possible only when refreshable properties are edited.

  • Changes made to configuration properties in a deployment are automatically saved. However, replicas cannot access updated properties unless they are published.

In addition, deployments also handle certificates used to secure communication between the configuration server and its clients. For more information, see Security Configuration.

The Deployments overview screen displays the following information for each deployment:

working with deployments deployments overview screen

  • Module: The module that the deployment configures.

  • Environment: The environment in which the deployment is used.

  • URI: The unique identifier of the deployment.

  • Replicas States: The number of replicas for that deployment and their current status. Possible statuses are as follows:

    • Pending: The Configuration Service is waiting for a response from the replica.

    • Up to date: The replica is running and using the latest configuration.

    • Outdated: The replica is running with an outdated configuration.

    • Invalid: There is an issue communicating with the replica.

    • Unknown: The current status of the replica cannot be retrieved.

      If there are no replicas for that deployment, no information is displayed.

      When viewing a deployment, the states are divided between those related to replicas (Running or Unknown) and those related to replica properties (Up to date, Outdated, Pending, Invalid).

Creating deployments

Prerequisite: You need to have at least one environment set up before creating a deployment. See Working with Environments in the Configuration Service.
  1. In the Configuration Service, go to the Deployments tab.

  2. Select Create.

  3. Configure the deployment details:

    working with deployments new deployment

    • Module: Select the module for which you want to create a deployment. Available modules include: dpm, aicore, rdm, mmm-fe, dpe, desktop, mmm-be, Other.

      In the current version, the only available option is Other and should be set for all modules.

    • Environment: Select the environment in which the deployment should be used.

    • URI: A unique identifier of the deployment. Can correspond to the name of the deployment. Only alphanumeric characters and dashes are allowed. The identifier is case-insensitive.

    • Public URL: The URL where users can access the deployment if the deployment is made public. This means that anyone with the link can view the module configuration. If the deployment is private, the field can be left empty. Needs to be in the form of a valid URL.

      The property is not used in the current version.
    • Internal URL: The URL where the deployment can be accessed with authorization. The field can be remain empty if the URL is not used, for example, in ONE Desktop deployments. Needs to be in the form of a valid URL.

      The property is not used in the current version.
    • Public Deployment: Select whether the deployment is public or private. Public deployments can be viewed by anyone who has access to the deployment’s URL and they do not need JWT tokens for authentication. However, it is not possible to monitor replicas for public deployments.

      To access a public deployment configuration, append the following to the URL of the Configuration Service: /v1/deployments/<deployment_URI>.

      For example, if you are running the Configuration Service locally, the full URL would be: localhost:8011/v1/deployments/<deployment_URI>.

      Accessing a public deployment retrieves a JSON file containing basic information about the deployment and the configured properties.

      Public deployment
      {
          "uri": "testDeployment",
          "property": {
              "version": "2020-07-13T10:58:02.551178Z",
              "properties": [
                  {
                      "key": "plugin.dqc.ataccama.one.mmm.hostname",
                      "value": "${constant}"
                  },
                  {
                      "key": "logging.file.path",
                      "value": "path/to/folder"
                  }
              ]
          }
      }
  4. To finish adding the deployment, click Save.

  5. Module-specific properties for the selected module are loaded under Configuration.

    working with deployments dpm test

    To set a property, uncomment it and provide a suitable value.

    Each property can be specified on a single or multiple lines. When using multiple lines, escape the newline character with a single backslash (\). For example:

    multiline.property=value\
    Spans\
    MultipleLines

    The client receives the value as: multiline.property=valueSpansMultipleLines.

    Deployment properties are stored encrypted in the Configuration Service database. However, this does not apply to properties that have been commented out. Plaintext password and secrets should therefore be completely removed from the configuration if they are not used.
    For more information about properties and their values, refer to one-platform-configuration-reference.adoc.
  6. If your deployment is private, set up the JWT authentication under JWT Secret. For more information, see Security Configuration.

  7. When you are finished editing the configuration, click Deploy Property.

    Deploying properties is required after every configuration update. Otherwise, the changes are not made available to the replica.

    If the updates have not been redeployed, the deployment is highlighted in yellow and marked as a Draft in the Deployments overview.

Editing deployments

  1. To edit a deployment, select the deployment that you want to update from the Deployments tab.

  2. Edit the properties as needed. For more information, refer to one-platform-configuration-reference.adoc.

    Deployment properties are stored encrypted in the Configuration Service database. However, this does not apply to properties that have been commented out. Plaintext password and secrets should therefore be completely removed from the configuration if they are not used.
  3. To publish the updates, click Deploy Property.

Deleting Deployments

Deleting a deployment changes the status of the deployment to DELETED and makes it view-only. However, the deleted deployment still appears in the list of deployments.

  1. In the Configuration Service, go to the Deployments tab.

  2. Find the deployment that you want to delete and select more options.

  3. Select the Delete option.

  4. A confirmation dialog appears. Confirm removing the deployment by clicking Delete. In the Deployments overview, the deployment is now highlighted in red and marked as Deleted.

Deployments can also be deleted when editing a deployment by clicking Delete and confirming your choice.

Was this page useful?