Halloween at Nexthosting: 10% off game servers with the code – until November 1
Server-Bereitstellung automatisieren mit Skripten, Ansible und Terraform: So setzt du VPS, Root- und Gameserver reproduzierbar, sicher und in Minuten auf.
Wenn du die Bereitstellung deiner Server automatisierst, beschreibst du einmal, wie ein fertiger Server aussehen soll, und lässt Werkzeuge diesen Zustand jedes Mal gleich herstellen. Dazu gehören Betriebssystem, Benutzer, Firewall, Pakete und bei Bedarf der Gameserver selbst. Statt sich durch Konsolen zu klicken und SSH-Befehle abzutippen, startest du ein Skript oder ein Playbook und hast nach wenigen Minuten einen identischen, dokumentierten Server. In diesem Leitfaden erfährst du, welche Ebenen der Automatisierung es gibt, welche Werkzeuge wofür gedacht sind und wie du das an einem konkreten Beispiel umsetzt: einem VPS für einen FiveM- oder Minecraft-Server. Außerdem geht es darum, worauf du bei der Sicherheit achten solltest.
Bei der manuellen Einrichtung läuft es meist so: Server bestellen, per SSH einloggen, Updates einspielen, Benutzer anlegen, Firewall setzen, Abhängigkeiten installieren, Gameserver-Dateien herunterladen, Konfiguration anpassen, Dienst starten. Das funktioniert, aber jeder Schritt ist eine Fehlerquelle. Beim dritten Server weißt du nicht mehr genau, ob du überall dieselbe Firewall-Regel gesetzt hast.
Automatisierung dreht das um. Du beschreibst den gewünschten Endzustand in Dateien, und ein Werkzeug sorgt dafür, dass der Server diesen Zustand erreicht. Experten sprechen hier vom Wechsel vom Zusammenklicken in Konsolen zu Infrastructure as Code (IaC). Der Vorteil: Infrastruktur wird versionierbar, per Pull Request überprüfbar und reproduzierbar. Änderungen landen nicht mehr als Erinnerung im Kopf eines Admins, sondern als nachvollziehbarer Commit in einem Git-Repository.
Dass sich das nicht nur für große Rechenzentren rechnet, zeigen Praxisberichte. In einem Fallbeispiel eines Fertigungsunternehmens gingen die Ausfallzeiten nach der Umstellung auf IaC um über 80 % zurück, und die Bereitstellung von Infrastruktur dauerte statt Tagen nur noch wenige Minuten. Bei einem Projekt für ein Landesrechenzentrum dauerte die Bereitstellung eines kompletten OpenShift-Clusters in der hochautomatisierten Umgebung im Schnitt rund 35 minutes. Dein Gameserver-Projekt ist deutlich kleiner, das Prinzip bleibt aber dasselbe: Was einmal sauber beschrieben ist, läuft beim nächsten Mal genauso.
Viele Einsteiger werfen alles in einen Topf. Hilfreicher ist es, drei Ebenen zu trennen, denn für jede gibt es passende Werkzeuge.
| Ebene | Was passiert | Typische Werkzeuge | Beispiel aus dem Gaming-Umfeld |
|---|---|---|---|
| Provisioning | Server, Netzwerke, IPs, Speicher werden angelegt | Terraform, Hoster-API, Control Panel | Neuen VPS für einen Testserver bestellen |
| Konfiguration | Betriebssystem und Dienste werden eingerichtet | Ansible, cloud-init, Shell-Skripte | Benutzer, Firewall, Java oder Abhängigkeiten installieren |
| Deployment | Anwendung bzw. Inhalte werden ausgerollt und aktualisiert | CI/CD-Pipelines, Git-Hooks, Container | Neue Ressourcen oder Mods auf den FiveM-Server spielen |
Diese Trennung ist keine Theorie. Fachleute nutzen Terraform vor allem für das Provisioning und Ansible für das Konfigurationsmanagement. Wer alles mit nur einem Tool erzwingen will, landet oft bei komplexen und fragilen Setups. Auch die Frage „Ansible oder Terraform?“ gilt unter Admins als falsch gestellt: Beide Werkzeuge ergänzen sich. Terraform beschreibt die Ressourcen, Ansible die Software darauf.
Du brauchst nicht sofort den kompletten Stack. Welches Werkzeug passt, hängt von der Zahl deiner Server und deinem Vorwissen ab.
| Werkzeug | Stärke | Grenzen | Passt für |
|---|---|---|---|
| Bash-Skript | Sofort einsetzbar, keine Zusatzsoftware | Wird schnell unübersichtlich, nicht idempotent ohne Mehraufwand | Einzelner VPS, erste Schritte |
| cloud-init | Konfiguriert den Server beim ersten Start | Läuft im Kern nur bei der Erstinstallation | Basis-Setup direkt bei Bereitstellung, sofern dein Image es unterstützt |
| Ansible | Agentenlos über SSH, gut lesbare YAML-Playbooks | Bei sehr vielen Hosts langsamer, braucht saubere Struktur | Mehrere Gameserver, wiederkehrende Wartung |
| Terraform | Deklaratives Provisioning, Zustand wird verfolgt | Benötigt eine API bzw. einen passenden Provider beim Hoster | Teams, viele Ressourcen, Cloud-Umgebungen |
| Container (Docker) | Anwendung inklusive Abhängigkeiten gekapselt | Zusätzliche Schicht, Netzwerk und Volumes wollen geplant sein | Mehrere Dienste auf einem Host, Testumgebungen |
| CI/CD-Pipeline | Automatisches Testen und Ausrollen bei jedem Commit | Einrichtungsaufwand, Rechte müssen sauber gesetzt sein | Entwickler-Teams, RP-Projekte mit vielen Skripten |
Ein Punkt zu Ansible, der es für Gameserver-Admins attraktiv macht: Playbooks beschreiben den gewünschten Zustand von Systemen. Läuft ein Playbook zweimal, ändert es beim zweiten Mal nur, was abweicht. Damit eignet es sich nicht nur für die Ersteinrichtung, sondern auch dafür, Abweichungen später wieder geradezuziehen.
Wie das in der Praxis zusammenspielt, zeigte ein Vortrag beim FileMaker Stammtisch: Ein Webserver wurde mit Terraform angelegt und anschließend mit Ansible automatisiert eingerichtet. Genau dieses Muster lässt sich auf Gameserver übertragen.
Nehmen wir an, du betreibst eine RP-Community und brauchst neben dem Live-Server regelmäßig Testserver für neue Skripte. Jedes Mal alles von Hand einzurichten kostet Zeit und führt zu Unterschieden zwischen Test und Live. So gehst du vor:
inventory/, playbooks/, templates/ (für Konfigurationsdateien wie server.cfg oder server.properties) und files/.Ein stark verkürztes Playbook für Schritt 4 und 5 könnte so aussehen:
- hosts: gameserver
become: true
vars:
game_user: gameserver
tasks:
- name: System aktualisieren
apt:
update_cache: true
upgrade: dist
- name: Systembenutzer für den Gameserver anlegen
user:
name: "{{ game_user }}"
shell: /bin/bash
create_home: true
- name: Passwort-Login per SSH deaktivieren
lineinfile:
path: /etc/ssh/sshd_config
regexp: '^#?PasswordAuthentication'
line: 'PasswordAuthentication no'
notify: ssh neu starten
- name: Konfiguration aus Template erzeugen
template:
src: templates/server.cfg.j2
dest: "/home/{{ game_user }}/server/server.cfg"
owner: "{{ game_user }}"
handlers:
- name: ssh neu starten
service:
name: ssh
state: restarted
Der Gewinn liegt in den Details: Der Gameserver läuft unter einem eigenen Benutzer statt als root, die Konfiguration stammt aus einem versionierten Template, und jede Änderung ist im Git-Verlauf nachvollziehbar. Brauchst du morgen einen zweiten Testserver, trägst du nur seine IP im Inventory ein.
Tipp: Halte Versionsnummern von Gameserver-Builds, Mods und Frameworks als Variablen fest. So weißt du immer, welche Version auf welchem Server läuft, und kannst bei Problemen gezielt auf die vorherige zurückgehen.
Nicht alles gehört sofort in ein Skript. Datenbank-Migrationen deines RP-Frameworks, das Zurückspielen von Backups auf einen Live-Server oder das Löschen von Welten sind Aktionen, bei denen ein Fehler teuer ist. Diese Schritte kannst du vorbereiten und dokumentieren, solltest sie aber bewusst manuell bestätigen, bis dein Setup wirklich ausgereift ist.
Ein automatisierter Prozess arbeitet schnell und ohne Rückfrage. Genau deshalb muss er abgesichert sein. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) formuliert dafür im IT-Grundschutz konkrete Anforderungen. Im Baustein zu Kubernetes verlangt es unter anderem, dass jede Aktion im automatisierten Betrieb authentifiziert und autorisiert wird, dass Automatisierungs-Accounts nur die nötigsten Rechte erhalten und dass die Planung den gesamten Lebenszyklus inklusive Sicherheit und Updates abdeckt. Die Prinzipien lassen sich gut auf kleinere Setups übertragen.
Für deinen Alltag heißt das:
Weitere Orientierung bieten die BSI-Bausteine SYS.1.3 Server unter Linux und Unix und OPS.1.1.2 Ordnungsgemäße IT-Administration. Wenn du für ein Unternehmen oder eine Agentur Server betreibst und Vorgaben wie ISO 27001 erfüllen musst, sprich die Gestaltung deiner Pipeline früh mit deinem IT-Sicherheitsverantwortlichen ab. Gerade bei CI/CD-Pipelines gilt: Sie beschleunigen die Entwicklung, erfordern aber eine Professionalisierung der Betriebsabläufe, damit Sicherheitsanforderungen lückenlos abgebildet bleiben.
Aus der Praxis kennen wir eine Handvoll Stolpersteine, die immer wieder auftauchen:
basis, firewall, fivem, minecraft, backup. So verwendest du Bausteine für verschiedene Spiele wieder.Wie viel Automatisierung sinnvoll ist, hängt stark von der Art deines Servers ab:
| Szenario | Sinnvolle Automatisierung | Passende Server-Art |
|---|---|---|
| Ein Minecraft-, FiveM- oder Garry’s-Mod-Server ohne Linux-Erfahrung | Control Panel, automatische Backups, Updates per Klick | Gameserver mit Verwaltungsoberfläche |
| Mehrere Gameserver oder eigene Mods und Skripte | Ansible-Playbooks, Git-Repository, Testserver | VPS |
| Netzwerk aus vielen Instanzen, eigene Datenbanken, Web-Panel | Ansible plus API-Provisioning, CI/CD | Mehrere VPS oder Root-Server |
| Agentur oder Unternehmen mit Kundenumgebungen | IaC mit Versionierung, Secret Management, Rollenkonzept | Root-Server oder VPS-Verbund |
Wenn du nur einen einzelnen Gameserver betreibst, ist ein verwalteter Gameserver oft die effizienteste Form der Automatisierung, weil Bereitstellung, Backups und Updates bereits über das Panel laufen. Sobald du eigene Abläufe abbilden willst, brauchst du Root-Zugriff auf einen VPS oder einen eigenen Server.
Bei Nexthosting stehen Server schnell bereit, und du verwaltest sie über ein intuitives Control Panel mit automatischen Backups und API-Anbindung. Alle Systeme laufen auf NVMe-SSDs im deutschen Rechenzentrum, mit DDoS-Schutz ohne Mehrkosten. Für dein erstes Ansible-Projekt eignen sich unsere VPS-Tarife von VPS Einfach für €6.49 per month bis VPS Ultra für €32.90 per month. Wenn du lieber direkt spielen willst, findest du fertige Gameserver für Minecraft, FiveM, Garry’s Mod und Rust ab €5.57 per month. Für größere Setups gibt es Root-Server ab €29.99 per month auf nexthosting.net.
Wir sehen bei unseren Kunden zwei Gruppen. Die einen richten jeden Server von Hand ein und verlieren bei jedem Umzug oder Testserver Stunden. Die anderen wollen sofort das große Setup mit allen Werkzeugen und kommen nie über die Planung hinaus. Am besten fährt, wer dazwischen startet: ein sauberes Basis-Playbook, ein Git-Repository und ein Testserver.
Für uns als Hoster heißt das vor allem, dass die Grundlage verlässlich sein muss. Automatisierung bringt wenig, wenn der Server beim Bereitstellen lange auf sich warten lässt oder die Performance von Instanz zu Instanz schwankt. Deshalb setzen wir auf sofort verfügbare Server, NVMe-SSDs, DDoS-Schutz ohne Aufpreis und Hosting im deutschen Rechenzentrum, damit DSGVO-Fragen nicht zur Baustelle werden. Und wenn dein Playbook an einer Stelle hängt, die mit unserer Infrastruktur zu tun hat, bekommst du Antworten direkt von unserem Team statt aus einer anonymen Warteschleife.
Unser Rat: Automatisiere zuerst das, was du am häufigsten tust und was am meisten nervt. Bei den meisten Communities sind das Updates, Benutzerrechte und das Aufsetzen von Testservern. Der Rest folgt, wenn dein Projekt wächst.
— Erik
Für den Einstieg reichen solide Linux-Grundlagen und Erfahrung mit SSH. Ansible-Playbooks sind in YAML geschrieben und lesen sich eher wie eine strukturierte Checkliste als wie ein Programm. Für Terraform und CI/CD-Pipelines lohnt es sich, Git sicher zu beherrschen.
Terraform legt Infrastruktur an, also Server, Netzwerke oder Speicher. Ansible richtet auf diesen Servern Software und Konfiguration ein. In vielen Setups arbeiten beide zusammen: Terraform erstellt den VPS, Ansible macht ihn zum fertigen Gameserver.
Für einen einzigen Server mit Control Panel ist der Aufwand oft höher als der Nutzen, da Backups und Updates bereits über die Oberfläche laufen. Sobald du Testserver brauchst, mehrere Instanzen betreibst oder umziehen willst, zahlt sich ein Playbook schnell aus. Spätestens beim zweiten identischen Server merkst du den Unterschied.
Niemals im Klartext im Repository. Nutze verschlüsselte Variablen wie Ansible Vault oder eine eigene Secret-Management-Lösung und gib Automatisierungs-Accounts nur die Rechte, die sie wirklich brauchen. Das entspricht auch den Anforderungen des BSI für automatisierte Umgebungen.
Ja, aber übertrage nicht einfach jeden alten Handgriff. Dokumentiere den Ist-Zustand, entscheide, was davon wirklich gebraucht wird, und baue daraus ein Playbook. Teste es auf einem frischen Server, bevor du es auf den Live-Server anwendest.