Band 1 · Online-Leseprobe
Grundlagen, Planung und der sichere Einstieg
Ein VPN-Tunnel. Mehr sollte es eigentlich nicht werden. Doch dann führte eine Frage zur nächsten: Wer steuert das Netzwerk? Wo bleiben die Daten? Und warum läuft der Webserver, während die Webseite nicht erscheint? Begleite den Aufbau vom ersten Plan bis zu den Fehlern, an denen aus Ausprobieren Verstehen wird.
Heimserver-Projekt
Planung und der
sichere Einstieg
Aus dem Vorwort
Eigentlich sollte es nur ein VPN werden.
Da steht dieser kleine Kasten. Er bewahrt Deine Fotos auf, liefert Filme und sichert Dokumente. Eigentlich tut er, was er soll. Und trotzdem bleibt der Gedanke, dass darin mehr steckt. Ein eigener Dienst vielleicht. Eine eigene Webseite. Ein kontrollierter Weg ins Internet. So beginnt dieses Buch: mit vorhandener Technik und einer Aufgabe, die zunächst überschaubar klingt.
Als Christoph und ich uns kennenlernten, war die Aufgabe viel kleiner: Auf einem Synology-System sollte lediglich ein VPN-Tunnel eingerichtet werden. Das klang überschaubar. Doch jede beantwortete Frage machte den nächsten Zusammenhang sichtbar. Aus dem Tunnel wurde ein kontrollierter Netzwerkweg, daraus das Zusammenspiel zweier NAS-Systeme, Ausfallschutz und schließlich ein vollständiges Heimserver-Projekt. Geplant war ein VPN-Tunnel – entstanden ist diese Buchreihe.
Das ist der Ausgangspunkt, keine Voraussetzung für Deinen eigenen Aufbau. Du musst weder dieselben Geräte besitzen noch bereits Linux-Befehle beherrschen. Die Beispiele zeigen Dir, welche Fragen Du stellen musst, damit aus dem nächsten Versuch eine bewusste Entscheidung wird.
Du liest dabei auch von den Momenten zwischen Anleitung und Wirklichkeit: Eine Einstellung sieht richtig aus, eine Anzeige ist grün, und doch fehlt genau das Ergebnis, auf das Du gewartet hast. An diesen Stellen bleibt das Buch stehen und nimmt Dich mit auf die Suche. Denn manchmal steckt hinter zwei Tagen Fehlersuche eine Änderung, die am Ende nur einen Augenblick braucht.
Dieses Buch richtet sich nicht nur an Menschen, die Linux-Befehle im Schlaf beherrschen. Es ist für Dich geschrieben, wenn Du neugierig genug bist, den nächsten Schritt zu wagen – und vorsichtig genug, vorher verstehen zu wollen, was Du veränderst.
Der Weg durch Band 1
Band 1 wächst auf elf Kapitel.
Elf Kapitel befinden sich im Aufbau. Die ersten sechs führen Dich von der Projektidee über Docker und Compose bis zur eigenen Webseite. Hier kannst Du bereits in ausgewählte Passagen hineinlesen. Die Kapitel 7 bis 11 werden ergänzt; ihre Titel und Leseauszüge folgen.
- B1K1 · KAPITEL 1
Projektidee und Ausgangslage
Warum ein VPN-Tunnel plötzlich Fragen nach Zuständigkeiten, Datenwegen und Ausfallschutz aufwirft.
- B1K2 · KAPITEL 2
Bestandsaufnahme: Hardware, Netzwerk und Anforderungen
Was bereits läuft, was erhalten bleiben muss und warum die Planung vor der nächsten Installation beginnt.
- B1K3 · KAPITEL 3
Warum Docker?
Wie aus den Anforderungen eine Entscheidung für Container wird – und welche Daten beim Austausch bleiben müssen.
- B1K4 · KAPITEL 4
Die ersten Schritte mit Docker Compose
Wie eine lesbare Datei aus einzelnen Einstellungen einen nachvollziehbaren Dienst macht.
- B1K5 · KAPITEL 5
Der erste Webserver und die ersten Stolpersteine
Warum ein gestarteter Apache-Container noch nicht die erwartete Webseite liefert.
- B1K6 · KAPITEL 6
Reverse Proxy: Der Weg zur eigenen Webseite
Eine gemeinsame Eingangstür für Webdienste – und eine Fehlersuche, die den ganzen Weg einer Anfrage sichtbar macht.
- B1K7 · KAPITEL 7
Im Aufbau
Kapitel 7 wird ergänzt. Titel und Leseauszug folgen.
- B1K8 · KAPITEL 8
Im Aufbau
Kapitel 8 wird ergänzt. Titel und Leseauszug folgen.
- B1K9 · KAPITEL 9
Im Aufbau
Kapitel 9 wird ergänzt. Titel und Leseauszug folgen.
- B1K10 · KAPITEL 10
Im Aufbau
Kapitel 10 wird ergänzt. Titel und Leseauszug folgen.
- B1K11 · KAPITEL 11
Im Aufbau
Kapitel 11 wird ergänzt. Titel und Leseauszug folgen.
Einblick in Kapitel 1 und 2
Der erste wichtige Schritt ist keine Installation.
Solange alles funktioniert, fällt eine gewachsene Ordnung kaum auf. Erst beim nächsten Neustart oder einer unerreichbaren Webseite beginnt das Rätsel: Welches NAS war zuständig? Welcher Ordner gehörte dazu? Und welche Weiterleitung wurde damals eingerichtet? Die erste überraschende Entscheidung im Projekt lautet deshalb: Wir installieren vorerst nichts Neues.
Ein weiterer schneller Aufbau hätte vielleicht ein kurzfristig sichtbares Ergebnis gebracht, aber dieselbe Schwäche nur vergrößert: Beim nächsten Fehler wäre erneut unklar gewesen, welche Einstellung an welcher Stelle entscheidend war. Darum fiel die erste wichtige Entscheidung gegen einen neuen Dienst – und für eine Bestandsaufnahme.
Du lernst, das Heimnetz wie einen Stadtplan zu lesen: Ein Name ist die gut lesbare Anschrift, DNS das dazugehörige Adressbuch, die IP-Adresse die Zahlenanschrift. Der Port bezeichnet die nummerierte Software-Tür zum Dienst. So wird verständlich, warum eine richtige Adresse allein noch keine funktionierende Verbindung beweist.
Eine Bestandsaufnahme zeigt Beziehungen.
Bei einem neuen System lässt sich jede Entscheidung von Anfang an festlegen. In einer bestehenden Umgebung erzählen dagegen mehrere Stellen jeweils nur einen Teil der Wahrheit: Der Container Manager zeigt, dass eine Anwendung läuft, die FRITZ!Box kennt eine Weiterleitung, ein gemeinsamer Ordner enthält Konfigurationen, und ein Lesezeichen im Browser verweist auf eine Adresse. Keine dieser Informationen erklärt allein den vollständigen Weg.
Das führte zu einer wichtigen Erkenntnis: „Läuft“ und „funktioniert wie beabsichtigt“ sind zwei verschiedene Aussagen. Ein Container kann fehlerfrei gestartet und trotzdem nicht erreichbar sein, ein Dienst kann intern antworten, während die externe Anfrage auf dem falschen NAS endet, und eine IP-Adresse kann stimmen, aber zu einer alten Freigabe gehören.
Die Bestandsaufnahme musste daher Beziehungen sichtbar machen – nicht nur, welcher Dienst vorhanden war, sondern auch, auf welchem Gerät er lief, welche Adresse und welcher Port zu ihm führten, wo seine dauerhaften Daten lagen und welche andere Komponente ihm vorausging.
Aus einer bloßen Geräteliste wird damit ein Werkzeug für Deine nächste Entscheidung. Wenn Du später einen Dienst verschiebst, kannst Du vorher prüfen, welche Verbindung und welcher Speicherort davon betroffen sind. Das spart Dir keine Planung – aber es erspart Dir manches Rätsel nach der Änderung.
Auch ein zweites Gerät löst nicht jede Frage. Eine Sicherung bewahrt Daten für die Wiederherstellung. Ein laufender Ersatzdienst muss dagegen eine Aufgabe tatsächlich übernehmen können. Band 1 erklärt diesen Unterschied, bevor spätere Bände daraus konkrete Ausfallkonzepte entwickeln.
Eine Datensicherung schützt Daten und Konfigurationen. Sie übernimmt aber nicht automatisch die laufende Aufgabe eines ausgefallenen Dienstes. Soll eine Funktion weiterarbeiten, braucht sie eine vorbereitete zweite Instanz, eine erkennbare Umschaltung und einen nachweislich erfolgreichen Test.
Welche Aufgabe hat das Gerät? Welche Daten müssen bleiben? Welcher Test zeigt, dass es funktioniert? Mit diesen Fragen beginnt Dein eigener Plan.
Diese Bestandsaufnahme wird später noch einmal wichtig. Wenn die Webseite von außen schweigt, helfen genau die hier festgehaltenen Wege, den Suchbereich kleiner zu machen. Was zunächst wie Vorarbeit aussieht, wird zum entscheidenden Werkzeug.
Einblick in Kapitel 3 und 4
Ein Container ist austauschbar. Deine Daten sind es nicht.
Docker ist ein Werkzeug, um Anwendungen in getrennten Umgebungen zu betreiben. Für den Einstieg zählt aber vor allem, welche Teile Du ersetzen kannst und welche erhalten bleiben müssen. Das Buch trennt dafür Image, Container und dauerhafte Daten.
Merksatz: Das Image ist die Bauanleitung, der Container das daraus gebaute Arbeitsgerät und das Volume der Schrank, in dem die Ergebnisse bleiben. Tauscht Du das Arbeitsgerät aus, darf der Schrank nicht versehentlich mit entsorgt werden.
Der nächste Schritt heißt Docker Compose: Eine Datei beschreibt, aus welchem Image ein Dienst entsteht, welche Verzeichnisse er verwendet und wie er erreichbar ist. Sie macht den Aufbau lesbar und hilft Dir, ihn später nachzuvollziehen.
Warum der zweite Aufbau schon beim ersten mitgedacht wird
Die Behauptung, ein Container lasse sich jederzeit neu erstellen, stimmt nur unter einer Bedingung: Seine Daten, Einstellungen, Ports und Umgebungswerte müssen bekannt sein. Wer diese Angaben lediglich in einer grafischen Oberfläche zusammenklickt, ohne sie zu dokumentieren, besitzt zwar einen Container, aber noch keinen reproduzierbaren Dienst.
Damit wurde Docker zugleich zum Prüfstein unserer eigenen Arbeitsweise: Jede Anwendung musste so beschrieben werden, dass ein zweiter Aufbau nicht vom Gedächtnis abhing. Erst an dieser Stelle wurde Docker Compose wichtig.
Damit wurde die Datei zu einem Vertrag zwischen Planung und Betrieb. Was dort steht, soll dem tatsächlichen Dienst entsprechen. Was dort nicht dokumentiert ist, darf nicht stillschweigend nur in einer Oberfläche existieren.
Im vollständigen Kapitel siehst Du, wie diese Entscheidungen zusammengehören: Projektordner, Konfiguration, Nutzdaten, Ports und Neustartverhalten. Du startest nicht bloß einen Dienst. Du kannst erklären, woraus er besteht.
Ein eigenes Projekt schafft erkennbare Grenzen.
Wenn mehrere Container ihre Dateien in einem gemeinsamen, beliebig gewachsenen Ordner ablegen, verschwimmen ihre Grenzen. Ein Backup enthält dann möglicherweise Unnötiges, während eine wichtige Konfiguration übersehen wird. Auch ein Update wird riskanter, weil unklar bleibt, welche Dateien zu welchem Dienst gehören.
Darum behandelten wir jede Anwendung als eigenes Projekt. Zu ihr gehören die Compose-Datei, benannte Konfigurationspfade, dauerhafte Daten und – falls erforderlich – Protokolle. Diese Struktur macht nicht alles automatisch richtig. Sie macht aber sichtbar, was geprüft werden muss.
Das ist besonders dann hilfreich, wenn der erste Erfolg einige Wochen zurückliegt. Du musst nicht mehr rekonstruieren, welcher Ordner zufällig ausgewählt wurde. Die Struktur gibt Dir einen Ausgangspunkt für Sicherung, Änderung und Fehlersuche.
Einblick in Kapitel 5 und 6
Der Container läuft. Warum erscheint trotzdem nicht das Richtige?
Eine kleine Webseite ist die erste sichtbare Bewährungsprobe. Der Apache-Container startet, der Browser erreicht den Webserver – und trotzdem stimmt das Ergebnis nicht. Genau dieser Unterschied macht das Beispiel so lehrreich.
Unser einfacher Test in der Datei index.php lautete:
<?php echo "PHP läuft."; ?>Erwartet: Im Browser steht nur PHP läuft.
Tatsächlich: Der Browser zeigte den PHP-Befehl
<?php echo "PHP läuft."; ?>als lesbaren Text an. Apache lieferte die Datei also aus, führte den darin enthaltenen PHP-Code aber nicht aus.
Was beweist dieser Test bereits? Und was fehlt noch? Das Kapitel nimmt Dich durch die Eingrenzung mit: vom ausgewählten Software-Image über das Webverzeichnis bis zum erneuten Aufruf. Die grüne Statusanzeige bekommt dadurch eine klare, begrenzte Bedeutung.
Die Seite soll auch den nächsten Container überleben.
Hätten wir die Webdateien nur in den laufenden Container kopiert, wäre der erste Test möglicherweise erfolgreich gewesen. Beim Neuerstellen des Containers hätten diese Dateien jedoch verschwinden können. Ein schneller Erfolg hätte damit eine spätere Schwäche verborgen.
Deshalb gehören die Webdateien in einen bewusst eingebundenen Ordner auf dem NAS. Der Container verwendet diesen Ordner, während Du die Inhalte unabhängig von seiner Lebensdauer bearbeiten und sichern kannst. Im Buch wird dieser Zusammenhang am konkreten Webserver erklärt: Welche Seite erscheint im Browser, aus welchem Verzeichnis stammt sie und was geschieht beim Austausch der Anwendung?
Auch der direkte Aufruf über einen Test-Port erhält eine klare Aufgabe. Er hilft Dir, den Webserver zunächst für sich zu prüfen. Wenn später ein Domainname oder eine vorgeschaltete Vermittlungsstelle hinzukommt, musst Du nicht wieder bei jeder Komponente von vorn anfangen.
Dann wird der Weg nach außen zur nächsten Frage.
Ein Reverse Proxy ist die vorgeschaltete Vermittlungsstelle für Webanfragen. Er nimmt die Anfrage entgegen und leitet sie an den passenden internen Dienst weiter. Kapitel 6 zeigt, warum diese gemeinsame Eingangstür die Architektur ordnet – und warum auch korrekt arbeitende Container von außen unerreichbar erscheinen können.
Die beteiligten Komponenten ließen sich einzeln erfolgreich prüfen. Apache lieferte Inhalte. PHP arbeitete. Das interne Docker-Netzwerk löste Dienstnamen auf. Nginx Proxy Manager konnte das Backend erreichen. Trotzdem erschien die Webseite von außen nicht.
Zwei Tage lang passen diese Beobachtungen scheinbar nicht zusammen. Innen funktioniert die Webseite, außen bleibt sie verschwunden. Noch einmal am Container drehen? Die Zertifikate erneuern? Oder wurde längst etwas erfolgreich geprüft, das die eigentliche Ursache gar nicht berührt? Das vollständige Kapitel verfolgt die Spur bis zu jener Einstellung, die alles erklärt. Die Reparatur ist klein. Der Weg zu ihr verändert die weitere Fehlersuche im Projekt.
Genau hier wäre es leicht gewesen, erneut Container zu löschen, Compose-Dateien zu verändern oder Zertifikate neu anzulegen. Stattdessen wurde die Anfrage als zusammenhängender Weg betrachtet: Internet, FRITZ!Box, internes Zielgerät, veröffentlichter Proxy-Port, Docker-Netzwerk und schließlich Apache.
Was Du mitnimmst
Dein Heimserver soll für Dich erklärbar werden.
Nach diesem Einstieg kennst Du die Fragen hinter dem Aufbau: Welche Rolle übernimmt ein Gerät? Wie bleiben Daten beim Containerwechsel erhalten? Was beschreibt eine Compose-Datei? Und wie unterscheidest Du einen laufenden Prozess von einer nachgewiesenen Funktion?
Die Zusammenarbeit mit Christoph, der KI am gemeinsamen Prüfstand, gehört zur Geschichte. Vorschläge müssen sich dabei an den Geräten bewähren. Und wenn Tron am liebsten schon den nächsten Schalter drücken würde, gilt erst einmal: lesen, verstehen, sichern – dann ändern und testen.
Vielleicht erkennst Du Dein eigenes Heimnetz schon in einer dieser Situationen wieder. Vielleicht möchtest Du erst anfangen und Dir genau diese Umwege ersparen. Band 1 verbindet die kleinen Entscheidungen zu einem Weg: vom ersten Blick auf die vorhandenen Geräte bis zu dem Moment, in dem die Webseite über den vorgesehenen Zugang antwortet – und Du erklären kannst, warum.
Weiter geht es mit Band 2.
Auf das Fundament folgt der weitere Ausbau der Infrastruktur. Im Ausblick von Band 1 kommen Überwachung und Datenbankdienste ins Spiel: MariaDB und PostgreSQL sowie Adminer und pgAdmin als Werkzeuge für ihre Verwaltung.
Die Leseprobe zu Band 2 erscheint demnächst hier auf der Webseite.