Deployment Diagram - BitnobiInc/RA-BitnobiPilotJuly2020 GitHub Wiki

• Bitnobi UI is accessed through a browser.
• Currently only the Google Chrome browser is supported.
• the Bitnobi UI is built with the Angular 9 application framework, using the Google Material design components.

This is the server or VM hosting the Bitnobi docker containers. During deployment a Bitnobi home directory is created to hold scripts for initializing, starting/stopping bitnobi, doing backup/restore.

The Bitnobi directory contains sub-directories which are mounted into docker containers to provide shared file persistence. Mounting of host directories for each container are indicated with the broken green lines in the diagram above. These directories include:

Sub directory	Description
config	holds bitnobi_env.list file for setting environment variables for the bitnobi-backend container
data	storage files for MongoDB
External	holds Python and R scripts and temp files used during workflow execution.
logs	holds Bitnobi log files
nginx	config files and log files for nginx for bitnobi-frontend
tools	command line tools for the operator (e.g. bulk-user-create, list-users. list-attributes)
vault	encrypted vault files

• The frontend container runs an nginx web server to serve up HTML, CSS and Javascript files for the UI. These files are bundled into the frontend container.
• the nginx service also acts as a reverse-proxy for RESTful API calls and the websocket connection to the Bitnobi Main Server (backend).
• by default nginx is configured with a self-signed certificate bundled with the frontend container to provide an HTTPS connection to the Browser. The customer can install their own CA signed certificate to replace the self-signed certificate.

• provides RESTful API (JSON based) to javascript code running in browser.
• uses a websocket connection for live update of notifications and workflow execution state.
• accesses MongoDB server to persist state, store user profile information, etc.
• written in Javascript and running on node.js
• host scripts for managing Bitnobi (e.g. start, stop, backup, restore) are bundled into the backend container. During deployment these scripts are copied to the host bitnobi directory.

• the Bitnobi backend loads a set of rules into OPA. These are updated whenever a policy is modified.
• Bitnobi then calls OPA for authorization and policy management operations.

• the Bitnobi backend processes use a vault service to securely store passwords that Bitnobi uses to access 3rd party systems (e.g. SQL servers, remote Bitnobis)

• Bitnobi main server uses a MongoDB service to hold Bitnobi's persistent state
• also persists temporary data to be analysed by Bitnobi workflows as well as results

• a pool of "worker" containers are created at Bitnobi startup. The workflow server queues Bitnobi user requests to run a workflow. A worker fetches the next workflow execution request from the queue, executes it, then fetches (or waits for) the next one.
• By default 5 workers are started, but additional workers can be started to increase workflow capacity.
• This worker pool model provides a simple mechanism to limit resource use by workflow execution and prevent system overload.
• Once the user runs a workflow, as long as there is an idle worker, the workflow will start executing immediately and go to Local workflow in progress status. However if all the workers are busy, then the workflow will go into Queued for execution status until one worker completes a workflow execution.

• A new container is launched by a worker process each time that Bitnobi workflow Script element needs to execute a Python or R script. This provides isolation from other user’s containers and from backend code.
• The container terminates when the script is completed or the user presses the “Stop” button in the workflow editor, or the user stops an executing workflow..

• hosts jupyter notebooks and launches a separate docker container for each user
• each time a Bitnobi user is created, Bitnobi automatically creates a corresponding account on Jupyterhub using the same userid and password.
• Bitnobi can do data transfer to a specific user’s jupyter notebook
• Jupyterhub is typically deployed on a separate VM.

• HTTPS communications between containers are done on a private docker network and these ports are not exposed in the host or outside the host.
• the nginx container is the only one that exposes a port to the outside world to allow it to be accessed through a browser.

Typically all the Bitnobi docker containers are deployed in the same VM host. We currently support only one instance of each container per deployment (i.e. 1 frontend, 1 backend, 1 MongoDB) and 5 instances of worker containers.