Deploying extensive applications in Kubernetes using Cellery

Prerequisites

Before we get started you need to have Cellery installed in your machine and also have a Cellery runtime setup.

Introduction

Cellery provides a developer runtime, tooling and a management plane which allows developers to run and manage their composite microservice applications on Kubernetes. In this blog, we will discuss how developers can utilize useful capabilities of Cellery when deploying large scale applications.

First clone Cellery sdk repo and go to test-cases/employee-portal directory. There is a sample hr application with 3 cell instances. The root cell instance is hr and it has 2 dependent cell instances; employee and stock.

Following is the cell file of hr cell instance and it defines dependencies to employee and stock cell instances; employeeCellDep and stockCellDep.

hr.bal

Lets assume the 3 cell images created by the user are; hr : myorg/hr:1.0.0 ,employee : myorg/employee:1.0.0,stock : myorg/employee:1.0.0 . First run employee cell instance as described in the readme.

Now only employee cell instance is running and stock and hr employee instances.

hr instance with primary dependencies

Let’s suppose you need to run hr instance but the employee instance is already running. In this scenario, cellery provides a way to run hr instance by providing a link to the already running employee instance. Execute cellery run myorg/hr:1.0.0 -l employeeCellDep:employee -l stockCellDep:stock -d .

running hr cell instance

Here, the link to already running employee cell instance is given by the relation -l alias:instance. Since we provide the flag -d (start-dependencies) the stock instance which is also dependent will get started.

Now lets further improve the hr instance to have transitive dependent cell instance (job and education).

hr instance with transitive dependencies and shared dependencies

In this example we have added two transitive dependencies; “education”: a dependent instance of employee and “job”: shared dependent instance of employee and stock instance. Simply execute cellery run myorg/hr:1.0.0 -n hr -d -s to start the hr instance. Here, by giving the flag -s (share-dependencies) only one instance for of job cell will get started.

running hr instance with shared dependencies

Note that the instance “job100j8s4” gets marked as “shared” in the table above which means it is shared by both employee cell and stock cell. Furthermore, if the links to the dependent cell instances were not provided, random instance names will be generated as seen above.

Users can also provide environment variables for each cell instance in the dependency tree. Simply give -e instance.ENV_VAR=VALUE . For instance, if you need to set “host” name for employee instance as “abc”, execute cellery run myorg/hr:1.0.0 -n hr -l stockCellDep:stock -l employeeCellDep:employee -e employee.host=abc -d . This environment variable can then be used in your application. This is important because multiple instances can have environment variables the same name but different values. For example, there can be another environment variable “host” for the instance employee with the value “xyz”. In that case we can provide that environment variable as -e employee.host=xyz.