This guides you through deployment of Harness Server and CLI using published Docker containers with simple Docker-compose container management. This project is typically used as a quickstart in proof-of-concept type settings, not for high demand scalable production deployments.
Contact ActionML other deployment options.
Note: this quickstart uses Harness-0.5.0-SNAPSHOT, which is in pre-release form and not recommended for production.
With Docker Compose, Harness and all dependent services run in Docker Containers, even the harness-cli is installed in its own container. This makes it very simple to install on a single machine or VM but is generally not sufficient for a high-demand production system.
The containers, by default, run in the following configuration:
It is good to become familiar with Docker and Docker Compose and how they work. We do not document them exhaustively here. Harness uses multiple containers and so is more complex than single container deployments.
On the machine you want to host Harness, install:
If you are familiar with Docker and Docker Compose, here is our "one-liner":
git clone https://github.com/actionml/harness-docker-compose.git && cd harness-docker-compose && cp .env.sample .env && docker-compose up -d --build
At this point Harness and the UR are running on
http://localhost:9090. Following the URL or executing
curl localhost:9090 should display
harness-cli can be used by logging in to the harness-cli container. Read on for more about operating the system.
Note: this method for running Harness puts all dependencies in containers, so MongoDB and Elasticsearch are not installed natively on the host. If you already have these services on the host, extra care must be taken that they do not conflict with container versions. We suggest you shut down host installed Mongo and Elasticsearch while running container versions.
The composed containers can be customized via changes to
mapping host filesystem to container filesystem. By default containers have no persistent files and sill loose state if they do not have some portion of the host filesystem to use.
change the environment passed to containers when they are launched.
cp .sample.env .env
.env if the defaults are not adequate.
One important thing to note is that in order to access files for
harness-cli import ... or
harness-cli add <some-engine.json> the file(s) must be accessible from the Harness Server or from the cli. By default we map a directory into the filesystems of both the harness and harness-cli containers:
With the docker tools installed:
docker-compose up -d --buildfor first time setup
Once deployed one or more containers in the collection can be updated. It is best to explore the docker-compose cli and options as well as docker commands. Some useful commands for updates are:
docker-compose downstops all container in the local yaml file. Do this before any other docker-compose updates.
git pull origin <branch>for this repo the lastest vesion under test is in branch
develop, the last stable release is in
gitrepo contains the latest project structure and
docker-compose pullthis will get all updated containers that are available.
docker-compose up -d --build --force-recreateto bring up all updated containers by recreating all images.
Once installed the containers work somewhat like a cluster of virtual machines all running on a single host. You can login to them, examine logs, and start and stop them.
Logs: Harness logs are in the
docker-persistence/harness/... directory and can be
tailed on the host as any local log file. Other containers may have logs available by using:
docker-compose logs <some-container-id>
Monitoring: Simple monitoring can be done by looking at memory, disk and CPU usage since all containers are running on the host. To get more granular several tools allow monitoring individual containers.
The way Docker supports a composed filesystem uses a mapping of container internal filesystem to the host's filesystem. By default they will appear in
harness-docker-compose/docker-persistence/... Be careful with these files, they will contain data for the database and elasticsearch so deleting them will destroy all data in Harness.
The Harness-CLI is also started in a container. To use it, log-in.
docker-compose exec harness-cli bash
This starts a
bash shell in the container, configured to communicate with the Harness container
docker-compose exec harness-cli bash -c 'harness-cli status'
this will return the status of Harness
The harness-cli can also be installed on the host OS as desired. It uses the REST API to control Harness and so can be on any host.
This method requires more prerequisites on the host but can be more convenient than using the harness-cli container.
For fully scalable, clustered deployment of a high demand Harness (+ UR) system we maintain a customizable Kubernetes project that is flexible enough for just about any type of deployment. Because it requires customization, this is not supported as OSS, contact us if you'd like more information
These projects are related and can be used together:
latestfor the current latest stable release. Use
developfor the current work-in-progress of the next release.
harness-clior create Python clients.