[DE][Loslegen] Modifiziertes Docker-Image erstellen #26

GitBook-Seite

Pfad: loslegen/die-installation-von-smartstore/smartstore-docker-images-ausfuhren/modifiziertes-docker-image-erstellen
GitBook URL: https://app.gitbook.com/s/TTbkdOKWtE8u6wJ7suvC/loslegen/die-installation-von-smartstore/smartstore-docker-images-ausfuhren/modifiziertes-docker-image-erstellen
Sprache: DE
Bereich: Loslegen
GitBook Page ID: djeZXUmKmooadTpt6W9F
Git Sync Pfad: de/loslegen/die-installation-von-smartstore/smartstore-docker-images-ausfuhren/modifiziertes-docker-image-erstellen.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/5d0ZP6IyMYwcz724RssM/
• Optimierung: https://app.gitbook.com/o/jug3iI9jtm3q3KRxHi73/s/TTbkdOKWtE8u6wJ7suvC/~/changes/niHPFKFdrM9ResfwxPwD/
• DE Fachcheck: GitBook CR #508
• Screenshots:
• EN Sync:

Optimierungsvorschläge

1. Veraltetes eingebettetes Dockerfile durch die gepflegte Quelle ersetzen

Betroffene Inhalte: Das Beispiel verwendet ASPNET_TAG=7.0 und ein vollständig in die Dokumentation kopiertes Dockerfile.

Vorschlag: Nicht länger eine unabhängige Dockerfile-Kopie pflegen. Stattdessen auf das zur verwendeten Smartstore-Version gehörende NoBuild.Dockerfile und das Buildskript im Smartstore-Repository verweisen oder deren versionierte Dateien zusammen mit dem Release bereitstellen.

Argumente für den Reviewer:

• Das aktuelle Smartstore-Repository basiert auf ASP.NET Core 10; das gepflegte NoBuild.Dockerfile verwendet einen entsprechenden Runtime-Tag.
• Die aktuelle Datei enthält zusätzliche Buildargumente und ein gepflegtes Installationsskript für native Abhängigkeiten.
• Eine kopierte Dockerfile-Version in der User-Dokumentation veraltet unabhängig vom Produktcode.

Empfehlung: Umsetzen. Die konkrete Quelle muss an einen Release-Tag statt dauerhaft an main gebunden werden.

2. Ausgangsartefakt und Plugin-Kompatibilität eindeutig definieren

Vorschlag: Vor dem Ablauf festlegen:

• Es wird das Linux-x64-Artefakt eines bestimmten Smartstore-Releases verwendet.
• Plugin und Smartstore müssen für dieselbe kompatible Produktversion gebaut sein.
• Das Plugin liegt vollständig entpackt vor und seine Lizenz erlaubt die vorgesehene Bereitstellung.
• Alle gegebenenfalls benötigten Plugin-Abhängigkeiten sind enthalten.

Argumente für den Reviewer:

• „Versionen müssen übereinstimmen“ ist für Drittanbieter-Plugins zu ungenau.
• Das Docker-Image kann nur funktionieren, wenn das Plugin für die verwendete Smartstore- und Runtime-Version geeignet ist.
• Lizenz und Abhängigkeiten lassen sich nicht aus dem Dateinamen ableiten.

Empfehlung: Umsetzen und Kompatibilitätsformulierung fachlich bestätigen.

3. Ordneraufbau und Arbeitsschritte als reproduzierbaren Ablauf darstellen

Vorschlag: Die vielen fett markierten Sätze durch nummerierte Schritte ersetzen und vor dem Build einen kleinen Verzeichnisbaum zeigen, beispielsweise mit Smartstore-Artefakt, entpacktem Plugin, Dockerfile, Installationsskript und Buildskript.

Argumente für den Reviewer:

• Der aktuelle Ablauf wechselt zwischen Ordnererstellung, Entpacken und Dateierstellung, ohne den erwarteten Endzustand kompakt zu zeigen.
• Windows-Pfade mit führendem Backslash wirken wie absolute Pfade, obwohl Unterordner gemeint sind.
• Ein Verzeichnisbaum macht COPY-Quelle und Buildkontext überprüfbar.

Empfehlung: Umsetzen.

4. Buildbefehl, Buildargumente und Image-Tag erklären

Vorschlag: Einen einzigen nachvollziehbaren Buildbefehl dokumentieren und die verwendeten Argumente erläutern. Das erzeugte Image sollte einen versionsbezogenen Namen erhalten, nicht nur smartstore-linux-image ohne Version. Arbeitsverzeichnis und Buildkontext müssen ausdrücklich genannt werden.

Argumente für den Reviewer:

• Das aktuelle Hilfsskript setzt voraus, dass es aus einem bestimmten Ordner ausgeführt wird.
• Das gepflegte Dockerfile erwartet Edition, Version, Runtime und einen daraus gebildeten Artefaktpfad.
• Ein versionsbezogener Tag verhindert, dass mehrere Builds ununterscheidbar überschrieben werden.

Empfehlung: Umsetzen und den finalen Befehl mit einem Release-Artefakt testen.

5. Ergebnis prüfen und nächsten Schritt ergänzen

Vorschlag: Nach dem Build zeigen, wie das neue Image mit docker image ls beziehungsweise docker image inspect geprüft und anschließend als Testcontainer gestartet wird. Danach auf die passende Anleitung für Datenbankanbindung oder Compose verweisen.

Argumente für den Reviewer:

• Der letzte Satz bestätigt nur, dass das Skript ein Image erstellt, prüft aber weder Tag noch Startfähigkeit.
• Anwender benötigen ein objektives Erfolgskriterium.
• Der Build allein ergibt noch keine vollständige Smartstore-Installation.

Empfehlung: Umsetzen.

6. Wartungshinweis für spätere Updates ergänzen

Vorschlag: Darauf hinweisen, dass bei einem Smartstore- oder Plugin-Update ein neues Image aus den passenden Artefakten gebaut, getestet und mit einem neuen Tag veröffentlicht werden sollte. Persistente Shopdaten gehören nicht in das Image.

Argumente für den Reviewer:

• Ein modifiziertes Image ist ein reproduzierbares Buildartefakt und sollte nicht nachträglich im laufenden Container verändert werden.
• Produktdaten und Konfiguration müssen den Containerlebenszyklus überdauern.

Empfehlung: Umsetzen.

Prüfquellen

• Aktuelles Smartstore-Repository und Docker-Builddateien: https://github.com/smartstore/Smartstore
• Gepflegtes NoBuild.Dockerfile: https://github.com/smartstore/Smartstore/blob/main/NoBuild.Dockerfile
• Smartstore-Releases: https://github.com/smartstore/Smartstore/releases
• Docker-Buildreferenz: https://docs.docker.com/build/concepts/dockerfile/

Reviewer-Hinweise

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

• Voraussetzungen, Plugin-Kompatibilität und Lizenzprüfung konkretisiert,
• Arbeitsordner und Pluginablage als nachvollziehbare Schritte strukturiert,
• veraltetes ASP.NET-7-Dockerfile auf ASP.NET Core 10 aktualisiert,
• releasepassendes install-wkhtmltopdf.sh für die PDF-Abhängigkeit eingebunden,
• versionsbezogenes Image-Tagging, Buildprüfung und Updatehinweise ergänzt.

Technische Validierung:

• kontrollierten Markdown-Roundtrip mit stabilen Datei-IDs verwendet,
• alle fünf Bilder, beide vorhandenen Links, beide Codeblöcke und den GitBook-Hinweis unverändert als Blocktypen erhalten,
• genau eine GitBook-Seite geändert; Titel, Pfad und Metadaten unverändert,
• CR ist aktuell und konfliktfrei.

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

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

Der Fachcheck wird von zihniartar durchgeführt.

Offene Fragen

• Der endgültige Beispielbefehl hängt vom freigegebenen Release-Artefakt und dessen tatsächlicher Ordnerstruktur ab.
• Das derzeitige Dockerfile-Beispiel mit ASP.NET 7 darf nicht unverändert übernommen werden.