# Deployment

A "Deployment" is a collection of

  • Workflows
  • Environments
  • Secrets
  • Extensions

which are being "deployed" to a Cluster of Reactive Engines. As you can tell, it is not a Project which is being deployed, but a selected subset of the Project's Assets (which could end up being everything in the Project, however).

Reactive Engines run Workflows (not Projects). Deployments stand for moving one or more Workflows on to a Reactive Engine or a Cluster of Reactive Engines. To do so initially we will have to perform the following steps:

Switch the view over to "Project (1) --> Deployments (2)":

Deployment Tab (Workflow Deployment)

A "Cluster Asset" resembles one or more Reactive Engine endpoints which can actually receive and then activate a Deployment. Therefore before we can deploy, we need to define what these endpoints are.

It is possible to create a Cluster either in global scope or Project scope:

  • Project --> The Cluster configuration is specific to this Project.
  • Global --> The Cluster configuration is available independent of a Project. Use this when your Cluster stays the same all the time.

We create a Cluster in the Project:

Create a Cluster (Workflow Deployment)

Our Cluster consists of one Node ("http://localhost:5842") which is the one Reactive Engine running on our local machine.

When do we define many Nodes here? We define many Nodes when

  1. We have a Cluster of many Nodes, and
  2. We want more than one Node to be able to receive a Deployment. In that case if deployment to Node 1 fails, it will try to deploy to Node 2. If that fails then it tries Node 3, until it runs out of configured Nodes.

How a Deployment is distributed in a Cluster

At this point it is important to understand, that a Deployment is automatically distributed to the individual Reactive Engines on separate Nodes within a Cluster. It is part of the concept of layline.io that the one Reactive Engine receiving a Deployment, then automatically distributes it to all other Reactive Engines in the same Cluster. It is not necessary to deploy individually to each Reactive Engine.

Example of how a Deployment is distributed in a Cluster (Workflow Deployment)

Therefore in the Cluster Asset which we define at this stage we only define the Nodes which shall be able to receive a Deployment, not necessarily all of the Nodes in a Cluster (this can also be a dynamically growing and shrinking number of Nodes based on load).

# Creating a Engine Configuration Asset

A "Engine Configuration" is a collection of

  • Workflows
  • Environments
  • Secrets
  • Extensions

which can be deployed together in one go.

We are adding a new one like this:

Creating a Engine Configuration Asset (Workflow Deployment)

  • Tag (1)
    The "Tag" is how we identify the Deployment on the Cluster, once it has been deployed. A Cluster can hold many different Deployments. One of which can be active at any time. Tag names must be unique throughout a Cluster. In the example we rely on a macro (${build:timestamp}) to automatically append the timestamp to the tag.


Trying to deploy a Deployment to a Cluster with a tag which the Cluster already knows (duplicate), will lead to an error.

  • Workflows to deploy (2)
    The Workflows which should be deployed.
  • Environments (3)
    Parameters which are specific to the environment.
  • Secrets (4)
    Secrets (passwords, etc.) which need to be deployed for the specific target.
  • Extensions (5)
    Extension configurations (only for Prometheus for now).

# Deploy to Cluster

The minimum configurations for the deployment to the local Reactive Engine are completed. We can now deploy to the Cluster.

  • In the Engine Configuration you see a blue box at the top
  • Pick as a target type "Deploy to Cluster"
  • Pick as the cluster to deploy the "LocalCluster" which we have defined previously.

Deploy to Cluster (Workflow Deployment)

  • Now click "Execute Deployment to Cluster".

# Login to Cluster

As the Cluster runs independently, it has its own security barrier. In case you are not logged in yet, you will be asked now:

Login to Cluster (Workflow Deployment)

The default login here is also "admin/admin", just like with the Configuration Server. Press "Login".

Check that the Cluster is running and reachable

Make sure it says "Cluster available" at the bottom of the login dialog. If not, then your Cluster Configuration is incorrect, or the Cluster cannot be reached (Reactive Engine may not be running, Network issues, etc.).

# Deploy directly to Cluster

The system will try to

  1. compile a Deployment from the Assets which have been selected in the Engine Configuration (and their dependent Assets), and
  2. send this to the Reactive Engine Node which have configured in "LocalCluster".

Deploy directly to Cluster (Workflow Deployment)

This signals, that the Deployment was successful.

To check, we switch to the Operations --> Cluster Tab. Select the correct Cluster (1).

Select Cluster (Workflow Deployment)

The "Operations" Tab let's us see what's going on on Clusters. It's also possible to perform necessary operations from here. You can select the Cluster from the drop-down box at the top of the Tab.

On the left-hand tree, select Controllers --> Deployment Storage. There we can check our recent Deployment (1):

Check latest Deployment on Cluster (Workflow Deployment)

# Deploy to File

Instead of deploying directly to Cluster, you may want to deploy to a File instead. This is useful, if you want to exchange Deployments asynchronously. A good example would be to transfer a Deployment to another Cluster outside of current reach, or simply to send a Deployment to someone else via email.

To deploy to a file select Write to File (1) from the "Deploy to Cluster" box. Enter a path and filename where to store the Deployment file (2).

The Deployment will be stored in a JSON-file which can be used for upload in a Cluster.

Deploy to zip File (Workflow Deployment)

Last Updated: 4/28/2022, 10:34:19 AM