How to run trytond with nginx + supervisord + uwsgi

This tutorial explains How to get up and running trytond with Nginx as a reverse proxy and trytond as a backend with supervisord + uwsgi configurations.

  • The package tools as nginx, supervisord and uwsgi would be explain with a debian distribution but should be very similar with other linux distributions.
  • The domain as example would be example.tryton.org
  • The installation of trytond would not be cover on this How to. pypi installation it’s the most probably installation to a production enviroment so that would be expect to set up a uwsgi configuration.
  • IP 192.168.1.1 it’s where backend trytond is running.
  • PORT 8000 it’s where backend trytond port is running.

Set Up nginx

Install nginx package

apt install nginx

Set up a new virtualhost

  • Create a new file called example.tryton.org.conf at /etc/nginx/sites-available.
server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2; 

  server_name example.tryton.org;
  ssl_certificate /etc/letsencrypt/live/example.tryton.org/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.tryton.org/privkey.pem;
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_prefer_server_ciphers on;
  ssl_verify_client optional_no_ca;

  location / {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_pass http://192.168.1.1:8000;
  }
}

server {
  listen 80;
  listen [::]:80;

  server_name example.tryton.org;
  return 301 https://example.tryton.org$request_uri;
}
  • Create a symlink from sites-available to sites-enabled.
cd /etc/nginx/sites-enabled
ln -svf /etc/nginx/sites-available/example.tryton.org.conf .

Reload nginx service

  • Verify that yours configuration are OK.
nginx -t 
  • Reload nginx service
service nginx reload

Set Up trytond backend

Installation of trytond would not be cover on this How to, but the idea is to run a production enviroment, so pip installation would be expected.

uWSGI

The uWSGI project aims at developing a full stack for building hosting services.

Application servers (for various programming languages and protocols), proxies, process managers and monitors are all implemented using a common api and a common configuration style.

Install uwsgi

apt install uwsgi uwsgi-plugin-python3 

Create a uwsgi configuration

[uwsgi]
http-socket=0.0.0.0:8000
master=true
plugins=python3
wsgi=trytond.application:app
cheaper=4
processes=16
threads=16

Note: If we set up our trytond inside a virtualenv we should add this line to the uwsgi.conf

virtualenv=/path/to/env

Supervisord

Supervisor is a client/server system that allows its users to control a number of processes on UNIX-like operating systems.

Installation

apt install supervisor

Configuration

Create a new config file under /etc/supervisor/conf.d/ called supervisor_tryton.conf. The contents of the file should be something like

[program:trytond]
command=uwsgi --ini /path/to/uwsgi_trytond.conf
autostart=true
autorestart=true
startretries=3
numprocs=1
stopwaitsecs=10
stopsignal=INT
redirect_stderr=true
environment=
    TRYTOND_DATABASE_URI="postgresql://db_username:db_password@db_hostname:db_port"
    TRYTOND_LOGGING_CONFIG="/path/to/trytond_tog.conf",
    TRYTOND_CONFIG="/path/to/trytond.conf",
    PYTHONOPTIMIZE="1"

Update supervisor

You need to update supervisord so reads the new configuration

supervisorctl update

start trytond daemon with supervisord

supervisorctl start trytond

Conclusion

That’s it!

You should go to https://example.tryton.org and tryton set up should be up and running!
Enjoy!

4 Likes

I have some issues with such tutorial which are:

  • pick arbitrary some stack of software (nginx, supervisord and uwsgi) when there are alternatives
  • it is based on specific distribution (e.g. configuration file of nginx, usage of service)
  • it will be difficult to maintain due to all the different stack used

Also I do not see who is the target audience. People who can not make such similar setup should probably be directed to using docker image (where most of this is already prepared and many tutorial exists for the extra stuff like ssl etc.).

Finally I have also an issue because it is not explained how trytond is installed but then uwsgi configuration presuppose it is system wild (which is not really recommended but virtualenv is more often preferred).

Need to install plugin python3:

Install uwsgi

apt install uwsgi uwsgi-plugin-python3 

and in your supervisor configuration, you should also add TRYTOND_CONFIG=“…” in your environment variable.

I’m really grateful for this HOWTO, thank you, @lukio.

Tryton is lacking these to an extreme extend. We are wasting so much time, over and over again, to investigate basic installation and handling, because we do not have a structured collection of advice on the very basics.

“Code is documentation” does not work. At least not for a considerable fraction of us.

1 Like

The pick is not arbtrary, uwsgi is the alternative choice of our images of docker. nginx is the most know as a reverse proxy system, and if you look at internet I believe is the most use by our community, and as I look for recomendations on this site when you talk about reverse proxy, you said “reverse proxy (ej nginx)” several times.

I prefered to use supervisord to exaplain it because it doesn’t care about your dsitribution, it could be debian, centos gentoo archilinux slackware or whatever (sysV or systemd systems). Of course I’m talking about gnu/linux system, and not under Windows servers.

The package installation, yes, it’s under debian distributions, but I’m clarifing that it would be similar under other distributions at the very top at the article.

I understand the usage of service, but the configuration file of nginx it’ would be similar to whatever distribution. If you are talking about the paths, probably if you know your system, you can set it up under the path that your distribution needs. The idea of this article is to let know the community more the content of the nginx/uwsgi/supervisord configuration files and how are they linked.

If someone found this article in 5 years, and like to use and it does not work, I believe the comunity would fix it.

Docker it’s good, and I work with docker more often under development and not to set it up my production servers. Not everyone wants or can do it with docker containers so that’s why I believe it should be nice to have this things explains. Also, probably you can achieve all of this configurations if you take your time and look for into this site, or our previous forum (under googlegroups). The idea of this article it was to have just one place to let the community known how to set it up.

Under the uwsgi section it says:

Note: If we set up our trytond inside a virtualenv we should add this line to the uwsgi.conf

virtualenv=/path/to/env

Cheers!

On almost every distribution systemd is installed. Even a lot of people don’t like it, it’s the standard these days and no need to install extra packages. Also some distributions have SELinux active which can bite you.

I have had a lot of trouble with uwsgi and pip these days because uwsgi takes the wrong pyhon3 plugin when your pip environment has as different Python version and then you have to compile uwsgi yourself which I don’t like on a production system. So I moved to gunicorn instead which works perfectly.

I prefer Podman which doesn’t need root and can completely run rootless. Also it’s more and more integrated with systemd to start automatically and restart on failure.

I tried to make it work with an URL containing a subdirectory (domain.de/path) instead of a subdomain (sub.domain.de), but it fails with encryption problems.

Would you (@lukio) be so nice and give some advice for this scenario - which IMHO is a useful and easy to handle one?

Thank you,
W

Certainly, if you are familiar with docker (or podman).

But it is a lot of work to get into it. My initial start with Tryton was very close to completely fail, as after 6 weeks of struggle I did not see any success. And I had some help by a relative who is an IT professional, unluckily this guy did not have experience with docker,

IMHO the focus on docker as the preferred deployment method is the wrong decision, Tryton should provide info on different methods. But I’m quite certain that it will not. Pity.

1 Like

which ones ? Let’s talk about it.

A post was split to a new topic: How to run uwsgi with different virtualenv

A post was split to a new topic: Deploy web client with subpath

Meaning no disrespect to anyone, but personally I am not in favor of using docker containers provided by others due to the effort to validate the container contents and security. However, if I was supporting clients each with their own Tryton system, it seems building a container for each client would significantly reduce my effort to support those clients (iirc, @ced has said this is what B2CK does).

I expect to be in the minority here, but my preferred platform is FreeBSD which does not have systemd. Also OpenBSD has had a Tryton port in their ports system for many years, so I assume this means there is strong interest for Tryton in the OpenBSD community (which also does not have systemd).

Personally, I like tutorials and howto articles even if opinionated because they are still a source of knowledge, even if I cannot apply them directly to my own situation.

This is what we do at KOPEN. So we have a single image that has all tryton base an each client has each own image with their custom code.

1 Like

I don’t use Docker because it depends on a centralized administration schema.
In theory, I co-administrate every virtual server (lx container) with the customer, which requires every setting to be set inside the container.

I’m talking about distributions not OS’es so I was referring to the different GNU/Linux flavors out there. I’m running pfSense as my router OS which is based on FreeBSD, so I know my way around a bit and I also tried FreeBSD a few times but it didn’t last. Entirely my fault because I’m lazy and GNU/Linux gives me everything I want. But I’m still monitoring the news around FreeBSD, jails, containers and bHyve.

Which must have root rights which is dangerous. Better to use Podman in rootless mode with rootless containers. So you only have basic user rights.

1 Like

My implementation is specific because I provide root access to customers.