Dotaz: nginx proxy - náhodná chyba Bad Gateway

[ales]

Ahoj, mám problém s nginx proxy. Používám hotový docker container jwilder/nginx-proxy za který schovávám python aplikaci. Vše funguje na první pohled jak má, jednou za čas mi ale v prohlížeči vyskočí chyba Bad Gateway (od nginx). stačí refreshnout tu samou stránku a zase vše funguje (v připadě GETu). Můj problém spočívá hlavně v tom, že nedokážu zjistit více informací o problému. Stejně tak když vyzkouším udělat nějakou opravu, nejsem schopný spolehlivě otestovat, jestli pomohla. Nemáte nějaký nápad jak postupovat?

v logu nginx je to vidět takto:

2017/04/11 14:02:25 [error] 44#44: *2868 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 10.2.1.114, server: mydomain.com, request: "POST /admin/images/118/delete/ HTTP/1.1", upstream: "http://172.17.0.3:8000/admin/images/118/delete/", host: "mydomain.com", referrer: "http://mydomain.com/admin/images/118/delete/"

konfigurace nginx (vygenerovaná, bez úprav):

# If we receive X-Forwarded-Proto, pass it through; otherwise, pass along the
# scheme used to connect to this server
map $http_x_forwarded_proto $proxy_x_forwarded_proto {
  default $http_x_forwarded_proto;
  ''      $scheme;
}
# If we receive X-Forwarded-Port, pass it through; otherwise, pass along the
# server port the client connected to
map $http_x_forwarded_port $proxy_x_forwarded_port {
  default $http_x_forwarded_port;
  ''      $server_port;
}
# If we receive Upgrade, set Connection to "upgrade"; otherwise, delete any
# Connection header that may have been passed to this server
map $http_upgrade $proxy_connection {
  default upgrade;
  '' close;
}
# Set appropriate X-Forwarded-Ssl header
map $scheme $proxy_x_forwarded_ssl {
  default off;
  https on;
}
gzip_types text/plain text/css application/javascript application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
log_format vhost '$host $remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 '"$http_referer" "$http_user_agent"';
access_log off;
# HTTP 1.1 support
proxy_http_version 1.1;
proxy_buffering off;
proxy_set_header Host $http_host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $proxy_connection;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto;
proxy_set_header X-Forwarded-Ssl $proxy_x_forwarded_ssl;
proxy_set_header X-Forwarded-Port $proxy_x_forwarded_port;
# Mitigate httpoxy attack (see README for details)
proxy_set_header Proxy "";
server {
        server_name _; # This is just an invalid value which will never trigger on a real hostname.
        listen 80;
        access_log /var/log/nginx/access.log vhost;
        return 503;
}
# mydomain.com
upstream mydomain.com {
                                ## Can be connect with "bridge" network
                        # app1
                        server 172.17.0.3:8000;
}
server {
        server_name mydomain.com;
        listen 80 ;
        access_log /var/log/nginx/access.log vhost;
        location / {
                proxy_pass http://mydomain.com;
        }
}
# mydomain2.com
upstream mydomain2.com {
                                ## Can be connect with "bridge" network
                        # app2
                        server 172.17.0.7:8000;
}
server {
        server_name mydomain2.com;
        listen 80 ;
        access_log /var/log/nginx/access.log vhost;
        location / {
                proxy_pass http://mydomain2.com;
        }
}

Předem díky

Odpovědi

[Josef Kufner]

Tím nginx říká, že ta python aplikace neodpověděla. Není v jejím logu nějaký problém?

Pokud nginx a aplikace nejsou na stejném serveru, nemohlo se pár paketů ztratit a tím překazit navazování spojení?

[chrono]

Je možné, že tá operácia trvala príliš dlho (napr. kvôli nejakej diskovej operácii) a tá aplikácia nič nevrátila (a teda ani HTTP hlavičku).

Neukladá aj tá Python aplikácia svoj log, v ktorom by sa dali porovnať časy, v ktorých bola tá požiadavka obslúžená?

[ales]

aplikace je v podstatě standartní wagtail CMS. Jediné, co by s tím mohlo mít spojitost je, že to běží v development režimu (manage.py runserver). Do budoucna to poběží například přes gunicorn, což by mohlo pomoct ale i tak mi přijde divné, že by to takhle samo zlobilo. Na localhostu, kde je nginx proxy vynechaná jsem se s tím nesetkal.

Zde je log konkrétního problematického requestu z nginx:

nginx.1    | 2017/04/12 10:20:29 [error] 79#79: *8318 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 10.2.1.53, server: mydomain.com, request: "GET /kontakt/ HTTP/1.1", upstream: "http://172.17.0.7:8000/kontakt/", host: "mydomain.com", referrer: "http://mydomain.com/o-nas/"

Mám k dispozici log z toho development serveru. Mělo by jít o ten samý request:

[12/Apr/2017 10:20:29] "GET /kontakt/ HTTP/1.1" 200 3209

[chrono]

Štandardne sú proxy_connect_timeout aj proxy_read_timeout nastavené na 60 sekúnd, takže ak tie parametre neboli zmenené, viac ako minútové načítavanie stránky by bolo jednoducho zistiteľné.

[ales]

Stránka se načítá maximálně nižší jednotky vteřin. Chyba se v prohlížeči zobrazí v podstatě ihned, rozhodně to netrvá 60sekund ani se to tomuto číslu neblíží

[Bystroushaak]

Co zkusit nastavit vyšší hodnotu timeoutu, to nepomůže? Z toho co jsem tak vygooglil, tak třeba: How to fix upstream timed out (110: Connection timed out) error in Nginx.

[ales]

přesně tohle jsem zkoušel a neudělalo to žádný rozdíl. Každopádně to imho není správné řešení. Jde o běžný request na načtení webu a to by stejně nemělo trvat déle než pár jednotek sekund.

[Bystroushaak]

Můžeš poslat ještě ten dockerfile, nebo ten script, ve kterém ti běží webserver?

Tohle mi trochu připomíná chybu, kterou jsem dělal, když jsem v pythonu provozoval server v bottle.py, kde jsem zapoměl zapnout paralelizaci. Zdánlivě to fungovalo, ale nesměly přijít dva a více requestů najednou, nebo když někdo pustil stahování souboru, tak pak ostatní requesty timeoutovaly. Řešení bylo říct bottle.py, aby používal jako backend paste (thredování).

Napadá mě, jestli nemáš podobný problém - psal jsi, že to provozuješ v development režimu, což by mohlo teoreticky jet jen v jednom vlákně a nespouštět thready pro každý request.

[ales]

Máš pravdu, mohlo by to být tím, že v tomto případě už na to může být více requestů zároveň. To mě nenapadlo, dobrý postřeh. Zkusím to předělat.

Tady kdyžtak Dockerfile

FROM python:3

RUN mkdir /var/code

ADD . /var/code

WORKDIR /var/code

ENV DJANGO_SETTINGS_MODULE myapp.settings.production

RUN pip install -r requirements.txt
RUN python manage.py migrate

#TODO: predelat na gunicorn?
CMD python manage.py runserver 0.0.0.0:8000 

EXPOSE 8000