Seite 8 - Docker

Wer Docker Logs nur mit docker logs liest, verliert im Produktionsbetrieb jeden Überblick. Strukturiertes Logging über stdout und stderr, der richtige Log-Treiber und ein zentrales Log-Management-System machen Container-Logs beobachtbar, durchsuchbar und alarmierbar.

Nicht jede Pipeline muss durch einen Push oder Merge Request ausgeloest werden. Naechtliche Security-Scans, wiederkehrende Aufraeumjobs oder regelmaessige Abhaengigkeits-Updates laufen am besten zeitgesteuert, unabhaengig davon, ob an dem Tag ueberhaupt jemand Code committet hat. GitLabs Scheduled Pipelines bieten dafuer einen in die Plattform integrierten Cron-Mechanismus. Dieser Artikel zeigt die Einrichtung, die cron-Syntax, den Umgang mit Pipeline-Variablen und warum eine Scheduled Pipeline etwas grundlegend anderes ist als ein klassischer Cronjob auf einem Server.

Ein offener Port bedeutet nicht, dass eine Anwendung wirklich bereit ist. Docker Healthchecks geben Containern eine eigene Stimme – sie melden, wann ein Service tatsächlich Anfragen verarbeiten kann, wann er degradiert ist und wann ein Neustart nötig wird. Ohne diesen Mechanismus bleibt Container-Orchestrierung blind.

Ein offener Datenbank-Port bedeutet noch lange nicht, dass MySQL bereit ist, Verbindungen zu verarbeiten. depends_on mit condition service_healthy verknuepft die Startreihenfolge von Docker Compose Services direkt mit dem Healthcheck-Status, statt sich auf ein reines Erreichbarkeits-Signal zu verlassen, und beseitigt damit eine der haeufigsten Fehlerquellen in Multi-Service-Stacks.

Nicht jedes PHP-Projekt ist ein Monolith wie Magento. Fuer eigenstaendige Microservices mit Symfony oder Laravel reicht eine deutlich schlankere .gitlab-ci.yml, die trotzdem dieselben Grundprinzipien aus Build, Test und Deployment sauber abbildet.

GitLab Pages macht aus statischer Dokumentation, ob aus PHPDoc, MkDocs oder einem anderen Generator erzeugt, einen festen Bestandteil der CI-Pipeline und veroeffentlicht sie bei jedem Merge automatisch neu, ohne dass jemand manuell Dateien hochladen muss.

Seed-Daten unterscheiden sich fundamental von reinen Init-Skripten: Init-Skripte legen das Schema an, Seed-Daten füllen es mit realistischen, wiederholbaren Testdaten. Wer beide Konzepte vermischt, endet entweder mit leeren Entwicklungsdatenbanken oder mit inkonsistenten Testständen zwischen Teammitgliedern.

Sobald ein Projekt mehrere Umgebungen oder mehrere verwandte Services hat, wird eine einzelne, monolithische compose.yaml schnell unuebersichtlich. extends und das neuere include bieten zwei unterschiedliche Wege, gemeinsame Definitionen auszulagern, ohne staendig alles zu kopieren.

Nicht jedes Team nutzt die GitLab-eigene Kubernetes-Integration. Oft reicht ein einfacher kubectl-Aufruf direkt aus der Pipeline heraus, solange Kubeconfig und Zugriffsrechte sauber und sicher konfiguriert sind. Dieser Artikel zeigt den kompletten Weg von der Kubeconfig-Variable bis zum geprueften Rollout.

Migrationslogik im Entrypoint des App-Containers zu verstecken, funktioniert eine Weile gut und faellt dann bei Skalierung, parallelen Starts oder fehlgeschlagenen Migrationen unangenehm auf. Ein eigener, kurzlebiger Init-Container mit klarer Erfolgsbedingung loest dieses Problem strukturell.