NGINX und Jekins

bywizard

Lieutenant
Registriert
Okt. 2018
Beiträge
537
Guten Tag liebes Forum!

Ich habe heute auf meinem server jenkins installiert für mich und mein kleines team um ein programm zu entwickeln. jedoch hört jenkins auf den port 8080 und ich muss sozusagen immer eingeben: ip:8080
ich nutze auch nginx für meine website

meine frage ist nun: ist es möglich dass ich jenkins mit nginx so verbiden kann dass ich zb eingebe: ip/jenkins

Wenn ja, wie?
 
Ja, du musst nur jenkins mit dem passenden Parameter im "/jenkins/" context starten (RTFM) und kannst dann im nginx einen entsprechenden location Block mit reverse proxy config anlegen.
 
Habt du denn keine Domain? Eine subdomain dürfte schöner sein als Unterverzeichnisse. Sieh mal hier: https://wiki.jenkins.io/display/JENKINS/Jenkins+behind+an+NGinX+reverse+proxy

Meine Konfiguration sieht im Groben so aus:

Code:
server {
    server_name  jenkins.example.com;
    listen *:443 ssl http2;
    # ssl_certificate & Co.

    # Needed for Jenkins CSRF-Protection (.crumb header)
    ignore_invalid_headers  off;

    location / {
        proxy_pass  http://127.0.0.1:8080;

        # Jenkins can be slow at times, allow higher timeouts
        proxy_connect_timeout  30s;
        proxy_read_timeout  60s;
        proxy_send_timeout  60s;

        proxy_redirect  http://  https://;
        proxy_request_buffering  off;
        proxy_buffering  off; # Required for HTTP-based CLI

        proxy_http_version  1.1;

        proxy_set_header Host               $server_name;
        proxy_set_header X-Real-IP          $remote_addr;
        proxy_set_header X-Forwarded-For    $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host   $host;
        proxy_set_header X-Forwarded-Proto  $scheme;
        proxy_set_header Connection         ""; # Clear for keepalive
    }
}
sowie ein weitere server {} mit dem gleichen server_name und listen *:80 der auf https:// weiterleitet. Wenn du kein SSL-Zertifikat hast dann direkt oben listen *:80; rein
 
  • Gefällt mir
Reaktionen: konkretor
für eine subdomain müsste ich dann sozusagen eine neue datei statt nur default bei sites-enabled anlegen?
 
Du musst gar nichts. Nginx interessieren die Dateien und deren Namen kein Stück, der Inhalt wird bei entsprechenden include <file>; anweisungen quasi 1:1 eingefügt. Es ist lediglich der Übersichtlichkeit wegen ratsam, für jede (sub)domain eine eigene Datei zu pflegen.

Wichtiger ist erstmal dass die Domain Records auch so konfiguriert sind das eine entsprechende subdomain existiert und auf den Server zeigt.
 
Ja. Also ist hübscher und besser zu pflegen - aber kein Muss.
Wo und wie kommt aber ein bisschen darauf an welche distri du verwendest und wie dein nginx eingestellt ist. Ich habe bspw meine in /etc/nginx/conf.d liegen - bspw: website.conf, jenkins.conf, nextcloud.conf...
Die config von @Marco01_809 habe ich beinahe identisch im Einsatz. Ssl solltest du auf jeden Fall davor schalten. Kostet nichts und macht auch keine Arbeit :)
https://www.digitalocean.com/commun...-using-an-nginx-reverse-proxy-on-ubuntu-18-04
Das sollte ein guter Einstiegspunkt sein. Solltest du bei etwas fragen / Probleme haben frag gerne :)
 
  • Gefällt mir
Reaktionen: Marco01_809, konkretor und madmax2010
snaxilian schrieb:
Sofern die Kiste öffentlich im Web erreichbar ist rate ich noch einen längeren Blick inkl. Umsetzung hier drauf: https://jenkins.io/doc/book/system-administration/security/
Wer sich denkt "aach wird schon nix passieren, meine Daten sind nicht spannend" dem empfehle ich u.a. das als Lektüre: https://www.helpnetsecurity.com/2020/02/11/cve-2020-2100/, ist gerade 7 Tage alt.

Ansonsten wie schon erwähnt: Reverse Proxy ist das Zauberwort.
Bei Firmen die eine "updates, maintenance, backup und crypto werden überbewertet" Mentalität haben nehme ich seit einiger Zeit einen deutlich höheren Stundensatz. Das gehört bestraft. Aber bitte nicht auf Kosten meiner Lebenszeit
 
  • Gefällt mir
Reaktionen: snaxilian
Danke für die antworten die config von marco hat funktioniert und ich verwende debian 10
 
Die reine Verwendung einer mit Updates versorgten Distribution befreit dich nicht von der Notwendigkeit, diese absichern zu müssen wenn du dies öffentlich erreichbar betreibst...
 
Zurück
Oben