Richten Sie nginx so ein, dass es nicht abstürzt, wenn der Host im Upstream nicht gefunden wird

Wir haben mehrere Rails-Apps unter einer gemeinsamen Domäne in Docker und verwenden Nginx, um Anfragen an bestimmte Apps zu leiten.

our_dev_server.com/foo # proxies to foo app
our_dev_server.com/bar # proxies to bar

Die Konfiguration sieht folgendermaßen aus:

upstream foo {
  server foo:3000;
}

upstream bar {
  server bar:3000;
}

# and about 10 more...

server {
  listen *:80 default_server;

  server_name our_dev_server.com;

  location /foo {
      # this is specific to asset management in rails dev
      rewrite ^/foo/assets(/.*)$ /assets/$1 break;
      rewrite ^/foo(/.*)$ /foo/$1 break;
      proxy_pass http://foo;
  }

  location /bar {
      rewrite ^/bar/assets(/.*)$ /assets/$1 break;
      rewrite ^/bar(/.*)$ /bar/$1 break;
      proxy_pass http://bar;
  }

  # and about 10 more...
}

Wenn eine dieser Apps nicht gestartet wird, schlägt nginx fehl und stoppt:

host not found in upstream "bar:3000" in /etc/nginx/conf.d/nginx.conf:6

Wir brauchen nicht alle, um auf zu sein, aber Nginx schlägt sonst fehl. Wie kann man Nginx dazu bringen, fehlgeschlagene Upstreams zu ignorieren?

1. Wenn Sie eine statische IP verwenden können, verwenden Sie diese einfach. Sie wird gestartet und gibt nur dann zurück 503, wenn sie nicht antwortet.

2. Verwenden Sie die resolverAnweisung, um auf etwas zu verweisen, das den Host auflösen kann, unabhängig davon, ob er gerade aktiv ist oder nicht.

3. Löse es auf der locationEbene, wenn du das oben genannte nicht kannst (dies ermöglicht es Nginx zu starten / laufen zu lassen) :

   location /foo {
     resolver 127.0.0.1 valid=30s;
     # or some other DNS (you company/internal DNS server)
     #resolver 8.8.8.8 valid=30s;
     set $upstream_foo foo;
     proxy_pass http://$upstream_foo:80;
   }
   
   location /bar {
     resolver 127.0.0.1 valid=30s;
     # or some other DNS (you company/internal DNS server)
     #resolver 8.8.8.8 valid=30s;
     set $upstream_bar foo;
     proxy_pass http://$upstream_bar:80;
   }
   

Für mich löste Option 3 der Antwort von @ Justin / @ duskwuff das Problem, aber ich musste die Resolver-IP auf ändern 127.0.0.11 (Docker-DNS-Server) :

location /foo {
  resolver 127.0.0.11 valid=30s;
  set $upstream_foo foo;
  proxy_pass http://$upstream_foo:80;
}

location /bar {
  resolver 127.0.0.11 valid=30s;
  set $upstream_bar foo;
  proxy_pass http://$upstream_bar:80;
}

Aber wie @ Justin / @ duskwuff erwähnt, können Sie jeden anderen externen DNS-Server verwenden.

Der Hauptvorteil der Verwendung upstreambesteht darin, eine Gruppe von Servern zu definieren, die verschiedene Ports überwachen und den Lastenausgleich und das Failover zwischen ihnen konfigurieren können .

In Ihrem Fall definieren Sie nur 1 Primärserver pro Upstream, sodass dieser aktiv sein muss .

Verwenden Sie stattdessen Variablen für Ihre proxy_pass(n) und denken Sie daran, die möglichen Fehler (404s, 503s) zu behandeln, die auftreten können, wenn ein Zielserver ausfällt.

Ich hatte das gleiche Problem "Host nicht gefunden", da ein Teil meines Hosts mithilfe $urivon $request_uri:

proxy_pass http://one-api-service.$kubernetes:8091/auth;

Und als die Anforderung in die Auth-Unteranforderung geändert wurde, $uriverlor die ihren Anfangswert. Das Ändern des zu verwendenden Mappings $request_urianstelle $urimeines Problems hat mein Problem gelöst:

map $request_uri $kubernetes {
    # ...
}

Sie können nicht verwenden --link Option , stattdessen können Sie die Portzuordnung verwenden und nginx an die Hostadresse binden.

Beispiel: Führen Sie Ihren ersten Docker-Container mit -p 180:80Option und den zweiten Container mit aus-p 280:80 Option aus.

Führen Sie nginx aus und legen Sie diese Adressen für den Proxy fest:

proxy_pass http://192.168.1.20:180/; # first container
proxy_pass http://192.168.1.20:280/; # second container