AURA Web

Deploy AURA Web

All required files can be found under /opt/aura/config/aura-web. For the described commands change to that directory.

Copy the sample.env to .env and set all values as needed.

Update the configuration file

Update at least following environment variables in the .env file:

  • AURA_AUDIO_STORE_SOURCE: The location where Tank is storing audio sources. It defaults to aura/audio/source.

  • AURA_TANK_ENGINE_PASSWORD: The password should match the one you’ll be configuring in AURA Playout. Avoid using the default one.

  • AURA_HOST_NAME: Set the host or domain name where the service are used from. See below why to avoid localhost.

  • AURA_HOST_PROTO: Defaults to https. Set to http if you are running locally.

  • AURA_HOST_CERTBOT_ENABLE: Enable in production in order to get TLS certificates automatically.

  • AURA_HOST_CERTBOT_EMAIL: Set a valid email for certbot.

Defining the host for production setups

You can use a public domain name or any locally defined hostname. For example by configuring aura.local in /etc/hosts. Keep in mind to use a LAN IP though. Using localhost or 127.0.0.1 for the production setup is not supported. Here you’d need to make adjustments on your own or use the dev-setup.

Changing the host

Any update of AURA_HOST_NAME in your .env file is not reflected in the actual configuration. In such cases you either need to manually update the relevant OIDC client database tables, or you simple create new OIDC client IDs in the configuration. After that you can delete any old OIDC clients via the Steering admin interface $AURA_HOST_NAME/steering/admin/oidc_provider/.

In case you have deployed AURA Playout to a different instance, also set the value for AURA_ENGINE_API_INTERNAL_URL.

Initialize the Steering container:

docker compose run --rm steering initialize

Start the services with Docker Compose:

docker compose up -d

We use named volumes for the data-volumes. That way all data will live in your docker-directory.

This deployment will make AURA Web reachable in the following way:

  • Dashboard is reachable directly under the domain given as $AURA_HOST_NAME

  • Steering is reachable under /steering

  • Tank is reachable under /tank

  • Track Service endpoints of engine-api will be reachable under /trackservice (if engine-api is running)

  • Icecast: If you enabled the optional Icecast server for the reverse proxy it will be reachable under /icecast. If you only enabled it, it will be reachable under port 8000 of the machine running AURA Web.

  • Dashboard Clock will be reachable from the configured network under the configured port. If you enabled it for the reverse-proxy, it will be reachable under /clock.

Create sample data using fixtures

Fixtures are required for now

Currently you need to install the fixtures in order to make Aura Web working correctly. We will change this in a future release.

In case you want to setup the fixtures with initial sample data, you need to bash into the running container via

docker compose exec steering bash

and then install the program fixtures by using the command

poetry run ./manage.py loaddata fixtures/program/*.json

Check the logs

Now everything should be up and running. You can check the logs with

docker compose logs -f --tail=100 <service-name>

See Maintenance and updates for more Information.

NGINX and Reverse Proxy

In the AURA Web setup all services are made reachable behind a reverse Proxy. For this NGINX is used. Here we also offer support for using SSL via Let’s Encrypt.

Be aware that the docker-compose by default opens ports 80 and 443. If you want to run AURA Web behind a reverse proxy on a different machine, you can just use port 80 of this machine. At the moment running another reverse proxy on the same machine isn’t supported with this setup, since there’s no possibility to close ports with an override.

If you wish to not use the NGINX whatsoever, you can override the docker-compose with the following content:

services:
  nginx:
    deploy:
      replicas: 0

This disables the internal NGINX. Keep in mind the nginx does a lot of heavy lifting to handle all redirections and URL rewrites correctly, which you will then need to handle manually.

If you wish to expand the nginx-config you can put further configs into the custom-folder. Keep in mind the configs need to end on .conf.

Extending the settings for Steering

If you need to extend the settings for steering, you can first make the necessary adjustments to the Docker Compose setup in a docker-compose.override.yml file.

# docker-compose.override.yaml
version: "3.4"

services:

  steering:
    environment:
      DJANGO_SETTINGS_MODULE: steering.production_settings
    volumes:
      - ./production_settings.py:/steering/steering/production_settings.py

This will point Django to the new settings module and mount the local production_settings.py file into the steering container.

Then, you need to create a new production_settings.py file with all that you need.

Refer to steering/sample_settings.py in the steering repository on how to load and override the settings, and to the Settings Reference for the available Django settings.

Creating Timeslots

Currently the start time of the timeslots created via the dashboard differs from the start time that is actually stored. Therefore you need to create your timeslots one hour in the past. Yes, we are working on this time travel problem steering#116.