Nginx ne démarre pas si l'hôte n'est pas trouvé en amont.

Question

J'utilise nginx comme proxy et pour maintenir des connexions persistantes avec des serveurs éloignés.

J'ai configuré une quinzaine de blocs semblables à cet exemple :

upstream rinu-test {
    server test.rinu.test:443;
    keepalive 20;
}
server {
    listen 80;
    server_name test.rinu.test;
    location / {
        proxy_pass https://rinu-test;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $http_host;
    }
}

Le problème est que si le nom d'hôte ne peut pas être résolu dans un ou plusieurs des éléments suivants upstream blocs, nginx ne (re)démarre pas. Je ne peux pas non plus utiliser d'IP statiques, certains de ces hôtes m'ont explicitement dit de ne pas le faire parce que les IP vont changer. Toutes les autres solutions que j'ai vues pour ce message d'erreur recommandent de se débarrasser des éléments suivants upstream et faire tout dans le location bloc. Ce n'est pas possible ici car keepalive est uniquement disponible sous upstream .

Je peux temporairement me permettre de perdre un serveur mais pas les 15.

Éditer : Il s'avère que nginx n'est pas adapté à ce cas d'utilisation. Un proxy keepalive alternatif (en amont) devrait être utilisé. Une alternative Node.js personnalisée se trouve dans ma réponse . Jusqu'à présent, je n'ai pas trouvé d'autres solutions qui fonctionnent vraiment.

Answer 1

Les versions antérieures de nginx (avant la 1.1.4), qui alimentaient déjà un grand nombre des sites web les plus visités au monde (et certains le font encore aujourd'hui, si l'on en croit les en-têtes du serveur), ne prenaient même pas en charge les éléments suivants keepalive sur le upstream car il n'y a que très peu d'avantages à le faire dans un centre de données, à moins que vous n'ayez une latence non négligeable entre vos différents hôtes ; cf. https://serverfault.com/a/883019/110020 pour une explication.

En gros, à moins que vous ne sachiez que vous avez spécifiquement besoin de keepalive entre votre amont et votre frontal, il y a de fortes chances que cela ne fasse que rendre votre architecture moins résiliente et moins performante.

(Notez que votre solution actuelle est également mauvaise parce qu'un changement d'adresse IP passera également inaperçu, car vous effectuez la résolution du nom d'hôte au moment du rechargement de la configuration uniquement ; ainsi, même si nginx démarre, il cessera de fonctionner dès que les adresses IP des serveurs en amont changeront).

Solutions potentielles, choisissez-en une :

• La meilleure solution semble être de se débarrasser simplement de upstream keepalive comme probablement inutile dans un environnement de centre de données, et utiliser les variables avec des proxy_pass pour une résolution DNS à jour pour chaque requête (nginx est encore assez intelligent pour faire la mise en cache de telles résolutions)

• Une autre option serait d'obtenir une version payante de nginx par le biais d'un abonnement commercial, qui a une resolve pour le paramètre server dans la directive upstream le contexte.

• Enfin, vous pouvez également essayer d'utiliser un fichier set variable et/ou un map pour spécifier les serveurs dans upstream ; il n'est ni confirmé ni démenti que cela a été mis en œuvre ; par exemple, cela peut fonctionner ou non.

Answer 2

Votre scénario est très similaire à celui de l'utilisation d'aws. ELB comme des flux ascendants dans où est critique pour resolve l'IP propre du domaine défini.

La première chose que vous devez faire et vous assurer que les serveurs DNS que vous utilisez peuvent résoudre vos domaines, alors vous pouvez créer votre configuration comme ceci :

resolver 10.0.0.2 valid=300s;
resolver_timeout 10s;

location /foo {
    set $foo_backend_servers foo_backends.example.com;
    proxy_pass http://$foo_backend_servers;
 }

location /bar {
    set $bar_backend_servers bar_backends.example.com;
    proxy_pass http://$bar_backend_servers;
 }

Remarquez le resolver 10.0.0.2 il doit s'agir de l'IP du serveur DNS qui fonctionne et répond à vos requêtes, selon votre configuration, il peut s'agir d'un service de cache local comme non consolidé . et ensuite utiliser simplement resolve 127.0.0.1

Maintenant, il est très important d'utiliser un variable pour spécifier le nom de domaine, à partir de la documentation :

Lorsque vous utilisez une variable pour spécifier le nom de domaine dans la directive proxy_pass, NGINX résout à nouveau le nom de domaine lorsque son TTL expire.

Vous pouvez vérifier votre résolveur en utilisant des outils tels que dig par exemple :

$ dig +short stackoverflow.com

En cas de besoin, il faut utiliser keepalive en amont, et s'il n'est pas possible d'utiliser Nginx +, alors vous pouvez essayer équilibreur ouvert vous devrez utiliser/implémenter lua-resty-dns

Answer 3

Une solution possible est d'impliquer un cache de DNS local. Il peut être un serveur DNS local comme à Lier ou à Dnsmasq (avec quelques petits malins configuration, notez que nginx pouvez également utiliser le serveur dns spécifié à la place de la valeur par défaut du système), ou tout simplement maintenir le cache en hosts le fichier.

Il semble que l'utilisation d' hosts le fichier avec certains de script est assez simple. Le fichier hosts doit être divisé en parties statiques et dynamiques (c - cat hosts.static hosts.dynamic > hosts), et la partie dynamique doit être généré (et mis à jour automatiquement par un script.

Peut-être il judicieux de vérifier de temps en temps les noms d'hôte pour changer les IPs, et de mettre à jour le fichier d'hôtes et recharger la configuration de nginx sur les changements. Dans le cas de certains nom d'hôte ne peut pas être résolu à l'ancienne adresse IP ou certaines IP par défaut (comme 127.0.1.9) doit être utilisé.

Si vous n'avez pas besoin de les noms d'hôte dans le fichier de configuration de nginx (c'est à dire, IPs sont assez), l' upstream section avec IPs (résolu les noms d'hôtes) peut être généré par un script et inclus dans la config nginx - et pas besoin de toucher au fichier hosts dans de tels cas.

Answer 4

J'ai mis le paramètre resolve sur le serveur et vous devez définir le résolveur Nginx dans nginx.conf comme ci-dessous :

/etc/nginx/nginx.conf :

http {
    resolver 192.168.0.2 ipv6=off valid=40s;  # The DNS IP server
} 

Site.conf :

upstream rinu-test {
    server test.rinu.test:443;
    keepalive 20;
}

Answer 5

Une alternative est d'écrire un nouveau service qui ne fait que ce que je veux. Ce qui suit remplace nginx pour l'acheminement des connexions https en utilisant Node.js

const http = require('http');
const https = require('https');

const httpsKeepAliveAgent = new https.Agent({ keepAlive: true });

http.createServer(onRequest).listen(3000);

function onRequest(client_req, client_res) {
    https.pipe(
        protocol.request({
            host: client_req.headers.host,
            port: 443,
            path: client_req.url,
            method: client_req.method,
            headers: client_req.headers,
            agent: httpsKeepAliveAgent
        }, (res) => {
            res.pipe(client_res);
        }).on('error', (e) => {
            client_res.end();
        })
    );
}

Exemple d'utilisation : curl http://localhost:3000/request_uri -H "Host: test.rinu.test" ce qui est équivalent à : curl https://test.rinu.test/request_uri