„Der Server läuft noch auf CentOS – was machen wir jetzt?“ Diese Frage erreicht uns seit Monaten regelmäßig. CentOS Stream 8 hat bereits im Mai 2024 sein End of Life erreicht, CentOS 7 im Juni 2024. Und wer noch auf diesen Systemen produziert, steht vor einer wichtigen Entscheidung.
Bei Never Code Alone haben wir uns seit über 15 Jahren auf Softwarequalität, Open Source und Remote Consulting spezialisiert. Wir sehen täglich, wie Teams vor der Frage stehen: Neue Linux-Distribution, teure RHEL-Lizenzen, oder den Sprung in die Container-Welt wagen? Docker ist nicht nur eine Alternative – es ist oft die strategisch bessere Wahl.
Die aktuelle Lage: CentOS ist Geschichte
Die Fakten sind klar: CentOS Stream 8 erhält seit Mai 2024 keine Updates mehr. CentOS Linux 7 ist seit Juni 2024 ohne Support. Die Repositories wurden auf vault.centos.org archiviert, aber neue Security-Patches gibt es keine. Wer heute noch Docker-Builds auf CentOS 7 oder 8 Basis laufen hat, kennt die „Could not retrieve mirrorlist“-Fehler bereits.
Red Hat bietet mit dem Convert2RHEL-Tool eine Migration zu RHEL an – aber das bedeutet Lizenzkosten. AlmaLinux und Rocky Linux sind solide Alternativen für alle, die beim klassischen Server-Modell bleiben wollen. Doch es gibt einen dritten Weg, der für viele Teams die bessere Lösung ist: Container-First.
Was passiert mit meinem CentOS Server ohne Updates?
Ohne Security-Updates ist euer Server ein offenes Scheunentor. Jeden Tag werden neue Schwachstellen entdeckt – CVEs, die nicht mehr gepatcht werden. Für Produktivumgebungen ist das untragbar, besonders wenn ihr personenbezogene Daten verarbeitet oder Compliance-Anforderungen erfüllen müsst.
Die Pakete bleiben zwar auf vault.centos.org verfügbar, aber das hilft euch nur beim Notfall-Restore alter Systeme. Neue Software-Versionen, Kernel-Updates, Bibliotheks-Patches – all das ist vorbei. In unserer Consulting-Praxis empfehlen wir: Maximal sechs Monate nach EOL sollte jedes System migriert sein. Danach steigt das Risiko exponentiell.
Warum Docker statt einer neuen Linux-Distribution?
Die klassische Antwort auf CentOS-EOL wäre: Installiert AlmaLinux, Rocky Linux oder zahlt für RHEL. Das funktioniert, aber ihr tauscht ein Problem gegen das nächste. In fünf bis zehn Jahren steht ihr wieder vor derselben Situation.
Docker löst dieses Problem fundamental anders. Eure Anwendung läuft in einem Container, der vom Host-Betriebssystem entkoppelt ist. Der Host kann Ubuntu, Debian oder jede andere Distribution sein – eure Anwendung merkt davon nichts. Wenn das Base Image veraltet, wechselt ihr es in der Dockerfile mit einer Zeile. Kein Server-Rebuild, keine Downtime für OS-Upgrades.
Für Developer-Teams bedeutet das: Konsistente Entwicklungsumgebungen auf jedem Laptop. Für Ops bedeutet das: Reproduzierbare Deployments und einfachere Skalierung. Für Entscheider bedeutet das: Geringere Vendor Lock-in und langfristig niedrigere Migrationskosten.
Welche Vorteile bietet Docker gegenüber klassischen Servern?
Docker-Container sind leichtgewichtig – sie teilen sich den Kernel des Host-Systems und brauchen kein vollständiges Betriebssystem. Ein Container startet in Sekunden, nicht Minuten. Wo eine VM mehrere Gigabyte belegt, kommt ein Container oft mit wenigen hundert Megabyte aus.
Die Isolation zwischen Containern schützt eure Anwendungen voreinander. Wenn ein Container abstürzt, laufen die anderen weiter. Das ist kein vollständiger Ersatz für VM-Isolation bei Security-kritischen Workloads, aber für die meisten Anwendungsfälle mehr als ausreichend.
Der größte Vorteil in der Praxis: Portabilität. Ihr baut euren Container einmal und deployt ihn überall – auf eurem Entwickler-Laptop, im Staging-Cluster, in der Produktion bei AWS, Azure oder on-premise. Die Zeiten von „auf meinem Rechner funktioniert es“ sind vorbei.
Wie migriere ich meinen CentOS Server auf Docker?
Die Migration hängt davon ab, was auf eurem Server läuft. Für Standard-Webanwendungen – PHP, Node.js, Python – ist der Weg relativ geradlinig:
# Statt CentOS: Nutzt offizielle Runtime-Images
FROM php:8.3-fpm-alpine
# Eure Anwendung
COPY . /var/www/html
# Dependencies installieren
RUN composer install --no-dev --optimize-autoloaderFür komplexere Setups mit mehreren Services empfehlen wir Docker Compose:
version: '3.8'
services:
app:
build: .
ports:
- "80:80"
database:
image: mariadb:11
volumes:
- db_data:/var/lib/mysql
volumes:
db_data:Der kritische Punkt ist immer die Datenmigration. Datenbanken, Upload-Verzeichnisse, Konfigurationsdateien – all das muss sauber übertragen werden. Erstellt Backups, testet den Container mit echten Daten in einer Staging-Umgebung, und plant genug Puffer für unvorhergesehene Probleme ein.
Welche Base Images sollte ich statt CentOS nutzen?
Für die meisten Anwendungen empfehlen wir Alpine-basierte Images. Sie sind minimal, sicher und werden aktiv gepflegt. Alpine Linux hat einen anderen Paketmanager (apk statt yum/dnf), aber für containerisierte Anwendungen ist das selten ein Problem.
Wenn ihr CentOS-Kompatibilität braucht, sind AlmaLinux und Rocky Linux als Base Images verfügbar:
FROM almalinux:9
# oder
FROM rockylinux:9Diese Images werden langfristig unterstützt und sind binärkompatibel mit RHEL. Für Legacy-Anwendungen, die auf bestimmte RHEL-Bibliotheken angewiesen sind, ist das oft der einfachste Migrationspfad.
Unser Praxis-Tipp: Prüft zuerst, ob es ein offizielles Image für eure Runtime gibt. php:8.3-fpm, node:20-alpine, python:3.12-slim – diese Images werden von den jeweiligen Communities gepflegt und sind für Container-Umgebungen optimiert.
Wie behalte ich meine Daten bei der Container-Migration?
Daten gehören nicht in Container. Das ist die goldene Regel. Container sind ephemer – sie können jederzeit gelöscht und neu erstellt werden. Alles, was persistent sein muss, gehört in Volumes.
# Daten aus dem alten Server exportieren
tar -cvpzf /backup/app_data.tar.gz /var/www/uploads
# Auf dem neuen Host: Named Volume erstellen
docker volume create app_uploads
# Daten in das Volume importieren
docker run --rm -v app_uploads:/data -v /backup:/backup alpine
tar -xvpzf /backup/app_data.tar.gz -C /dataFür Datenbanken gilt: Nutzt keine Filesystem-Kopien zwischen verschiedenen Versionen. Macht einen logischen Dump (mysqldump, pg_dump) und importiert diesen in den neuen Container. Das ist langsamer, aber sicher.
Volumes sind der Standardweg für persistente Daten in Docker. Alternativ könnt ihr Bind Mounts nutzen, bei denen ein Host-Verzeichnis direkt in den Container gemappt wird. Für Produktionsumgebungen mit mehreren Hosts sind Storage-Plugins oder externe Speicherlösungen wie NFS, Ceph oder Cloud-Storage die bessere Wahl.
Ist Docker auch für Produktionsumgebungen geeignet?
Kurze Antwort: Ja, absolut. Über 3,5 Milliarden Anwendungen laufen weltweit in Docker-Containern. Die Technologie ist ausgereift und battle-tested.
Die längere Antwort: Es kommt auf eure Anforderungen an. Für einzelne Container auf einem Host reicht Docker Compose. Für größere Deployments mit automatischer Skalierung, Rolling Updates und Self-Healing braucht ihr einen Orchestrator wie Kubernetes oder Docker Swarm.
Managed Kubernetes Services – AWS EKS, Google GKE, Azure AKS – nehmen euch viel Komplexität ab. Ihr zahlt mehr als für eine einfache VM, aber ihr bekommt dafür Hochverfügbarkeit, automatische Skalierung und einfaches Deployment out of the box.
Für kleine bis mittlere Workloads empfehlen wir den Einstieg mit Docker Compose auf einem soliden Host. Wenn die Anforderungen wachsen, könnt ihr immer noch zu Kubernetes migrieren – die Container-Images bleiben dieselben.
Was kostet der Wechsel von CentOS zu Docker?
Die Software selbst kostet nichts. Docker Engine ist Open Source und kostenlos. Docker Desktop für Windows und Mac ist für kleine Teams und persönliche Nutzung ebenfalls kostenlos, für größere Unternehmen fallen Lizenzgebühren an.
Die echten Kosten sind Zeit und Know-how. Euer Team muss lernen, mit Containern zu arbeiten. Dockerfiles schreiben, Images bauen, Compose-Stacks verwalten, Volumes handhaben – das ist eine Lernkurve. Rechnet mit zwei bis vier Wochen Einarbeitungszeit für erfahrene Entwickler, länger für Teams ohne Linux-Erfahrung.
Dazu kommen die Migrationskosten: Analyse der bestehenden Infrastruktur, Containerisierung der Anwendungen, Tests, Staging, Rollout. Für eine typische Webanwendung mit Datenbank kalkulieren wir in unseren Projekten drei bis fünf Personentage für die initiale Containerisierung.
Langfristig spart ihr durch Docker: Weniger OS-Wartung, einfachere Skalierung, schnellere Deployments, bessere Ressourcenauslastung. Die Investition amortisiert sich meist innerhalb von sechs bis zwölf Monaten.
Wie integriere ich Docker in meine CI/CD-Pipeline?
Docker und CI/CD sind natürliche Partner. Ihr baut euer Image in der Pipeline, pusht es in eine Registry, und deployt es automatisch in Staging und Produktion.
# Beispiel: GitLab CI/CD
build:
stage: build
script:
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
deploy:
stage: deploy
script:
- docker pull $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
- docker compose up -dDie großen CI/CD-Plattformen – GitLab, GitHub Actions, Jenkins, CircleCI – haben alle erstklassigen Docker-Support. Für private Images braucht ihr eine Container Registry: Docker Hub, GitHub Container Registry, GitLab Container Registry oder eine selbstgehostete Lösung wie Harbor.
Der Workflow wird dadurch reproduzierbar: Jeder Build erzeugt exakt dasselbe Image. Rollbacks sind trivial – ihr deployt einfach das vorherige Image. Und ihr könnt mehrere Umgebungen parallel betreiben, ohne euch um Konflikte zwischen Abhängigkeiten zu sorgen.
Wie sichere ich meine Docker-Container richtig ab?
Container-Security beginnt beim Base Image. Nutzt offizielle Images, haltet sie aktuell, scannt sie regelmäßig auf Schwachstellen. Tools wie Trivy, Grype oder Docker Scout zeigen euch bekannte CVEs in euren Images.
# Image auf Schwachstellen scannen
trivy image myapp:latestLauft Container nicht als Root. Die meisten offiziellen Images unterstützen das bereits:
FROM node:20-alpine
USER node
WORKDIR /app
COPY --chown=node:node . .Begrenzt die Ressourcen, die ein Container nutzen kann:
services:
app:
deploy:
resources:
limits:
cpus: '0.5'
memory: 512MNutzt Read-only Filesystems wo möglich, beschränkt die Netzwerk-Kommunikation zwischen Containern, und loggt alles zentral. Für Produktionsumgebungen empfehlen wir zusätzlich Runtime-Security-Tools wie Falco oder Sysdig.
Der Praxis-Check: Für wen ist der Wechsel zu Docker sinnvoll?
Nach über 15 Jahren Consulting-Erfahrung sehen wir klare Muster, wo Docker glänzt und wo nicht.
Docker ist die richtige Wahl für Teams, die moderne Webanwendungen entwickeln und deployen. Für Microservices-Architekturen. Für Organisationen, die Multi-Cloud-Strategien verfolgen. Für Entwickler-Teams, die konsistente Entwicklungsumgebungen brauchen. Für alle, die ihre Deployment-Frequenz erhöhen wollen.
Docker ist weniger geeignet für Legacy-Anwendungen mit tiefen OS-Abhängigkeiten. Für Workloads, die direkten Hardware-Zugriff brauchen. Für Teams ohne grundlegende Linux-Kenntnisse. Für Umgebungen mit extremen Security-Anforderungen, wo vollständige VM-Isolation zwingend ist.
Unterstützung für euer Team
Ihr plant die Migration von CentOS zu Docker oder habt Fragen zur Container-Strategie? Mit über 15 Jahren Expertise in Softwarequalität, Open Source und Remote Consulting helfen wir euch gerne weiter.
Wir bieten:
- Analyse eurer aktuellen Server-Infrastruktur
- Containerisierungsstrategie für eure Anwendungen
- Hands-on Workshops für Docker und Kubernetes
- Begleitung bei der Migration in die Produktion
Kontakt: roland@nevercodealone.de
Gemeinsam finden wir den richtigen Weg für euer Team – keine theoretischen Konzepte, sondern praktische Lösungen die funktionieren.
Fazit: Die Zeit für Container ist jetzt
CentOS ist Geschichte. Die Frage ist nicht mehr ob ihr migriert, sondern wohin. Docker bietet einen zukunftssicheren Weg, der euch nicht nur das aktuelle Problem löst, sondern euch für die nächsten Jahre aufstellt.
Der beste Einstieg: Containerisiert eine einzelne, unkritische Anwendung. Sammelt Erfahrungen, baut Know-how auf, und weitet dann schrittweise aus. In sechs Monaten werdet ihr euch fragen, warum ihr nicht früher gewechselt habt.
Never Code Alone – Gemeinsam für bessere Software-Qualität!
