Ein Servertyp ist die Rolle, die du einem Server beim Erstellen gibst. Der Typ bestimmt, was Vimonto Deploy bei der Einrichtung installiert, welche Ports die Firewall öffnet und welche Seiten der Server in Vimonto Deploy hat. Du weißt nicht, welchen du brauchst? Wähle einen App-Server: Er führt alles auf einer Maschine aus und passt für die meisten Anwendungen.
Mit den anderen Typen verteilst du eine Anwendung auf mehrere Server, wenn sie wächst: Webserver hinter einem Load Balancer, separate Worker für Queues und eigene Datenbank-, Cache- und Suchserver, verbunden über ein privates Netzwerk.
Welchen Servertyp sollte ich wählen?
| Typ | Wofür | Installiert |
|---|---|---|
| App-Server | Alles auf einem Server. Passt für die meisten Anwendungen. | Nginx, PHP, eine Datenbank (optional), Redis, Memcached, Node.js, Supervisor |
| Webserver | Deine Anwendung ausliefern, mit Datenbank und Cache auf anderen Servern. | Nginx, PHP, Node.js, Supervisor |
| Worker-Server | Queue-Worker und andere lang laufende PHP-Prozesse. Nicht über HTTP erreichbar. | PHP, Supervisor |
| Datenbankserver | Eine Datenbank für deine App-, Web- und Worker-Server. | MySQL, MariaDB oder PostgreSQL |
| Cache-Server | Redis und Memcached für deine App-, Web- und Worker-Server. | Redis, Memcached |
| Meilisearch-Server | Eine schnelle Suchmaschine für deine Anwendung, erreichbar über das private Netzwerk. | Meilisearch |
| Load Balancer | Den Datenverkehr einer Domain auf deine App- und Webserver verteilen. | Nginx |
Jeder Typ bekommt außerdem dieselbe Basis: Ubuntu-Updates, den Serverbenutzer, SSH-Härtung, die Firewall ufw, fail2ban, automatische Sicherheitsupdates, Swap, Standard-Jobs im Scheduler und den Monitoring-Agenten.
Welche Seiten hat jeder Typ?
Ein Server zeigt nur die Seiten, die zu dem passen, was auf ihm installiert ist.
| Seite | App | Web | Worker | Datenbank | Cache | Meilisearch | Load Balancer |
|---|---|---|---|---|---|---|---|
| Übersicht | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Sites | ✓ | ✓ | – | – | – | – | ✓ |
| Datenbanken | ✓¹ | – | – | ✓ | – | – | – |
| Backups | ✓¹ | – | – | ✓ | – | – | – |
| PHP | ✓ | ✓ | ✓ | – | – | – | – |
| Prozesse | ✓ | ✓ | ✓ | – | – | – | – |
| Scheduler | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Monitoring | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Terminal | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Netzwerk | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| SSH-Schlüssel | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Services | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Einstellungen | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
¹ Nur wenn der App-Server mit einer Datenbank erstellt wurde, nicht mit Keine.
App-Server
Der App-Server hat alles: Nginx, PHP (die Version, die du wählst, mit Composer), Node.js und npm, eine Datenbank, Redis, Memcached und Supervisor für Queue-Worker. Die Ports 80 und 443 sind für deine Sites offen. Datenbank, Redis und Memcached lauschen nur auf dem Server selbst (localhost) und sind daher von außen nicht erreichbar.
Du kannst einen App-Server ohne Datenbank erstellen, indem du unter Datenbank die Option Keine wählst, zum Beispiel wenn du einen separaten Datenbankserver nutzt. Er hat dann keine Seiten Datenbanken und Backups.
Webserver
Ein Webserver führt deine Sites wie ein App-Server aus, mit Nginx, PHP, Node.js und Supervisor, aber ohne Datenbank oder Cache. Verbinde ihn über ein privates Netzwerk mit einem Datenbankserver und einem Cache-Server. Setze mehrere Webserver hinter einen Load Balancer, um mehr Traffic zu bewältigen.
Worker-Server
Ein Worker-Server hat PHP und Supervisor für Queue-Worker und andere Prozesse, aber kein Nginx. Die Firewall erlaubt nur SSH, daher ist er über HTTP nicht erreichbar. Nutze ihn, um deine Webserver von aufwendiger Queue-Arbeit zu entlasten.
Datenbankserver
Ein Datenbankserver führt nur MySQL (8.4 LTS oder 8.0), MariaDB (11.4 LTS oder 10.11 LTS) oder PostgreSQL (18, 17 oder 16) aus; für diesen Typ ist eine Datenbank Pflicht. Anders als auf einem App-Server lauscht die Datenbank auf allen Adressen, damit sich deine anderen Server mit ihr verbinden können. Liegt der Server in einem privaten Netzwerk, erlaubt die Provisionierung Port 3306 (MySQL und MariaDB) oder 5432 (PostgreSQL) nur aus diesem Netzwerk. Ohne privates Netzwerk blockiert die Firewall jeden eingehenden Datenverkehr zur Datenbank, bis du auf der Seite Netzwerk des Servers eine Regel für die Adressen deiner anderen Server hinzufügst.
Die Einrichtung legt einen Datenbankbenutzer mit dem Namen des Serverbenutzers (standardmäßig vimonto) an, mit vollen Rechten und dem Datenbankpasswort, das einmal angezeigt wird, sowie eine Datenbank mit demselben Namen. Verwalte Datenbanken und Benutzer auf der Seite Datenbanken und plane Backups in deinen eigenen Speicher.
Cache-Server
Ein Cache-Server führt nur Redis und Memcached aus. Sie lauschen auf allen Adressen, damit deine anderen Server sie nutzen können. Redis läuft hier ohne Passwort, also hält nur die Firewall das Internet draußen. Liegt der Server in einem privaten Netzwerk, erlaubt die Provisionierung Port 6379 (Redis) und 11211 (Memcached) nur aus diesem Netzwerk. Ohne privates Netzwerk erreicht sie nichts, bis du auf der Seite Netzwerk eine Regel für die Adressen deiner anderen Server hinzufügst.
Meilisearch-Server
Ein Meilisearch-Server führt die Suchmaschine Meilisearch als Systemdienst auf Port 7700 im Produktionsmodus aus. Ihr Master Key wird beim Erstellen des Servers erzeugt und einmal zusammen mit dem sudo-Passwort als Meilisearch Master Key angezeigt. Liegt der Server in einem privaten Netzwerk, erlaubt die Provisionierung Port 7700 nur aus diesem Netzwerk; sonst fügst du auf der Seite Netzwerk eine Regel hinzu. Trag die private Adresse des Servers und den Key in deiner Anwendung ein (für Laravel Scout: MEILISEARCH_HOST und MEILISEARCH_KEY).
Server in einem privaten Netzwerk
Datenbank-, Cache- und Meilisearch-Server, die du in einem privaten Netzwerk erstellst, bekommen sofort Firewall-Regeln für ihre Dienste. Deine App-, Web- und Worker-Server im selben Netzwerk können sich dann ohne weitere Einrichtung verbinden:
| Typ | Aus dem privaten Netzwerk erlaubte Ports |
|---|---|
| Datenbankserver | 3306 (MySQL, MariaDB) oder 5432 (PostgreSQL) |
| Cache-Server | 6379 (Redis), 11211 (Memcached) |
| Meilisearch-Server | 7700 |
Die Regeln erlauben den Adressbereich des Netzwerks, zum Beispiel 10.0.0.0/16. Kennt Vimonto Deploy den Bereich nicht, nimmt es das /16 um die private IP-Adresse des Servers. Du findest die Regeln auf der Seite Netzwerk des Servers, markiert als Standard; du kannst sie entfernen oder eigene hinzufügen. Das Internet bleibt draußen: Die Firewall blockiert jeden anderen eingehenden Datenverkehr.
Server ohne privates Netzwerk, auch ein eigener VPS, bekommen diese Regeln nicht: Füge dann selbst eine Regel für jeden Server hinzu, der Zugriff braucht.
Load Balancer
Ein Load Balancer führt nur Nginx aus, mit offenen Ports 80 und 443, und verteilt den Datenverkehr einer Domain auf deine App- und Webserver. Er hat kein PHP. Die einzige Art von Site, die du darauf anlegen kannst, ist eine Load Balancer-Site (unter Neue Site), und diese Art von Site kann nur auf einem Load-Balancer-Server liegen.
Auf der Seite Lastverteilung der Site wählst du:
- die Methode: Round Robin (jeder Server der Reihe nach, nach Gewicht), Wenigste Verbindungen (der Server mit den wenigsten offenen Verbindungen) oder IP-Hash (jeder Besucher bleibt anhand seiner IP-Adresse bei einem Server);
- die Server, an die er den Verkehr weitergibt: Mit Server hinzufügen wählst du einen aktiven App- oder Webserver deiner Organisation, mit einem Port, einem Gewicht (höher bekommt mehr Verkehr) und auf Wunsch als Reserveserver, der nur Verkehr bekommt, wenn die anderen Server ausfallen (nicht mit IP-Hash, das Nginx nicht mit Reserveservern kombiniert). Mit Bearbeiten änderst du Port, Gewicht und Reserve-Einstellung später. Der Verkehr läuft über das private Netzwerk, wenn beide Server im selben Netzwerk sind.
Jeder App-Server braucht eine Site für dieselbe Domain. Der Load Balancer gibt die IP-Adresse des Besuchers und die Information, ob er über HTTPS kam, an die App-Server weiter, und die Sites dort vertrauen diesen Angaben nur von diesem Load Balancer. Die lastverteilte Site braucht eine eigene Domain, bevor du App-Server hinzufügst, weil diese nicht für ihre on-deploy.link-Adresse antworten können. Solange noch kein App-Server hinzugefügt ist, bekommen Besucher einen 503. Wie du alles einrichtest, steht unter Lastverteilung.
Häufig gestellte Fragen
Sollte ich mit einem App-Server oder mit separaten Servern anfangen?
Fang mit einem App-Server an. Das ist das einfachste und günstigste Setup und bewältigt viel Traffic. Lagere einen Datenbankserver, Cache-Server oder Worker-Server aus, wenn ein Server nicht mehr reicht oder wenn du Webserver unabhängig skalieren willst.
Wie kommunizieren separate Server miteinander?
Lege sie beim Erstellen in dasselbe private Netzwerk. Datenbank-, Cache- und Meilisearch-Server erlauben ihre Ports dann schon aus diesem Netzwerk (siehe Server in einem privaten Netzwerk); für alles andere erlaubst du den Port aus dem Adressbereich des Netzwerks auf der Seite Netzwerk des empfangenden Servers. Verwende in den Einstellungen deiner Anwendung die private IP-Adresse, die in der Übersicht jedes Servers steht.
Kann ich einem Webserver später eine Datenbank hinzufügen?
Die Einrichtung installiert beim Erstellen des Servers, was der Typ braucht. Wähle einen App-Server, wenn du eine Datenbank auf derselben Maschine willst, oder erstelle einen Datenbankserver und verbinde dich mit ihm.