Wie man Docker-Container auf Remote-Servern bereitstellt

Arbeiten mit Docker-Containern auf Remote-Servern Es ist mittlerweile die Grundlage für alle, die moderne Anwendungen bereitstellen möchten, ohne sich in Abhängigkeiten, Bibliotheksversionen und dem klassischen „Es funktioniert auf meinem Rechner“ zu verlieren. Wenn wir jedoch von der Ausführung einer einfachen Anwendung zu einem komplexeren System übergehen, … docker run Wenn man von der Einrichtung einer ernsthaften lokalen Bereitstellung auf einem Linux-Server mit Docker Compose, GitHub-Freigaben, Plesk, Portainer oder sogar grafischen Anwendungen, die über den Browser zugänglich sind, ausgeht, wird die Sache etwas komplizierter.

Wenn Ihr Ziel darin besteht, Docker-Container auf einem Remote-Server bereitzustellen (Ubuntu, Debian, Windows mit WSL 2, ein Cloud-Server, Plesk usw.) und dies auf eine wartungsfreundliche, automatisierte und sichere Weise zu tun, bietet Ihnen dieser Leitfaden eine ziemlich vollständige Reise: von der grundlegenden Verwendung von Docker Compose remote über Entwicklungsumgebungen mit VS Code, Bereitstellungen von Plesk, Administration mit Portainer bis hin zur Remote-Ausführung grafischer Anwendungen mit noVNC und Caddy.

Grundlagen: Docker-Container und Remote-Bereitstellung

Docker ist eine Containerplattform Es verpackt eine Anwendung zusammen mit allem, was sie benötigt (Bibliotheken, Abhängigkeiten, Binärdateien, minimale Systemkonfiguration), sodass sie auf jedem Rechner mit installiertem Docker-Container identisch läuft. Der Hauptunterschied zu einer virtuellen Maschine besteht darin, dass der Container kein vollständiges Betriebssystem enthält; stattdessen nutzt er den Host-Kernel, was zu kleineren Images und besserer Performance führt.

Um Docker-Container auf Remote-Servern bereitzustellen Üblicherweise verwendet man einen Host (z. B. einen Ubuntu-Server in der Cloud) mit Docker und optional Docker Compose, an den man dann den Code oder die Images zur Ausführung sendet. Dies kann manuell per SSH erfolgen, mit GitHub Actions automatisiert oder in Panels wie Plesk oder Tools wie Portainer integriert werden.

Die wichtigsten realen Szenarien, denen Sie begegnen werden Wenn von „Remote-Docker“ die Rede ist, gibt es drei Aspekte: lokale Entwicklung mit Containern auf einem anderen Rechner (oder in WSL 2), automatisierte Bereitstellung von Backend-/Frontend-Diensten und Verwaltung von Produktionscontainern (Überwachung, Protokollierung, Neustarts, Netzwerkrichtlinien usw.). Die Technologie bleibt dieselbe; die Orchestrierung ändert sich.

Zusätzlich zu den traditionellen Backend-DienstenDocker ermöglicht eine weniger bekannte, aber sehr leistungsstarke Funktion: das Ausführen grafischer Anwendungen (E-Mail-Clients, IDEs, Analysetools usw.) in entfernten Containern und der Zugriff darauf über einen Browser mittels VNC über WebSocket. Es ist eine komfortable Möglichkeit, leistungsstarke Server zu nutzen, wenn der eigene PC nicht ausreicht.

Von docker run zu Docker Compose auf einem Remote-Server

Ein recht häufiges Muster der manuellen Bereitstellung Es besteht aus einem Code-Repository auf GitHub, einem Remote-Ubuntu-Server mit installiertem Docker und einem CI/CD-Workflow (z. B. GitHub Actions), der beim Pushen in einen Branch Folgendes ausführt: development o main:

• Stellen Sie über SSH eine Verbindung zum Remote-Server her.
• Laufende Container stoppen und entfernen.
• Laden Sie die neuen Images von Docker Hub (oder von Ihrer privaten Registry) herunter.
• Lauf docker run für jeden Dienst.
• Lassen Sie Nginx (oder den von Ihnen verwendeten Reverse-Proxy) den Datenverkehr an die Ports der einzelnen Container umleiten.

Wenn Sie zu Docker Compose wechseln Der Ablauf wird erheblich vereinfacht, da Sie anstatt Container einzeln zu verwalten, Ihren gesamten Stack (Frontend, Backend, Datenbank, Cache usw.) in einer einzigen Datei definieren. docker-compose.yml, mit seinen Netzwerken, Volumina und Umweltvariablen.

Die einfachste (und recht gängige) Vorgehensweise bei GitHub Actions Der Workflow sollte Folgendes ausführen: cd zum Projektverzeichnis auf dem Remote-Server (wo sich Ihr docker-compose.yml) und führen Sie Befehle wie die folgenden aus:

• docker compose pull um die aktuellsten Bilder zu präsentieren.
• docker compose down um alte Behälter zu entfernen (optional mit --remove-orphans).
• docker compose up -d --build wenn Sie Images direkt vom Server erstellen.

Dieser Ansatz funktioniert gut und ist sehr robust.Sofern Sie die Kontrolle über Anmeldeinformationen, Umgebungsvariablen und Volumes haben, können Sie die Sicherheit verbessern, indem Sie verhindern, dass GitHub Actions vollen Root-Zugriff auf den Server erhält, SSH-Schlüssel einschränken, dedizierte Benutzer verwenden oder Docker sogar als sicheren Remote-Dienst mit Zertifikaten bereitstellen, anstatt alles über SSH auszuführen.

Es gibt keinen "magischen Weg", der viel besser ist als dieser. In einer einfachen Umgebung ist es entscheidend, den Code zu automatisieren und gut zu schreiben. docker-compose.ymlVerwenden Sie unveränderliche Bild-Tags (z. B. spezifische Versionen) und verfügen Sie über einen Rollback-Mechanismus (z. B. Speichern der vorherigen Version der Komposition oder der Bilder).

Remote-Entwicklungsumgebung mit Docker, WSL 2 und VS Code

Unter Windows ist die Entwicklung mit Docker unter Verwendung von WSL 2 sehr verbreitet.Docker Desktop für Windows bietet eine auf WSL 2 basierende Engine, mit der Sie Linux- und Windows-Container auf demselben Rechner ausführen können, während Sie gleichzeitig Code mit VS Code bearbeiten und im lokalen Browser testen.

Der typische Arbeitsablauf zum Einrichten einer Entwicklungsumgebung mit Remote-Containern unter Verwendung von WSL 2 Es ist das Folgende:

1. Installieren Sie WSL 2 und eine Linux-Distribution (z. B. Ubuntu).
2. Sie installieren Docker Desktop unter Windows und aktivieren die Option „WSL 2-basierte Engine verwenden“ unter Einstellungen > Allgemein.
3. Unter Einstellungen > Ressourcen > WSL-Integration wählen Sie die WSL-Distributionen aus, auf denen Docker funktionieren soll.
4. Sie überprüfen die Installation mit docker --version und Laufen docker run hello-world innerhalb der WSL-Distribution.

Um sich „innerhalb“ der Container weiterzuentwickeln Und es geht nicht nur darum, Docker als Engine zu verwenden; VS Code ist entscheidend. Mit WSL, Dev Containers und Docker-Erweiterungen können Sie beispielsweise Folgendes tun:

• Öffnen Sie Ihren in WSL gehosteten Projektordner direkt in VS Code.
• Öffnen Sie diesen Ordner erneut „in einem Entwicklungscontainer“ (Dev Container), indem Sie … Dockerfile und devcontainer.json die Ihre ideale Umgebung beschreiben (Python-Version, Node usw.).
• Debuggen Sie Ihre Anwendung direkt aus VS Code heraus, während sie im Container ausgeführt wird.

Ein sehr häufiges Beispiel Es funktioniert mit einem Django- oder Node.js-Projekt: Sie klonen das Repository innerhalb von WSL und öffnen den Ordner mit code .Sie wählen eine Entwicklungscontainerdefinition (z. B. „Python 3“) aus, woraufhin VS Code das Image erstellt und den Container mit allen Abhängigkeiten startet. Anschließend können Sie den Code ausführen, debuggen und überprüfen, ob er unter Linux läuft, selbst wenn Ihr Hostsystem Windows ist.

Diese Vorgehensweise ist auch dann nützlich, wenn Ihr Rechner nicht sehr leistungsstark ist.Weil man mit Docker einen Teil der Last auf einen Remote-Server verlagern und sich mit VS Code über SSH und Dev Containers verbinden kann, sodass es fast so funktioniert, als wäre es lokal, aber man ist auf die Ressourcen des Servers angewiesen.

Anwendungen auf einem Cloud-Server mit Docker und Docker Compose bereitstellen

Richten Sie einen Cloud-Server mit Docker ein, der für die Bereitstellung bereit ist. Bei den meisten Anbietern geht es sehr schnell: Man wählt ein Systemabbild, auf dem Docker bereits vorinstalliert ist, wartet ein paar Minuten, und schon ist die Maschine bereit, Container zu empfangen.

Ein typisches Muster für die Bereitstellung einer einfachen Node.js-Anwendung Es wäre folgendes:

1. Erstellen Sie das Node.js-Projekt (zum Beispiel ein „Hello World“-Projekt mit Express) auf Ihrem lokalen Rechner: Projektordner, Unterverzeichnis app, npm initInstallation von Abhängigkeiten (wie z. B. express) und ein index.js Dadurch wird ein Server auf Port 3030 mit einer einfachen Nachricht eingerichtet.
2. Dockerisieren Sie die App mit einem Dockerfile das das Basisbild definiert (zum Beispiel node:12), The WORKDIRKopieren Sie die App-Dateien und führen Sie sie aus. npm install und den internen Anschluss freilegen.
3. Fügen Sie ein .dockerignore um zu vermeiden, dass Dinge wie node_modules.
4. Erstellen Sie eine docker-compose.yml im Projektstammverzeichnis, wobei die Version angegeben wird (zum Beispiel 3.8und die Definition des Hauptdienstes, seines build, Portzuordnung (3030:3030) und der Befehl (node index).

Sobald Sie das Projekt und die Compose-Datei bereit habenDie Bereitstellung auf dem Remote-Server erfolgt üblicherweise nach folgendem Ablauf:

• Sie stellen die Verbindung zum Server über SSH her.
• Sie klonen das Repository oder laden die Dateien hoch (Git, SCP, rsync…).
• Sie installieren Docker-komponieren falls es nicht bereits vorhanden ist (bei vielen Distributionen muss man es separat von Docker installieren, zum Beispiel durch Herunterladen der Binärdatei von GitHub und Erteilen von Ausführungsberechtigungen).
• Sie führen aus docker-compose up (o docker compose up (abhängig von der Version) damit die Images heruntergeladen, Ihr App-Image erstellt und die Container gestartet werden.

Ein Punkt, der oft übersehen wird, ist die Firewall des Anbieters.Wenn Ihr Dienst auf Port 3030 lauscht, müssen Sie diesen in Ihren Firewall-Regeln freigeben oder eine spezielle Richtlinie erstellen und diese dem Server zuordnen. Andernfalls erhalten Sie von außen lediglich die Meldung „Verbindung abgelehnt“, selbst wenn der Container ordnungsgemäß ausgeführt wird.

Sobald die Anwendung betriebsbereit ist, können Sie darauf zugreifen. unter Verwendung der öffentlichen IP-Adresse und des freigegebenen Ports des Servers (zum Beispiel, https://IP_DEL_SERVIDOR:3030oder indem man diesen Port hinter einem Reverse-Proxy wie Nginx/Traefik versteckt, der auf Port 80/443 lauscht.

Verwaltung von Remote-Containern mit Plesk und Docker

Wenn Sie Plesk als Ihr Kontrollpanel verwendenSie können sich auch auf die Docker-Erweiterung verlassen, um Container direkt über die Weboberfläche zu verwalten, sowohl auf dem Server selbst als auch auf entfernten Docker-Hosts.

Plesk unterstützt Docker auf einer Vielzahl von Betriebssystemen.CentOS 7, RHEL 7, Debian 10/11/12, verschiedene Ubuntu-Versionen (18.04, 20.04, 22.04, 24.04), AlmaLinux 8/9, Rocky Linux 8.x und das aktualisierte Virtuozzo 7. In Plesk für Windows läuft Docker nicht lokal, sondern auf einem entfernten Rechner, der als Docker-Host fungiert.

Es gibt einige wichtige Einschränkungen zu beachten.:

• Die Docker-Erweiterung kann nicht verwendet werden, wenn Plesk in einem Docker-Container bereitgestellt wird.
• Für die Nutzung von Docker-Diensten auf entfernten Hosts (d. h. externen Hosts) benötigen Sie eine zusätzliche Lizenz oder spezielle Pakete (Hosting Pack, Power Pack, Developer Pack).
• Von Plesk verwaltete Docker-Container sind im eigentlichen Sinne nicht "migrierbar", allerdings können die von ihnen verwendeten Daten mithilfe von Volumes oder Snapshots gesichert werden.

Über die Plesk-Oberfläche können Sie nach Bildern suchen. sowohl im lokalen Repository (bereits auf den Host heruntergeladene Images) als auch in Docker Hub. Das Bedienfeld führt Sie durch den Start eines Containers:

1. Ir a Docker > Container > Container ausführen.
2. Suchen Sie das gewünschte Image und lesen Sie gegebenenfalls die zugehörige Dokumentation auf Docker Hub.
3. Optional kann eine bestimmte Bildbezeichnung/Version ausgewählt werden.
4. Konfigurieren Sie die Containerparameter (Umgebungsvariablen, Ports, Volumes, Speicher, automatischer Start usw.) und klicken Sie auf Ausführen.

Plesk ermöglicht Ihnen außerdem die Verwaltung erweiterter Einstellungen. Für jeden Container: Weisen Sie Ports neu zu (automatisch oder manuell), entscheiden Sie, ob der Port aus dem Internet oder nur vom lokalen Rechner aus erreichbar ist, begrenzen Sie den vom Container verbrauchbaren Arbeitsspeicher, definieren Sie Volumes (Pfad auf dem Host und im Container) oder fügen Sie so viele Umgebungsvariablen hinzu, wie Sie benötigen.

Hinsichtlich des Aspekts der FernsteuerungPlesk kann mit „Remote-Docker-Diensten“ arbeiten. Dies beinhaltet die Konfiguration des Docker-Daemons auf dem Remote-Host (zum Beispiel mithilfe eines Docker-Servers). /etc/docker/daemon.json (mit Unterstützung für TLS und TCP-Sockets) Zertifikate generieren .pem und registrieren Sie diesen Host in Plesk von Docker > Umgebungen > Server hinzufügenDann können Sie diesen Docker-Knoten als aktiv markieren und über dieselbe Benutzeroberfläche zwischen verschiedenen Servern wechseln.

Docker Compose-Stacks von Plesk aus bereitstellen

Wenn Sie Docker Compose bereits für Ihre Infrastruktur verwendenMöglicherweise sind Sie daran interessiert, dass Plesk die Bereitstellung von „Stacks“ aus Dateien übernimmt. docker-compose.yml.

Der Workflow für die Bereitstellung eines Compose-Projekts in Plesk Es ist relativ einfach:

1. Geben Sie ein Docker > Stacks > Stack hinzufügen.
2. Weisen Sie dem Stack einen Projektnamen zu.
3. Wählen Sie die Quelle der Compose-Datei: Editor (Inhalt einfügen), Datei von Ihrem Computer hochladen oder eine vorhandene Datei im Webspace einer Domain auswählen.
4. Bestätigen Sie die Konfiguration und erlauben Sie Plesk, die definierten Container zu deklarieren und zu erstellen.

Alles, was während des Bauprozesses gebaut wird Die zugehörige Compose-Datei wird im Hauptverzeichnis der Website gespeichert, was den Zugriff auf Protokolle, Zwischenergebnisse oder zusätzliche, vom Build-Prozess generierte Dateien erleichtert.

Plesk erleichtert auch die Verwaltung lokaler Bilder: von Docker > Images Sie können filtern, verschiedene Produkt-Tags überprüfen, den belegten Speicherplatz einsehen und veraltete Bilder löschen, um Speicherplatz freizugeben. Dies ist besonders wichtig in Remote-Umgebungen mit begrenztem Speicherplatz.

Wenn Sie Nginx als Ihren Frontend-Webserver verwendenPlesk wendet Proxy-Regeln an (zum Beispiel in der nginx.conf (von der Domain), um den Datenverkehr zu Ihren Docker-Containern zu leiten, selbst in Szenarien hinter NAT. Dadurch entfällt die manuelle Konfiguration von Reverse-Proxys auf entfernten Servern.

Remote-Container mit Portainer verwalten

Portainer ist eine leichtgewichtige Webschnittstelle Für Docker vereinfacht es die tägliche Arbeit derjenigen erheblich, die nicht ständig mit der Kommandozeile arbeiten möchten. Es fungiert selbst als Container und kann den lokalen Host oder mehrere Remote-Hosts verwalten (sogar mit Portainer Agent).

So installieren Sie Portainer auf Ihrem Server mithilfe von Docker Üblicherweise befolgt man diese grundlegenden Schritte:

• Erstellen Sie ein Volume für Portainer-Daten: docker volume create portainer_data.
• Starten Sie den Portainer-Container, indem Sie die Ports 8000 und 9000 mappen und den Docker-Socket einbinden (/var/run/docker.sockund das Datenvolumen: docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer.

Dadurch lauscht Portainer auf Port 9000 des Servers.Wie immer müssen Sie den Port in Ihrer Firewall öffnen oder ihn über einen HTTPS-Reverse-Proxy bereitstellen. Beim ersten Zugriff über einen Browser werden Sie von Portainer aufgefordert, einen Administratorbenutzer anzulegen. Anschließend können Sie auswählen, ob Sie den lokalen Docker-Container oder zusätzliche Remote-Hosts verwalten möchten.

Das Bedienfeld von Portainer ist recht intuitiv.Sie sehen aktive Container, deren Protokolle, Statistiken zum Ressourcenverbrauch, Compose-Stacks, Netzwerke, Volumes und vieles mehr. Und vor allem ermöglicht es Ihnen, Container mit unterschiedlichen Parametern neu zu erstellen, Images zu aktualisieren, Stacks zu verwalten und mehrere Remote-Server über eine einzige Oberfläche zu zentralisieren.

Grafische Anwendungen in Remote-Containern ausführen und über einen Browser darauf zugreifen

Wenn Ihrem Computer die Ressourcen ausgehen Wenn Sie jedoch rechenintensive grafische Anwendungen (wie E-Mail-Clients, IDEs oder Reverse-Engineering-Tools) benötigen, bietet sich eine sehr interessante Lösung an: die Ausführung dieser Anwendungen in Docker-Containern auf einem leistungsstarken Server und der Zugriff darauf über das Web.

Eine sehr gut dokumentierte Fallstudie Die Idee besteht darin, Mozilla Thunderbird in einem Container zu kapseln, seine grafische Oberfläche über TigerVNC/noVNC zugänglich zu machen und den Zugriff mit Caddy zu sichern. Dieses Konzept lässt sich für nahezu jede Linux-GUI-Anwendung wiederverwenden.

Die grundlegende Architektur dieser Art von grafischem Container umfasst üblicherweise Folgendes::

• Ein leichtgewichtiger VNC/X11-Server (TigerVNC), der als Display-Server fungiert.
• Ein minimalistischer Fenstermanager (OpenBox) zur Verwaltung von Fenstern.
• Ein kleiner, einfach zu bedienender Servertyp easy-novnc Dabei wird VNC als WebSocket bereitgestellt und eine HTML-Seite generiert, um die Verbindung vom Browser aus herzustellen.
• supervisord oder etwas Ähnliches, um alle Prozesse innerhalb des Containers zu starten und zu überwachen.
• Die Anwendung selbst (Thunderbird, GIMP usw.), die so konfiguriert ist, dass sie auf dem entfernten Bildschirm angezeigt wird (DISPLAY=:0).

In der Praxis wird ein Arbeitsverzeichnis eingerichtet. (zum Beispiel, ~/thunderbird) wo sie platziert werden:

• Un supervisord.conf Dabei werden die zu startenden Programme definiert: TigerVNC, easy-novnc, OpenBox und die Hauptanwendung, wobei Prioritäten festgelegt werden, sodass der grafische Server vor der Anwendung gestartet wird.
• Un menu.xml OpenBox konfiguriert das Desktop-Menü (Hauptanwendung, Terminal, Prozessmonitor mit htop usw.).
• Un mehrstufiges Dockerfile was in der ersten Phase kompiliert easy-novnc mit Go, und im zweiten Schritt wird das endgültige Image auf Debian erstellt, wobei Openbox, TigerVNC, Supervisor, Konsolenprogramme und die Anwendung (im Beispiel Thunderbird) installiert werden, die Binärdateien und Konfigurationen kopiert, ein Benutzer ohne Root-Rechte erstellt und ein persistentes Datenvolume definiert wird. /data.

Der Standardbefehl des Containers wird üblicherweise an supervisord delegiert., indem man es wie ein normaler Benutzer startet gosuNach der Anpassung der Berechtigungen für das Datenvolume werden beim Start des Containers VNC, noVNC, der Fenstermanager und die Anwendung automatisch gestartet, und Sie müssen nur noch auf den von easy-novnc bereitgestellten HTTP-Port zugreifen.

Um es robuster und benutzerfreundlicher für das Internet zu gestaltenEs empfiehlt sich, einen Webserver wie Caddy vorzuschalten, ebenfalls in einem Container, der als Reverse-Proxy für Ihre grafische Anwendung fungiert, eine Basisauthentifizierung (gehashter Benutzername und Passwort) hinzufügt und optional einen WebDAV-Anschluss für den Zugriff auf die Dateien bereitstellt. /data von Ihrem lokalen Rechner.

Orchestrieren Sie die Lösung mit Netzwerken, Volumes und Caddy.

Um diese Art von Einsatz organisiert zu halten Üblicherweise erstellt man ein eigenes Docker-Netzwerk und ein oder mehrere Datenvolumes:

• Netzwerk, zum Beispiel thunderbird-net, die von allen zugehörigen Containern gemeinsam genutzt wird.
• Volumen thunderbird-data welche das Benutzerprofil und die persistenten Daten der grafischen Anwendung enthalten wird.

Der Container der grafischen Anwendung Sie können es beispielsweise so starten:

• Politik --restart=always damit es von selbst stehen kann.
• Volumenmontage thunderbird-data:/data.
• Verbindung zum Netzwerk thunderbird-net.
• Identifizierbarer Name (thunderbird-app(zum Beispiel) den Caddy für den Reverse-Proxy verwenden wird.

In einem anderen Verzeichnis (zum Beispiel ~/caddy) Das Bild von Caddy wird konstruiert mit den notwendigen Modulen (wie dem WebDAV-Plugin) und einem Caddyfile was Folgendes definiert:

• Ein Server auf Port 8080.
• Un reverse_proxy zu thunderbird-app:8080 (oder der Port, den noVNC bereitstellt).
• Zusätzliche Pfade zum Navigieren durch Dateien (/files) und für WebDAV (/webdav), die beide dem Inhalt des Datenvolumens dienen.
• Ein Block von basicauth wodurch alle Pfade mit einem Benutzer und einem aus Umgebungsvariablen gelesenen gehashten Passwort geschützt werden.

Beim Erstellen des Caddy-ContainersDas gleiche Volumen wird zusammengestellt thunderbird-data:/dataEs verbindet sich mit dem Netzwerk thunderbird-net und sein Hafen wird veröffentlicht (zum Beispiel, -p 8080:8080) auf dem Host. Damit müssen Sie nur noch in Ihrem Browser zu http://IP_DEL_SERVIDOR:8080Geben Sie Ihre Zugangsdaten ein und klicken Sie auf „Verbinden“, um die grafische Anwendung remote zu nutzen.

Die langfristige Wartung ist einfachWenn Sie ein Update durchführen müssen, können Sie die Container stoppen und löschen, die Images mit den neuen Versionen neu erstellen und sie anschließend neu starten. docker run Das Datenvolumen wird beibehalten, sodass die Einstellungen und Dateien des Benutzers erhalten bleiben.

Mit all diesen Komponenten (Docker Compose, Plesk, Portainer, VS Code, WSL 2, Caddy, noVNC…). Es ist möglich, alles einzurichten, von einfachen Backend-Bereitstellungen bis hin zu Remote-Desktops, die in Containern gekapselt und perfekt über den Browser zugänglich sind. Dabei werden Server genutzt, die viel leistungsstärker sind als Ihr Rechner, und gleichzeitig behält man eine sehr gute Kontrolle über Netzwerke, Sicherheit, Speicherung und Updates.