Config Management
Config Management is about taking a configuration described in a formal language, and actually applying it to a Digizuite solution. This includes adding new product configurations, managing "system" users and more.
Use cases
Configuration management should cover the following use cases:
I have an empty DAM and want to add a Media Manager and Sitecore to it
I have done some configuration on a Test environment, and now want to move it to production, however I'm not 100% sure about exactly what I did.
Somebody changed some configuration on an environment manually, however they did not write down what exactly was changed. I want a detailed list of those changes.
A new update of Media Manager is now available, and I want to deploy the required configuration changes, without breaking my existing modifications to the configuration.
As a consultant I want to be able to create predefined configurations that can be used to provide a base for doing custom configuration.
I should be able to manage all things under the System tools area, including things like metafield, members and transcodings.
Concepts
To understand how Digizuite Configuration Management works you need to understand the following concepts:
As mentioned in the previous documentation of Configuration management, the State is defined in a set of Configuration layers which in turn is a text file which described configuration by declaration.
The text language in which configuration is defined is called Digizuite configuration language (DCL).
The language
The language is a simple declarative language in which you can define the desired configuration. Below is a descriptions of the concepts.
Resources
A resource is the most basic thing in config management. Each resource entry corresponds to a single thing configuration in the Digizuite. It could can be any configuration like a metafield, a user, or simply a single node in a tree metafield.
A resource has many properties, some that can be set as part of configuring the resource, and some that only exists after the resource has been created, but can be used with other resources, . This could for instance be an identifier that is generated on creation and used from other resources to easily link related resources together.
A resource can be created, updated and deleted by the config management system. This allows management of resource resources consistently between environments.
...
| Code Block |
|---|
resource metafield my_field {
name = "My Field"
} |
Variables
A variable is a special kind of value, where the value itself is not defined as part of the configuration, but is provided from an external system. This could be things like keys for Azure blob storage, which is something that needs to be different between environments, but where the underlying purpose of having a "blob storage" is the same.
...
| Code Block |
|---|
variable my_variable {
type = "string"
} |
Locals
Locals a temporary values that are used internally to allow easily reusing certain values without repeating them over and over.
...
| Code Block |
|---|
locals {
my_first_local = "Foo"
my_second_local = 42
} |
Layers
To achieve to ability to provide configurations that can be changed and updated independently the config management system provides something called "layers". Each layer is a separately provided configuration. For example the bottom most layer is likely the basic DAM configuration that is required for the DAM to even be able to start. The next layer up might be the Media Manager layer, which provides all the metafields, labels and other configuration Media Manager needs to start.
Layers can generally be separated into two categories, predefined layers, like the DAM and Media Manager layer mentioned above, and customized layers like what each customer would do. The predefined layers are not editable by the customer, while the custom layers are.
Data references
To access something on a previous layer you need to use a data reference. Data references looks like normal resources, but rather than creating a resource that matches the specified description, it checks all previous layers for a unique resource that looks like that specified definition. Once you have a data reference, you can either use the properties when creating new resource, or use the patch functionality to modify the resource.
Data references use te the following syntax in the DCL:
| Code Block |
|---|
data metafield my_field {
Name = "My target field"
} |
Patches
The To change a resource in a previous layer patches can be used. A patch takes a target to update, and the new values the properties should have. It is only necessary to specify the properties that should actually change in the patch definition.
...
| Code Block |
|---|
patch metafield my_patch {
target = data.metafield.my_field
Name = "The new name"
} |
The Digizuite Configuration Language (DCL)
The DCL consists of several individual parts that are brought together to allow for huge flexibility. The language is heavily inspired by HCL from Hashicorp: https://www.terraform.io/docs/language/syntax/configuration.html .
The major building blocks will be shown in this section, and then we will finish with an example of how to attach these things together.
DCL types
The first thing you need to know about the language are the available primitive types:
...
Object, which is a collection of key-value pairs, where each value is one of the types described in this section. Keys are always strings, but without the quotes.
Array, which is an array of values of objects.
Example
A full example of using all these types can look like this:
...
| Code Block |
|---|
resource metafield title {
object {
my_key = "my value"
}
} |
Functions
DCL allows calling predefined functions to do things that are not directly available in the syntax.
...
A set of functions are available out of the box. It is not possible to define custom functions. As an example, the special file function
The available functions are as follows
file(<Relative path to file in the configuration file structure>)- function that can be used to refer to binary files
...
text_file(<Relative path to file in the configuration file structure>)- function that allows the user to have e.g. workflow definitions in separate files in a configuration layer
...
Both function input and outputs are strongly typed, and will be validated.
References
To make it easier to reuse parts between resources and link resources, DCL has a concept of references. References are a way of using a property of one resource in another resource.
...
It is possible to use properties that are not known at compile time. Because of this the config management engine is smart enough to create resources in the correct order. In the above case the meta_group, asset_info, would be created before the title metafield. In the same, but opposite veindirection, if there are no references, direct or indirect between two resources, they are freely be created in parallel.
References can also be passed as arguments to function, in which case the functions will only be called after the referenced properties are available.
String interpolation
All string types support string interpolation, which looks like this:
...