Suche Ideen zu Verteilung von Updates

[OnDemand]

Hallo zusammen,

ich plane grad, wie ich Updates an die User verteile und würde mich freuen wenn ihr etwas Input geben könntet.

Ich habe : Eine Sring Boot + Vaadin App welcher auf VMs läuft (Je User eine kleine VM) darauf wird das jar geladen über ein systemctl service namens app.service

Dazu habe ich auf jeder VM ein updateApp.service dieser soll in der Lage sein die Hautpapp neuzustarten, zu updaten usw. (das ist ein eigenständiges .jar welches API Schnittstellen bereit hält)
Dachte mir wenn die "Hauptapp" abstürzt, muss der User im Kundenportal eine Möglichkeit haben diese über die updateapp.jar wieder neuzustarten (Kundenportal sendet ein POST an update.service welcher dann das app.jar neu startet über Konsolenaufruf.

Um ein Update zu verteilen hab ich mir überlegt, dass mit jedem Kundenlogin unser "Admin-Server" angefragt wird ob ein neues Update vorliegt. Wenn ja soll der User informiert werden nach dem Login und die Möglichkeit bekommen das Update anzustoßen. Intern haz jedes User-System einen Scheduler welcher dann angehalten werden würde, dann würde die updateapp angetriggert werden "mach update" die zieht dann das update und startet die Hauptapp neu.

So erstmal mein Plan, ich möchte mit der updateapp eine alternative haben wie ich die Kundensysteme steuern kann, falls die Hauptapp mal abstürzt (keine Lust auf SSH usw).
Was sagt ihr erstmal im groben dazu?

 

[Robert Zenz]

Der Nachteil eines eigenen Update-Programms ist immer Sicherheit. Das Ding muss die Dateien laden koennen, und dann muss es ins System eingreifen koennen, und das unter Umstaenden auch mit root-Rechten. Das ist halt einfach ein weiterer Weg ins System. Auszerdem ist dieses Programm auch nicht unbedingt fehlerfrei, bedeutet es ist ein weiteres bewegliches Teil (Update des Udpate-Tools?).

Spricht etwas grundsaetzlich dagegen dass ihr das Update fuer den Kunden macht, auf Zuruf beziehungsweise mit Termin-Vereinbarung? Also, ich kenne eure Dienstleistungen bis jetzt nicht, aber es klang immer so als wuerdet ihr die Systeme stellen oder zumindest betreuen, damit wuerde es Sinn machen wenn Updates auch mit eurer Absprache und Zutun eingespielt werden.

Grundsaetzlich laesst sich zum Beispiel so etwas sehr einfach ueber SSH in Masse machen. Ihr hinterlegt einen Public-Key fuer euch auf jeder Maschine, dann faellt auch das eingeben vom Passwort weg. Dann koennt ihr wirklich die Server in Masse updaten.

 

[OnDemand]

Hey! Danke. Stimmt an das automatische verteilen per ssh hab ich noch nicht gedacht. Das machen wir bei anderen Servern auch (für OS updates) aber sollte da sicher auch klappen.

aber damit wäre der Kunde im update zwang. Unter Umständen will er das update nicht zum Zeitpunkt X, sondern selber entscheiden

Serverkollegen sagen, geht über ansible. Sehr gut. Danke für den Tipp, sparst Arbeit
Man würde also SSH Befehle an alle gewählten Server senden.

wie kann ich mir das vorstellen?
1. wget downloadnewjar-url
2. systemctl restart app

 

[Robert Zenz]

Unter Umständen will er das update nicht zum Zeitpunkt X, sondern selber entscheiden

Da ist dann die Frage wie euer Geschaeft funktioniert und was im Update ist und wie oft es Updates gibt (welche auch fuer einzelne Kunden relevant sind). Wie bereits gesagt, es waere ja moeglich das mit euch zu koordinieren, ist natuerlich Arbeit auf eurer Seite, aber wenn ihr es schafft dass zu skripten/automatisieren, ist es auch nicht mehr als ein Knopfdruck/Aufruf um das Update bei diesem Kunden durchzufuehren. Theoretisch koenntet ihr natuerlich auch ein fixes Update-Planung einfuehren. Also jeden zweiten Samstag im Monat gibt es automatische Updates, haendische Updates nach Bedarf und Zuruf (neues Features welches jetzt vom Kunden gebraucht wird, Sicherheits-Update damit der Praktikant nicht mehr den Kontostand vom Chef lesen kann, solche Sachen...).

Wenn ihr Dienstleister seid, also Software, Support, Consulting und die Systeme, wuerde ich nicht unbedingt die Update-Last auf den Kunden abladen wenn man das irgendwie automatisieren oder gezielt handhaben kann, insbesondere nicht wenn ihr viele Updates macht und die Systeme ohnehin in eurem Haus leben. Damit sind Updates dann nicht etwas um was sich der Kunde kuemmern muss, sondern eine Dienstleistung (Feature) von euch. Wenn der Kunde die Systeme selbst betreut, ist das natuerlich eine andere Sache, aber klingt so als wuerdet ihr das machen. Und es klingt auch so als wuerdet ihr euch schnell bewegen wollen und nicht vielleicht zweimal im Jahr ein Update fuer alle machen wollen.

Der Grundsatz "der Kunde soll entscheiden ob er das braucht und jetzt haben will" ist schon gut, eigentlich, aber meiner Erfahrung nach interessiert einen Kunden Updates genau Hintern. Was wichtig ist, ist dass das System laeuft und so funktioniert wie man es braucht. Es gibt natuerlich Ausnahmen, aber der Groszteil der Kunden, Firmen, welche euch dafuer bezahlen das alles laeuft machen das ja nicht aus Spasz, sondern damit alles laeuft. Damit interessiert es den Kunden weniger ob es Updates gibt, sondern ob sich etwas wichtiges am Betrieb aendert. Weil selbst wenn ein Kunde sagt "das Update will ich nicht", aus welchem Grund auch immer, dann macht der Kunde nie wieder Updates weil man an dem einen Update nicht vorbeikommt. Beim naechsten Anruf bei euch, ein halbes Jahr spaeter, wegen Problemen heiszt es dann "ja erstmal Update machen" und dann den Kunden ein halbes Jahr Updates "mal eben so" nachziehen lassen, wo es vielleicht einen guten Grund hatte wieso nicht, kann nicht gut enden denke ich.

Und zuletzt, Updates haben ja auch eine Auswirkung auf den Betrieb. Wenn ein Kunde "unkontrolliert" Updates machen kann, machen die das vielleicht am Mittwoch um 11:00 weil es ihnen in den Kram passt...aber eventuell passt das nicht zum Betrieb ("Okay, das Formular an welchem ich jetzt 10 Minuten getippt habe ist weg...ich ruf mal bei der Firma an").

 

[kneitzel]

Prinzipiell kann man für sowas natürlich auch bestehende Tools nehmen ...

Serverkollegen sagen, geht über ansible.

Wenn schon entsprechende Tools im Einsatz sind, dann würde ich auf diese setzen soweit möglich.

Ebenso würde ich die befragen, die damit etwas machen sollen. Du willst doch Software Entwickeln. Also irgendwelche Kollegen werden da dann doch die Geräte warten. Daher ist die Frage doch eher, was die Kollegen, die die Maintenance machen, ggf. brauchen. Reicht da schon etwas Software, was wann zu tun ist? Oder brauchen sie ggf. wirklich irgendwelche Tools.

Aber so Tools arten dann mit der Zeit auch schnell aus. Das ist mit ein Grund, wieso ich immer schauen würde, was es denn da so fertiges gibt.

 

[OnDemand]

Wow vielen Dank! Das hilft sehr weiter. Es ist in der Tat so, dass neue Features manche Kunden nicht interessiert, es aber nicht schlimm ist wenn es per Update eingespielt wurde wir möchten einmal in der Woche, spätestens alle zwei Wochen ein Update einspielen.

Wenn ein Kunde ein halbes Jahr keine Updates eingespielt hat, weil er keine Lust oder kein Bedarf hatte, ist es wichtig dass wir dann das Problem haben und alle Updates nach schieben müssen. Allein dieser Grund macht es sinnvoll die Updates automatisch zu verteilen, dann können wir einen fixen Tag in der Woche nachts oder früh am Morgen die Updates automatisch an die Kunden verteilen

 

[Robert Zenz]

wie kann ich mir das vorstellen?
1. wget downloadnewjar-url
2. systemctl restart app

Wahrscheinlich eher

1. scp neues-update.jar server:/path/to/app-new.jar
2. ssh Sitzung auf
   1. stop app
   2. mv neues-update.jar app.jar
   3. start app

Aber wie @kneitzel sagt, wenn du nicht derjenige bist der sich darum kuemmert, unbedingt die einbinden die das machen muessen. Kommunikation ist hier sehr wichtig, lieber einen zuviel damit belaestigen, der anschlieszen vergessen muss e sgehoert zu haben, als einen zu wenig, und dann einen Server-Admin vor vollendete Tatsachen stellen die gar nicht ins Konzept passen.

 

[sascha-sphw]

Wenn das doch eh in einer VM läuft, hast Du schonmal über Docker Cluster o.ä. nachgedacht? Ich habe das selbst noch nicht gemacht, aber ich stelle mir das damit viel einfacher vor.