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 toaura/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 avoidlocalhost
.AURA_HOST_PROTO
: Defaults tohttps
. Set tohttp
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
(ifengine-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 port8000
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.