Skip to content

README.md

Latest commit

 

History

History
90 lines (61 loc) · 6.33 KB

README.md

File metadata and controls

90 lines (61 loc) · 6.33 KB

Argos Compose Profiles System

Quick start

argos.sh

The argos.sh (from the root directory) can be used on sh OSes to quickly get up and running.
Its syntax is

./argos.sh <profile> <docker cmd>

where profile could be one of the below profiles (see the table), or client-dev and the cmd is the normal argument passed into docker compose, such as up -d to start the process and fork to background. Make sure to down with the same profile that you used up with!

Profiles & your own setup

Profiles:

Name Usecase Scylla Siren Client Database
brick Device connected to base station to collect data No rate limit On base station External (router) Active
router The base station collecting on a rate limit and hosting Rate limited Active, bridging to car Active Active
tpu The on-car data collection node Rate limited External (TPU OS) None Active
client-dev To develop the client with a working backend Rate limited Active None (run your own pointing to localhost) Active
scylla-dev To develop scylla with a working frontend None (run your own pointing to localhost) Active Active localhost (MUST BUILD FIRST) Active

The base docker compose (compose.yml) contains some important features to note. However, it is useless standalone. Please read the profile customization selection below before using the base compose.

  • It persists the database between down commands via a volume named <project>_db-data (e.g. odyssey_client-dev_db-data for the default client-dev stack). Wipe it with ./argos.sh <profile> down -v or docker volume rm <project>_db-data to start with a new database next up.
  • It weighs the CPU usage of siren higher, so it is prioritized in CPU starvation scenarios.

These profiles are non-exhuastive, there are plently of use cases these profiles do not cover. In that case, you can write your own profile to cover it.

Running multiple dev stacks side-by-side

Every published host port in the dev compose files reads from an env var with today's value as the default: ODYSSEY_DB_PORT (5432), SCYLLA_HOST_PORT (8000), CLIENT_HOST_PORT (80), SIREN_MQTT_PORT (1883), SIREN_WS_PORT (9002), GRAFANA_HOST_PORT (3002). With no env vars set, behavior is byte-identical to before.

To run a second dev stack alongside the first, set those vars (shifted to free values) plus STACK_OFFSET=N, which argos.sh appends to the project name as _N so down, logs, and exec target the right stack:

# stack 1 at defaults
./argos.sh client-dev up -d

# stack 2, shifted by 10 — each profile only consumes the vars its services need.
# Use 'env' so the vars don't leak into stack 1's teardown.
N=10
env STACK_OFFSET=$N \
    ODYSSEY_DB_PORT=$((5432+N))   SCYLLA_HOST_PORT=$((8000+N)) \
    CLIENT_HOST_PORT=$((80+N))    SIREN_MQTT_PORT=$((1883+N)) \
    SIREN_WS_PORT=$((9002+N))     GRAFANA_HOST_PORT=$((3002+N)) \
    ./argos.sh fake-data up -d

# Teardown: stack 1 needs nothing; stack 2 only needs STACK_OFFSET since
# 'compose down' targets containers by project name, not by port.
./argos.sh client-dev down
STACK_OFFSET=$N ./argos.sh fake-data down

STACK_OFFSET is purely a project-name suffix: any non-empty value (including 0) creates a separate compose project, so don't set it when running production profiles. Production profiles (router, brick, tpu) are unaffected when run with no env vars. Multiple ng serve clients and multiple cargo run scyllas are already supported via the existing port flags and are independent of this.

Examples with and without profiles

  • To send some simulated data to a client you are running with npm: ./argos.sh client-dev up
  • To start a mqtt server with simulated data you want to send to an instance of scylla running through cargo: docker compose -f ./siren-base/compose.siren.yml -f ./compose/compose.calypso.yml up

Customizing runtime profiles of the project via docker compose

This project uses docker compose overrides to secify configurations. Therefore there are multiple "profiles" to choose from when running in production, and there are some profiles for development testing. Also, there are fragment files for siren and client in siren-base and angular-client respectively, as they are services only used in certain cases. These profiles are specified via the command line on top of the base compose.yml file as follows.

docker compose -f compose.yml -f <override_file_name> <your command here>

Additionally if you need to create your own options, you can create a compose.override.yml file in this directory and specify what settings should be changed, which is ignored by git. If you think the override would become useful, document it here and name it compose.<name>.yml.

Examples:

Router deploy and send to background: docker compose -f compose.yml -f compose.router.yml up -d

Build and deploy

Using the above profiles, one can build the app. Then, with correct permissions, you can push the app then pull it elsewhere for usage. Note that you must push and pull on the same architecture, so you cannot use for example a dell laptop to build for the router! To get push permissions, create a PAT here and copy the token into this command:

sudo docker login ghcr.io -u <gh username> -p <token>

Now you can update the image on a remote server. Note to save time you can just specify which service to upload, like scylla-server or client.

sudo docker compose -f compose.yml -f compose.router.yml build && sudo docker compose -f compose.yml -f compose.router.yml push