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.
The software components needed to run this setup are;
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.
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. The supported databases are: - git, use url of the form https://<location-of-remote-git-repo> or file://<location-of-local-git-clone> - postgresql, pg://<user>:<pass>@<host>:<port>/<name-of-database> Usage: kwanza serve [flags] Flags: --cluster Enable cluster mode --color string Optional color to be shown in admin interface etc (default "blue") -d, --database string Database connection url (default "git:///tmp/kwanza") --expvarsPort int The port from which to serve expvars, -1 to disable (default 8080) -h, --help help for serve --install Install the service with the given arguments -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 --uninstall Uninstall the service --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")
$ ./kwanza serve --auth jwt --database pg://foo:bar@localhost:1234 --port 6000
will start an instance which
6000and grpc on port
jwtas authentication mechanism
Only configuration (hardcoded at build-time) is the location of the Kwanza to connect to. Cuesta must therefore be built specifically for a deployment.
Perhaps the easiest approach is to run a
docker setup. In that case inspiration may be had from the following
version: '3' services: kwanza: image: registry.gitlab.com/sirenia/dist/kwanza:v2.4.1 restart: unless-stopped environment: KWANZA_DATABASE: pg://postgres:postgres@postgres/kwanza KWANZA_CERT: "/cert/cert.pem" KWANZA_KEY: "/cert/key.pem" KWANZA_SALT: <salt-goes-here> KWANZA_AUTH: jwt ports: - "8000:8000" # HTTP(S) - "8001:8001" # TCP (gRPC) - "6060:6060" # Profiling volumes: - "/usr/local/etc/sirenia/cert:/cert" - "/usr/local/etc/sirenia/kwanza/conf:/etc/sirenia/kwanza" depends_on: - postgres cuesta: image: registry.gitlab.com/sirenia/dist/cuesta:v1.3.0 restart: unless-stopped environment: CUESTA_CERT: "cert.pem" CUESTA_KEY: "key.pem" KWANZA_URL: "https://<server-fqn>:8000/v1" KWANZA_STREAMURL: "wss://<server-fqn>:8000/v1/stream" ports: - "80:80" - "443:443" volumes: - "/usr/local/etc/sirenia/cert:/cert" depends_on: - kwanza postgres: image: postgres:10 restart: always ports: - "5444:5432" environment: PGDATA: "/data" volumes: - "/root/postgresdata:/data"
This will run a postgres, a kwanza and a cuesta instance and connect them appropriately. You still need to supply postgres logins, certificates and the like as well as access to the docker images for kwanza and cuesta.
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.
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 installation process is straightforward, simply run the
.msi file. It should not show any UI and will install shortcuts in the startmenu.
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 installation procedure is the same as for the machine-wide installer.
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.