Deployment

Table of Contents

Typically we’d run a connected configuration with a Context Management Registry (Kwanza) and its interface and the let the Driver Platform (Manatee) instances which runs on the local desktops connect to the CMR for its configuration. It is however also possible to run the Manatee without the CMR on a standalone configuration by providing it with an initial configuration.

Connected configuration

The software components needed to run this setup are;

Deployment setup

  • A database - we currently support postgresql, rethinkdb and an embedded db for configurations
  • Kwanza Context Management Registry - a server which provides access to the db
  • Cuesta Configuration interface for Kwanza - a web application for configuring flows, manages configurations in Kwanza
  • Manatee Driver Platform - runs on local Windows desktops and interfaces with applications, gets it configuration from Kwanza

Kwanza

Kwanza is distributed as a single binary or as a docker image. Contact us for access to the distribution platform for Kwanza if you haven’t already got a version.

Pre-requisites

  • a valid SSL certificate (and private key), e.g. from letsencrypt.org, it should match the location (url or ip address) you plan on running Kwanza from
  • [optionally] a database (not needed if you’re using the embedded db option)

Installing and running the Kwanza binary

Run the kwanza serve command with suitable arguments. Running kwanza serve --help will display available options (here shown for v2.0.0):

$ ./kwanza serve --help
Command will start registry, connecting to the given database.

Usage:
  kwanza serve [flags]

Flags:
      --cluster             Enable cluster mode
  -d, --database string     Database connection url (default "rdb://localhost")
  -p, --port int            The port Kwanza will listen for requests on (default 8000)
  -s, --salt string         The salt used for checking hashed passwords (default "kwanzified")
      --typeprefix string   Optional type prefix to add to all types
      --verbose             Enable verbose (debug level) logging

Global Flags:
      --auth [none|jwt]   The mechanism by which to authenticate. Allowed values: 'none' (default) and 'jwt'. (default none)
      --cert string       The location (relative to pwd) of the certificate/public key. (default "cert/kwanza.pem")
      --config string     config file (default is $HOME/.kwanza.yaml)
      --key string        The location (relative to pwd) of the private key. (default "cert/kwanza.key")

E.g.

$ ./kwanza serve --auth jwt --database rdb://foo:[email protected]:1234 --port 6000

will start an instance which

  • connects to a RethinkDB database running on localhost:1234 with username foo and password bar
  • serve http requests on port 6000 and grpc on port 6001
  • use jwt as authentication mechanism

Cuesta

Cuesta is the configuration interface for Kwanza. It consists of static html files and javascript and can therefore be served by any webserver. Simply place the files in location served by an http server and it should work. It is also available as a docker image (nginx serving the files).

Only configuration (hardcoded at build-time) is the location of the Kwanza to connect to. Cuesta must therefore be built specifically for a deployment.

Manatee

The Driver Platform (Manatee) is distributed as a machine-wide installer (.msi file) or as a per-user installer (.exe file) as well as a hybrid of the two.

Machine-wide

The machine-wide installer should be used for rolling out Manatee in enterprise environments or in deployments where a normal desktop user does not have administrative rights. Using the machine-wide installer means that:

  • The application will not self-update.
  • All users for a given machine will get the application installed.
  • The application will not automatically be started when the installer is done.

The installation process is straightforward, simply run the .msi file. It should not show any UI and will install shortcuts in the startmenu.

Per-user

The per-user installer should be used when individual users themselves are responsible for installing software on their own machine. It has the properties that:

  • The application will automatically update when new versions are released.
  • The application willl only get installed for the one user running the installer.
  • The installer will start the application when it has been installed.

The installation procedure is the same as for the machine-wide installer.

Hybrid

The hybrid installer is an .msi file which is intended to be run either by each individual user or by an administrator. It will install the application for the each user when the user next logs in on the machine using the per-user installer. Its intended use is for situations where an .msi installation is the only viable option (enterprise environments) but the automatic updates are considered critical.