Skip to content
dictyBase Developer Docs

Overall Concepts

Deployment

Dictybase deployment strategy is inspired by twelve factor app methodology. Our strategy primarily follows these concepts..

  • Declarative format for automation, such as Dockerfile.
  • Maximum portability across OS, for example both docker and kubernetes could run in all major OS.
  • Suitable for deployment on cloud platforms.
  • Minimum divergence between development and production platforms.
  • Scaling of applications.

Strategy

For deploying, all dictyBase softwares are packaged using Docker. The packaged (containerized) application are generally available publicly from the dictyBase repository of Docker Hub. Each repository in the Docker Hub will be linked to its respective source code in GitHub. The GitHub source code and docker hub repository are linked and the application packages are automatically built from the source code. The package applications (containerized applcations) are then deployed to Kubernetes cluster (manages lifecycle of containerized applications). For development platform of kubernetes, we use Minikube and for production we use Google Container Engine.

Concept

Application deployments are managed by grouping them into virtual application stack where every stack provides a particular service (shares similar functions). In other words, each stack can also be considered as multi tiered applications.* Every stack is generally consists of the following core applications

  • Backend: Application that provide storage, for example, postgresql database application.
  • API server/middleware/microservice: Application that provides HTTP(and grpc) endpoints to access data from the backend based on an specified API.
  • Frontend: A ReactJS based application that runs in a web browser and fetches data through API server.

So, overall a basic stack is organized as

frontend <--> api server <---> backend.

Now, there are other applications that might be part of some stacks. These are generally management applications to run one-off tasks(runs to completion).

  • Schema loader: Application that loads/manage database schema in the backend.
  • Data generator: Generate or pre-process raw data to make it compatible for loading. Unless the data is embeddable, it should be a S3(or compatible) bucket. For our case we are using minio for production and development.
  • Data loader: Bootstrap the backend with initial data. Unless the data is embeddable, it should be made available from a S3(or compatible) bucket. For our case we are using minio for production and development.The generated data is generally loaded in batch.

Common checklist and steps for installing charts

  • Make sure you have added the correct repositories. If not, add them with helm repo add command.

helm repo list

  • Check for available dictybase charts

helm search -l dicty

  • Update repositories

helm repo update

  • Always add the --namespace dictybase parameters for deploying every chart, otherwise they might not work as expected.

  • At least aware about different configuration parameters and their default values(if any) of the chart you are deploying. The README.md of every accompanying chart is available here. If no README.md is available, read through the values.yaml file, it is generally more or less annotated for understanding.

  • In addition, use helm inspect <chart-name> to check for all configurable options.

  • Configuration parameters could be set either from command line --set something=xxxx or through a yaml file or a combination of both.