Bahmni distribution - Configurations

Shared Single Instance

This setup is more ideal for single facility e.g. Hospitals OR Multi-tenant SAAS setup (note: current Bahmni is not multi-tenant. There are future plans to leverage location concept in OpenMRS in order to achieve multi-tenancy i.e. using location for logical grouping of data in database to isolate various tenants).

Single Bahmni Instance
Shared node group
1 - * Nodes (depending on the scale)
Single shared database

Multiple Instance on Shared Resources

This setup leverages kubernetes namespace in order to support multiple bahmni instances on the shared infrastructure where every instance have their own Database. This is still single tenant but provides more opportunities to optimize cost by sharing resources. This is more ideal for setting up smaller hospitals or polyclinics in a given geography cluster. Note: scale up and down would impact all the instances. We leveraged this setup to support various development environments on shared infra such as dev, qa, demo etc.

Multiple Bahmni Instance (namespace)
Each instance with their own Database (same RDS)
Shared node group
1 - * Nodes (depending on the scale)

Multiple Instance on Shared & Dedicated Resources

This setup is very similar to above except it also allows allocating dedicated infrastructure resources to one or more instances. This gives more control to scale up or down one or more bahmni instances based on the needs. This may be ideal for supporting bigger facilities into their own nodegroup within a given geography cluster to allow independent scale (e.g. we leveraged this setup to isolate our performance test environment from other development environments).

Multiple Bahmni Instance (in multiple nodegroups)
Each instance with their own Database (shared RDS across nodegroups)
multiple node group
1 - * Nodes (depending on the scale) independently managed in various nodegorups

Setup

Infra

Follow the setup guide to provision the infrastructure. Take a note while creating the resources to decide on what configuration you would want to support - specifically for the nodegroups. For example if you want to configure one shared nodegorup (FOO) with 2 bahmni instances and another dedicated nodegroup (BAR) for single bahmni instance you would have two folders under /terraforms/nodegroups. For reference see nonprod

FOO

// terraform.tfvars
cluster_name         = "bahmni-cluster"
node_role_name       = "BahmniEKSNodeRole"
node_group_name      = "foo"
desired_num_of_nodes = 2
min_num_of_nodes     = 1
max_num_of_nodes     = 2
node_instance_type   = "m5.xlarge"

BAR

// terraform.tfvars
cluster_name         = "bahmni-cluster"
node_role_name       = "BahmniEKSNodeRole"
node_group_name      = "bar"
desired_num_of_nodes = 1
min_num_of_nodes     = 1
max_num_of_nodes     = 1
node_instance_type   = "t3.2xlarge"

Cluster

Bahmni uses Helm Umbrella Chart (Chart of Charts) strategy to deploy Kubernetes cluster. There arent very many great resources to understand umbrella charts but you can refer this document to get the gist of how the charts are assembled using umbrella charts for Bahmni.

For deploying the culster we recommend using the CI (github actions) instead of CLI. Start with forking the repository.

The values represent the configuration for your cluster

a) Services to run in the cluster (toggle ON) e.g

openmrs:
  enabled: true
bahmni-lab:
  enabled: false

b) By default AWS assigns a label with nodeGroup name to each node eks.amazonaws.com/nodegroup=$nodeGroupName. Bahmni uses kubernetes nodeselector to target the pods onto specific nodegroup. In the values.yml we would need to specific the nodegroup where the the bahmni instance is intended to run i.e. dedicated nodegroup or shared. e.g. if you want to target BAR nodegroup then your values.yml would have global nodeSelector (where bar is the nodeGroup name)

c) The deploy pipeline accepts the ENVIRONMENT input argument to represent the namespace in the kubernetes cluster. You can have one or more namespace share the same nodegroup.

Bahmni uses AWS ssm parameter to manage the application environment values and secrets. You would need to add the respective environment values in SSM (based on the bahmni services you are running e.g. OpenMRS, Crater etc) before running the umbrella chart pipeline. Consider only keeping the parameters you need in the setupEnvSecrets.sh