Applikationen unter Linux am Beispiel CentOS
Aus CentOS 8 wird CentOS Stream.Über die Meldung, dass CentOS 8 zugunsten von CentOS Stream einstellt, habe ich mich sehr geärgert. Ich war sogar richtig gehend angepisst.
CentOS war immer die Möglichkeit, eigene Dinge auf Red Hat Kompatibilität zu testen, ohne Subskriptionskosten (für das Patching) bezahlen zu müssen.
Leider hat es das CentOS-Team mit der Version 8 nicht geschafft, zeitnah auf Updates und Hotfixes durch Red Hat zu reagieren und ist aus diesem Grund auch nicht mehr meine Distribution der Wahl. Mein Kram wird im Lauf der nächsten Wochen und Monate auf Ubuntu LTS migriert.
Machen wir uns aber bitte nichts vor. CentOS ist keine "schöne" Linux-Distribution. Das Tooling ist nicht so berühmt. Durch die lange Unterstützung und die durch Red Hat versprochene API-Kompatibilität über die ganze Laufzeit veraltet Software in Red Hat Enterprise Linux (RHEL) und damit auch in CentOS sehr schnell. (Gilt übrigens für andere paketbasierte Distributionen im gleichen Mass, die helfen sich nur mit häufigeren Releases).
RHEL (CentOS) möchte man eigentlich nur aus genau einem Grund einsetzen, nämlich, dass nahezu jede Business-Software für RHEL zertifiziert wird. Und aufgrund der versprochenen Kompatibilität ist es nahezu garantiert, dass sie auch über die komplette Laufzeit das Major-Releases von zehn Jahren bzw. 13 Jahren mit extended Support auch lauffähig bleibt.
Wenn man aktuelle Open-Source-Software auf CentOS einsetzen möchte, so konnte man sich nur dadurch behelfen, dass man entweder darauf vertraut hat, dass die irgendwann in den Software-Kollektionen aufgeschlagen ist, da wurde sie dann "neben" der Basisinstallation installiert oder dass man externe Repositories verwendet hat. Bei meinen Servern habe ich beispielsweise PHP aus den Remi Repositories, sowie Docker und MariaDB direkt vom Hersteller bezogen.
Das hat auch Red Hat erkannt und mit Version 8, Modules oder "Application Streams" eingeführt. Hier gibt es eine sehr gute englischsprachige Erklärung dazu. Kurz zusammengefasst, lassen sich mit diesem Konzept mehrere Versionen der gleichen Software parallel installieren und auch benutzen.
Vermutlich hat dieses neue Konzept die Ressourcen vom CentOS-Projekt gesprengt, ich habe keinen Beweis für diese Vermutung. Für mich ist dieses Konzept aber nur ein Zwischenschritt auf dem Weg, das Basis-Betriebssystem komplett vom Applikationsteil zu trennen.
Im Grossen und Ganzen: Kernel, Netzwerk, Infrastruktur (Backup, Authentifizierung, ...) macht die Distribution und den ganzen Rest können Applikationen alleine besser.
Wenn wir die Distributionen nur als stabile Basis ansehen, auf der wir Dienste mit den Hersteller-Repositories (Docker, MariaDB, ...) oder Snaps, Flatpaks und AppImages oder Containern (Docker, Podman, ...) aufsetzen, dann würden wir allem gerecht werden.
Es entspricht einer Trennung von Applikation und Plattform, die in vielen Firmen trotz DevOps immer noch betrieben wird. DevOps bezieht sich im Grossen und Ganzen auch mehr auf Applikationsentwicklung und -betrieb. DevOps (oder EngOps) für die Plattformentwicklung ist davon getrennt.
Wenn wir diese Sichtweise weiterspinnen, werden paketbasierte Linuxdistributionen obsolet.
Wohin das in Summe führen kann, sehen wir mit Kubernetes (und OpenShift) oder durch den Einsatz von Containern (mit Docker oder Podman oder ...).
Kubernetes ist es egal, auf welchem linuxbasierten OS es läuft, wenn die Voraussetzungen gegeben sind. Den Leuten, die Kubernetes benutzen (nicht verwalten), ist die komplette Infrastruktur darunter egal, so lange das Cluster zur Verfügung steht.
Und, die alten erinnern sich, das hatten wir schon einmal, aber nicht ganz so ausgereift.
Java hat den Ruf (weitestgehend) plattformunabhängig zu sein. Klar, dafür muss man mit der Runtime (JRE) oder dem JDK auch ein halbes OS mitinstallieren. Darauf kann man Applikationsserver wie Tomcat, JBoss, Weblogic, Websphere, ... betreiben und auch da gab es das Versprechen, sich nicht um die darunter liegenden Schichten kümmern zu müssen.
Meiner Meinung nach wurde dieses Versprechen nie komplett eingelöst, obwohl sehr viele gute Konzepte vorhanden waren.
Mit Containern und Orchestrierungslösungen sind wir aber der Erfüllung dieses Versprechens einen Schritt näher gekommen.
Bin an Euren Meinungen und einer Diskussion darüber sehr interessiert.
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Ulf Volmer am :
Insofern war das für mich privat nie eine Lösung. Und beruflich wird halt brav RHEL, SLES und OEL eingekauft.
Mit der Trennung von Appl. vs. OS bin ich bei Dir. Ich beobachte in meinem Umfeld, dass da auch ohne Docker und Co. die Basis der jeweiligen Applikation, also Java, Perl, whatever vom Kunden am Betriebssystem vorbei ins jeweilige Home installiert wird.
Grüße
Ulf
Dirk Deimeke am :
Ich kann Deine Sichtweise sehr gut nachvollziehen.
Dass ich CentOS privat eingesetzt habe, war dem geschuldet, dass ich mich nicht ständig umgewöhnen wollte.
Wir animieren sogar unsere Applikatiönler dazu, sich unabhängig vom OS zu machen. Damit unsere Patchzyklen sich nicht mit der Applikation beissen.
plocki am :
Vor ein paar Wochen habe ich nebenher ein Testsetup aufgebaut, mit dem ich ausschließlich Ubuntu 20.04 lts Container betreibe (Proxmox/LXE).
Ist vorerst nur ein Versuch, habe auch nicht viel Erfahrung mit Ubuntu im Dauerbetrieb, aber bislang sieht das eigentlich ziemlich gut aus. Habe halt noch Null Langzeiterfahrung.
Etwas spezieller sieht es bei meinem selbst gebauten CentOS7 Firewall-Cluster aus, der läuft seit CentOS 7 Release (ca. vor 5 Jahren) ohne irgendwelche Spinnereien.
Ich spiele mit dem Gedanken, das in Zukunft durch opnsense/pfsense zu ersetzten. Eine pfsense läuft schon. Ist halt FreeBSD, damit funktioniert mein ganzes Ansible Orchester (noch) nicht.
Gruß
plocki
Dirk Deimeke am :
Ich komme ja eigentlich von Ubuntu und kehre gerade wieder dahin zurück. Man muss nur aufpassen, dass man keine experimentellen Features erwischt, sonst ist alles prima. Das mit den experimentellen Features gilt natürlich auch für andere Distributionen.
Stefan Betz am :
Gute Erfahrung gibt es mit Rolling Releases, z.B. Arch Linux or Manjaro, weil diese mehr Entwicklerzentrisch funktionieren. Wenn dein Ziel dann aber alt und gammelig ist, dann ist Docker/Podman/Kubernetes/Whatever notwendig um Dinge aus 2020 auf Plattformen aus 2018 fahren zu können.
Teil des "Docker Problems" ist das Applikationen nun das ganze Betriebssystem mitbringen, im schlimmsten Fall wieder ein Debian oder Ubuntu. Man ersetzt also ein gut gepatchtes Betriebssystem (Annahme!) mit einem Container der meist zu selten angefasst wird. Effektiv ist der Einsatz von CI/CD und "gutem" DevOps / GitOps / EngOps erforderlich sobald auch nur ein Docker Container im Unternehmen läuft.
In jedem anderen Fall hat man gammelige Software auf gepatchten Maschinen, oder im schlimmsten Fall wird gammelig mit gammelig im Stack betrieben.
So lange Applikationsentwickler beim Wort "Patches" und IT Leiter / Verantwortliche beim Wort "Updates" noch vor Angst zittern, bleiben wir in der guten alten IT Hölle gefangen.
(Ich fang jetzt wieder an mein Baldrian zu nehmen, 180er Puls auf Dauer nix gut
Gruß
Stefan
Dirk Deimeke am :
Mit Containern hätten wir aber die Situation, dass diese Applikation viel besser gekapselt ist.
Die Situation wird mit Containern nicht besser oder schlechter, sie verschiebt sich nur.
Markus am :
ja, das liebe CentOS!? Mit CentOS bin ich auf dem Server seit Version 4 "unterwegs". Es hat immer ausgereicht und einwandfrei funktioniert.
Kommt ja auch immer auf den jeweiligen Kontext an, wo und wie man es einsetzt.
Bei uns im Betrieb gibt es mittlerweile, allerdings nicht mehr lange, nur noch drei RHEL- und eine CentOS-Installation, der Rest ist durchgängig (virtualisiert) Debian stable.
Beruflich trifft es mich von daher gar nicht. Privat auf den Servern seit ca. einem Jahr auch nicht mehr, da ist es Debian stable.
Die Desktops waren, sind und bleiben Fedora (seit Fedora Core 3, ohne Ausnahme).
Aber genau aus dem von Dir genannten Grund bin ich z.B. von CentOS langsam aber sicher weggegangen, da ich eigentlich fast alles aus den SCL holen musste.
Das mochte ich nicht so sehr.
Ebenso störte mich, aber wie gesagt rein privat, dass RH soviel Hardwareunterstützung mit Version 8 rausgeworfen haben. Damit laufen einige meiner privat betreuten Geräte nicht mehr.
Man liest im Netz zu diesem Thema CentOS im Moment ja wirklich sehr viel. Vielleicht erweist sich CentOS-Stream als gar nicht so schlecht. Übrigens ist Fedora für den Servereinsatz auch gar nicht so übel, man muss sich halt damit auskennen und genau wissen wo und wofür man es einsetzt.
In der c't gab es doch mal im Jahr 2016 einen Artikel über Ubuntu-LTS, dort kam man u.a. auch zu dem Schluss, dass Rolling-Releases bzw. Distributionen mit kürzerer Lebensdauer höchstwahrscheinlich vorteilhafter sind.
Meine Erfahrungen beziehen sich da aber auch eher weniger auf Container usw., da ich damit nur wenig Erfahrung habe und die sind auch nur privater Natur.
Allerdings habe ich noch niemals irgendwo jemanden getroffen oder gesprochen, der Ubuntu LTS ernsthaft einsetzt. Ich kann mir persönlich darüber absolut kein Urteil bilden ob es gut ist und sich wirklich bewährt, da ich dem teilweise provokanten Gemeckere im Netz nicht vertraue.
Ist es so schlecht wie sein Ruf? Wie sieht es denn wirklich in der Praxis aus? Hat oder macht diese Distri mehr Probleme als alle anderen? Warum? Welche? Nur weil sie alle Canonical, Oracle und Redhat nicht mehr mögen, sind die Produkte auch schlecht?
Was ist mit OpenSuse? Das war mein Einstieg in die Linuxwelt. Wenn man mal alles unterm Strich mit den ganzen Auf's und Ab's betrachtet so sind sie doch erstaunlich konstant geblieben. Habe mir die 15.2 mal in einer VM angeschaut.
Ist OpenSuse ggf. nicht auch eine Alternative, da sie ja mit dem SLES die selbe Codebasis bilden? Die alten "Yast überschreibt alles"-Gerüchte sind ja wohl schon lange aus der Welt. Der Supportzeitraum ist kürzer, ja.
Wie siehst Du das oder auch gerne jemand anderes?
Das alles löst natürlich die Probleme, die du in deinem Artikel ansprichst nicht
Viele Grüße (und das es 2021 eine ORR gibt)
Dirk Deimeke am :
Wenn Du Unterstützung für Business-Software brauchst, wird die Luft sehr schnell sehr dünn. Da fällt Debian leider sofort raus und auch Ubuntu LTS ist relativ weit hinten. RHEL ist da auf Platz 1 und SLES mit ordentlich Abstand auf dem zweiten Platz.
Wenn ich an meine privaten Server denke, komme ich schon fast an Containern nicht mehr vorbei. Da gibt es Software, die braucht PHP 7.3 und läuft nicht mit 7.4, bei anderer Software ist das umgekehrt. Statt PHP kann man gerne auch Ruby oder NodeJS einsetzen, das tut sich nichts.
Mir hat daher die Idee mit den Application-Streams gut gefallen und die Trennung von System-Python und Application-Python (als Beispiel).
Ja, Container haben eine Reihe an Nachteilen, da kann ich jedem nur Recht geben, aber die kann man in den Griff bekommen, wenn man Container selber baut. Alle anderen Lösungen haben auch deutliche Nachteile, über die spricht man aber nicht, weil man sich damit arrangiert hat.
Ja, auf eine ORR 2021 freue ich mich schon jetzt und hoffe, dass es sie geben wird.
Lioh am :
Allerdings möchte ich kein vollständig immutable OS wie Silverblue oder microOS, da ich gerne auch am Kernel tinkere. Geht da zwar auch, aber nicht so schön.
Christoph am :
wir setzen seit Ubuntu 14.04 die LTS Version in Produktion ein. Aktuell sind wir auf 16.04 und migrieren gerade alles auf 20.04. Migration ist hier auf jedem System immer eine Neuinstallation. Das können wir für die Services Downtime frei machen, da genügend Replicas vorhanden. Bisher hatten wir niemals Probleme die auf Ubuntu konkret zurückzuführen sind. Wir hatten Probleme mit dem Kernel und Netzwerkhardware, dass haben wir dann aber mit neueren Kernel gelöst. Mittlerweile bauen wir unsere eigenen Kernel mit unseren Patches solange sie noch nicht Upstream sind. Da steht uns Ubuntu auch nicht im Weg.
In der Cloud phasen wir Ubuntu aus und ersetzen es mit Amazon Linux 2, da wir Amazon EKS nutzen um unsere Applikationen im Container darauf zu deployen. Da wir auch hier managed Nodes nutzen, kümmert sich komplett Amazon um das Host OS. Unsere API ist die von Kubernetes. Unsere Applikationen sind Eigenentwicklungen in Go oder basierend auf der JVM. Für unsere REST Services ist der zugrundeliegende Kernel quasi irrelevant. Das ist weit genug abstrahiert.
Wir setzen kaum zugekaufte Software ein, und selbst die lief bisher immer auf den aktuellen Ubuntu LTS Versionen.
Dirk Deimeke am :
Vollständig immutable finde ich auch schwierig, aber ein langsamer drehendes Basis OS mit beliebig schnell drehenden Applikationen (auch langsamer als das Basis OS) hat echt etwas für sich.
Dirk Deimeke am :
Warum dann überhaupt Ubuntu? Braucht Ihr den Support?
Ich würde in einem solchen Setting auf Alpine Linux setzen (was ich auch in Containern benutze).
Christoph am :
in den Container setzen wir auf Distroless bzw SCRATCH. Java Images bauen wir mit jib das nutzt Distroless als BaseImage.
Ubuntu setzen wir auf unserer OnPremise Hardware in der Colocation ein. Hier vor allem, da wir außer mit der Netzwerkhardware keine Treiberprobleme hatte und jeder sich gut genug mit Ubuntu auskennt. Damals war vorallem die frühe Unterstützung von systemd ein Grund nicht auf CentOS zu wechseln. Wir hatten ein paar CentOS 6 basierende Appliances. Daher können wir unsere internen Packages (prometheus exporter und andere Dinge) mit fpm sowohl als RPM als auch als DEB bauen. Die DEB Packages mit systemd waren einfacher zu pflegen als die SysV Init pasierenden RPMs.
Mit OpenSuse hatte einfach niemand im Team Vorwissen.
Dirk Deimeke am :
Vielen Dank für den Hinweis.
Wir sind in der Firma auf RHEL angewiesen ("cover your ass") und aufgrund der Tatsache, dass viel Software eine keine Zertifizierung für andere Linux mitbringt.
Ich glaube ich baue mir mal etwas mit Alpine und Podman, das ist bestimmt spannend ... wenn ich mir mal Zeit dafür nehmen kann.
Jörg Kastning am :
meine Meinung zum Ende von CentOS habe ich gerade frisch in "My 2 Cents on CentOS verbloggt. Daher gehe ich in diesem Kommentar nur auf den Aspekt der Abhängigkeit von Anwendungen zum Betriebssystem ein.
In einem früheren Berufsleben haben mein Team und ich auf Ubuntu LTS gesetzt. Die Firma entwickelte etliche Webanwendungen. Die meisten davon hatten Abhängigkeiten zu Java und PHP. Und unsere Entwickler standen auf den neusten und heißesten Scheiss. Daher mussten Java und PHP stets aktuell sein. Im Vergleich zu Ubuntu war das was CentOS, SUSE und Debian stable in ihren Quellen zu bieten hatten alles kalter Kaffee. Unsere Hoffnung war, dass das Zeug aus Ubuntus Paketquellen aktuell genug sein würde. Diese Hoffnung und gut planbare Release-Zyklen waren die Gründe auf Ubuntu LTS zu setzen.
Leider stellte sich bald heraus, dass auch die Pakete in Ubuntus Paketquellen nicht aktuell genug waren. Und so mussten wir doch wieder Fremdquellen wie das Remi-Repo einbinden und Software-Pakete direkt aus den Upstream-Projekten installieren.
Während Inplace-Upgrades bei Ubuntu eine lange Zeit gut funktionierten, wurde dies mit der Zeit immer unzuverlässiger. So dass wir dazu übergingen, neue Systeme zu installieren, die Anwendungen zu migrieren und die alten Systeme anschließend abzuschalten.
Das Ubuntu Universe bot uns mit der Zeit immer mehr Pakete, die Probleme machten. Als ich die Firma verließ, habe ich auch Ubuntu auf dem Server den Rücken gekehrt.
Auf der Arbeit setzen wir auf RHEL. Was mir gefällt ist, dass Red Hat für Pakete, die es ausliefert, 10 Jahre Support verspricht. Es ist mir egal wie alt ein PHP oder Python ist, so lange Red Hat wichtige Sicherheitsupdates dafür bereitstellt. Das hilft natürlich nicht, wenn die zu betreibende Software mit so alten Versionen einfach nicht laufen will. Hier stimme ich Dirk zu, dass die Arbeit mit den Software-Collections... anstrengend ist. Hier gefällt mir das AppStream-Konzept von RHEL 8. Hier werden in den ersten 5 Jahren des Lebenszyklus aktuelle Versionen nachgereicht. Danach ist für die letzten 5 Jahre des Lebenszyklus wieder Sendepause. Allerdings wird Red Hat alle 3 Jahre ein neues Major-Release veröffentlichen. So dass dann auch wieder ein Release mit Paketen bereit steht, die aktuell genug sein sollten.
Linux-Container gibt es bei uns noch nicht. Sie können sicherlich dabei helfen, die Abhängigkeit von Anwendungen zum Betriebssystem zu lösen. Allerdings sehe ich auch die Gefahr mit ihnen Software einzukaufen, die bereits veraltete und scheintote Bibliotheken mitbringt. Da mir die praktische Erfahrung in diesem Umfeld fehlt, kann ich dazu nicht mehr beitragen.
Privat setze ich seit etwa einem Jahr wieder komplett auf Debian stable. Es erfüllt meine Anforderungen und funktioniert einfach reibungslos. Ob Debians Inplace-Upgrade-Fähigkeit immer noch hält was sie verspricht, muss sich jedoch noch zeigen.
Viele Grüße
Jörg
Dirk Deimeke am :
Mir ist bei der ganzen Diskussion rund um Sicherheitsprobleme bei Containern wichtig, dass es die gleichen Probleme schon heute ohne Container gibt.
Dass sich jetzt alle so auf Container stürzen, verschleiert das eigentliche Problem.
Ich bleibe dabei, es ist gut eine stabile Basis zu haben, die auch lange stabil bleibt. In der Ecke sind RHEL und SLES aufgrund der Laufzeiten weit vorne.
Darin gekapselt und weitestgehend unabhängig vom Basissystem laufen die Applikation, ob man das mit "lightweight" Virtualisierung durch Container oder Jails oder mittels CGroups und Kernel-Namespaces via systemd macht, ist zweitrangig.
Das bisherige paketbasierte Releasemodell hat meiner Ansicht nach ausgedient.
Ich habe das vor einigen Jahren schon einmal in einem Vortrag thematisiert.
Jörg Kastning am :
Ein Freund und ich haben uns schonmal unabhängig voneinander als Paketbetreuer für unterschiedliche Distributionen versucht. Beide fanden wir die Ökosysteme nicht einladend und nicht wirklich offen für Nachwuchs. Dabei stäubten sich mir bei manchen Toolchains die Haare und die Dokumentation(en) möchte ich beschreiben mit: "Beschissen ist geprahlt."
Da ich mit Containern keinerlei praktische Erfahrung habe, kann ich allerdings noch keinen Vergleich anstellen.
Dirk Deimeke am :
Das bezieht sich jetzt nicht unbedingt auf Dich, aber wer bei Cloud ausschliesslich daran denkt, VMs bei irgendwelchen Providern zu hosten, liegt völlig daneben.
Cloud ist vor allem Platform-as-a-service und Software-as-a-service, da kommen die Einsparpotentiale her. Und ja, es gibt die Sparmöglichkeiten wirklich.
OpenShift ist bei uns in der Firma die am stärksten wachsende Plattform. VMs werden immer weniger bestellt. Diesen Trend sehe ich sehr oft.
Jörg Kastning am :
Denn der persönliche Austausch mit Gleichgesinnten, fehlte mir in diesem Jahr am stärksten. Virtuelle Veranstaltungen im Cyberspace treffen meinen Geschmack einfach nicht.
Dirk Deimeke am :
Mir liegen die virtuellen Veranstaltungen ebenfalls nicht.
Meine Hoffnungen liegen ebenfalls auf der OpenRheinRuhr.
Und, gerade in unserem Bereich gibt es viel zu diskutieren. Meiner Meinung nach ist der klassische Administrator ein Auslaufmodell.
Lioh am :
Dirk Deimeke am :
Manche Anwendungen hinken sogar Major Releases hinterher. Netbackup liefert immer noch keine systemd-Service-Files aus.