To configure the deployment-archive you have to understand a bit about the anatomy of a Chef run. The deployment-archive uses chef-solo which itself allows to define all attribute configurations within a JSON file. In the deployment archive you will find these files below the nodes folder, which corresponds to the global/deployment/chef/nodes folder in the workspace.

Before you take a look at some example files, you should understand the basic structure of a node JSON file and the actual structure defined by the CoreMedia Chef cookbooks.

Basic node structure

The basic structure of each node file consists of Chef attributes in form of an attribute hash and a run_list array, that can contain either roles or recipes.

CoreMedia attributes structure

The CoreMedia attributes structure is defined by the CoreMedia cookbooks below global/deployment/chef/cookbooks. It is recommended to review the README.md Markdown files of each cookbook to see what attributes can be set. Because the set of application properties CoreMedia applications can be configured with is large and changing, you won't find application property attributes defined by the cookbooks but instead a generic way of defining those properties using a hash map associated with each application. A detailed documentation how that is done can be found in the global/deployment/chef/cookbooks/blueprint-spring-boot/README.adoc file.

Note

An attribute declaration in Ruby style corresponds to the same nested structure in JSON.

node['blueprint']['studio']['foo'] = 'bar'

maps to

{
 "blueprint": {
   "studio": {
     "foo": "bar"
   }
 }
}

In the following figure you see the sketched attribute tree. There are 5 different categories of attributes:

Figure 2.1. Attribute Structure

The run_list

The run_list array within the node file can contain roles and recipes. In case of a role, all recipes defined in that role will be populated during the chef run. You should always include the role[base] at the start of your run list and you are not bound to the roles included in the workspace. You are free to modify, replace or delete them to match your deployment needs. The roles included in the workspace are only a proposition for a very simple setup. In most cases it will be more transparent to use the recipes directly.

The node JSON file

If you take a look at an example node file shown in the listing below, you see a configuration how to install a content-management-server configured using a PostgreSQL database.

{
  "blueprint": {
    "maven_repository_url": "file://localhost/tmp/maven-repo",
    "apps":{
      "content-management-server": {
        "application.properties": {
          "cap.server.license": "properties/corem/license.zip",
          "sql.store.driver": "org.postgresql.Driver",
          "sql.store.url": "jdbc:postgresql://postgresql:5432/coremedia",
          "sql.store.dbProperties": "corem/postgresql",
          "sql.store.user": "cm_management",
          "sql.store.password": "cm_management"
        }
      }
    }
  },
  "run_list": [
    "role[base]",
    "recipe[blueprint-spring-boot::content-management-server]"
  ]
}

If you now want to deploy an application that requires a connection to the content-management-server you can simply create another node json file and configure the connection properties accordingly. Let's install the content-feeder application on a different machine, then you could create a node file like the one below.

{
  "blueprint": {
    "maven_repository_url": "file://localhost/tmp/maven-repo",
    "apps":{
      "content-feeder": {
        "application.properties": {
          "repository.url": "http://<CMS HOST>:40180/coremedia/ior",
          "solr.url": "http://<SOLR HOST>:8983/solr"
        }
      }
    }
  },
  "run_list": [
    "role[base]",
    "recipe[blueprint-spring-boot::content-feeder]"
  ]
}