Deploying with docker-compose

Docker is a great way to get SOTA running in a clean, reproducible way. sbt can build and publish local docker images to test with, and docker-compose combined with some ATS-provided images makes sure all of SOTA’s dependencies are taken care of.

docker-compose overview

Deploying with docker-compose should be quite straightforward. Assuming docker is running on the deployment system, docker-compose -p sota -f deploy/docker-compose/[filename].yml up should get you a running SOTA system. This depends on the following images:

  • From SOTA

    • advancedtelematic/sota-core

    • advancedtelematic/sota-resolver

    • advancedtelematic/sota-webserver

  • External images provided by ATS

    • advancedtelematic/mariadb

    • advancedtelematic/rvi (optional)

When you run docker-compose, it will first search for those images locally, and if it does not find them, it will pull the ones ATS has published on Docker Hub. To ensure you’re running the latest code, you can build the images locally with sbt docker:publishLocal. To check for updates on the published images, you can do a docker-compose -f deploy/docker-compose/[filename].yml pull, or simply docker pull [image name] to update an individual image.

Deployment options

There are six docker-compose files included in the git repo, under /deploy/docker-compose:

  • docker-compose.yml contains the default SOTA Server components.

  • core-rvi.yml contains the additional RVI server node with environment overrides for the SOTA Core server.

  • core-local-storage.yml contains additional values to configure a data volume for persistent local storage of uploaded packages

  • core-s3-storage.yml contains additional values to configure SOTA Core to use Amazon S3 for persistent storage of uploaded packages

  • client-rvi.yml contains the additional RVI client node for testing with the SOTA Client

  • client-device.yml contains the additional SOTA client for testing

To start the base SOTA Server, run docker-compose -f docker-compose.yml up. To start the SOTA Server with an RVI backend node, run docker-compose -f docker-compose.yml -f core-rvi.yml up. To start the SOTA Server with both RVI backend and device nodes, run docker-compose -f docker-compose.yml -f core-rvi.yml -f client-rvi.yml up.

To start the base SOTA Server with a SOTA Client device, run docker-compose -f docker-compose.yml -f client-device.yml up. Note that you may have to restart some services to ensure proper startup order, e.g. docker restart dockercompose_sota-client_1. You can check logs with e.g. docker logs dockercompose_sota-client_1.

Persistent package storage

By default, uploaded packages will be stored in /tmp inside of the Core docker container, and thus disappear on restart. If you want persistent storage, you have two options: configure an S3 bucket to store uploads, or mount a local directory inside the Core docker container.

S3 Storage

For S3 storage, you will need to set the following environment variables:

  • CORE_AWS_ACCESS_KEY

  • CORE_AWS_SECRET_KEY

  • CORE_AWS_BUCKET_ID

Then, deploy with docker-compose as usual, but with core-s3-storage.yml added. For example,

docker-compose -f docker-compose.yml -f core-s3-storage.yml up

Local storage

To configure a local directory to store uploaded packages, you need to create a directory and give ownership to the user daemon, then pass that directory in the SOTA_PACKAGE_DIR environment variable and deploy with docker-compose as usual, but with core-local-storage.yml added. For example, to use /opt/sota-packages:

mkdir /opt/sota-packages
chown daemon:daemon /opt/sota-packages
SOTA_PACKAGE_DIR=/opt/sota-packages docker-compose -f docker-compose.yml -f core-local-storage.yml up

If your packages aren’t showing up, double-check ownership and permissions.

Cloud deployment

If you want to deploy to the cloud, docker-compose can also help you do that. The easiest way is to use docker-machine’s AWS driver to create and deploy to a remote host.

Connecting a client

Once you have the server up and running, you’ll probably want to set up a client and get it talking to the server. See Building the SOTA Client for build instructions.

Once you have a binary on a client device, you will need to create a device in the SOTA server UI, and then configure the client to use the device ID you just created. Creating the device is straightforward; log into the admin UI (user: genivi, password: genivirocks!), click the Vehicles tab, and add a new one.

To configure the client to use this UUID, please take a look at the detailed configuration instructions available here.

Connecting a client with RVI

If you want RVI communication, you’ll also need to configure your client RVI node with the appropriate device ID. Edit the DEVICE_ID environment variable in client-rvi.yml to match the device you just created, then restart the client RVI node.

GENIVI Software Loading Manager

See genivi_swm on how to run the Software Loading Manager demo. It also contains instructions for creating an update image, which can be uploaded as a package to the SOTA Server.

Now you can create an update campaign on the SOTA Server, using the same update_id as the uuid in the update image you created. Also, as the genivi_swm demo runs as root, remember to run the sota_client as root as well so that they can communicate on the same system bus.

Quickstart

    git clone https://github.com/GENIVI/genivi_swm
    cd genivi_swm
    export PYTHONPATH="${PWD}/common/"
    python software_loading_manager/software_loading_manager.py

As the genivi_swm demo runs as root, remember to run the sota_client as root as well so that they can communicate on the same system bus.