"Enterprise ready" Python Modulverwaltung

[Judge]

Hallo zusammen,

ich habe vor kurzem bereits einen ähnlichen Thread (Mehrere Pythons in produktiver Umgebung) gestartet, jedoch habe ich damals extrem unpräzise und nur zu einem Teilaspekt des Themas gefragt. Daher macht es in meinen Augen gerade mehr Sinn, das als anderes Thema zu behandeln und einen neuen Thread zu eröffnen.

Es geht um folgendes: Ich arbeite in einem Umfeld mit rund 1000 Systemen. Wir setzen CentOS und sehr viel Python ein; bis auf ein paar noch zu migrierende Reste haben wir nur noch CentOS 6 und 7.
Unter CentOS 6 ist Python 2.6.6 verfügbar.
Unter CentOS 7 ist Python 2.7.5 verfügbar.
Beides CentOS typisch recht angestaubt.
Wir wollen vor dem End of Life von Python 2.x 2020 gerne unsere bestehende Codebasis auf 3.x portiert haben und daher so langsam Infrastruktur weit einen entsprechenden Interpreter verfügbar machen.
Unsere Systeme sind nur durch fein granulierte Firewall Regeln zugreifbar; von den allermeisten kann man z.B. nichtmal einfach eine Datei aus dem Internet herunterladen; also auch nicht PIP mit pypi so einfach nutzen. Die RPM Pakete kommen von internen Mirror.

Das gestaltet sich recht schwierig: Scheinbar gibt es da als Quellen nur:

• EPEL
• iUS
• SCL

Alle haben bestimmte Vor- und Nachteile:
* EPEL soll laut Erfahrenen Leuten in den einschlägigen IRC Kanälen "broken" sein und immer wieder Workarrounds erfordern; https://bugzilla.redhat.com/show_bug.cgi?id=1263057 , https://bugzilla.redhat.com/show_bug.cgi?id=1319963
* EPEL hat "nur" Python 3.4
* Dafür hat EPEL vergleichsweise viele Module als Pakete
* iUS hat Python 3.6.1, dafür jedoch keinerlei Module als RPM und unterliegt keinerlei Red Hat Qualitätskontrolle / Support
* SCL ist zwar Red Hat supportet, jedoch auch kaum Module und Python 3.5

... alles schwierig

Normal würde ich ja sagen, das das mit den fehlenden Paketen kein Problem ist; genau dafür gibt es ja PIP!
Nur ist das halt in einem abgeschotteten Enterprise Umfeld nicht so einfach; da müssen technische Maßnahmen eingezogen werden, die verhindern, das jeder alles mögliche aus den abenteuerlichsten Quellen des Internets nachzieht.

Wie kann man denn in so einem Umfeld ein halbwegs aktuelles (3.x) Python bereitstellen, ohne das ein wilder Zoo an unterschiedlichsten Modullisten und -versionen entsteht?
Würde mich über Anregungen freuen!

[BlackJack]

Ist jetzt keine Komplettlösung, sondern eher für die Module, aber man kann ja auch PyPI lokal spiegeln und dann ``pip`` sagen es soll von dort installieren. Und man muss es nicht komplett spiegeln, damit nicht einfach irgendwas von dort installiert werden kann, sondern nur Sachen die ihr auch erlauben wollt.

[Judge]

Das wäre auf jeden Fall schonmal eine Idee; nur leider wird man dann auch mit dem ganzen anderen unangenehmen Kram rund um PIP und pypi zu kämpfen haben; bei Installationen mit PIP muss man die Vorbedingungen ja erfüllen; so muss ja bei vielen Modulen ein entsprechendes dev - Paket installiert sein, etc. Auch hat man so ein weiteres Werkzeug und zu wartende Toolkette neben RPM/YUM.
Massen Rollouts und Updates sind so nicht mehr wirklich trivial. Und so Sachen wie "modul xy auf alle Hosts bringen" werden recht abenteuerlich. Von der nachhaltigen, einheitlichen Versionspflege ganz zu schweigen.

[BlackJack]

@Judge: Wenn Du Module mit C-Quelltext nicht auf den Maschinen selbst bauen kannst, müsstest Du entsprechende Wheels erstellen und im privaten PyPI bereitstellen.

[__deets__]

@BlackJack denen fehlt dann aber ggf die Bibliothek.

Ich habe noch nie ein RPM gebaut (bin Debian basiert), aber so schwer kann das doch nicht sein. Warum habt ihr nicht eine Maschine auf der ihr die Pakete schnürt, und dann können die installiert werden?

[Judge]

Das Problem ist weniger das Know How in der Frage "wie baue ich ein Paket"; das ist alles kein Hexenwerk.
Doch handelt man sich, wenn man das alles selbst maintained einen Haufen zeitaufwändiger Arbeit ein. Man muss ja auf tausend Dinge achten: Abhängigkeit zu anderen Paketen und -versionen, Upstream bugfixing, neuere Feature-Versionen, etc.
Wenn das alles so wenig zeitaufwändig wäre, gäbe es keine Distributionen, schon garnicht mit Langzeitunterstützung, sondern jeder würde seinen Kram immer selbst Paketieren/Kompilieren

Das würde ich gerne vermeiden; am besten wäre es natürlich, wenn es ein Repo für CentOS gäbe, welches das bereits tut.

[__deets__]

Also die Erwartung das jemand für eure Skripte und deren Zoo an Abhängigkeiten nun präzise passende Pakete hat kannst du doch nicht wirklich haben, oder?

Und gleichzeitig auf einer(wenn nicht der) konservativsten Plattformen zu sitzen war ja auch eine bewusste Entscheidung. Das hat halt Konsequenzen - da packt halt keiner den heissen Scheiss für euch zusammen.

Darum bleibe ich bei meinem Vorschlag: auf einer Pilot-Maschine konfiguriert man das ganze mittels Pip, Panzerband & Spucke zusammen, und das Ergebnis (zB der Inhalt eines virtual envs) wird als im internen Netz zugängliches rpm bereitgestellt.

[Judge]

Hey, das ist jetzt ähnlich unsachlich wie in den Raum zu stellen, das alle, die eine kostenlose Linux-Distribution einsetzen alle nur "nehmen, nehmen und erwarten, das andere Ihre Linux-Probleme lösen" - was soll das?
Die Hoffnung ist, das jemand ein Projekt kennt, welches ein ähnlich gelagertes Problem / Anforderung adressiert, nämlich: Halbwegs aktuelle Module und Python selbst für CentOS bereitzustellen.
Nur weil CentOS ein konservatives Distributionsmodell hat bedeutet das doch nicht, das man den für einen selbst relevanten Teilbereich nicht durch Projekte/Drittanbieter anders nutzen kann. Für manche ist es z.B. ungemein wichtig, das aktuellste Kernel vorliegen; oder kompilieren gleich einen selbst. Das bedeutet doch nicht, das derjenige deswegen auf Linux From Scratch umsteigen und alles selbst und in der neuesten Version kompilieren muss, nur weil derjenige Wert auf einen speziellen Kernel legt.
Uns ist z.B. fast alles andere egal: Kernel, Apache Version, glibc - Version, gcc Version, ... wir legen nur Wert auf ein aktuelles Python mit möglichst vielen Modulen und möglichst aktuell out-of-the-box. Ich wüsste gerne mal was daran einen unrealistischen Anspruch darstellt.

[BlackJack]

@Judge: Die unrealistische Erwartung ist die Erwartung das jemand für dieses Nischenproblem, das wie Du ja selbst sagst aufwändig zu lösen ist, jemand eine Lösung zur Verfügung stellt. Und CentOS bedeutet sehr wohl das man da keine aktuellen Pakete erwarten darf, auch nicht von Drittanbietern, denn wenn man *irgendwas* am System aktuell haben möchte, dann nimmt man ganz sicher kein CentOS. Auch wenn das natürlich nicht unmöglich ist, ist diese Kombination CentOS und etwas Aktuelles extrem unwahrscheinlich.

[Judge]

@__deets__: Sorry, wenn ich auf Deinen Post eben etwas harsch reagiert habe. Ich hatte nur das Gefühl als jemand der zu faul ist oder unfähig seine Probleme selbst zu lösen dargestellt zu werden.

Es geht mir nur darum, das nach meinem Verständnis absolut nichts gegen eine konservative/rock-solid - Basis spricht, bei der man nur in wichtigen Teilbereichen zugunsten neuerer Features von bestimmter Software auf neuere Versionen dessen, was mitgeliefert wird, setzt.
Egal in welcher Kombination; was spricht z.B. gegen eine konventionelle/alte Basis von glibc, Kernel, SSHd, Apache ... wenn man nur ein aktuelles PHP benötigt? Oder nur ein aktuelles JDK?

Ich verstehe den Widerspruch noch immer nicht wirklich. Genau dafür, "Nischen" nämlich, gibt es für nahezu alle aktuellen Distributionen ja externe Quellen in Form von Repos.
Anders herum gibt es das ja auch: Ich erinnere nur an z.B. das "Deadsnakes" - Repo für ältere Python Versionen als mit den aktuellen Ubuntus mitgeliefert wird.

PS: Für mich, als One-Man-Show wäre es zuviel Arbeit das alleine zu warten. Aber das bedeutet ja nicht, das es auf der Welt keine Interessengruppe gibt, die sich bereits zusammengetan haben um sowas gemeinsam zu realisieren. Ich bin ja auch garnicht abgeneigt an sowas mitzuwirken.

[__deets__]

Was dagegen spricht sind die Graphen aus Abhängigkeiten. Das neue PHP braucht das neue OpenSSL, aber du hast nur das alte. Also hast du jetzt plötzlich zwei (oder drei...). Und wenn ein bug in OpenSSL festgestellt wird, dann wird das im System ssl gepatcht. Aber wer macht das bei den Abhängigkeiten? Letztlich baust du ein mehr oder minder komplettes Linux in top auf (nur weil DU wenige Dinge brauchst heißt das nicht, das alle anderen die gleichen wenigen Dinge brauchen... ).

Und das kann so weit gehen, dass du Konflikte hast, die nicht mehr auflösbar sind. Weil sich Dinge zur Laufzeit in die Quere kommen.

Das ganze ist also sowohl wenig robust als auch arbeitsintensiver als EINE Distro mit ihren Abhängigkeiten.

[Judge]

Da hast Du natürlich recht.
Nur, stell Dir mal folgendes vor:
Du kommst in eine Firma, wo Du mit einer bestehenden, nicht gerade kleinen (~1k Systeme) Infrastruktur konfrontiert wirst. Diese ist wenigstens schonmal so homogen, das Du es nur mit CentOS zu tun hast.
Jetzt ist es Dein Anliegen, als Python Entwickler Python 3.x zur Verfügung zu haben. Was würdest Du machen? Und wie würdest Du der berechtigten Befürchtung, das unwartbarer Versions- und Bestandswildwuchs entsteht, wenn Du zusätzlich zu RPM mit PIP arbeitest, begegnen?
Zudem Python nicht Teil der Kernapplikationen ist (größtenteils JAVA), sondern für Deployment-Scripte, Config Management DB, etc.
verwendet wird?

Ich halte es für unrealistisch sich jetzt auf den Standpunkt zu stellen, das dazu halt das komplette Infrastruktur-Konzept und bestehende Provisioning-Scripte, Systeme, etc. auf $neue_loesung umgestellt werden müssen.

[BlackJack]

Also ich würde einfach das Python 2.x verwenden was die gegebene Infrastruktur eben bereit stellt. Auf Python 3.x kannst Du dann umstellen wenn CentOS soweit ist. Vielleicht in 10 oder 20 Jahren.

[snafu]

Ich denke, hier sollte man auf jeden Fall den Nutzen gegen den Aufwand abwägen. Da die Verwendung von Python 3 auf CentOS offenbar alles andere als trivial ist, solltest du dich vielleicht besser von der Idee verabschieden...

[__deets__]

@judge ich bin kein devops - darum kann ich da nur aus zweiter Hand berichten.

Aber bei Kollegen und meiner Freundin (auch Entwicklern) dreht sich das Rad weiter, und statt schwer zu administrierender normaler Systeme wird zB auf docker gesetzt. Damit bekommst du leichtgewichtig Virtualisierte unterschiedliche Linux distros. Die aber auch auf einem filesystem arbeiten können. Etc.

Und da gibt's auch noch viel anderes. Nur die Erwartung, dass du auf einem Haufen alter Systeme sitzend nun die Früchte der neuesten Entwicklungen ernten kannst - die erfüllt sich eben nicht.

Aber vielleicht solltest du mal in spezialisierteren Foren zu devops schauen, was die Leute da so treiben.