Local (LAN) dashboard server & browser extension for extended reporting, measurement and control of Netrics experimentation.
This repository provides the source code behind the Netrics local dashboard and browser extension. Basic orchestration for the local dashboard is also provided, via Docker, as well as for its required ndt-server.
Docker images are stored in Docker Hub: netrics-dashboard and ndt-server.
To provision a Netrics device, a bootstrapping script is maintained under bin/netrics-docker-run.
This script is intended for execution from the Netrics device. To execute this script from another network-connected device (e.g. your laptop), any tool such as SSH should be sufficient.
Tip
|
The below covers installation of a specified version of the local dashboard. Or query the latest release (via curl -s --head https://github.com/chicago-cdac/netrics-dash/releases/latest | grep location: |
To execute the script on a Netrics device and provision it with the local dashboard – version 0.2.0 – without cloning this repository:
curl -s https://raw.githubusercontent.com/chicago-cdac/netrics-dash/0.2.0/bin/netrics-docker-run | bash
Tip
|
The Netrics device is generally network-accessible at host name
netrics.local and this will be assumed below.
|
To execute the script from your laptop and provision your Netrics device with the local dashboard – version 0.2.0 – without cloning this repository:
curl -s https://raw.githubusercontent.com/chicago-cdac/netrics-dash/0.2.0/bin/netrics-docker-run | ssh ubuntu@netrics.local
Or, from a repository clone:
<./bin/netrics-docker-run ssh ubuntu@netrics.local
The local dashboard is then accessible at http://netrics.local/.
As the target artifact of development is the Docker image, the Docker CLI is the development environment’s core requirement.
All development and orchestration tasks are defined (akin to the Makefile
)
by the manage.py
Python module, which is executed by the manage
command
(see argcmdr).
Development environment requirements beyond the above are therefore slim-to-none. Nonetheless, a Python virtual environment is recommended, (if relatively unnecessary):
-
pyenv (and its extensions) remain among the most powerful development tools by which to ensure Python versioning and library requirements are met.
-
Alternatively, self-management will always do the trick, e.g.:
python3 -m venv .venv . .venv/bin/activate
The development and orchestration environment may be configured and verified via the guided set-up script develop:
$ ./develop
(install) begin
(python-3.7.0) check passed ✓
(cli) install?
1) yes, install { pip install -r requirement/develop.txt }
2) no, ignore
#?
All development and orchestration tasks may be managed via the manage
command.
Get started serving the local dashboard from the cloned repository’s source:
manage serve
Explore management tasks via the --help
flag, e.g.:
manage --help
and:
manage serve --help
Preview tasks' operations via --dry-run
(or -d
):
manage --dry-run serve
And view these as they’re executed via --show
(or -s
):
manage --show serve