Use nginx with uswgi

[Kelvin-M]

We should use nginx in front of uwgsi
https://uwsgi-docs.readthedocs.io/en/latest/tutorials/Django_and_nginx.html#basic-nginx

[Kelvin-M]

@ClementGautier Can you review the nginx configuration. Should I add more options ?

[inelgnu]

This should be passed as values and also should be the path to statics below

[Kelvin-M]

Those paths are hardcoded in deployment-server, I don't think we should let them configurable or we need to make everything configurable (path to statics, socket and medias) which is not the aim of this PR.
I keep it like this for consistency :)

[AurelienGasser]

Minor: /usr/src is an uncommon folder for a socket, isn’t it?
What about a more standard folder, like /var/substra ?

[Kelvin-M]

Yes !

[ClementGautier]

sockets usually live in /var/run/xxx.sock if you are looking for something standard ;)

[Kelvin-M]

Yes, good point !

[ClementGautier]

I'm not completely confident we should add a webserver here... Every configuration (like max upload size, number of open connexion, forwarding X-forwarded headers etc.) will have to be duplicated between the loadbalancer and here and that gave me headache already.

I understand we need a WSGI server to translate the http request into something python can understand but I don't see the added value here. If you think uwsgi isn't performing well why not trying gunicorn for example ?

I would stick to http if it change nothing for you.

[Kelvin-M]

I'm not completely confident we should add a webserver here... Every configuration (like max upload size, number of open connexion, forwarding X-forwarded headers etc.) will have to be duplicated between the loadbalancer and here and that gave me headache already.

I understand we need a WSGI server to translate the http request into something python can understand but I don't see the added value here. If you think uwsgi isn't performing well why not trying gunicorn for example ?

I would stick to http if it change nothing for you.

In fact, we should not expose directly uwsgi (even gunicorn) directly. It always needs to have a webserver to server the request.

We run into something like this issue : https://medium.com/@gabriel.m.troy/aws-alb-docker-uwsgi-502-bad-gateway-16d0a36f6240

https://uwsgi-docs.readthedocs.io/en/latest/tutorials/Django_and_nginx.html

Now normally we won’t have the browser speaking directly to uWSGI. That’s a job for the webserver, which will act as a go-between.

But here nginx/kubernetes-ingress#143, it says that we do not need a webserver between ingress and nginx by adding more configuration in uwsgi.

[ClementGautier]

You don't expose uwsgi directly, the Nginx ingress controller is the webserver in our case.
My point is the same as this: nginx/kubernetes-ingress#143 (comment)

If you still need to add a proxy Nginx, could you test that configuration put at ingress level isn't overwritten by this one:

# nginx controller chart values
config:
  server-tokens: 'false'
  use-forwarded-headers: 'true'
  compute-full-forwarded-for: 'true'
extraArgs:
  enable-ssl-passthrough: ''

# ingress annotations
nginx.ingress.kubernetes.io/client-body-buffer-size: 100m
nginx.ingress.kubernetes.io/proxy-body-size: 100m

[Kelvin-M]

@ClementGautier I will try to update the uwsgi settings along the github issue if it solves the 502 bad gateway.

[Kelvin-M]

We will try to handle it with ingress and uwsgi (http-socket directly)