Wie mehrere Apps auf einem Server hosten mit selben Port hosten?

[Barock]

Ich habe zwei Web Apps app1 und app2. Der Einfachheit halber läuft der Server nur lokal. Nun möchte ich, dass nach dem Starten meines Servers meine Anwendungen wie folgt verfügbar sind.

http://localhost:8080/app1 bzw. https://localhost:5000/app1 und
http://localhost:8080/app2 bzw. https://localhost:5000/app2.

Mit welchem leichten Server kann ich das realisieren? Versucht habe ich es bisher mit

• http-server (npm) und
• lighttpd

, doch beide scheinen nur eine index.html zu unterstützen.

Mit geht es vor allem um Modularität und Skalierbarkeit.

Welche Server können das bzw. wie ist der state of the art?

 

[Masamune2]

In den meisten Fällen wir wohl nginx als reverse Proxy verwendet. Gibts dazu zahlreiche Anleitungen und auch fertige Appliances.

 

[Zer0DEV]

Bin mir nicht mehr sicher, aber ich meine nginx kann das.

 

[Barock]

Dann ist dieses Vorhaben tatsächlich doch so speziell, dass es nur mit wenigen, insbesondere aber nginx, Web Servern funktioniert. 🤔 Dann weiß ich erstmal bescheid und werde mich in nginx einarbeiten.

 

[Gelöscht 871778]

Traefik oder nginx reverse proxy

 

[andy_m4]

Pound ist auch ein relativ einfacher Reserve-Proxy mit dem man das machen kann. Die Konfiguration ist simpel und die Software ist leichtgewichtig. Als SSL-Endpunkt lässt er sich ggf. auch nutzen.

 

[playerthreeone]

Auch ein Apache kann das, spätestens über die htaccess.
Daran ist nix spezielles oder schwieriges.

 

[RalphS]

Natürlich, aber hier muß gebetsmühlenartig immer "Reverse proxy" herangezogen werden, obwohl der eigentlich nur einen sehr speziellen Einsatzzweck hat... den man für zuhause praktisch niemals braucht. 🤷‍♀️

Wenn es um zwei Webapps geht, gibts grundlegend folgende Optionen (ich lasse mal HTTPS außen vor, das nehmen wir überall als zusätzliche Option an):

1. http://server.name/app1 & http://server.name/app2
Einfach zwei Verzeichnisse anlegen, egal ob "echt" im DocumentRoot oder virtuell per Alias. Kann jeder Webserver.

2. http://app1.domain & app2.domain
Virtuelle Hosts. Kann auch jeder. Erfordert ein bißchen Zusatzarbeit, entweder mit extra IP Adresse für jede Anwendung (ja, das geht auch auf demselben Server) oder indem man mit SNI arbeitet und dann über DNS dem Server entsprechende CNAMEs oder wegen mir auch weitere A Records verpaßt.

3. Wie 2, aber mit dedizierter Portnummer (siehe OP).
Selbe Anforderungen wie in (2), nur daß man zusätzlich die Portnummern in der Konfiguration mit angeben muß.
Sie werden aber nicht benötigt. Und das ist auch der Punkt, warum ständig irgendwelcher Blödsinn "empfohlen" wird, daher bitte hinter die Ohren schreiben:

1. Eine Website lauscht an einem Socket.
2. Ein Socket ist eindeutig.
3. Ein Socket ist die Kombination aus IP-Adresse und TCP(oder UDP)Portnummer.

Via SNI wird nur ein Socket benötigt, das muß der Webserver unterstützen.
Ohne SNI kann man sogar fünf verschiedene Webserver auf dieselbe Maschine hauen -- nicht daß man muß, aber man kann es --- solange man nur dafür sorgt, daß die Kombination aus IP-Adresse und TCP-Port eindeutig bleibt.


Reverse Proxies dagegen braucht man prinzipiell (nur) dann, wenn man einen Webservice anbieten will von einer Maschine aus, die selbst nicht aus dem Internet erreichbar ist (und das auch nicht sein soll). Dann gibt es einen Gateway mit öffentlicher IP-Adresse, der die Anfragen von Clients annimmt und diese Anfragen an einen (der) nachgelagerten Webserver OHNE öffentliche IP-Adresse weiterreicht.
Dieser Gateway ist der Reverse proxy.