Problem with manage.py about trax

[agateblue]

Thank you for your issue, and congratulations on being the first one to actually open an issue on the repository (apart from me, of course). There is indeed an issue I can reproduce, locally.

You can fix it by editing your .env file, updating DJANGO_SETTINGS_MODULE=config.settings.production to DJANGO_SETTINGS_MODULE=config.settings.local.

I'll push a fix to the documentation so other people don't hit face the same issue.

I´d really like to see trax more modular and better documented to integrate it into our running Mattermost instance.

I'm not sure what you mean by more modular, but I can sure help with the documentation. It would be really great if you could open a dedicated issue, pointing to unclear / not good enough parts of the documentation, I'd be more than happy to work on that.

I´m not very familiar with Docker and have no idea what went wrong.

Docker is used as the privileged deployment method because it should make things simpler. Trax requires five services to work properly:

1. A database (PostgreSQL)
2. A web server (Nginx)
3. An application server (Django / WSGI)
4. A cache server (Redis)
5. (optional) A task process to run recurring tasks, such as sending reminders, or stopping too old timers.

While you could deploy this by yourself and make the whole thing work, it would require a lot of plumbery and knowledge of how the underlying systems works (how to configure a database, a redis servir, a Nginx server, etc.).

The idea is to avoid that by using Docker, which will spawn and configure each service automatically, running them into isolated containers, thanks to the docker-compose.yml file. It also offer additional security out of the box, since containers are isolated and not reachable publicly. For example, the PostgreSQL server, running in a container will only be accessible by the application server container, meaning you don't have to configure your firewall to block access to it from external world.

[agateblue]

You can see a special mention in the documentation regarding the whole .env file setup.

[elpatron68]

Hi @EliotBerriot,

first of all thanks for your explanations, I will try my luck again if I find some time the next days.

As for users, who already have a productive Mattermost environment, most of the mentioned components are already there. As for our environment we´ve got

• A database (PostgreSQL)
• A web server (Nginx) with SSL certs
• An application server (Django / WSGI)
• A cache server (Redis)
• A task process to run recurring tasks, such as sending reminders, or stopping too old timers.

So I don´t want to setup another VM running Docker and serving a complete Mattermost ecosystem just for the benefit of an easy deployment of the few missing parts.

Nevertheless: Thanks for this great integration!

Regards,
Markus

[agateblue]

Please note that mattermost is provided in the development docker-compose file, so you can test your code changes locally directly in a fully working mattermost instance (in case you don't have another accessible mattermost instance).

However, in production, we assume you already have a separate, working mattermost instance, as shown in the deployment documentation.

When you want to try trax locally, you usally want to spend the less time possible on configuration, this is why the dev.yml docker-compose file is provided.

Now, regarding deployment, the good new is you can totally reuse your Postgres instance to store trax data. You just need to provide a DATABASE_URL variable in the .env file, such as DATABASE_URL=psql://user:password@yourdatabaseip/database. I have to admit it is not documented, but it is possible.

You can also use your existing nginx server, using a proxy_pass directive pointing to the trax container.

To get rid of the services you don't want in production, just edit the example docker-compose.yml file, removing any service you don't want to keep (such as postgres and nginx):

version: '2'

services:

  django: &django_base
    build:
      context: .
      dockerfile: ./compose/django/Dockerfile
    user: django
    depends_on:
      - redis
    command: /gunicorn.sh
    env_file: .env
    ports:
      # Here you can provide another port for your host machine to bind the container port on.
      # For example, set 8001:5000 to have your trax instance accessible locally on port 8001
      # You can then configure your own nginx to proxy pass to 127.0.0.1:8001
      - 7087:5000
    
  worker:
    <<: *django_base
    command: python manage.py trax_schedule
 
  redis:
    image: redis:latest

This way, you keep only the services you want, while keeping the flexibility of using docker for the trax-related containers. If you really don't want to use Docker, even for trax processes and redis, you can install and launch them by yourself, but it will require more configuration. You can start by looking at compose/django/Dockerfile to see what should be installed and how.

[elpatron68]

Hi @EliotBerriot, this seems to be a good approach, I only had a problem with redundant services. Using Docker for hosting Trax and it´s direct dependencies is totally okay for me. Thanks a lot again!

[agateblue]

Sure, keep me informed if you face any issue :)