News Spotify migriert 5.000 Server von Debian nach Ubuntu

[dMopp]

"LTS"... Muss da immer lachen. LTS braucht ne "Webbude" maximal im Payment Bereich. Beim Rest ist die Welt doch so schnelllebig, das man lange vor Ablauf der LTS Zeit wieder aktualisiert...

Naja jemand hat es schon geschrieben: Managemententscheidung...


(80% der Software kommt eh nicht aus dem Paketmanager, und wenn doch: Die armen Entwickler)

 

[flappes]

Spotify wird nicht auf 0815 Software setzen, da ist ein Update nicht immer so einfach umsetzbar. Das Debain jetzt auch Langzeit Support bieten will wird wohl eine bereits laufende Migration nicht so einfach stoppen können.

Klar für Streaming von Dateien und einen Webserver sind mysthische Softwarekomponenten von einem anderen Planeten notwendig ;-)

Ich hab den Artikel auch beim 2. lesen nicht so richtig verstanden -> bis auf das Fazit: Debian braucht Kohle damits ordentlich funktioniert und für Unternehmen interessant bleibt (logisch)

 

[exoterrist]

Eigentlich ist der Artikel doch recht eindeutig. Spotify will einen besser vorhersagbaren Release-Zyklus und LTS. LTS gab es bis vor kurzem aber nur bei Ubuntu, also hat man sich für einen Umstieg von Debian zu Ubuntu entschieden.
Nachdem Spotify diesem Umstieg geplant hatte, hat Debian inzwischen zwar auch LTS angekündigt, allerdings kann man sich darauf nicht verlassen, denn aktuell fehlt es Debian am nötigen Geld, um den versprochenen LTS auch wirklich zu liefern.

 

[Daaron]

"LTS"... Muss da immer lachen. LTS braucht ne "Webbude" maximal im Payment Bereich. Beim Rest ist die Welt doch so schnelllebig, das man lange vor Ablauf der LTS Zeit wieder aktualisiert...

Auch die kleine Webbude hat besseres zu tun als alle 2 Jahre ein Dist-Upgrade durchzuführen.

Ergänzung (17. Juli 2014)

Eigentlich ist der Artikel doch recht eindeutig. Spotify will LTS, den gab es bis vor kurzem aber nur bei Ubuntu, also hat man sich für einen Umstieg von Debian zu Ubuntu entschieden.

Auch CentOS bietet LTS, sogar auf längeren Zeiträumen. Entscheidend war wohl eher, dass CentOS 7 noch nicht fertig war und irgend jemand die paar Wochen Geduld nicht aufbieten konnte/wollte.

 

[dMopp]

Du musst es ja wissen... Einzelne Pakete und ggf der Kernel sollte sogar deutlich öfter aktualisiert werden, wobei die Pakete dann hoffentlich selbst geschnürt sind

 

[exoterrist]

Auch CentOS bietet LTS, sogar auf längeren Zeiträumen. Entscheidend war wohl eher, dass CentOS 7 noch nicht fertig war und irgend jemand die paar Wochen Geduld nicht aufbieten konnte/wollte.

Natürlich, aber das ist dann noch mal was ganz anderes. Mit "nur bei Ubuntu" meine ich "nicht bei Debian".

 

[Daaron]

Zu welchem Zweck, dMopp?
Kernel-Updates? Entweder es gibt einen LTS-Kernel mit regelmäßigen Upgrades (siehe Ubuntu) oder man lässt die Finger von den Basteleien und nutzt nur, was der Maintainer bereit stellt. Und Anwendungen? Klar, wenn man auf die zusätzliche Arbeit steht...

Mal ganz ehrlich: Hast du den ganzen Tag nix besseres zu tun, als deine Pakete zu aktualisieren? Bezahlt dich jemand nur dafür, dass du Upstream auf Sicherheits- und Stabilitätsfixes lauschst und selbige in deine handgeklöppelten und mundgeblasenen Pakete einpflegst?
Wozu gibt es Paket-Maintainer, wozu gibt es LTS? Genau: Damit ich mich eben NICHT darum kümmern muss, dass Sicherheit und Stabilität des Systems gewährleistet sind. Ich muss NICHT alle paar Tage ein halbes Dutzend Anwendungen neu kompilieren.

 

[dMopp]

Kann es sein, dass du einer dieser oldscool kelleradmins bist( also mental ).

Nehmen wir doch mal Java/Tomcat. Glaubst du wirklich dass Entwickler warten bis sich RHEL und Co mal bemühen java8/tomcat8 zu implementieren?

 

[Daaron]

Bleiben wir bei deinem Beispiel: Wie stellst du für all deine angepassten Pakete sicher, dass du über kritische Sicherheitslücken und deren Fixes informiert wirst? Wie viel Aufwand ist es, permanent neue Pakete zu bauen, sobald mal wieder eine Lücke gefixt wird?

Und wo ändert sich deine Anforderung im Bezug auf andere Stable-Distributionen mit kürzeren Release-Zyklen? Wenn du nicht gerade so schräg drauf bist, eine frickelige RR-Distribution wie Arch als Server betreiben zu wollen, dann wirst du bei JEDER Distribution dein Tomcat 8 manuell nachrüsten müssen.
Das ändert aber nichts daran, dass du bei einer LTS-Distribution 99,9% deiner Pakete eben NICHT laufend neu zurechtfrickeln musst, sondern für 5-10 Jahre dem Maintainer anvertraust. Nur die 0,1%, die deinen Bedürfnissen nicht entsprechen, löst du anderweitig.

Außerdem, um dein Beispiel nochmal aufzugreifen, ein kleines Zitat von der Tomcat-Seite:
Tomcat 8 is currently in a beta state.
Das verwendest du auf einem Live-Server? Du bist mutiger als ich dachte...

 

[dMopp]

Du schlussfolgerst Schwachsinn, ich behaupte nicht tomcat 8 irgendwo ein zu setzten..

Aber mal ganz grob: Paket bauen = jenkins job. einchecken, warten, fertig.

Deine Einstellung bezüglich Systemen kannst du gerne behalten, damit wirst du aber langfristig nicht mehr erfolgreich sein

PS: 80% der Firmen (geschätzt) updaten doch noch nicht mal ihre Pakete, wollen aber trotzdem ne LTS Version. paradox.

 

[Cool Master]

Wie stellst du für all deine angepassten Pakete sicher, dass du über kritische Sicherheitslücken und deren Fixes informiert wirst?

Newsgroups, RSS Feed, Newsletter, Update Chanel usw.

Als Systemadmin sollte man da eh recht aktiv sein und immer mal wieder ein "apt-get update && upgrade" machen. Ich schau bei uns auf dem Servern zwar nicht alle 24h aber wöchentlich schau ich schon mal nach neuem Zeug.

 

[Daaron]

Newsgroups, RSS Feed, Newsletter, Update Chanel usw.

Tja, und jetzt zähl mal die Stunden, die du in all den Newsgroups etc. zubringst, um die für dich relevanten Informationen zu filtern.

Wenn du ausschließlich aktiv gewartete Repos verwendest, dann hast du das Problem nicht. Dann reicht tatsächlich ein "yum update". Und dann sind da noch Unattended Upgrades in den Debian-Ablegern... Wieder viel Zeit gespart.

 

[Cool Master]

Tja, und jetzt zähl mal die Stunden, die du in all den Newsgroups etc. zubringst, um die für dich relevanten Informationen zu filtern.

Je nach Webseite kann man heute schon gut filtern.

Wie gesagt Sinnvoll ist es einfach einmal oder zweimal die Woche nach updates zu suchen und falls vorhanden zu installieren. So mach ich es immer. So habe ich sogar das Debian 7.6 Update diese Woche installiert bevor es überhaupt eine News dazu gab.

 

[Daaron]

So... und wenn du jetzt nicht nur Stock-Pakete verwendest, wie lange sitzt du jeweils daran, deine Custom-Pakete zu aktualisieren? Darum gings mir. Wie lange brauchst du für den Workflow:
- bemerken, dass kritisches Update vorhanden
- neue Source laden
- Source kompilieren
- TESTEN TESTEN TESTEN (oder spielst du den Kram blind in ein Live-System?)
- einspielen

Wenn du LTS mit Stock-Paketen verwendest, dann entfallen die ersten 3 Punkte quasi komplett und der 4. zu weiten Teilen (Testing gegen das System erfolgt ja schon beim Maintainer)

 

[dMopp]

Daaron, sag mal, wusstet du, dass man für ARBEIT bezahlt wird?

Und im Gegensatz zu dem was du sagt, bleibt Punkt4 bestehen. TESTEN. Der Maintainer testet nur Abhängigkeiten, nicht jedoch die komplette Funktionalität. Deine Einstellung mag ja funktionieren, aber sorgt dafür, das du früher oder später von ALM Unternehmen geschluckt wirst, da diese in der Zeit deutlich weiter sind. Da mein beruf jedoch eh hauptsächlich nur noch aus "Überzeugungsarbeit" besteht, habe ich hier keine Lust mehr weiter zu diskutieren, hier werde ich dafür nicht bezahlt

 

[Cool Master]

@Daaron

Ja und wo genau liegt nun das Problem?

- bemerken, dass kritisches Update vorhanden

Joar wie ich schon sagte per Mail, Newsgroup etc...

- neue Source laden
- Source kompilieren

Joar auch hier kein problem

- TESTEN TESTEN TESTEN (oder spielst du den Kram blind in ein Live-System?)

Deswegen arbeitet man heute mit VM's. Ich mach eine Kopie vom aktuellen Live System, test das neue Paket und

- einspielen

spiele es ein, wenn keine Probleme auftreten.