diff --git a/components/influx-client/src/connection.rs b/components/influx-client/src/connection.rs index f9e1225..ecc115e 100644 --- a/components/influx-client/src/connection.rs +++ b/components/influx-client/src/connection.rs @@ -32,13 +32,13 @@ const PARAM_INFLUXDB_TOKEN_FILE: &str = "influxdb-token-file"; /// /// The following arguments are being added: /// -/// | long name | environment variable | default value | -/// |---------------------|----------------------|---------------| -/// | influxdb-bucket | INFLUXDB_BUCKET | `demo` | -/// | influxdb-org | INFLUXDB_ORG | `sdv` | -/// | influxdb-uri | INFLUXDB_URI | - | -/// | influxdb-token | INFLUXDB_TOKEN | - | -/// | influxdb-token-file | INFLUXDB_TOKEN_FILE | - | +/// | long name | environment variable | default value | +/// |---------------------|-------------------------|---------------| +/// | influxdb-bucket | INFLUXDB_BUCKET | `demo` | +/// | influxdb-org | INFLUXDB_ORG | `sdv` | +/// | influxdb-uri | INFLUXDB_URI | - | +/// | influxdb-token | INFLUXDB_TOKEN | - | +/// | influxdb-token-file | INFLUXDB_TOKEN_FILE | - | /// pub fn add_command_line_args(command_line: Command) -> Command { command_line @@ -61,7 +61,7 @@ pub fn add_command_line_args(command_line: Command) -> Command { .help("The API token to use for authenticating to the InfluxDB server.") .group("influxdb-auth-token") .value_name("TOKEN") - .env("INFLUXDB_API_TOKEN"), + .env("INFLUXDB_TOKEN"), ) .arg( Arg::new(PARAM_INFLUXDB_TOKEN_FILE) @@ -72,7 +72,7 @@ pub fn add_command_line_args(command_line: Command) -> Command { .group("influxdb-auth-token") .value_name("FILE") .conflicts_with("influxdb-token") - .env("INFLUXDB_API_TOKEN_FILE"), + .env("INFLUXDB_TOKEN_FILE"), ) .arg( Arg::new(PARAM_INFLUXDB_ORG) diff --git a/fms-blueprint-compose.yaml b/fms-blueprint-compose.yaml index 1f78b41..0302206 100644 --- a/fms-blueprint-compose.yaml +++ b/fms-blueprint-compose.yaml @@ -160,13 +160,13 @@ services: command: "influx" env_file: "${FMS_FORWARDER_PROPERTIES_FILE:-./influxdb/fms-demo.env}" environment: - INFLUXDB_API_TOKEN_FILE: "/tmp/fms-demo.token" + INFLUXDB_TOKEN_FILE: "/etc/forwarder/fms-demo.token" KUKSA_DATA_BROKER_URI: "http://databroker:55556" RUST_LOG: "info,fms_forwarder=info,influx_client=info" volumes: - type: "volume" source: "influxdb-auth" - target: "/tmp" + target: "/etc/forwarder" read_only: true csv-provider: image: "ghcr.io/eclipse/kuksa.val.feeders/csv-provider:main" diff --git a/leda/Setup.md b/leda/Setup.md index 77c2ec1..5ec2214 100644 --- a/leda/Setup.md +++ b/leda/Setup.md @@ -18,69 +18,89 @@ limitations under the License. SPDX-License-Identifier: Apache-2.0 --> -# Setting Up a Leda Image +The components of the Fleet Management blueprint fall into two categories: the *kuksa.val Databroker*, +*CSV Provider* and *FMS Forwarder* components are supposed to run in the vehicle, whereas the remaining +components are supposed to run in a (cloud) back end to which the vehicle is connected via (public internet) +networking infrastructure. -The setup for this FMS scenario assumes a split into components running in the vehicles and components -running in a (cloud) backend. The following page describes how to configure a Leda instance to become part -of this FMS setup. More precisely, we deploy the containers for the feedercan, the fms-forwarder, -and the Kuksa.val databroker with an FMS-specific vehicle model. +All of the components can be run on a single Docker host as described in the [top level README](../README.md). However, the following sections describe a more realistic deployment scenario in which +[Eclipse Leda](https://eclipse-leda.github.io/leda/) is used as the vehicle runtime environment. -## Run Leda -The following steps assume a running instance of Eclipse Leda. For more details see the -[Eclipse Leda Getting Started](https://eclipse-leda.github.io/leda/docs/general-usage/) -This guide was tested with release v0.1.0-M1 of Eclipse Leda. +This guide was tested with release v0.1.0-M2 of Eclipse Leda. -## Backup existing manifestes -In Leda, there are manifests to manage the execution of containers by Eclipse Kanto. During the next steps we -will overwrite some of the default manifests (`databroker.json`, `feedercan.json`). Because of that, -we recommend to backup the existing manifests from `/data/var/containers/mainfests`. +# Start Back End Components -## Copy manifests to Leda -To trigger the execution of the required containers for the FMS setup, copy the manifest files from -`leda/data/var/containers/manifests` in the host to `/data/var/containers/manifests` in Leda: +The containers for the back end components are run on the local host using Docker Compose: -``` -manifests % scp -P 2222 *.json root@127.0.0.1:/data/var/containers/manifests +```sh +# in this repository's root folder +docker compose -f fms-blueprint-compose.yaml up influxdb grafana fms-server --detach ``` -## Create folders in Leda mounted in mainfests -The containers described within the manifests require files that are not present in Leda like the FMS-specific vehicle model. -Therefore, we need to create the paths (e.g,. `mkdir`) in Leda from which the containers try to mount these files which are: +# Start In-Vehicle Coponents -- `mkdir -p /data/usr/fms/dbc` -- `mkdir -p /data/usr/fms/databroker` +The containers for the in-vehicle components are deployed to a Leda instance running on the +same (local) host that the back end components have been started on. +The *FMS Forwarder* running in Leda will then directly connect to the *influxdb* server managed +by Docker Compose. -## Copy required files to leda folders: -Now you can copy the files required by the containers to Leda. Execute in the root of this repository on the host: -``` -scp -P 2222 csv-provider/signalsFmsRecording.csv root@127.0.0.1:/data/usr/fms/csv -scp -P 2222 spec/overlay/vss.json root@127.0.0.1:/data/usr/fms/databroker -``` +Please refer to [Leda's Getting Started](https://eclipse-leda.github.io/leda/docs/general-usage/) +guide for setting up a Leda instance. + +## Stop default Containers + +Leda comes with a set of default containers (including kuksa.val Databroker) that are managed using +Eclipse Kanto's *container-manager*. These containers are defined by means of JSON manifest files in +Leda's `/data/var/containers/mainfests` folder. -## Start backend on host -Besides the in-vehicle containers in Leda, we still need the backend for the full FMS setup. -You can start the remaining containers on the host with: +We will stop and disable some of Leda's default containers, make some changes to the configuration of the +Databroker container and also deploy additional containers. +```sh +# in Leda instance's /data/var/containers/mainfests folder +tar cf manifests.orig.tar * +kanto-cm stop --force -n feedercan +mv feedercan.json feedercan.json.disabled +kanto-cm stop --force -n hvacservice-example +mv hvac.json hvac.json.disabled +kanto-cm stop --force -n seatservice-example +mv seatservice.json seatservice.json.disabled ``` -docker compose -f fms-blueprint-compose.yaml up influxdb grafana fms-server --detach + +## Deploy in-vehicle Blueprint Components + +Some of the Fleet Management blueprint containers require access to configuration files that are not present +in Leda, e.g. the FMS-specific VSS definitions. + +Create the folders in Leda from which the containers can mount these files: + +```sh +# in Leda instance +mkdir -p /data/usr/fms/csv /data/usr/fms/databroker /data/usr/fms/forwarder ``` -## Configure InfluxDB token -The fms-forwarder needs a token to write data into the InfluxDB which has been started on the host. -There are multiple ways to retrieve this token, e.g., through the web-interface of InfluxDB -(localhost:8086). One approach through the command line is the following: +Now copy the files required by the containers to the Leda instance: +```sh +# on the (local) host that you have started the back end components on +docker exec -it influxDB cat /tmp/out/fms-demo.token > /tmp/influxdb.token ``` -docker exec -it influxDB cat /tmp/out/fms-demo.token + +```sh +# in this repository's root folder +# The CSV Provider needs acces to the recording of the signals to play back. +scp -P 2222 csv-provider/signalsFmsRecording.csv root@127.0.0.1:/data/usr/fms/csv +# The kuksa.val Databroker needs to be configured with the VSS definition that also contains +# the fleet management specific signals. The default definition file that comes with Leda does +# not contain these. +scp -P 2222 spec/overlay/vss.json root@127.0.0.1:/data/usr/fms/databroker +# The FMS Forwarder needs to read the token required for authenticating to influxdb. +scp -P 2222 /tmp/influxdb.token root@127.0.0.1:/data/usr/fms/forwarder ``` -You can then insert the token in the `/data/var/containers/manifests/fms-forwarder.json` manifest -in Leda at the bottom of the file as value for +Finally, copy the manifest files to Leda, triggering the execution of the in-vehicle containers: -```json -"config": { - "env": [ - "INFLUXDB_API_TOKEN=" - ] -} +```sh +# in this repository's root folder +scp -P 2222 leda/data/var/containers/manifests/*.json root@127.0.0.1:/data/var/containers/manifests ``` diff --git a/leda/data/var/containers/manifests/fms-forwarder.json b/leda/data/var/containers/manifests/fms-forwarder.json index a62590e..b15633d 100644 --- a/leda/data/var/containers/manifests/fms-forwarder.json +++ b/leda/data/var/containers/manifests/fms-forwarder.json @@ -4,6 +4,13 @@ "image": { "name": "ghcr.io/eclipse-sdv-blueprints/fleet-management/fms-forwarder:main" }, + "mount_points": [ + { + "source": "/data/usr/fms/forwarder", + "destination": "/etc/forwarder", + "propagation_mode": "rprivate" + } + ], "host_config": { "devices": [], "network_mode": "bridge", @@ -42,8 +49,8 @@ "RUST_LOG=info,fms_forwarder=debug", "KUKSA_DATA_BROKER_URI=http://databroker:55555", "INFLUXDB_URI=http://10.0.2.2:8086", - "INFLUXDB_API_TOKEN=" + "INFLUXDB_TOKEN_FILE=/etc/forwarder/influxdb.token" ], - "cmd": [] + "cmd": [ "influx" ] } }