Kibana 5.5.1 derrière un proxy nginx 1.13 (dockerized)

Objectif:

Je veux lancer la stack d’élans dans un conteneur de docker. Pour pouvoir accéder à la stack ELK via un proxy nginx afin de contourner les ports individuels des services.

Le service Kibana (port par défaut 5601)

http://.com:5601 

devrait être accessible à l’adresse suivante:

 http://.com/kibana 

Problème:

Le problème est qu’il n’est pas possible d’accéder au site kibana après avoir ajouté le paramètre server.basePath à la configuration. Je peux seulement faire apparaître le service si j’ajoute chaque appel d’api de base de Kibana à la configuration nginx (/ api, / ui, …).

Config:

La config pour Kibana:

 /opt/kibana/config/kibana.yml 

A les entrées suivantes:

 server.host: "0.0.0.0" server.basePath: "/kibana" 

tout le rest est par défaut

Doku server.basePath

 # Enables you to specify a path to mount Kibana at if you are running behind a proxy. This only affects # the URLs generated by Kibana, your proxy is expected to remove the basePath value before forwarding requests # to Kibana. This setting cannot end in a slash. 

La configuration nginx:

 location /kibana/ { rewrite ^/kibana(/.*)$ $1 break; proxy_pass http://.com:5601/; } 

J’utilise l’image docker sebp / elk: 551 et le fichier docker-compose suivant:

 version: '2' services: elk: image: sebp/elk:551 container_name: "elk" volumes: - /etc/kibana/config/kibana.yml:/opt/kibana/config/kibana.yml ports: - "5601:5601" - "9200:9200" - "5044:5044" environment: SERVICE_5601_NAME: "kibana" SERVICE_9200_NAME: "elasticsearch" SERVICE_5044_NAME: "logstash" restart: always 

Ce que j’ai essayé:

J’ai essayé la même configuration avec Kibana 4.6.1 et cela fonctionnait parfaitement comme prévu.

Versions que j’ai testées et ne fonctionnent pas: 5.4.3, 5.1.2, 5.0.2

Ce que je ne veux pas:

Je ne veux pas append tous les sous-répertoires de Kibana comme /api, /ui, /app/kibana, ... à append à la configuration du proxy.

Y a-t-il une autre solution ou version?

Edit1: @ whites11: le navigateur renvoie le site 502 Bad Gateway à partir de nginx. Infos navigateur:

Général

 Request URL:http://.com/kibana/ Request Method:GET Status Code:502 Bad Gateway Remote Address::80 Referrer Policy:no-referrer-when-downgrade 

En-têtes de réponse

 Connection:keep-alive Content-Length:575 Content-Type:text/html Date:Thu, 24 Aug 2017 13:54:49 GMT Server:nginx/1.13.3 

En-têtes de demande

 Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 Accept-Encoding:gzip, deflate Accept-Language:en-US,en;q=0.8 Connection:keep-alive Host:.com Upgrade-Insecure-Requests:1 

Journal de nginx

 34#34: *8 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: , server: , request: "GET /kibana/ HTTP/1.1", upstream: "http://:5601/", host: ".com" 

Je n’ai pas exactement le même déploiement que vous, mais j’utilise un kibana dockerisé.

Tout d’abord, vous avez besoin des éléments suivants dans vos parameters nginx:

  location /kibana/ { proxy_pass http://kibana_server:5601/; } 

Changez les valeurs en fonction de votre environnement, mais les barres obliques finales sont critiques! Ne les enlevez pas! Ils veillent à ce que la réécriture se fasse comme prévu par Kibana –ie, le kibana est supprimé de l’URL dans la pétition envoyée au serveur kibana.

Ensuite, maintenez les éléments suivants:

 server.basePath: /kibana 

dans vos parameters de kibana. Cela garantit que les documents fournis par kibana (liens et URL) ont le préfixe /kibana .

Ça marche pour moi.

Tout d’abord, il est inutile de toucher Kibana, car nous allons utiliser Nginx comme proxy inverse. Alors laisse tomber ton server.basePath

Ensuite, changez votre configuration nginx ci-dessous

 location /kibana/ { proxy_pass http://.com:5601/; } 

Cela signifie que vous accédez à http://:/kibana/xyz/abc . Ce serait équivalent à utiliser http://.com:5601/xyz/abc . Supprime toute complexité de votre système

Edit-1

Pour ceux qui pensent que cela ne fonctionne pas, ce n’est pas le cas. Voici un exemple de cas de test que j’avais défini avant de poster cette réponse.

 events { worker_connections 1024; } http { server { listen 80; location /test1 { proxy_pass http://127.0.0.1:81; } location /test2 { proxy_pass http://127.0.0.1:81/; } location /test3/ { proxy_pass http://127.0.0.1:81; } location /test4/ { proxy_pass http://127.0.0.1:81/; } } server { listen 81; location / { echo "$request_uri"; } } } 

Maintenant, les résultats expliquent la différence entre les 4 blocs de localisation

 $ curl http://192.168.33.100/test1/abc/test /test1/abc/test $ curl http://192.168.33.100/test2/abc/test //abc/test $ curl http://192.168.33.100/test3/abc/test /test3/abc/test $ curl http://192.168.33.100/test4/abc/test /abc/test