[DE][Loslegen] Smartstore Docker-Images unter Linux ausführen #24

GitBook-Seite

Pfad: loslegen/die-installation-von-smartstore/smartstore-docker-images-ausfuhren/smartstore-docker-images-unter-linux-ausfuhren
GitBook URL: https://app.gitbook.com/s/TTbkdOKWtE8u6wJ7suvC/loslegen/die-installation-von-smartstore/smartstore-docker-images-ausfuhren/smartstore-docker-images-unter-linux-ausfuhren
Sprache: DE
Bereich: Loslegen
GitBook Page ID: J7NYzqfKMgu8ElA2XDRX
Git Sync Pfad: de/loslegen/die-installation-von-smartstore/smartstore-docker-images-ausfuhren/smartstore-docker-images-unter-linux-ausfuhren.md

Durchläufe

• DE Sprache
• DE Sprachreview
• DE Optimierungsvorschläge
• DE Optimierungsreview
• DE Fachcheck
• DE Fachreview
• Screenshots prüfen
• Screenshots ggf. ersetzen
• EN Sync
• EN Review

Change Requests

• DE Sprache: https://app.gitbook.com/o/jug3iI9jtm3q3KRxHi73/s/TTbkdOKWtE8u6wJ7suvC/~/changes/Wevsop2559bHliSlz0dz/
• Optimierung: https://app.gitbook.com/o/jug3iI9jtm3q3KRxHi73/s/TTbkdOKWtE8u6wJ7suvC/~/changes/U0bYMM7Ge4hXJ06GPv1w/
• DE Fachcheck: GitBook CR #505
• Screenshots:
• EN Sync:

Optimierungsvorschläge

1. Verwendungszweck der Anleitung klar eingrenzen

Betroffene Aussage: Der einzelne docker run-Befehl wirkt wie eine vollständige Betriebsanleitung.

Vorschlag: Zu Beginn erklären, dass die Seite einen schnellen Funktionstest eines einzelnen Smartstore-Containers beschreibt. Für eine vollständige Installation wird zusätzlich eine erreichbare Datenbank benötigt; für einen dauerhaften Betrieb müssen außerdem persistente Daten, eine kontrollierte Versionswahl und sichere Zugangsdaten berücksichtigt werden.

Argumente für den Reviewer:

• Der gezeigte Container besitzt weder eine Datenbank noch ein eingebundenes Volume für App_Data/Tenants.
• Die Datenbankabhängigkeit wird erst am Ende genannt.
• Docker-Volumes bestehen unabhängig vom Lebenszyklus eines Containers und sind der vorgesehene Mechanismus für persistente Containerdaten.

Empfehlung: Umsetzen und früh auf die vorhandene Compose-Anleitung verweisen.

2. latest nicht als „aktuelles“ Smartstore-Release darstellen

Betroffene Aussage: Mit :latest werde das aktuelle Smartstore-Docker-Image geladen.

Vorschlag: Einen Platzhalter für einen fachlich freigegebenen Release-Tag verwenden und denselben Tag beim Abrufen und Starten angeben. nightly ausdrücklich nur als Entwicklungsstand einordnen.

Argumente für den Reviewer:

• In der GitHub Container Registry ist nightly der zuletzt veröffentlichte Stand, während latest derzeit einem älteren getaggten Image zugeordnet ist.
• Ohne expliziten Tag verwendet Docker ebenfalls latest.
• Ein fester Release-Tag macht Installation und Wiederherstellung reproduzierbar.

Empfehlung: Umsetzen, sobald der aktuell unterstützte produktive Image-Tag fachlich bestätigt ist.

3. Voraussetzungen vor den Befehlen ergänzen

Vorschlag: Eine kurze Prüfliste voranstellen:

• Docker Engine ist installiert und gestartet.
• Der Benutzer darf Docker-Befehle ausführen; andernfalls werden die Befehle mit sudo ausgeführt.
• Port 80 ist auf dem Host frei oder wird durch einen anderen freien Host-Port ersetzt.
• Für den Installationsabschluss ist eine unterstützte Datenbank erreichbar.

Argumente für den Reviewer:

• Die Seite prüft derzeit nur die Docker-Installation.
• Ein bereits belegter Host-Port führt unmittelbar zum Abbruch des Startbefehls.
• Die Voraussetzungen erklären typische Fehler, bevor sie auftreten.

Empfehlung: Umsetzen.

4. Ablauf und erwartete Ergebnisse textlich nachvollziehbar machen

Vorschlag: Die Befehle als klar nummerierten Ablauf darstellen und nach jedem Schritt das erwartete Ergebnis nennen: Docker testen, Image abrufen, Container starten, Status mit docker ps prüfen und Smartstore über http://localhost aufrufen.

Für Zugriffe von einem anderen Rechner sollte http://<IP-Adresse-des-Docker-Hosts> genannt und auf eine gegebenenfalls erforderliche Firewallfreigabe hingewiesen werden.

Argumente für den Reviewer:

• „localhost oder lokale IP-Adresse“ unterscheidet nicht zwischen Zugriff auf dem Docker-Host und Zugriff aus dem Netzwerk.
• Textliche Prüfkriterien sind robuster als Terminal-Screenshots und helfen bei abweichender Ausgabe.

Empfehlung: Umsetzen.

5. Diagnose- und Aufräumbefehle ergänzen

Vorschlag: Am Ende die Befehle zum Anzeigen des Containerstatus und der Protokolle sowie zum Stoppen und Entfernen des Testcontainers ergänzen. Dem Container sollte dafür ein eindeutiger Name gegeben werden.

Argumente für den Reviewer:

• Der aktuelle Ablauf erklärt nicht, wie Anwender einen fehlgeschlagenen Start untersuchen.
• Ohne Containername müssen Anwender eine automatisch erzeugte ID oder einen zufälligen Namen ermitteln.
• Ein ausdrücklich als Test gekennzeichneter Container sollte kontrolliert beendet und entfernt werden können.

Empfehlung: Umsetzen.

6. Screenshots auf bleibenden Informationswert prüfen

Vorschlag: Nur den Screenshot der Smartstore-Installationsseite beibehalten, sofern er im Screenshot-Pass noch der aktuellen Oberfläche entspricht. Terminal-Screenshots durch kurze erwartete Textausgaben ersetzen oder auf wirklich notwendige Stellen reduzieren.

Argumente für den Reviewer:

• Konsolenoberflächen und Ausgaben ändern sich häufiger als die zugrunde liegenden Befehle.
• Die vier Bilder vermitteln überwiegend Informationen, die sich zugänglicher und wartungsärmer als Text darstellen lassen.

Empfehlung: Im späteren Screenshot-Pass entscheiden.

Prüfquellen

• Smartstore-Linux-Paket und veröffentlichte Tags: https://github.com/smartstore/Smartstore/pkgs/container/smartstore-linux
• Smartstore-Repository und aktuelle Dockerdateien: https://github.com/smartstore/Smartstore
• Docker-Volumes und Persistenz: https://docs.docker.com/engine/storage/volumes/

Reviewer-Hinweise

Die Optimierungsvorschläge wurden in GitBook Change Request #59 umgesetzt:

• Voraussetzungen und Zweck als schneller Einzelcontainer-Test präzisiert,
• direkten Paketlink und konsistente Verwendung des Tags latest ergänzt, ohne ihn als aktuellen Release-Stand auszugeben,
• Testcontainer benannt sowie Portabbildung und Netzwerkzugriff verständlicher erklärt,
• Datenbankbedarf, fehlende Persistenz und Anforderungen für den dauerhaften Betrieb deutlich gemacht.

Technische Validierung:

• vollständige JSON-Dokumentstruktur verwendet,
• 13 Hauptknoten, alle vier Bilder, der interne Seitenverweis und der bestehende Docker-Link erhalten,
• alten allgemeinen Paketlink gezielt durch den direkten Link auf smartstore-linux ersetzt,
• Überschriftenanker, Titel, Pfad und Metadaten unverändert,
• genau eine GitBook-Seite geändert; CR ist aktuell und konfliktfrei.

Der Change Request wurde nicht gemergt und wartet auf den DE Optimierungsreview.

GitBook Change Request #59 wurde geprüft und gemergt.

Der Fachcheck wird von zihniartar durchgeführt.

Offene Fragen

• Der derzeit freigegebene produktive Tag des Smartstore-Linux-Images muss bestätigt werden.
• Die verbindliche Volume-Konfiguration für einen dauerhaften Einzelcontainer-Betrieb benötigt einen Fachcheck.