guten Montag, ich möchte einen neuen Versuch starten, Grafana mit als Reverse Proxy auf meinem existierenden Webserver (apache2, letsencrypt) korrekt zum Laufen zu bekommen. Dazu möchte ich der Empfehlung folgen hier aus dem Forum, Grafana in einem Docker-Image zu betreiben und dazu dieses vorbereitete Image zu benutzen: https://github.com/nginx-proxy/docker-letsencrypt-nginx-proxy-companion Ich habe also docker installiert und getestet wie hier beschrieben: https://www.codeflow.site/de/article/how-to-install-and-use-docker-on-debian-10 Jetzt zu den Fragen: Mein Webserver läuft ja und verwendet Port 80 und 443. Wenn ich jetzt den Container laufen lasse, um die Lets encrypt-Zertifikate zu erzeugen, brauche ich die gleichen Ports. Ich habe aber nur einen externen dynDNS-Namen, und für letsencrypt muss der DNS sauber auflösen. ? wird da letsEncrypt nicht merken, dass es da schon ein Zertifikat gibt, und durcheinanderkommen ? ? Muss ich also solange, wie ich die Zertifikate für den Container mache, meinen Webserver runterfahren? ? wenn ich die Zertifikate dann habe und nur noch Port 3000 für Grafana aus dem Container brauche, wird die automatisch Erneuerung ohne Port 80 und 443 funktionieren? ? brauche ich für Grafana überhaupt ein extra Zertifikat, wenn es doch später auf meinem Webserver als reverse Proxy eingerichtet werden soll und der schon ein Zertifikat hat?
Rudi schrieb: > ? brauche ich für Grafana überhaupt ein extra Zertifikat, wenn es doch > später auf meinem Webserver als reverse Proxy eingerichtet werden soll Nein, brauchst du nicht, falls du nicht die Verbindung zwischen Proxy und Grafana auch verschluesseln und authentifizieren willst (unnoetig wenn das auf dem selben Rechner laeuft). Also musst du dich nur um das Zertifikat fuer nginx kuemmern.
Also Grafana braucht kein Zertifikat, danke. Apache/NGINX habe ich nicht gut erklärt, mein Setup sähe so aus:
1 | (Internet) |
2 | v ^ |
3 | (Apache Webserver mit Domainnamen und gültigen Zertifikat) |
4 | v ^ v ^ v ^ |
5 | /Wordpress /Owncloud /docker als reverse proxy |
6 | v ^ |
7 | Grafana (localhost:3000) |
Somit reicht das (vorhandene) apache-Zertifikat, habe ich verstanden, richtig?
Junge, stell dich auf ein Abenteuer bereit. Durch dieses Tal bin ich schon gelaufen - ist wirklich tricky. Ist leider schon ein wenig her, sonst würde ich dir mehr sagen können. Ich weiß nur noch, ohne reverse proxy geht es nicht. Und du brauchst eine Portweiterleitung. Und ein selbsterstelltes Zertifikat bringt auch Probleme (apache). Ich versuch mich mal an mehr zu errrinern :)
reverse proxy schrieb: > Und ein > selbsterstelltes Zertifikat bringt auch Probleme (apache). Ich versuch > mich mal an mehr zu errrinern :) Ja versuch mal :) Das Zertifikat ist aber nicht selbst erstellt, sondern von Let's encrypt.
Rudi schrieb: > Somit reicht das (vorhandene) apache-Zertifikat, habe ich verstanden, > richtig? Richtig. nginx sehe ich da nirgendwo, ist aber auch nicht noetig wenn du Apache als reverse proxy verwenden moechtest. Wenn du einen funktionierenden Apache mit SSL hast ist alles was du brauchst nun also Grafana in einem Docker-Container, wo du den internen Grafana-Port des Containers (z.B. 3000) an einen beliebigen Port von localhost (z.B. 1234) bindest (`-p 127.0.0.1:1234:3000`). Dann richtest du in Apache einen reverse proxy von `/foobar/*` auf `http://127.0.0.1:1234/` ein (damit kenne ich mich nicht aus, bei nginx koennte ich helfen).
Andreas ist auf ner guten Spur, wenn du keinen docker swarm oder anderes load-balancing hast - passt das, ansonsten musst du irgendwie die ports hochzählen (odern Bereich angeben). Man wenn mein Hirn nicht so löchrig wäre...
Ah gut, dann werde ich mir also einen Container suchen mit einem mini-headless-debian, und mal schauen, wie sich da Grafana so macht.
Klingt nach einem Plan, aber den reverse proxy brauchst du definitiv - ansonsten gibt es cross-domain errors im Browser. Auch wird da dein selbsterstelltes Zertifikat als nicht sicher angezeigt werden...
Und dokumentiere jeden Schritt (am besten bau die ein Buildskript, das deine Anwendung ausrollen kann [Also docker container neu bauen, starten etc.]. Ich denke den Entwickler-Modus im Browser kennst du? ;) Viel Erfolg!
So, jetzt hab ich ein debian image heruntergladen und die Grafana-Installationsschritte ausgeführt. Jetzt muss ich lesen, wie ich im Docker den Grafana-Service starte und am Leben erhalte. Das brauche ich ja noch nicht zu dokumentieren, oder?
Wieso verwendest du nicht das existierende Grafana Docker-Image? https://grafana.com/docs/grafana/latest/installation/docker/ Nutzdaten/Konfiguration kannst du mit einem Volume (`-v`) ausserhalb des Containers speichern.
Doch! Wenn du es richtig professionell machen willst - ist der erste Schritt eine frische virtuelle Maschine zu booten und nur hier deine Entwicklung stattfinden zu lassen. Damit umgehst du mögliche Nebeneffekte, die jetzt oder später auftretten können und die sehr viel Zeit beim Debuggen kosten. Somit bist du isoliert. Dann schreibst du dir ein script, das dir die Docker-Umgebung in der VM installiert (Docker ist meistens schon da). Das Host-Netzwerk musst du unbedingt mit der VM teilen, ansonsten baust du dir eine weitere Hürde ein. Jetzt nehm am besten einen fertigen grafana docker container (erspart einiges) und bau dir (damit) ein Docker-Build script. Dann grafana docker container starten (mit "run"..."). Jetzt sollte sich der Dockercontainer aus dem Cache bauen lassen. Dann vom Host prüfen ob erreichbar (http und https). Wenn du soweit bist, kannst du deinen "Startpunkt" für die weitere Entwicklung jederzeit wiederherstellen und zwar ganz frisch. Wenn du soweit bist, meld dich nochmal. Viel Erfolg.
PS. Was für einen Internetprovider hast du? Bei vodafone und unitymedia wirst du von "außen" keine Verbindung aufbauen können -> shared ip v6...
P.P.S: Ach, obacht mit Datenbanken und Docker. Beendest du den Dockercontainer ist die Datenbank futsch. Das zu umgehen, muss die Datenbankdatei im Dateisystem der virtuellen Maschine leben (wie oben erwähnt) und beim Starten des Containers mit -v der Pfad zum Ordner mit der DB angegeben werden.
hört sich gut an schrieb: > Bei vodafone und unitymedia > wirst du von "außen" keine Verbindung aufbauen können Mein Webserver s.o. ist ja schon von außen erreichbar.. hört sich gut an schrieb: > Beendest du den > Dockercontainer ist die Datenbank futsch. ist ja seltsam. Aber das Problem stellt sich nicht, DB ist influx und läuft direkt auf dem Server (uns sammelt nebenbei fleißig weiter Sensordaten) Andreas schrieb: > Wieso verwendest du nicht das existierende Grafana Docker-Image? Weil ich nicht wusste, dass es das gibt. Ich hab noch nicht mal rausbekommen, wir ich nur ein ganz kleines Debian (slim) ziehen kann.. Und da sind auch sicher E-Nummern drin :)
Angehängte Dateien:
Also das "fertige" Grafana-Image "aus der Dose" geht schneller. Habe es heruntergeladen und gestartet wie hier beschrieben, und dann 2 kleine Namen verändert, damit man sieht dass es dieses ist. https://grafana.com/docs/grafana/latest/installation/docker/ Wenn ich jetzt im LAN auf <Server-IP>:3000 gucke, sehe ich die Grafana-Instanz. (siehe Anlage) So weit so gut. Jetzt versuche ich es wieder mit reverse proxy. Wenn es funktioniert, müsste es ja dann unter der URL https://********.no-ip.biz/grafana genauso aussehen, oder?
>Jetzt versuche ich es wieder mit reverse proxy. Wenn es funktioniert, >müsste es ja dann unter der URL https://********.no-ip.biz/grafana >genauso aussehen, oder? So ist es. htaccess bzw. die apache config kennst du? Da wirst du mindestens zwei Einträge hinzufügen müssen. Einmal für http (80) und einmal für https(443). Weiterleitung von www. nicht vergessen. Du willst das alle anfragen die mit "www." beginnen beschnitten werden -> damit du die weitere Konfiguration nur für eine Konstellation machen musst. Und du willst das alle http anfragen nach https "weitergeleitet werden". VG JOnas
>> Beendest du den >> Dockercontainer ist die Datenbank futsch. >ist ja seltsam. Eigentlich nicht, überleg mal, wenn du die Datenbank im gleichen Container laufen lässt - hast du gegenüber eines klassischen Webservers keinen Vorteil. Der kommt ja gerade dadurch, das du Frontend und Datenbank trennst. Hat den Vorteil, das du nach Bedarf Frontend Instanzen erzeugen und beenden lassen kannst (load balancing -> docker swarm bzw. kubernetes) und das auf verschiedenen Maschinen. Heißt du hast nicht mehr das Problem, wenn deine klassische Webanwendung selbst auf dem größten besten Server nur noch bescheiden läuft, du nichts mehr über bessere Hardware verbessern kannst. Also eine monolithische Anwendung auf Anschlag, geht schneller als man glaubt ->gerade wenn der User größere Datenmengen verarbeiten lassen kann. Noch was, git kennst du? Wenn nicht, musst du dir auf jeden Fall anschauen. Schau mal, hier alles erklärt: https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html
Rudi schrieb: > Jetzt zu den Fragen: Mein Webserver läuft ja und verwendet Port 80 und > 443. Nunja, wenn Dein Webserver nicht in einem Docker-Container läuft, den Du ebenfalls hinter den Nginx Reverse Proxy vom Letsencrypt-Companion klemmen kannst, wird das so leider nicht gehen -- es sei denn, Du hast eine zweite IP-Adresse auf dem System, an die Du die Ports 80/http und 443/https des Letsencrypt-Companion binden kannst. Andernfalls kannst Du den Letsencrypt-Companion weglassen, den vorhandenen Webserver als Reverse Proxy einrichten und Grafana dennoch in einem Docker-Container betreiben. Dazu kannst Du Port 3000 (den Grafana standardmäßig benutzt) des Grafana-Containers auf localhost (127.0.0.1) publizieren, und Deinen vorhandenen Webserver als Reverse Proxy auf http://localhost:3000 konfigurieren. Vielleicht ist es allerdings einfacher, den vorhandenen Webserver in einen eigenen Container zu packen und ihn ebenfalls hinter Letsencrypt-Companion zu betreiben. Das Schöne am Letsencrypt-Companion ist, daß er sich vollautomatisch um die Zertifikate kümmert, sobald ein Container mit den richtigen Umgebungsvariablen (VIRTUAL_HOST und LETSENCRYPT_HOST) gestartet wird.
Rudi schrieb: > Ah gut, dann werde ich mir also einen Container suchen mit einem > mini-headless-debian, und mal schauen, wie sich da Grafana so macht. Grafana selbst stellt zwei offizielle Docker-Images bereit, einen auf Basis von Alpine Linux und einen auf Basis von Ubuntu. Einfach
1 | docker run --name grafana --detach --publish 127.0.0.1:3000:3000 grafana/grafana |
eingeben, das wird: das offizielle Grafana-Alpine-Image (grafana/grafana) aus dem Docker-Hub laden, in den lokalen Docker-Daemon importieren, dann einen Container namens grafana aus dem Image erstellen und den Container starten, und dabei Port 3000 an die IP-Adresse 127.0.0.1 (localhost) binden. Wenn Du dann in die Adreßzeile Deines Browsers "http://localhost:3000/"; eingibst und Dich mit admin:admin einloggst, wirst Du nach einem neuen Paßwort gefragt und kannst dann sofort loslegen.
hört sich gut an schrieb: > P.P.S: Ach, obacht mit Datenbanken und Docker. Beendest du den > Dockercontainer ist die Datenbank futsch. Nein. Die Datenbank bleibt bestehen, wenn Du den Container nur beendest und wieder startest. Die Datenbank ist nur dann "futsch", wenn Du den Container zerstörst und neubaust, ohne ihr Datenverzeichnis auf ein Volume oder einen Mount gelegt zu haben.
Rudi schrieb: > hört sich gut an schrieb: >> Beendest du den >> Dockercontainer ist die Datenbank futsch. > > ist ja seltsam. Aber das Problem stellt sich nicht, DB ist influx und > läuft direkt auf dem Server (uns sammelt nebenbei fleißig weiter > Sensordaten) Tu' Dir bitte den Gefallen und hör' nicht auf das, was "hört sich gut an" sagt. Er scheint nicht sonderlich tief in der Materie zu sein, vorsichtig gesagt. > Weil ich nicht wusste, dass es das gibt. Es gibt heute ziemlich wenig, das es nicht als fertiges Docker-Image gibt. > Ich hab noch nicht mal > rausbekommen, wir ich nur ein ganz kleines Debian (slim) ziehen kann..
1 | docker pull debian:10-slim |
Rudi schrieb: > Jetzt versuche ich es wieder mit reverse proxy. Wenn es funktioniert, > müsste es ja dann unter der URL https://********.no-ip.biz/grafana > genauso aussehen, oder? Das... kommt darauf an. Ich weiß nicht, wie das bei Grafana ist, aber vermutlich mußt Du Grafana noch mitteilen, daß es unter dem URL /grafana anstatt unter / laufen soll, sonst können Redirects und das Nachladen von Assets (Grafiken, CSS, JS) fehlschlagen. Du kannst dem Docker-Container aber die Umgebungsvariable GF_SERVER_ROOT_URL mit dem Inhalt "https://********.no-ip.biz/grafana"; setzen, dann sollte das klappen.
>Tu' Dir bitte den Gefallen und hör' nicht auf das, was "hört sich gut >an" sagt. Er scheint nicht sonderlich tief in der Materie zu sein, >vorsichtig gesagt. Ich wollt nur helfen und hab sofort klar gemacht, dass das nur gefährliches Halbwissen ist, weil schon ne ganze Weile her und ich tatsächlich lange was ganz anderes entwickel. Und nur weil ich mal Image schreibe wenn ich Container meine. >Es gibt heute ziemlich wenig, das es nicht als fertiges Docker-Image >gibt. Da wäre ich allerdings tatsächlich vorsichtig. Denn ein offizielles Image z.B. von Ubuntu ist relativ sicher frei von Schadsoftware, ein Docker Image das irgendwer irgendwo zusammmengebaut hat und rekursiv weitere Images von sonstwo lädt...hm. Aber wer benutzt schon docker Images, die nicht vom Hersteller kommen. "Achso, eh was fürn Ocker? Nee Container machen wir hier nicht". Aber hey, da die Container ja isoliert laufen... oh wobei da ist ja noch die persistente Datenbank und der Process der Docker ausführt hat (alte docker version musste sogar als sudo ausgeführt werden) hat auch noch Schreibrechte... Sowas würde man ja nie produktiv einsetzen, ne? Da wird jede Abhängigkeit geprüft, klar natürlich auch im Frontend-Code der fleißig npm einsetzt. Also immer Obacht, Glotzen uff und Attenzione. Bleibt gesund, ich hoffe eure sämtliche Hardware überhitzt.
hört sich nicht mehr so gut an schrieb: >>Es gibt heute ziemlich wenig, das es nicht als fertiges Docker-Image >>gibt. > > Da wäre ich allerdings tatsächlich vorsichtig. Denn ein offizielles > Image z.B. von Ubuntu ist relativ sicher frei von Schadsoftware, ein > Docker Image das irgendwer irgendwo zusammmengebaut hat und rekursiv > weitere Images von sonstwo lädt...hm. Ach, immer diese Unkenrufe. Ja, wer IT-Infrastrukturen betreibt, braucht Umsicht und Sorgfalt, ganz unabhängig davon, ob der Betrieb klassisch auf dem Blech, in VMs oder in Containern stattfindet. Aber bei Blech und VMs kommen die Unkenrufe nie. Warum eigentlich nicht? Containerisierte Anwendungen sind viel einfacher, schneller, und risikoloser zu aktualisieren als manuell installierte. Aktualisierungen sind so einfach, daß es mit Watchtower [1] sogar eine automatisierte Lösung dafür gibt. Und wo die Anwendung geschäftskritisch ist und nach der Inbetriebnahme einen Schluckauf bekommt? Kein Problem, das alte Image ist ja noch vorhanden und wird dann einfach benutzt, bis der Fehler behoben ist. Yay! Andererseits gibt es bis heute eine Vielzahl von Servern und VMs, auf denen auf ganz klassische Weise veraltete Software betrieben wird. Zwei Monate, bevor Ende 2018 der Support für PHP in der Version 5 eingestellt wurde, liefen laut W3Techs immer noch knappe 62% der PHP-Seiten auf, genau, PHP5. Sogar heute, fast zwei Jahre nach Ende des Supports, sind es immer noch über 32% [2]. Darüber redet aber niemand, genau wie über die Massen an veralteten Installationen von Typo3, Wordpress, Drupal, Magento, OS-Commerce, XT-Commerce, und wie sie alle heißen. Aber immer, wenn die Rede auf Containertechnologien kommt, poppen sie jedesmal auf, die Unken, und rufen "aber die Sicherheit, aber die Sicherheit". Es ist super, daß ich nicht der Einzige bin, der sich Gedanken über Sicherheit macht. Aber das ist nicht auf Container beschränkt, und so frage ich mich: was soll der Quatsch? Zumal für etwa 90% der mir bekannten Webserver-Installationen weder ein sauberes Staging noch ein automatisiertes Deployment vorhanden sind, erst Recht keines mit einer vernünftigen Möglichkeit für ein Rollback. Genau deswegen trauen sich viele Betreiber nicht, ihre Software zu aktualisieren: "never change a running system", sie haben Angst, daß etwas kaputt geht. "Meine Software läuft ja", höre ich dann, und, sowas wurde mir letztens sogar hier im Forum erklärt: "in meinen Server ist noch niemals jemand eingebrochen". Ich denk' dann immer "bis jetzt"... [1] https://github.com/containrrr/watchtower [2] https://w3techs.com/technologies/details/pl-php/5
Jetzt bin ich mit Docker soweit - Grafana läuft als Container auf meinem Webserver, der heißt bei mir intern "h2server". Lokal ist alles schick, ich kann also in meinem Lan aufrufen: h2server:3001/grafana und er fragt nach dem login und liefert mir dann mein test-dashboard unter dieser URL: h2server:3001/grafana/d/ZiTcVOAMz/plopp?orgId=1 Für den Container habe ich ein storage-volume erstellt, und ich starte ihn so:
1 | docker run -d \ |
2 | -p 3001:3000 \ |
3 | --name=grafana5 \ |
4 | -e "GF_SERVER_ROOT_URL=https://********.no-ip.biz/grafana" \ |
5 | -e "GF_SERVER_SERVE_FROM_SUB_PATH=true" \ |
6 | -v grafana-storage:/var/lib/grafana \ |
7 | grafana/grafana |
************** Nun wieder zum Reverse Proxy mit apache: Es funktioniert mit Chrome, aber nicht mit Firefox (evtl. war das mein ursprüngliches Problem auch). Es erscheinen in der Addresszeile 2 unterschiedliche URLs nach dem login - warum / woran kann das nun wieder liegen? chrome: https://********.no-ip.biz/grafana/?orgId=1 firefox: https://********.no-ip.biz/grafana/?orgId= meine 000-default-ssl-le.conf sieht so aus;
1 | <IfModule mod_ssl.c> |
2 | <VirtualHost *:443> |
3 | |
4 | ServerAdmin webmaster@localhost |
5 | DocumentRoot /var/www/html |
6 | |
7 | ErrorLog ${APACHE_LOG_DIR}/error.log
|
8 | CustomLog ${APACHE_LOG_DIR}/access.log combined
|
9 | |
10 | #LogLevel debug |
11 | |
12 | ServerName ********.no-ip.biz |
13 | SSLCertificateFile /etc/letsencrypt/live/********.no-ip.biz/fullchain.pem |
14 | SSLCertificateKeyFile /etc/letsencrypt/live/********.no-ip.biz/privkey.pem |
15 | Include /etc/letsencrypt/options-ssl-apache.conf |
16 | |
17 | Header always set X-XSS-Protection "1; mode=block" |
18 | Header always set x-Frame-Options "SAMEORIGIN" |
19 | Header always set X-Content-Type-Options "nosniff" |
20 | Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" |
21 | # next line caused login refresh every 5 sec, so changed to overnext |
22 | #Header always set Content-Security-Policy "default-src 'none'; img-src 'self'; script-src 'self'; style-src 'self'" |
23 | Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *" |
24 | Header always set Referrer-Policy "strict-origin" |
25 | |
26 | |
27 | #grafana |
28 | ProxyRequests Off |
29 | ProxyPass "/grafana" "http://127.0.0.1:3001" |
30 | ProxyPassReverse "/grafana" "http://127.0.0.1:3001" |
31 | |
32 | #influx |
33 | ProxyPass "/influx" "http://localhost:8086" |
34 | ProxyPassReverse "/influx" "http://localhost:8086" |
35 | |
36 | |
37 | </VirtualHost> |
38 | </IfModule> |
Kommando zurück - der reverse Proxy funktioniert nicht außerhalb von meinem LAN. Gibt es noch etwas anderes in der Apache-Konfiguration, was ich beachten müsste? Oder wie kann ich noch debuggen? Ich hab im Pfad, den der Browser anzeigt nach Aufruf der URL, immer einmal /grafana zuviel, also aufgerufen wird https://********.no-ip.biz/grafana und angezeigt wird daraufhin https://********.no-ip.biz/grafana/grafana/d/DpRVfdAGk/plopp Page not found (404 error) Aber das Zertifikat wird als sicher angezeigt und das Grafana meldet sich, also so ein bisschen Reverse Proxy funktioniert schon..?
Ich denke, ich habe es herausgefunden: Diese Header-Zeile (für die owncloud-Sicherheit) war das Problem:
1 | Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *" |
kann ich die für Owncloud weiter gelten lassen, aber für den Grafana Reverse Proxy nicht? (Datei komplett siehe oben)
Benutzt hier auch jemand Proxmox VE? Habe ich dieses WE installiert und das scheint auch eine Lösung für die Wünsche des TO zu sein. Man kann sehr einfach Container oder VM für getrennte Server auf einem Rechner anlegen, für so Standard Software gibt es turnkey templates die mit wenigen Klicks und Einstellungen zum Server werden. Alles über ein Webinterface zu administrieren.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.