103 lines
4.1 KiB
Plaintext
103 lines
4.1 KiB
Plaintext
# =====================================================================
|
|
# owuitools ingress gateway.
|
|
#
|
|
# Deliberately dumb: this is the ONLY container that joins
|
|
# openwebui_default, and it holds no application logic. Its whole job is
|
|
# to let open-webui reach owuitools-api, which lives on an internal-only
|
|
# network and therefore cannot be reached - or reach out - any other way.
|
|
#
|
|
# Keeping the app off openwebui_default is the point. If the app sat
|
|
# there it would have a default route, and a bug in URL validation would
|
|
# put the host's other stacks one HTTP request away.
|
|
# =====================================================================
|
|
|
|
worker_processes 1;
|
|
# Both destinations on purpose: stderr keeps `docker compose logs`
|
|
# working, the file puts it with every other component in ./logs.
|
|
error_log /dev/stderr warn;
|
|
error_log /logs/gateway.error.log warn;
|
|
pid /tmp/nginx.pid;
|
|
|
|
events { worker_connections 512; }
|
|
|
|
http {
|
|
access_log /dev/stdout combined;
|
|
access_log /logs/gateway.access.log combined;
|
|
|
|
# Read-only rootfs: everything nginx wants to write goes to tmpfs.
|
|
client_body_temp_path /tmp/client_body;
|
|
proxy_temp_path /tmp/proxy;
|
|
fastcgi_temp_path /tmp/fastcgi;
|
|
uwsgi_temp_path /tmp/uwsgi;
|
|
scgi_temp_path /tmp/scgi;
|
|
|
|
sendfile on;
|
|
server_tokens off;
|
|
|
|
# Tool responses are capped server-side but a datasheet fetch can
|
|
# still be a few hundred KB before trimming.
|
|
client_max_body_size 1m;
|
|
proxy_buffering off;
|
|
|
|
upstream owuitools_api {
|
|
server owuitools-netguard:8000;
|
|
keepalive 8;
|
|
}
|
|
|
|
server {
|
|
listen 8000;
|
|
server_name _;
|
|
|
|
# A tool call that needs a slow origin plus a PDF parse can take a
|
|
# while: at 90 s a 995-page manual was cut off mid-extraction and the
|
|
# model received nginx's HTML 504 page as its tool result. The app
|
|
# bounds its own slow paths (PDF extraction at 120 s) so that it, not
|
|
# this gateway, is what answers.
|
|
#
|
|
# CORRECTION, measured on 0.11.3. This comment used to say Open WebUI
|
|
# sets no tool-server timeout of its own "because AIOHTTP_CLIENT_TIMEOUT
|
|
# is unset here". That is wrong, and wrong in the dangerous direction:
|
|
# env.py falls AIOHTTP_CLIENT_TIMEOUT_TOOL_SERVER back to
|
|
# AIOHTTP_CLIENT_TIMEOUT, which defaults to 300 when unset - not to
|
|
# "no limit". So there are TWO clocks on an ordinary tool call, and
|
|
# Open WebUI's is the shorter one.
|
|
proxy_connect_timeout 10s;
|
|
proxy_send_timeout 240s;
|
|
proxy_read_timeout 240s;
|
|
|
|
# The one exception. A VM session is a slow model with thinking on
|
|
# driving a real machine, so it is minutes to hours rather than
|
|
# seconds. This needs all three clocks raised together - this one,
|
|
# OWUITOOLS_VM_WAIT_SECONDS in the app, and
|
|
# AIOHTTP_CLIENT_TIMEOUT_TOOL_SERVER on the open-webui container -
|
|
# and the app's is deliberately the smallest so that IT answers.
|
|
#
|
|
# Only this location: every other tool keeps the 240 s ceiling,
|
|
# because a tool that hangs should fail rather than tie up a worker
|
|
# for two hours.
|
|
location = /tools/vm_agent {
|
|
proxy_pass http://owuitools_api;
|
|
proxy_http_version 1.1;
|
|
proxy_set_header Connection "";
|
|
proxy_set_header Host $host;
|
|
proxy_set_header X-Real-IP $remote_addr;
|
|
proxy_pass_request_headers on;
|
|
proxy_read_timeout 7200s;
|
|
proxy_send_timeout 7200s;
|
|
}
|
|
|
|
location / {
|
|
proxy_pass http://owuitools_api;
|
|
proxy_http_version 1.1;
|
|
proxy_set_header Connection "";
|
|
proxy_set_header Host $host;
|
|
proxy_set_header X-Real-IP $remote_addr;
|
|
|
|
# open-webui forwards these when ENABLE_FORWARD_USER_INFO_HEADERS
|
|
# is on; the app keys its per-user rate limits off them, so they
|
|
# must survive the hop.
|
|
proxy_pass_request_headers on;
|
|
}
|
|
}
|
|
}
|