Linux-Cloud-Boxen auf Dockup: 7 Distributionsoptionen

Linux-Cloud-Boxen stellen eine Betriebssystemumgebung bereit, die Sie über SSH konfigurieren. Sie eignen sich für Experimente, Legacy-Software, benutzerdefinierte Systemdienste, Build-Hosts und Workloads, deren Lebenszyklus nicht natürlicherweise an ein Git-Repository oder ein Container-Image gebunden ist.

Dockup unterstützt sieben Image-Optionen: Ubuntu 22.04, Ubuntu 24.04, Debian 12, Alpine 3.20, Fedora 40, AlmaLinux 9 und Rocky Linux 9.

Wann ist eine Linux-Box besser als ein Container-Service?

Wählen Sie eine Box, wenn der Workload Kontrolle über das Betriebssystem benötigt und nicht nur über einen Anwendungsprozess.

Geeignete Beispiele sind:

• Mehrere System-Daemons installieren.
• Betriebssystempakete interaktiv testen.
• Eine Legacy-Anwendung manuell einrichten und ausführen.
• Einen Build- oder Automation-Host betreiben.
• Eine Kundenumgebung unter Linux reproduzieren.
• Lang laufende Tools ausführen, die nicht als Git-Deployment organisiert sind.
• Einen temporären, isolierten SSH-Arbeitsbereich erstellen.

Bevorzugen Sie einen Dockup-Service, wenn es sich um eine reproduzierbare Anwendung mit Repository, Build- und Startbefehl, Health-Endpunkt und Bedarf an horizontaler Skalierung handelt.

Anforderung	Linux-Box	Container-Service
Anpassung des Betriebssystems mit Root-Rechten	Sehr gut geeignet	Änderungen in Dockerfile ablegen
SSH-Administration	Nativ	Interaktive Shell ist PRO
Automatisches Deployment per Git-Push	Manuelle Einrichtung	Integriert
Blue-Green-Health-Gate	Manuelles Design	Integriert
Reproduzierbares Image	Runbook/Script erforderlich	Dockerfile/Nixpacks
Autoscaling	Nicht Teil des Box-Modells	Kubernetes-Option
Schnelles Testen von Distributionen	Sehr gut geeignet	Base-Image kann ausreichen

Eine Box bietet Flexibilität beim Betriebssystem auf Kosten der Deployment-Automatisierung.

Welche sieben Linux-Distributionen sind verfügbar?

Rufen Sie die aktuelle Image-Liste ab:

dockup box images --json

Image	Paketökosystem	Typischer Grund für die Auswahl
ubuntu-22.04	APT	Langfristige Kompatibilität
ubuntu-24.04	APT	Neuere Ubuntu-LTS-Basis
debian-12	APT	Konservativer allgemeiner Server
alpine-3.20	apk	Kleine, auf musl basierende Umgebung
fedora-40	DNF	Neuere Linux-Tools
almalinux-9	DNF	Kompatibilität mit Enterprise Linux
rockylinux-9	DNF	Kompatibilität mit Enterprise Linux

Richten Sie die Distribution an der vom Softwareanbieter unterstützten Umgebung aus. Alpine verwendet statt glibc musl, was sich auf vorgefertigte native Binaries auswirken kann. Enterprise-Linux-Varianten sind nützlich, wenn die Software dieses Paketökosystem erwartet.

Notieren Sie den exakten Image-Slug. „Ubuntu“ reicht nicht aus, da sich Paketversionen und Supportzeiträume zwischen 22.04 und 24.04 unterscheiden.

Wie erstellen Sie eine Linux-Cloud-Box?

Stellen Sie das Image mit einem Namen, Arbeitsspeicher und einer CPU bereit:

dockup box create \
  --project production \
  --image ubuntu-24.04 \
  --name build-host \
  --memory 2048 \
  --cpu 1 \
  --json

Dieses Beispiel fordert 2.048 MB RAM und 1 vCPU an. Beginnen Sie mit gemessenen Anforderungen und passen Sie die Konfiguration anhand des beobachteten Workloads an. CPU-, RAM- und Festplattennutzung werden mit minutengenauer Messung vom Plan-Guthaben abgezogen.

Der Free-Plan kostet 0 $ pro Monat und umfasst ein Startguthaben von 10 $, einen Workspace, drei Datenbanken und drei Deployments. Bezahlte Pläne erlauben eine unbegrenzte Anzahl von Ressourcen, während der tatsächliche Compute-Verbrauch weiterhin das enthaltene Guthaben belastet. Der empfohlene Pro-Plan kostet 20 $ pro Monat und enthält ein Nutzungsguthaben von 20 $.

Die erstellte Box wird zu einer Projektressource mit einem stabilen Target wie production/build-host. Halten Sie dieses Target im Runbook fest.

Wie rufen Sie den SSH-Zugang ab und schützen ihn?

Fordern Sie die Verbindungsdetails an:

dockup box ssh production/build-host --json

Die Antwort enthält Host, Port, Benutzer und Passwort. Behandeln Sie das Passwort als vertrauliche Information. Speichern Sie es in einem freigegebenen Passwortmanager, geben Sie es nicht in einer Agent-Antwort aus und ändern oder ersetzen Sie den Zugang gemäß den Richtlinien Ihrer Organisation.

Vor dem Verbindungsaufbau:

1. Überprüfen Sie Projekt- und Box-Slug.
2. Bestätigen Sie, dass der Operator dazu berechtigt ist.
3. Halten Sie den Zweck der Sitzung fest.
4. Kopieren Sie keine Produktionsgeheimnisse auf eine verworfene Box.
5. Halten Sie Befehlsverlauf und Logs frei von Zugangsdaten.
6. Schließen Sie nicht benötigte Zugangswege und Sitzungen.

SSH-Zugang verleiht innerhalb der Box weitreichende Berechtigungen. Ein Coding-Agent mit diesen Zugangsdaten könnte Pakete installieren, Services ändern, Ports freigeben oder Dateien löschen. Gewähren Sie Agent-Zugriff nur im Rahmen einer geprüften, eng begrenzten Aufgabe und bewahren Sie außerhalb der Shell einen Audit-Nachweis auf.

Der Artikel AI-Agent-Produktionsleitplanken beschreibt das Autonomiemodell.

Wie sollte ein SSH-Workload auf einer Linux-Box starten?

Konfigurieren Sie nach dem Abrufen des SSH-Zugangs den Prozessstart mit den unterstützten Betriebssystem-Tools der jeweiligen Distribution. Ubuntu, Debian, Fedora, AlmaLinux und Rocky Linux verwenden üblicherweise systemd; Alpine nutzt eigene Konventionen für die Serviceverwaltung.

Die Startdefinition sollte das ausführbare Programm, das Arbeitsverzeichnis, den Laufzeitbenutzer, die erforderliche Umgebung, die Restart-Policy und das Log-Ziel angeben. Halten Sie Zugangsdaten außerhalb der Unit-Datei oder des Startskripts und verwenden Sie absolute Pfade, damit das Verhalten nicht von einer interaktiven Shell abhängt.

Testen Sie:

• Der Workload startet nach einem Neustart ohne Anmeldung eines Operators.
• Die erforderliche Umgebung ist verfügbar, ohne nur in der Shell gesetzte Variablen.
• Logs befinden sich an einem bekannten Ort.
• Der Prozess läuft unter dem vorgesehenen Benutzer.
• Fehler sind erkennbar.
• Updates ersetzen Abhängigkeiten nicht unbemerkt.

Für einen einzelnen Webprozess mit diesen Anforderungen bietet ein containerbasierter Service auf Git-Basis möglicherweise bereits den besseren Lebenszyklus.

Wie sollte eine Linux-Box betrieben und neu aufgebaut werden?

Betrachten Sie jeden manuellen Befehl als potenzielle Konfigurationsabweichung. Halten Sie die Einrichtung in einem Script oder einem Configuration-Management-Prozess fest:

#!/usr/bin/env bash
set -euo pipefail

apt-get update
apt-get install -y git ca-certificates
mkdir -p /opt/app

Dieses allgemeine Beispiel ist kein Dockup-Befehl, sondern veranschaulicht, wie sich die Box-Konfiguration reproduzierbar gestalten lässt. Fixieren oder dokumentieren Sie Paketversionen, wenn der Workload Stabilität erfordert.

Ein Box-Runbook sollte Folgendes enthalten:

• Image-Slug.
• Angeforderte CPU- und Arbeitsspeicherressourcen.
• Installierte Pakete und Repositories.
• Benutzerkonten und SSH-Richtlinie.
• Dateisystempfade.
• Start-Service, ausführbares Programm und Arbeitsverzeichnis.
• Offene Services und deren Authentifizierung.
• Methode zur Datensicherung.
• Vorgehen für Patches und Neustarts.
• Schritte zum Neuaufbau.
• Kriterien für Migration oder Stilllegung.

Gehen Sie nicht davon aus, dass das Dateisystem einer Box denselben Snapshot-Workflow wie ein Dockup-Service-Volume besitzt, sofern dieser Workflow nicht ausdrücklich für die Ressource konfiguriert und unterstützt wird. Entwerfen Sie Backups für die Daten und Software, die dort tatsächlich ausgeführt werden.

Wann sollte der Workload in einen Container wechseln?

Wechseln Sie zu einem Container-Service, wenn:

• Die Einrichtung zu einem stabilen Script geworden ist.
• Ein einzelner Anwendungsprozess den Hauptzweck darstellt.
• Änderungen am Quellcode aus Git deployt werden sollen.
• Health-Gates für Releases ohne Downtime erforderlich sind.
• Für ein Rollback eine vorherige Deployment-ID ausgewählt werden soll.
• Mehrere identische Replicas benötigt werden.
• Die Box zwischen verschiedenen Operatoren voneinander abweicht.
• SSH nur noch für manuelle Redeployments verwendet wird.

Überführen Sie die Einrichtung in ein Dockerfile, definieren Sie den Application-Port und den Health-Pfad und deployen Sie zunächst einen Preview- oder Nicht-Produktions-Service. Vergleichen Sie das Verhalten, bevor Sie die Box abschalten.

Der Leitfaden Nixpacks vs. Dockerfile hilft bei der Auswahl der neuen Build-Methode. Kubernetes vs. Docker erläutert die Optionen für die Platzierung der Runtime.

Checkliste zur Auswahl einer Linux-Box

Eine fundierte Entscheidung für Linux-Cloud-Boxen beantwortet folgende Fragen:

1. Welcher der sieben Image-Slugs entspricht dem Support des Anbieters?
2. Warum kann der Workload keinen normalen Service verwenden?
3. Wie werden SSH-Zugangsdaten geschützt?
4. Wie wird die Einrichtung reproduziert?
5. Wo befinden sich Logs und dauerhaft zu speichernde Daten?
6. Wie werden Patches getestet?
7. Welcher Prozess soll automatisch starten?
8. Welches Ereignis löst die Containerisierung oder Stilllegung aus?

Verwenden Sie die Dockup-CLI-Referenz für die aktuellen Box-Befehle und die Image-Liste. Für reine Windows-Workloads vergleichen Sie Windows-VM mit RDP.

Vertrauen in Pakete und Repositories kontrollieren

Eine Box kann jedes vom Operator angeforderte Paket installieren. Daher werden Paketquellen zu einem Teil der Sicherheitsgrenze. Verwenden Sie die signierten Repositories der Distribution, dokumentieren Sie Drittanbieter-Repositories und leiten Sie nicht geprüfte Netzwerk-Skripte nicht direkt in eine Root-Shell weiter.

Halten Sie die Paketliste nach der Einrichtung fest und vergleichen Sie sie bei der Wartung. Wenn ein Agent die Installation eines Tools vorschlägt, verlangen Sie Paketquelle, Version, Zweck und Entfernungsplan.

Prüfen, ob die Box weiterhin gerechtfertigt ist

Überprüfen Sie jeden Monat die Häufigkeit von SSH-Sitzungen, manuellen Deployment-Schritten, Verfügbarkeitsanforderungen, Ressourcennutzung und Vorfällen durch Konfigurationsabweichungen. Eine Box, auf der regelmäßig Anwendungs-Releases über SSH durchgeführt werden, signalisiert, dass ein reproduzierbarer Service-Workflow sinnvoll wäre.

Prüfen Sie die CPU-, RAM- und Festplattennutzung der Box in app.dockup.ai gemeinsam mit dem Runbook. Linux-Cloud-Boxen sind wertvoll, wenn die Betriebssystemkontrolle die entscheidende Anforderung ist. Operativ werden sie teuer, wenn sie lediglich ein nicht dokumentiertes Application-Deployment verbergen.

Temporäre Boxen bewusst stilllegen

Eine Test-Box sollte bereits bei ihrer Erstellung einen Verantwortlichen und ein Ablaufdatum haben. Exportieren Sie vor der Stilllegung nur genehmigte dauerhafte Daten, entfernen Sie kopierte Zugangsdaten, bewahren Sie wiederverwendbare Setup-Skripte auf und bestätigen Sie, dass kein DNS-Eintrag, kein geplanter Job und kein Team-Runbook mehr vom Host abhängt.

So verhindern Sie, dass aus einem kurzen Experiment ein dauerhaft ungepatchter Server wird.

Eine verantwortliche Person für den Notfallzugang festlegen

Benennen Sie die Person oder das Team, die beziehungsweise das verantwortlich ist, wenn der reguläre SSH-Operator nicht verfügbar ist. Die Vertretung sollte wissen, wo die Zugangsdaten gespeichert sind und wie sich das exakte Target überprüfen lässt, ohne Passwörter weiterzugeben.

Die Begründung dokumentieren

Dokumentieren Sie, warum Linux-Cloud-Boxen weiterhin erforderlich sind.

Mit einem überprüfbaren Deployment beginnen

Erstellen Sie eine kleine Box für Nicht-Produktionszwecke, skripten Sie die vollständige Einrichtung ausgehend von einem sauberen Image und legen Sie im Voraus fest, welche Nachweise den Wechsel des Workloads in einen Container rechtfertigen würden.

Kostenlos auf app.dockup.ai starten. Der Free-Plan kostet 0 $ pro Monat, enthält ein Startguthaben von 10 $ und unterstützt einen Workspace, drei Datenbanken und drei Deployments.

FAQ

Welche Linux-Distributionen können Dockup-Boxen verwenden?

Dockup unterstützt ubuntu-22.04, ubuntu-24.04, debian-12, alpine-3.20, fedora-40, almalinux-9 und rockylinux-9.

Wie erhalte ich SSH-Zugangsdaten für eine Linux-Box?

Führen Sie dockup box ssh mit dem exakten Projekt-/Box-Target und --json aus und speichern Sie die zurückgegebenen Verbindungsdetails anschließend sicher.

Wie sollte Software nach der SSH-Einrichtung starten?

Konfigurieren Sie den Start mit dem unterstützten Service-Manager der ausgewählten Distribution und dokumentieren Sie ausführbares Programm, Arbeitsverzeichnis, Laufzeitbenutzer, Umgebung, Restart-Policy und Logs.

Wann ist ein Container-Service besser als eine Linux-Box?

Verwenden Sie einen Container-Service, wenn es sich um eine reproduzierbare Anwendung handelt, die von Git-Deployment, Health-Gates, Rollback und Autoscaling profitiert.

Wie werden Ressourcen von Linux-Boxen abgerechnet?

CPU-, RAM- und Festplattenverbrauch werden pro Minute mit dem Plan-Guthaben verrechnet. Überwachen Sie daher die tatsächliche Nutzung und vermeiden Sie überdimensionierte Zuweisungen.