Seite 6 - Docker

Ein guter Code-Review-Workflow in GitLab lebt nicht von guten Vorsaetzen, sondern von den richtigen Werkzeugen: anwendbare Suggestions, sauber aufgeloeste Diskussions-Threads und Strategien, um auch grosse Diffs in vertretbarer Zeit zu pruefen.

Ein durchdachtes System aus Issue-Templates und Labels verwandelt vage Bug-Meldungen in nachvollziehbare, priorisierbare Tickets und macht Quick Actions wie /label und /assign zum echten Automatisierungswerkzeug im Alltag.

Wer mehrere Magento Stores für verschiedene Kunden oder Marken betreibt, steht vor der Frage, ob jeder Shop einen eigenen Compose Stack braucht oder ob ein gemeinsamer Stack mit klar getrennten Netzwerken, Datenbank-Schemas und Caches genügt. Dieser Artikel zeigt, wie ein einziger Docker Compose Stack mehrere Magento Stores zuverlässig isoliert, ohne dass Ressourcen mehrfach vorgehalten werden müssen.

Docker Bench Security prüft Host, Daemon und laufende Container automatisiert gegen die CIS-Docker-Benchmark und liefert in wenigen Minuten einen strukturierten Prüfbericht. Wer die Ausgabe richtig liest, priorisiert und in die CI-Pipeline einbindet, verwandelt einen einmaligen Audit in einen kontinuierlichen Sicherheitsprozess statt in eine ignorierte PDF-Datei.

Wer in mehr als einem Repository eine .gitlab-ci.yml pflegt, kennt das Problem: Build-, Test- und Deploy-Jobs werden immer wieder kopiert und driften mit der Zeit auseinander. Das include-Keyword loest genau dieses Problem, indem es Pipeline-Definitionen aus anderen Dateien, anderen Projekten oder sogar externen URLs zur Laufzeit zusammenfuehrt. Dieser Artikel zeigt alle vier include-Varianten im Detail und wie daraus eine zentrale CI-Template-Bibliothek fuer die gesamte Organisation wird.

helm upgrade --install ist schnell getippt, aber ohne Lint, Diff und Rollout-Prüfung bleibt unklar, ob ein Deployment wirklich erfolgreich war. Bash-Automatisierung um Helm-Deployments herum prüft Charts vor dem Anwenden, wartet aktiv auf einen gesunden Rollout und rollt bei Fehlern automatisch zur letzten funktionierenden Revision zurück.

Ein Devcontainer verlagert die komplette Entwicklungsumgebung in einen Container, sodass jeder Entwickler exakt dieselbe PHP-Version, dieselben Extensions und dieselben Tools nutzt, unabhängig vom eigenen Rechner. Statt stundenlanger Onboarding-Dokumentation genügt ein Klick auf "Reopen in Container".

Schwankende Build-Last ist der Normalfall: nachts kaum Pipelines, am Nachmittag ein Ansturm von Merge-Request-Pipelines. Statischtes Runner-Provisioning verschwendet entweder Geld oder produziert Wartezeiten, Autoscaling loest beides.

Ein Dashboard zeigt 40 Prozent CPU-Auslastung, trotzdem häufen sich Timeouts und Latenzspitzen. Der Widerspruch löst sich fast immer über einen Blick in cpu.stat auf: Der Container wird gedrosselt, lange bevor die durchschnittliche Auslastung irgendein Limit erreicht.

Ohne systematischen Docker Cleanup füllen sich CI-Runner und Produktionsserver innerhalb von Wochen mit ungenutzten Images, verwaisten Volumes und veralteten Build-Caches. Das richtige Automatisierungskonzept verhindert Disk-Volllauf, ohne versehentlich wichtige Daten zu löschen.