Ubuntu Dedicated Server

Ein Ubuntu-Dedicated-Server ist eine physische Single-Tenant-Maschine, die Ubuntu Server direkt auf der Hardware ausführt — ohne Virtualisierungsschicht zwischen Ihrer Workload und CPU, Arbeitsspeicher und NVMe. Sie erhalten vollen Root-Zugriff, jeden Core und vorhersehbare Leistung, statt nur eines Anteils an einem geteilten Host.

Ubuntu ist das am weitesten verbreitete Server-Linux, und genau deshalb ist es die sichere Standardwahl: die größte Paketbasis, erstklassige cloud-init-Automatisierung und der tiefste Fundus an Tutorials, Images und Upstream-Support für Docker, Kubernetes und praktisch jede Runtime, die Sie bereitstellen möchten.

Sie vergleichen Distributionen? Lesen Sie unseren Leitfaden zu Linux-Dedicated-Servern.

LTS-Versionen und der Release-Zyklus

Ubuntu veröffentlicht alle zwei Jahre ein Long-Term-Support-Release (LTS), jeweils im April gerader Jahre, mit Interim-Releases alle sechs Monate dazwischen. Für Server möchten Sie fast immer ein LTS: fünf Jahre reguläre Sicherheitswartung, mit Ubuntu Pro erweitert auf zehn Jahre und mit dem kostenpflichtigen Legacy-Support-Add-on, das obendrauf auf Pro aufsetzt, auf bis zu zwölf Jahre.

Wir provisionieren standardmäßig das aktuelle und das vorherige LTS, sodass Sie eine Flotte auf einer Version standardisieren und diese über ihr gesamtes Support-Fenster hinweg betreiben können, statt auf ein rollierendes Ziel gezwungen zu werden. Falls Sie ein Interim-Release für einen neueren Kernel oder ein neueres Userland benötigen, ist dies auf Anfrage verfügbar.

Wenn Sie bereit sind, zwischen LTS-Releases zu wechseln, übernimmt do-release-upgrade den Sprung an Ort und Stelle; da Sie vollen Root-Zugriff und eine KVM-Konsole haben, steuern Sie das Upgrade — oder eine saubere Neuinstallation auf das neuere LTS — nach Ihrem eigenen Zeitplan, ohne Versionsbindung und ohne dass von unserer Seite etwas erzwungen wird.

Ubuntu Pro, ESM und Livepatch

Ubuntu Pro erweitert die Sicherheitsabdeckung über das Repository „main“ hinaus auf die weitaus größere „universe“-Sammlung und ergänzt Kernel-Livepatch, um kritische Kernel-CVEs ohne Neustart einzuspielen — nützlich, wenn Uptime auf einem Bare-Metal-Host zählt. Canonical stellt Pro für den privaten und kleinen Einsatz kostenlos bereit; kommerzielle Flotten binden ein Abonnement an.

Da Sie auf einer Serverside-Maschine vollen Root-Zugriff haben, steht es Ihnen frei, Ihr eigenes Ubuntu-Pro-Token anzuhängen, Landscape zu betreiben oder das Patching vollständig selbst zu verwalten — wir sperren das OS nicht.

Booten Sie Ihr eigenes Ubuntu mit custom iPXE

Sie sind nicht auf unsere Standard-Images beschränkt. Mit custom iPXE-Konfigurationen können Sie Ihren eigenen Ubuntu-Build oder einen custom Kernel direkt auf das Metal chain-booten, sodass die Maschine genau das Image hochfährt, das Sie freigegeben haben.

Über denselben Weg lässt sich Ubuntu vollständig im Arbeitsspeicher betreiben — ein diskless, RAM-only Root, der die lokale NVMe für Daten frei lässt oder bei jedem Boot sauber wischt. Es ist der stärkste Ausdruck desselben Prinzips: Wir übergeben Ihnen die Hardware und halten uns aus der Boot-Kette heraus.

apt und snap: was Sie tatsächlich betreiben

Ubuntu basiert auf dpkg/apt, und dort liegt die überwiegende Mehrheit der Serversoftware. Ubuntu liefert außerdem snap aus, Canonicals eingegrenztes Paketformat, das manche Server-Betreiber für selbstaktualisierende Daemons bevorzugen und andere deaktivieren, um die Basis minimal zu halten.

Auf einem Dedicated Server liegt die Wahl ganz bei Ihnen: snapd behalten, entfernen oder alles auf apt festlegen. Nichts in unserem Provisioning hängt davon ab.

Was Teams auf Ubuntu-Bare-Metal betreiben

Ubuntus Allgegenwart macht es insbesondere für Container- und Orchestrierungs-Workloads zum Weg des geringsten Widerstands — offizielle Docker- und Kubernetes-Images, Runtimes und CI-Runner zielen zuerst darauf ab.

• Container-Hosts und Kubernetes-Nodes (kubeadm, k3s, RKE2), die rohe CPU- und NVMe-Leistung ohne Hypervisor-Overhead wollen
• Web- und API-Tiers mit hohem Durchsatz, bei denen das volle Uplink und die enthaltene DDoS-Mitigation zählen
• Selbst gehostete Datenbanken und Caches (PostgreSQL, MySQL, Redis) auf lokalem NVMe
• CI/CD-Runner und Build-Farmen, die Cores durchackern
• Game- und Voice-Server — unsere DDoS-Profile sind pro Titel für die in unserem Netzwerk gehosteten Spiele abgestimmt

Einen Ubuntu-Server absichern

Ubuntus standardmäßige Mandatory-Access-Control-Schicht ist AppArmor (nicht SELinux), das aktiviert mit Profilen für gängige Daemons ausgeliefert wird und im Allgemeinen einfacher nachzuvollziehen ist.

Bevor Traffic überhaupt den Host-Stack erreicht, filtern ihn unsere self-service DDoS-Mitigation und Firewall-Regelverwaltung bereits am Netzwerkrand. Das gibt Ihnen eine mehrschichtige Verteidigung: Filterung auf Netzwerkebene, die Sie selbst steuern, ganz vorn, während ufw und AppArmor die Policy auf der Maschine selbst durchsetzen. Virtual Private Networking zwischen Ihren Servern hält Ost-West-Traffic — Datenbankreplikation, Kubernetes-Node-zu-Node — vollständig von der öffentlichen Schnittstelle fern.

Eine sinnvolle Baseline auf einer frischen Serverside-Maschine:

• unattended-upgrades aktivieren, damit Sicherheits-Patches automatisch eingespielt werden
• SSH absichern: ausschließlich Key-Authentifizierung, kein Root-Login per Passwort, und unsere Filterung auf Netzwerkebene davor
• ufw einschalten und nur die Ports freigeben, die Ihre Workload benötigt
• AppArmor im Enforce-Modus belassen; Profile für alles Eigene hinzufügen
• Ubuntu Pro + Livepatch ergänzen, falls Sie Kernel-CVE-Abdeckung ohne Neustarts benötigen