To-do List Runner

First step in building this application will be development of the runner, which will facilitate read/write operations to a MongoDB collection.

Open the Element Screen

Open the Element screen from your Devops app. Unless you've modified your implementation, this screen is located at https://[YOUR_ADMIN_UI_DOMAIN]/app/devops/common/element.

Element Screen

Create a State Element

Next, you will create the configuration for a new data store which will maintain to-do list records in a MongoDB collection.

Click on "CREATE NEW" button on top of the menu lister of Element screen. This will clear the contents of Element design page, and allow you to create a new Element from scratch.

Create New Button

Provide a unique identifier to your new element from top left corner marked with "ID: " tag and a pencil icon. For this example, we are using "state-todo-0001" as the id.

Enter the following details from "DEFINITION" and "STATE DEFINITION" tabs and save:

State Definition Tab

• DEFINITION

  • Element Name: Todo

  • Element Type: STATE

  • Element Status: ACTIVE

  • Element Description (optional): Example todo list data store

• STATE DEFINITION

  • Manager: Mongo State Manager

  • System: mongo_master

  • Collection: todo

These settings will mean that this state will be managed by a MongoStateManager using connection settings provided by the already existing "mongo_master" system element and records will be stored in a collection named "todo".

Why do you need Elements?

Elements provide reusable building blocks for runners. Without such an element structure, you would need to define all configurations, settings and parameters within the runners, which would mean replications and maintenance issues for systems, states or handlers shared between different runners.

Create a Runner

Next, you will create a new runner, which will be responsible for executing read/write operations on the new todo state you defined.

Click on the Runner icon on navigation bar to switch to the Runner screen on your Devops app. Unless you've modified your implementation, this screen is located at https://[YOUR_ADMIN_UI_DOMAIN]/app/devops/common/runner.

Runner Screen

Click on "CREATE NEW" button on top of the menu lister of Runner screen and provide the unique identifier "todo-0001".

Define the Runner

Click on the circled edit icon for displaying Runner definition screen.

Definition Button

Enter the following details on displayed screen for describing your new Runner graph:

Runner Definition Screen

• Runner Name: Todo

• Runner Status: ACTIVE

• Runner Domain (optional): admin

• Base Runners: Base CRUD

• Runner Description (optional): This is an example runner for todo list management.

These settings will mean that the new runner will inherit features from the "Base CRUD" runner, making it possible to perform standard CRUD operations with default read, write handlers.

For this example, you do not need to set I/O or Settings details. Click on the close icon on top right corner to apply changes.

Add Runner Elements

From the stencil, drag and drop a System element to the runner graph.

Runner Stencil

Similarly, drag and drop , a State element from the stencil. Your graph should look like the following after these actions:

Runner Elements

Select System Element

Click on the System element and you will see an edit icon displayed on its top left corner, click on it to edit element details as follows:

System Selection Screen

• Element: system-mongo_master-0001

• Member Type: OPERATION

• Alias: mongo_master

• Description(optional): MongoDB system for master collections

These settings will add the predefined "system-mongo_master-0001" system element to the runner with "mongo_master" alias. This assigned alias automatically links the system to related other elements (such as the State element).

Why do you need Aliases?

We use aliases in addition to element ids when assigning elements to runners. This allows us to replace core elements such as Systems when needed without having to update all other elements dependent on them. It also allows reusing same elements multiple times within a runner, which can be preferred for organization or configuration purposes (e.g. using 2 copies of the same Handler with different parameter overrides).

If you click on the "ELEMENT" tab, you can see parameters assigned to this elements during its initial definition.

System Element Screen

Click on APPLY button to apply changes and close the dialog.

Select State Element

Next, edit the State element in a similar way, with the following details:

State Selection Screen

• Element: state-todo-0001 (as created in earlier step)

• Member Type: OPERATION

• Alias: todo

• Description (optional): State for todo list records

Click on APPLY button to apply changes and close the dialog.

Deploy the Runner

Once your runner is defined, next step is to deploy it to get it up and running. It is possible to deploy multiple runners within a single deployment package, but for this example, you will be deploying the runner as a stand-alone package.

Deployment from within Rierino UI is not enabled for Sandbox deployments. For deploying new runners in sandboxes, they can be added to the existing adminrunner deployment and the Docker container can be restarted to enable the runner. This section focuses on regular K8s deployments.

First, open the Deployment screen from your Devops app. Unless you've modified your implementation, this screen is located at https://[YOUR_ADMIN_UI_DOMAIN]/app/devops/common/deployment.

Create a Deployment

Click on "CREATE NEW" button on top of the menu lister of Deployment screen and provide the unique identifier "example-0001".

Fill in the "DEFINITION" tab with following details:

Deployment Definition Screen

• Name: Example Runners

• Status: ACTIVE

• Description (optional): Deployment package for execution of example runners

• Runners:

  • Name: todo

  • Class: CRUD Runner

  • Element: todo-0001

  • Deployment Version: 1

These settings assign 1 runner with "todo-0001" identifier, which is created in previous steps to this deployment. Runner name has various uses, such as log labeling, targeting runners for commands, forming URL paths, as well as application / consumer naming. Runner class defines the type of Runner to be used for execution (such as CRUD, RPC, Socket or Samza). Deployment version is useful when multiple versions of a runner needs to be running at the same time (e.g. during a systems migration).

Why do you need a Deployment?

Runners define "how" and "what" of microservices to be used, providing an abstraction over "where" these services are deployed. This approach allows separation of configuration and infrastructure responsibilities, while allowing deployment of same runners in different servers (e.g. for multi-national deployments, replication). It also allows coupling of multiple runners into single deployment, for microservices that do not require heavy resources.

Next, switch to the "PARAMETERS" tab and enter the following parameter key-value pairs:

Deployment Parameters Screen

• rierinoVersion: 0.1.1

• template: spring

• namespace: admin-backend

• pool: admin-node-pool

These settings specify the Rierino core libraries and settings to deploy, as well as the Kubernetes namespace and node pool to utilize for creating this runner.

You can increase scalability of your runner by setting replicaCount parameter to 2 or more, or increase its log level by setting logLevel to "DEBUG".

Click on SAVE button to finalize creation of the deployment.

Trigger the Deployment

Next, from the dropdown menu on top right side of the Deployment screen, click on "DEPLOY" button.

Deployment Action Menu

This will automatically trigger a deployment request and you will receive a notification of successful delivery of the request.

Test Your Runner

In case you have access rights to your infrastructure, you can check deployment status of your Runner through the Jenkins interface as well as Kubernetes management portal of your cloud service provider.

Once the runner is up and running, you can use to test its status using your new runner's endpoints for read / write operations on your todo list records. By default, all runners in K8s are deployed in a secure cluster without exposing a public endpoint and are only accessible from within that cluster or through the Gateway Servers.

If you don't wish to wait for setting up the gateway access as described in next section, you can use kubectl commands for this test as follows:

kubectl exec -ti --namespace=admin-backend deployment/runner-example-0001-deployment -- /bin/bash

This will establish connection to your deployed runner, from which you can do REST calls using curl:

#Following should return status:"UP"
curl localhost:1235/actuator/health

#Following should return details of the new record created
curl -X POST -H "Content-Type: application/json" -d '{"data": {"name": "Take out trash", "project": "Personal"}}' localhost:1235/api/todo/todo/1

#Following should return a list including the new record created
curl localhost:1235/api/todo/todo