Beliebiges Docker-Image mit Container App deployen

Container App führt jedes Image aus, das sich aus einer Registry ziehen lässt: einen Node- oder Next.js-Server, eine Python-API, ein Go-Binary oder ein Tool, das noch niemand für den Katalog verpackt hat. Du gibst ein Image und einen Port an; die Plattform kümmert sich um Adresse, TLS-Zertifikat und Neustarts. Diese Anleitung deployt zuerst ein öffentliches Image, damit du den ganzen Ablauf siehst, und erklärt dann, was dein eigenes Image braucht.

Was du brauchst

Ein Headpat Space-Konto mit bestätigter E-Mail-Adresse und hinterlegten Rechnungsdaten.
Ein Image in einer Registry wie Docker Hub oder GitHub Container Registry. Hast du nur Quellcode, kann Container App ihn für dich bauen: Wähle in Schritt 1 Code hochladen oder Von GitHub statt Direktes Image. Diese Anleitung bleibt bei Images.

1. Container App bestellen

Melde dich im Panel an, öffne Apps in der Seitenleiste und klicke auf App erstellen.
Suche unter Vorlage nach Container App und wähle es aus.
Wähle unter Paket ein Paket und stelle CPU und Arbeitsspeicher so ein, wie dein Image sie braucht. Beides kannst du später ändern.
Trage unter Details einen Anzeigename ein.
Lass unter App-Quelle die Option Direktes Image ausgewählt und fülle aus:
- Container-Image: die vollständige Referenz inklusive Registry und Tag. Nimm für einen ersten Test docker.io/nginxinc/nginx-unprivileged:1.27.
- Container-Port: der Port, auf dem deine App im Container lauscht. Beim Test-Image ist das 8080.
- Lass Startbefehl und Argumente leer, sofern das Image sie nicht braucht.
- Lass Persistenter Speicher für das Test-Image leer; Schritt 2 erklärt, wann du es ausfüllst.
Setze das Häkchen, mit dem du bestätigst, dass die Bereitstellung sofort beginnen darf, klicke auf App bereitstellen und schließe die Zahlung ab.

Das Image wird geladen und gestartet. Auf der App-Seite zeigt die Karte Zugriff die Adresse deiner App. Warte, bis dort HTTPS aktiv steht, und klicke dann auf Öffnen. Mit dem Test-Image siehst du die Willkommensseite von nginx über HTTPS, unter einer Adresse, die ab jetzt dir gehört.

2. Dein eigenes Image einsetzen

Öffne auf der App-Seite die Karte Konfiguration. Sie hat dieselben Felder wie das Bestellformular: Container-Image, Container-Port, Startbefehl, Argumente, Umgebungsvariablen und Private Registry-Zugangsdaten. Ändere, was du brauchst, und klicke auf Anwenden & neu deployen. Die App startet mit den neuen Einstellungen neu und behält ihre Adresse.

Prüfe vier Dinge, bevor du auf dein eigenes Image zeigst. Sie sind für fast jeden fehlgeschlagenen ersten Deploy verantwortlich.

Es muss als Nicht-Root laufen

Container starten hier als normaler Benutzer, und ein Image, das root sein will, wird abgewiesen. Dein Dockerfile braucht eine USER-Zeile, und die Verzeichnisse, in die der Prozess schreibt, müssen diesem Benutzer gehören. Die meisten Sprach-Base-Images und gut gepflegten Tools machen das bereits. Einige beliebte offizielle Images nicht: nginx, httpd und caddy starten als root, deshalb nutzt der Test oben nginx-unprivileged. Bleibt deine App auf der Karte Status bei 0/1 bereit stehen und erreicht nie HTTPS aktiv, prüfe das zuerst; die Karte Logs & Diagnose auf der App-Seite nennt den Grund.

Es muss auf allen Interfaces lauschen, auf Port 1024 oder höher

Binde an 0.0.0.0, nicht an 127.0.0.1 oder localhost; ein Server, der nur auf localhost lauscht, ist von außerhalb des Containers nicht erreichbar. Ports unter 1024 brauchen root, nimm also etwas wie 3000 oder 8080 und trage dieselbe Nummer unter Container-Port ein. Die Plattform prüft diesen Port mit einer einfachen TCP-Verbindung: Sobald deine App Verbindungen annimmt, gilt sie als bereit und der Verkehr fließt.

Es muss für linux/amd64 gebaut sein

Unsere Server sind x86-64. Auf einem Mac mit Apple Silicon erzeugt docker build standardmäßig ein arm64-Image, und das startet hier nicht. Baue mit docker build --platform linux/amd64 -t ghcr.io/konto/app:1.0 . oder pushe ein Multi-Plattform-Image.

Gib ihr ein Volume, wenn sie Daten auf der Festplatte hält

Eine Container App hat keine eigene Festplatte, sofern du ihr keine gibst. Trage unter Persistenter Speicher den Ordner ein, in den deine App schreibt, zum Beispiel /data: Dieser Ordner behält seinen Inhalt über Neustarts und Neu-Deploys hinweg und ist in den Backups der App enthalten. Alles außerhalb ist nach einem Neu-Deploy oder Neustart weg, behandle den Rest des Containers also als Wegwerfware. Datenbanken gehören weiterhin in eine Datenbank-App wie PostgreSQL oder MariaDB: siehe PostgreSQL-Datenbank erstellen und verbinden. Eine App mit Volume startet bei jedem Neu-Deploy an Ort und Stelle neu, rechne also mit wenigen Sekunden Ausfall pro Release.

3. Konfiguration und Geheimnisse

Nutze Umgebungsvariablen für alles, was sich zwischen deinem Laptop und der Produktion unterscheidet: Datenbank-URLs, API-Schlüssel, die öffentliche URL der App. Klicke auf Variable hinzufügen, trage Name und Wert ein und wende an. Die Werte liegen auf der Plattform und werden dem Container beim Start übergeben; ins Image müssen sie nie.

Muss dein Framework seine eigene öffentliche URL kennen (Next.js, Django und Rails wollen das oft), kopiere die Adresse von der Karte Zugriff in die passende Variable.

4. Images aus einer privaten Registry

Ist dein Image nicht öffentlich, füge unter Private Registry-Zugangsdaten eine Docker-config-JSON ein. Die Form ist:

{"auths": {"ghcr.io": {"auth": "BASE64"}}}

BASE64 ist benutzername:token, mit base64 kodiert, zum Beispiel echo -n 'konto:ghp_xxx' | base64. Für Docker Hub lautet der Schlüssel https://index.docker.io/v1/. Verwende ein Token, das nur pullen darf, nicht dein Kontopasswort. Nach dem Speichern zeigt die Karte Konfiguration den Hinweis Zugangsdaten gesetzt; füge dort eine neue JSON ein, um sie zu ersetzen.

5. Eine neue Version ausliefern

Baue und pushe das neue Image unter einem neuen Tag, zum Beispiel ghcr.io/konto/app:1.1.
Öffne die Karte Konfiguration, ändere den Tag unter Container-Image und klicke auf Anwenden & neu deployen.

Verwende für jedes Release einen neuen Tag. Erneut auf denselben Tag zu pushen holt das neue Image nicht zuverlässig. Nutzt du trotzdem latest, zieht der Button Neustarten oben auf der App-Seite das neueste latest und startet die App neu.

Eigene Domain verwenden

Eine Container App kann deine eigene Domain mit Zertifikat tragen. Siehe Eigene Domain mit einer App verbinden.

Gut zu wissen

Die Karte Logs & Diagnose auf der App-Seite zeigt, was der Container ausgibt, und wenn er nicht läuft, warum: ein fehlgeschlagener Pull, ein abgelehnter root-Benutzer, ein Absturz mit Exit-Code. Teste das Image trotzdem zuerst lokal mit docker run --rm -p 8080:8080 dein-image; ein Problem, das du auf dem Laptop siehst, ist dort schneller behoben.
Es läuft immer eine Instanz. Bei einem Neu-Deploy wird der neue Container gestartet, bevor der alte stoppt, kurze Neustarts verursachen also selten Ausfälle, aber deine App sollte schnell starten und sich bei SIGTERM sauber beenden.
Der gewählte Arbeitsspeicher ist eine harte Grenze. Eine App, die darüber hinauswächst, wird neu gestartet; erhöhe in dem Fall den Arbeitsspeicher im Paket.