Strategien für Software-Deployment (Linux-Server)

Probleme bei der Installation?
Antworten
Benutzeravatar
sls
User
Beiträge: 480
Registriert: Mittwoch 13. Mai 2015, 23:52
Wohnort: Country country = new Zealand();

Ein Thema das bei mir seit längerem immer wieder für Herausforderungen sorgt ist, dass wir eine etwas größere Server-Landschaft mit unterschiedlichsten Distributionen haben. Das ganze reicht von Ubuntu 12.04 (fragt nicht...) bis 18.04, ein wenig CentOS und extrem selten noch antike Suse-Kisten.

Das Topic hier ist vermutlich viel zu generisch, aber mich würde interessieren wie ihr eure Applikationen (besonders für Linux) ausrollt. Ist es als Entwickler in eurer Hand, die Software nach Bereitstellung auch zu deployen? Wer ist dafür verantwortlich, die Infrastruktur bereitzustellen und wie geht (oder würdet ihr umgehen) wenn ein o.g. Mischmasch aus unterschiedlichen Serverklassen zur Verfügung steht?

Wir haben u.a. folgende Tools im Einsatz:

- Salt (zum automatisierten Ausrollen von Software auf mehreren Servern / Minions)
- Docker (in der Produktion nur auf einem Teil der Infrastruktur verfügbar)
- LXC (ich weiß nicht warum das parallel zu docker läuft)
- einfach auf Blech via dpkg (Debian-Pakete)
- ultra einfach hässlich händisch via Executable

Anmerkung: zusätzlich muss noch zwischen Upstart und Systemd unterschieden werden, immerhin gibt's keine Cronjobs mehr die alle X-Minuten checken ob die Applikation noch läuft und zur Not erneut startet :D

Am liebsten wäre mir persönlich, ich könnte meine Applikationen nur noch als Docker-Container bereitstellen, nicht weil Docker so toll ist, sondern ich mich dann nicht mehr darum scheren muss ob auf dieser oder jener Kiste ein Python3.4, 3.5, 3.7 oder was auch immer läuft. (Es wird Python aus dem Standard-Ubuntu-Repo verwendet)

Mich würde nun interessieren, wie ihr damit umgeht? Für welche Systeme stellt ihr eure Applikationen bereit, und wie "baut" ihr diese.
When we say computer, we mean the electronic computer.
Benutzeravatar
__blackjack__
User
Beiträge: 13003
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@sls: Das mit den unterschiedlichsten Linux-Versionen, inklusive Museumsstücken, kommt mir bekannt vor. :-)

Bei mir läuft das in der Regel nach dem letzten Punkt. Also händisch, nach Anleitung. Wobei bei mir noch dazu kommt, das die ganzen Rechner auch noch auf viele Kunden verteilt sind, das heisst es gibt da nicht die eine IT-Abteilung die den Rechner-Zoo beaufsichtigt und Richtlinien aufstellt und Entscheidungen trifft. Es ist also nicht nur die Systemlandschaft sehr heterogen, sondern auch was man wo darf und welche Vorgaben und Einschränkungen es gibt, ist auch verschieden. Damit fällt zentral gesteuertes, automatisiertes ausrollen letztlich aus, denn die ganzen Besonderheiten zu pflegen, macht mehr Arbeit als es am Ende nutzt. Zudem sind teilweise auch Schritte enthalten, die man doch wieder manuell machen muss. Zum Beispiel vor Änderungen die Genehmigung von Verantwortlichen einholen, oder die Änderungen in einer bestimmten Art und Weise für einzelne Systeme dokumentieren. Beispielsweise in einem Wiki beim Kunden, oder gar in Word-Dokumenten die irgendwo auf einer Freigabe beim Kunden liegen.

Letztlich läuft es darauf hinaus, dass ich die Abhängigkeiten für meine Programme/Skripte dokumentiere und irgendwelche Besonderheiten beim Installieren notiere, und das dann von Kollegen oder mir ergänzt wird wenn bei einer konkreten Installation Probleme damit aufgetreten sind. Noch sind die Abhängigkeiten meist als Debian-Pakete und/oder `requirements.txt` formuliert, aber das soll nach Möglichkeit durch `pipenv`/`Pipfile` ersetzt werden, damit man unabhängiger von den Versionen auf dem jeweiligen Rechner wird.

Am liebsten mag ich Webanwendungen, weil man die dann nicht auf so viele Arbeitsplatzrechner bringen (lassen) muss. :-)
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
Benutzeravatar
sls
User
Beiträge: 480
Registriert: Mittwoch 13. Mai 2015, 23:52
Wohnort: Country country = new Zealand();

__blackjack__ hat geschrieben: Sonntag 23. Dezember 2018, 22:30 @sls: Das mit den unterschiedlichsten Linux-Versionen, inklusive Museumsstücken, kommt mir bekannt vor. :-)
Das beschäftigt mich zur Zeit etwas, da ich häufig das Problem habe dass viele Abhängigkeiten der verwendeten Bibliotheken herrschen die unter Python XY nicht laufen, dann läuft auf dieser oder jener Serverklasse wieder kein Python >= 3.5 usw. Ironischerweise haben wir zwar ein eigenes Repository, irgendwie werden dort aber keine Python-Versionen (z.B. Python3.4 - Python3.7) als Pakete zur Verfügung gestellt. Zumindest hätte ich dann das Problem nicht mehr, dass ich Software auf Grundlage der Servertypen entwickeln muss.
__blackjack__ hat geschrieben: Sonntag 23. Dezember 2018, 22:30Damit fällt zentral gesteuertes, automatisiertes ausrollen letztlich aus, denn die ganzen Besonderheiten zu pflegen, macht mehr Arbeit als es am Ende nutzt. Zudem sind teilweise auch Schritte enthalten, die man doch wieder manuell machen muss.
Interessanter Punkt. Das zentrale, super-fancy automatisierte, per Knopfdruck Ausrollen funktioniert auch eher selten, da zu viel Kleinkram automatisiert werden müsste (Firewallfreigaben, VMs spawnen, Software ausrollen uvm.)

Ich bin eigentlich fan davon, meine Applikation samt aller Abhängikeiten in ein Zip-Archiv zu stecken, Ausführbar zu machen und samt Config-Files, Logfile-Ordner usw. via Debian-Paket bereit zu stellen. Das ganze dann je nach System als Systemd- oder Upstart-Unit. Ich muss aber auch dazu sagen, dass es einige Fälle gibt, in dem so ein Ziparchiv als "Executable" nicht funktioniert, da sich bspw. .so-Dateien nicht einbinden lassen. Bei Flask hatte ich da auch mal Probleme mit statischen HTML-Files und Jinja.

__blackjack__ hat geschrieben: Sonntag 23. Dezember 2018, 22:30Am liebsten mag ich Webanwendungen, weil man die dann nicht auf so viele Arbeitsplatzrechner bringen (lassen) muss. :-)
Du siehst dann oben, welche Probleme man so hat wenn man auf einer etwas größeren IT-Landschaft Applikationen betreibt :-D

Zwar sind viele Probleme historisch bedingt entstanden, aber oftmals sind Abhängigkeiten ein Problem dass man nicht die neuste Software-Version eines Frameworks, einer Bibliothek oder gar eines Betriebssystems verwenden kann. Als Beispiel wäre hier noch ein Datenbank-Cluster erwähnt wo man ziemlich auf die Nase fiel bei dem Versuch von Ubuntu 14.04 auf 16.04 zu migrieren.
When we say computer, we mean the electronic computer.
nezzcarth
User
Beiträge: 1632
Registriert: Samstag 16. April 2011, 12:47

Ich hoffe, das ist nicht zu sehr Offtopic, aber das mit "den unterschiedlichsten Linux-Versionen" interessiert mich. Wie kommt das denn zustande? Bisher habe ich es immer nur so kennengelernt, dass man sich auf eine, oder einige wenige Distributionen geeinigt hat, die dann ausschließlich verwendet werden dürfen. Oder sind das oftmals dann System von Kunden?

Die Beschränkung auf bestimmte Distributionen hat ja schon den Vorteil, dass man für konkrete Plattformen entwickeln kann. Nachteilig ist sicher, dass gerade die für den produktiven Betrieb beliebten "Enterprise Distributionen" oft eher veraltete Software mitbringen (Centos/RHEL), oder die Paketauswahl überschaubar ist (SLES). Ein aktuelles Django 2.X wäre z.B. unter CentOS 7 im Auslieferungszustand mit Postgres und Python 3 nicht lauffähig. Da muss man sich dann anders behelfen, insb. wenn externe Repos vermieden werden sollen. Container (Docker, Systemd-Nspawn, ...) sind da schon praktisch. Zwar hat man dann streng genommen meistens doch wieder eine zusätzliche Distribution, aber irgendwelche Kompromisse muss man wohl immer machen.
Benutzeravatar
__blackjack__
User
Beiträge: 13003
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

Systeme von Kunden. Die firmeneigenen Systeme sind da im Verhältnis in der Unterzahl und natürlich relativ homogen.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
Benutzeravatar
sls
User
Beiträge: 480
Registriert: Mittwoch 13. Mai 2015, 23:52
Wohnort: Country country = new Zealand();

nezzcarth hat geschrieben: Samstag 19. Januar 2019, 13:15 Ich hoffe, das ist nicht zu sehr Offtopic, aber das mit "den unterschiedlichsten Linux-Versionen" interessiert mich. Wie kommt das denn zustande?
In *meinem* Falle ist das die eigene Infrastruktur. Das sind ca. 1000 Server und ein vielfaches an VMs die auf diesen hausen. Der Großteil wird mit Ubuntu betrieben, nur ist da von 12.04 bis 18.04 (LTS) alles enthalten.
Ein jüngeres Beispiel ist eben ein marodes 14.04-Cluster auf dem ein altes DBMS läuft das mangels Zeit / Arbeitskräfte und der wenigen Leute die vorhanden sind schlicht die Erfahrung fehlt, keiner das "Ding" anrühren will.
nezzcarth hat geschrieben: Samstag 19. Januar 2019, 13:15Die Beschränkung auf bestimmte Distributionen hat ja schon den Vorteil, dass man für konkrete Plattformen entwickeln kann. Nachteilig ist sicher, dass gerade die für den produktiven Betrieb beliebten "Enterprise Distributionen" oft eher veraltete Software mitbringen (Centos/RHEL), oder die Paketauswahl überschaubar ist (SLES). Ein aktuelles Django 2.X wäre z.B. unter CentOS 7 im Auslieferungszustand mit Postgres und Python 3 nicht lauffähig. Da muss man sich dann anders behelfen, insb. wenn externe Repos vermieden werden sollen. Container (Docker, Systemd-Nspawn, ...) sind da schon praktisch. Zwar hat man dann streng genommen meistens doch wieder eine zusätzliche Distribution, aber irgendwelche Kompromisse muss man wohl immer machen.
Ich glaube dass man sich in meinem Beispiel genau die Vorteile ggü. Enterprise Distributionen zu Nichte macht, in dem man sich nur der Standard-Paketquellen bedient und keine aktuelle Software zur Entwicklung moderner, robuster und wartbarer Software bereitstellt.

AFAIK spricht nichts dagegen Python3.4.x - 3.7.x selbst zu kompilieren und in einer dedizierten Paketverwaltung zur Verfügung zu stellen. Damit wären ungleich viele Probleme bei der Entwicklung erschlagen. Egal ob das jetzt Ubuntu 12.04, 18.04 oder weiß der Geier was, ist.
When we say computer, we mean the electronic computer.
Antworten