Custom configuration

Search…
The Mitter.io docker container comes with some parameters that are configurable. In its current format the configurability is quite limited and we plan to add a lot more options very soon.
Basic configuration
When running the container the following environment variables can be provided:
1.
APP_AUTHORITY_NAME - The name used to issue JWT tokens to users. On the cloud instance it is mitter-io
2.
API_ENDPOINT - The publicly resolvable address for the API server.
3.
DASHBOARD_ENDPOINT - The publicly resolvable address for the dashboard. This is not required to be modified unless you are extending the docker image and need some services to use the dashboard externally.
Specifying an APPLICATION_CONFIG
To further configure the running services, you can also supply an APPLICATION_CONFIG containing key-value pairs for various properties. The two environment variables used would be:
1.
CENTRAL_APPLICATION_CONFIG - This passes an application configuration object to the API server.
2.
DASHBOARD_APPLICATION_CONFIG - This passes an application configuration object to the dashboard.
On the command line you would supply them using:
1
docker run -eCENTRAL_APPLICATION_CONFIG='{\
2
    "mitter.property": "value"\
3
}' mitterio/mitter:sa
Copied!
Since this can get quite lengthy to type and manage on the CLI (especially with the newlines), it is recommended to store the configuration in a file, let's say mitter.api.config and mitter.dashboard.config with the specific JSON and then supply it using:
1
docker run -eCENTRAL_APPLICATION_CONFIG=`cat mitter.api.config` \
2
           -eDASHBOARD_APPLICATION_CONFIG=`cat mitter.dashboard.config` \
3
            -p11901:11901 -p11902:11902 mitterio/mitter:sa
Copied!
Do note that you cannot nest JSON properties, the entire property path must be specified as a single string in the key. You can, however use integer/boolean values when applicable.
The supported properties are covered in the following sub-sections.
Configuring the signing key for JWTs
By default a random string is used for signing the JWTs for user authorization. This might not always be desired (although will always work if the JWTs are being verified by no other than your running container) and can be overridden using (along with other parameters for JWTs) the following in CENTRAL_APPLICATION_CONFIG:
1
{
2
    "mitter.security.jwt.issuer": ".. your issuer name ...",
3
    "mitter.security.jwt.validity": 1000, // Milliseconds
4
    "mitter.security.jwt.signing-key": ".. your key, base64 encoded .."
5
}
Copied!
Configuring an external broker
To push messages via websockets from multiple docker containers behind a load balancer you will need to enable a rabbitmq server that can act as a central broker between the multiple containers.
NOTE This feature is currently experimental and not officially supported.
A test container can be run simply using:
1
docker run rabbitmq
Copied!
Refer to the rabbitmq documentation to find out the following information:
1.
The port the RabbitMQ server is running on
2.
The username and the password.
Then enable the broker by adding the following in CENTRAL_APPLICATION_CONFIG:
1
{
2
    "mitter.delman.websockets.broker.enabled": true,
3
    "mitter.delman.websockets.broker.host": ".. host ..",
4
    "mitter.delman.websockets.broker.port": RABBITMQ_PORT,
5
    "mitter.delman.websockets.broker.username": ".. rabbitmq username ..",
6
    "mitter.delman.websockets.broker.password": ".. rabbitmq password .."
7
}
Copied!
Storing media in S3
If you do not wish to store media from messages (file messages, image messages etc.) locally where your container is running but instead on AWS S3 then you can configure the media storage to do so.
NOTE When images are stored in S3 there is no access protection mechanism active. You must designate a publically-accessible bucket that can be accessed by anyone. This is not recommended if you are handling sensitive data.
NOTE This feature is currently experimental and not officially supported.
To configure the API server to store media in S3, set the following keys in your CENTRAL_APPLICATION_CONFIG:
1
{
2
    "mitter.media.store.minio.enabled": false,
3
    "mitter.media.store.s3.enabled": true,
4
    "mitter.media.store.s3.bucketname": ".. S3 bucket to store media in ..",
5
    "mitter.media.store.s3.aws.access-key": ".. aws access key ..",
6
    "mitter.media.store.s3.aws.access-secret": ".. aws secret key ..",
7
    "mitter.media.store.s3.aws.region": ".. aws region ..",
8
}
Copied!
Using an event bus
You can also have the docker container send installation-wide events to an AWS SNS topic. The events sent on event bus are extremely granular and can result in a huge flux of messages to your message queue. Most use-cases can be solved by using a simpler and minimal Webhooks interface.
NOTE This feature is currently experimental and not officially supported.
To configure an AWS SNS queue to receive all events on your installation, set the following keys in CENTRAL_APPLICATION_CONFIG:
1
{
2
    "mitter.eventing.entbus.enabled": true,
3
    "mitter.eventing.entbus.sns.topic-arn": ".. aws sns topic ..",
4
    "mitter.eventing.entbus.sns.aws.access-key": ".. aws access key ..",
5
    "mitter.eventing.entbus.sns.aws.access-secret": ".. aws secret key ..",
6
    "mitter.eventing.entbus.sns.aws.region": ".. aws region .."
7
}
Copied!
Get mitter.io
Next - Getting started
Build Your First Android App
Last modified 2yr ago
Copy link
Contents
Basic configuration
Specifying an APPLICATION_CONFIG
Configuring the signing key for JWTs
Configuring an external broker
Storing media in S3
Using an event bus