[DE][Loslegen] Smartstore Docker-Images ausführen

[muratcakir]

GitBook-Seite

Pfad: loslegen/die-installation-von-smartstore/smartstore-docker-images-ausfuhren
GitBook URL: https://app.gitbook.com/s/TTbkdOKWtE8u6wJ7suvC/loslegen/die-installation-von-smartstore/smartstore-docker-images-ausfuhren
Sprache: DE
Bereich: Loslegen
GitBook Page ID: w5BeoF8cmwH33fOScA3e
Git Sync Pfad: de/loslegen/die-installation-von-smartstore/smartstore-docker-images-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/kWvqrUTmyZOqqIG0kKEr/
• Optimierung: https://app.gitbook.com/o/jug3iI9jtm3q3KRxHi73/s/TTbkdOKWtE8u6wJ7suvC/~/changes/TmYxGTzWc7w51XFLDOgC/
• Fachcheck:
• Screenshots:
• EN Sync:

Optimierungsvorschläge

1. Image und Container fachlich sauber unterscheiden

Betroffene Aussage: Anwendungen würden in Images „gepackt“, Images könnten weitergegeben und kopiert werden und seien wesentlich schlanker als virtuelle Maschinen.

Vorschlag: Die Einleitung kurz und handlungsorientiert neu formulieren:

• Ein Container-Image enthält die Dateien, Bibliotheken und Konfiguration, die zum Starten einer Anwendung benötigt werden.
• Aus einem Image wird ein laufender Container erstellt.
• Container teilen sich Ressourcen des Hostsystems und verursachen deshalb in vielen Szenarien weniger Overhead als vollständige virtuelle Maschinen.

Die pauschale Aussage, Docker-Images seien „viel schlanker“, sollte entfallen oder auf den geringeren Laufzeit-Overhead von Containern gegenüber vollständigen virtuellen Maschinen präzisiert werden.

Argumente für den Reviewer:

• Die aktuelle Fassung vermischt Image, Container und Virtualisierung.
• Ein Image ist das unveränderliche Anwendungspaket; der Container ist dessen laufende Instanz.
• Die Größe eines Images lässt sich nicht pauschal mit einer virtuellen Maschine vergleichen. Der relevante Vorteil entsteht vor allem dadurch, dass Container keinen vollständigen Gast-Kernel benötigen.

Empfehlung: Umsetzen.

2. Die Seite als Auswahlhilfe für den passenden Docker-Weg strukturieren

Vorschlag: Nach der kurzen Einleitung eine kompakte Auswahl ergänzen:

• Smartstore unter Windows starten: Docker Desktop verwenden und der Windows-Anleitung folgen.
• Smartstore unter Linux starten: Docker Engine verwenden und der Linux-Anleitung folgen.
• Smartstore zusammen mit einer Datenbank starten: die vorhandene Docker-Compose-Anleitung verwenden.
• Plugins oder andere Anpassungen integrieren: ein modifiziertes Docker-Image erstellen.

Argumente für den Reviewer:

• Die Übersichtsseite besitzt vier fachlich passende Unterseiten, listet derzeit aber nur die Windows- und Linux-Anleitung auf.
• Anwender erfahren erst in der Linux-Unterseite, dass für die Installation zusätzlich eine erreichbare Datenbank benötigt wird.
• Die Auswahl nach Ziel führt schneller zum richtigen Ablauf als die derzeitige Mischung aus Einführung, Paketlink und zwei Betriebssystemlinks.

Empfehlung: Umsetzen und alle vier vorhandenen Unterseiten intern verlinken.

3. Alten Atlassian-Link durch die vorhandene GitBook-Unterseite ersetzen

Betroffene Verlinkung: „modifizierte Docker-Images erstellen“ verweist auf eine alte Seite unter smartstore.atlassian.net.

Vorschlag: Den externen Link durch den internen GitBook-Verweis auf „Modifiziertes Docker-Image erstellen“ ersetzen.

Argumente für den Reviewer:

• Die passende Seite ist bereits als direkte Unterseite dieser Übersicht in GitBook vorhanden.
• Der interne Link hält Anwender in der aktuellen Dokumentation.
• Dadurch gibt es für denselben Inhalt nur noch ein sichtbares Dokumentationsziel und keinen vermeidbaren Verweis auf das Altsystem.

Empfehlung: Umsetzen.

4. Paketverlinkung präzisieren und die unterstützten Images benennen

Betroffene Verlinkung: Der sichtbare Rohlink https://github.com/orgs/smartstore/packages führt nur zur allgemeinen Paketübersicht der Organisation.

Vorschlag: Einen beschreibenden Link direkt auf das verwendete Paket smartstore-linux setzen und den vollständigen Image-Namen ghcr.io/smartstore/smartstore-linux nennen. Zusätzlich fachlich klären, ob das ebenfalls veröffentlichte Paket smartstore-windows weiterhin unterstützt und in dieser Übersicht erklärt werden soll.

Argumente für den Reviewer:

• Die Smartstore-Compose-Dateien und Linux-Buildskripte verwenden ghcr.io/smartstore/smartstore-linux.
• Das Windows-Buildskript erzeugt ghcr.io/smartstore/smartstore-windows, während die vorhandene Windows-Anleitung unter Docker Desktop das Linux-Image verwendet.
• Ein direkter Paketlink vermeidet, dass Anwender in der Organisationsübersicht das passende Image selbst auswählen müssen.
• Die unterschiedlichen Windows-Szenarien sollten nicht ohne fachliche Bestätigung zusammengeführt werden.

Empfehlung: Linux-Paket direkt verlinken; Aussage zum nativen Windows-Image erst nach Fachcheck ergänzen.

5. Versions- und Tag-Auswahl ausdrücklich erklären

Vorschlag: Kurz erläutern, dass Anwender für eine gezielte Smartstore-Version einen veröffentlichten Versions-Tag verwenden sollen. latest kann für einen bewusst aktuellen Teststand genannt werden; für reproduzierbare Installationen sollte ein konkreter Release-Tag empfohlen werden. Ein Digest ist nur für Szenarien erforderlich, in denen exakt dasselbe Image reproduziert werden muss.

Argumente für den Reviewer:

• GitHub Container Registry unterstützt das Abrufen nach Name, Versions-Tag und Digest.
• Ohne expliziten Tag verwendet Docker standardmäßig latest; dessen Inhalt kann sich bei einer späteren Bereitstellung ändern.
• Die Unterseiten verwenden derzeit teils :latest, teils gar keinen Tag.
• Eine zentrale Tag-Regel verhindert widersprüchliche Befehle in den nachgelagerten Anleitungen.

Empfehlung: Grundregel auf der Übersicht festlegen und anschließend in den Unterseiten vereinheitlichen.

6. Voraussetzungen und Einsatzgrenze der Übersicht nennen

Vorschlag: Vor den weiterführenden Links einen kurzen Hinweis ergänzen:

• Docker Desktop oder Docker Engine muss installiert und gestartet sein.
• Ein allein gestarteter Smartstore-Container benötigt für die Installation eine erreichbare, unterstützte Datenbank.
• Für Smartstore und Datenbank in einem gemeinsamen Ablauf ist die Docker-Compose-Unterseite vorgesehen.
• Für produktive Systeme müssen persistente Daten, sichere Zugangsdaten und eine kontrollierte Versionsstrategie berücksichtigt werden.

Argumente für den Reviewer:

• Die aktuelle Übersicht erweckt den Eindruck, das Abrufen und Starten eines Images reiche für den vollständigen Betrieb aus.
• Die bestehende Linux-Unterseite weist erst am Ende auf die benötigte Datenbank hin.
• Die Repository-Beispiele verwenden Volumes und separate Datenbankdienste; damit sind Persistenz und Datenbankanbindung wesentliche Bestandteile des vorgesehenen Betriebs.

Empfehlung: Als kurzen Hinweisblock umsetzen; Detailanleitungen bleiben in den Unterseiten.

Prüfquellen

• Smartstore-Paketübersicht mit smartstore-linux und smartstore-windows: https://github.com/orgs/smartstore/packages
• Smartstore-Linux-Paket: https://github.com/smartstore/Smartstore/pkgs/container/smartstore-linux
• Smartstore-Repository mit Dockerfiles, Buildskripten und Compose-Beispielen: https://github.com/smartstore/Smartstore
• Docker: Unterschied zwischen Image und Container: https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-an-image/
• Docker: Container und Abgrenzung zu virtuellen Maschinen: https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-a-container/
• GitHub: Images nach Name, Versions-Tag oder Digest aus der Container Registry abrufen: https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry

Reviewer-Hinweise

Die freigegebenen Vorschläge wurden in GitBook Change Request #52 umgesetzt:

• Einleitung mit klarer Unterscheidung zwischen Container-Image, laufendem Container und virtueller Maschine neu gefasst,
• allgemeine Paketübersicht durch den direkten Link auf das Smartstore-Linux-Paket ersetzt,
• vollständigen Image-Namen und Empfehlung für konkrete Release-Tags ergänzt,
• Voraussetzungen, Datenbankbedarf und Hinweise für produktive Systeme ergänzt,
• die Übersicht als Auswahlhilfe mit allen vier vorhandenen Unterseiten aufgebaut,
• alten Atlassian-Link durch den internen GitBook-Verweis auf „Modifiziertes Docker-Image erstellen“ ersetzt.

Nicht vorweggenommen wurde die offene Fachentscheidung, ob das native Paket smartstore-windows weiterhin unterstützt und empfohlen wird.

Technische Validierung:

• genau eine GitBook-Seite geändert,
• vollständige JSON-Dokumentstruktur verwendet,
• Titel, Pfad, Metadaten und Navigation unverändert,
• ein externer Paketlink und vier interne Seitenverweise als strukturierte Referenzen gespeichert,
• alle vier erwarteten Page IDs validiert,
• Change Request ist aktuell und konfliktfrei.

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

Offene Fragen

• Die Unterstützung und Positionierung des nativen Windows-Images muss im späteren Fachcheck bestätigt werden.
• Die konkreten Befehle, Compose-Beispiele, Zugangsdaten, Screenshots und Runtime-Versionen der vier Unterseiten benötigen separate technische Reviews.