Hallo,
salt-stack zeigt mir nicht stdout/stderr des dpkg-Aufrufs an.
Es kommt zu einem Fehler, aber ich habe keine Ahnung was los ist.
Was tun?
Ich habe hier einen Wrapper geschrieben, der eine Log-Datei erzeugt, und der Aufrufer bekommt gar nicht mit, dass er nicht dpkg sondern meinen Wrapper aufruft. Funktioniert mit kleinen Anpassungen für alle Befehle, nicht nur dpkg.
Ich bin froh so die Ursache des Fehlers gefunden zu haben.
Hier der Code: https://github.com/guettli/wrap_and_log_calls
Eins ist klar. Salt-stack ist großer Mist. Das nächste mal nehme ich Ansible.
Feedback ist willkommen, Thomas
Thomas Güttler guettliml@thomas-guettler.de (Fr 30 Aug 2019 17:42:59 CEST):
Ich bin froh so die Ursache des Fehlers gefunden zu haben. Hier der Code: https://github.com/guettli/wrap_and_log_calls
Ich verstehe nicht viel von Py, aber es sieht mir so aus, als wenn Du erst die Daten sammelst und dann ins Log schreibst. Ist das gut? Warum nicht in der While True Schleife nach dem select gleich ins Log schreiben, was Du gelesen hast?
Oder noch besser, stdout und stderr das Prozesses auf den fd des Logfiles legen und dann exec des gewünschten Kommandos.
Analog zu
#!/bin/sh exec "$@" 1>logfile 2>&1
oder gleich so wie diese zwei Zeilen. Was habe ich verpasst, das Dein Script mehr macht (ausser, daß er noch Blümchen dran malt mit Datum und so und in der Ausgabe trennt nach stderr und stdout. Letzteres Feature hättest Du auf der Konsole auch nicht, wenn beide Datenströme direkt dorthin gehen.)
Da geht vielleicht das hier:
#!/bin/bash exec 3>/tmp/log exec "$@" 1> >(sed -u 's/^/out: /' >&3) 2> >(sed -u 's/^/err: /' >&3)
Man kann auch noch den FD 3 einsparen.
-- Heiko
Am 30.08.19 um 23:24 schrieb Heiko Schlittermann:
Thomas Güttler guettliml@thomas-guettler.de (Fr 30 Aug 2019 17:42:59 CEST):
Ich bin froh so die Ursache des Fehlers gefunden zu haben. Hier der Code: https://github.com/guettli/wrap_and_log_calls
Ich verstehe nicht viel von Py, aber es sieht mir so aus, als wenn Du erst die Daten sammelst und dann ins Log schreibst. Ist das gut? Warum nicht in der While True Schleife nach dem select gleich ins Log schreiben, was Du gelesen hast?
Oder noch besser, stdout und stderr das Prozesses auf den fd des Logfiles legen und dann exec des gewünschten Kommandos.
Analog zu
#!/bin/sh exec "$@" 1>logfile 2>&1oder gleich so wie diese zwei Zeilen. Was habe ich verpasst, das Dein Script mehr macht (ausser, daß er noch Blümchen dran malt mit Datum und so und in der Ausgabe trennt nach stderr und stdout. Letzteres Feature hättest Du auf der Konsole auch nicht, wenn beide Datenströme direkt dorthin gehen.)
Zum einen will ich die Parent-Prozesse sehen. Also nicht den einen, sondern alle Elternprozesse bis ganz nach oben.
Ich habe die Befürchtung, dass `exec "$@"` zwar meist funktioniert, aber es Sonderfälle gibt, bei denen es nicht klappt. Wenn zB das Argument ein Dollar, Semikolon oder Newlinezeichen enthält.
Wenn ich `#!/bin/sh` sehe, dann werde ich total nervös. Dass kann ja alles mögliche sein. Eine Bash, eine Dash, unter Solarix/AIX noch mal etwas anderes.
stdout/stderr sollen ausgegeben getrennt ausgegeben werden, nicht gemeinsam.
Außerdem ist die Dopplung des Stroms nötig. Also ins Logfile und auf stdout/stderr (zB mit "tee").
Da geht vielleicht das hier:
#!/bin/bash exec 3>/tmp/log exec "$@" 1> >(sed -u 's/^/out: /' >&3) 2> >(sed -u 's/^/err: /' >&3)Man kann auch noch den FD 3 einsparen.
Obige Zeile verstehe ich nicht mehr. Ich schreibe seit langem keine Shell-Scripte mehr.
Vermutlich wird das zeilenweise gepuffert. Es gibt aber Aufrufer, die wollen zB den Fortschrittsbalken auslesen um den dann schön in einer GUI anzuzeigen. Dafür darf der Wrapper nicht puffern
Ich bin mir sicher, dass es möglich ist, dass auch in der Shell zu lösen.
Gruß, Thomas
Thomas Güttler guettliml@thomas-guettler.de (Mo 02 Sep 2019 09:15:07 CEST):
oder gleich so wie diese zwei Zeilen. Was habe ich verpasst, das Dein Script mehr macht (ausser, daß er noch Blümchen dran malt mit Datum und so und in der Ausgabe trennt nach stderr und stdout. Letzteres Feature hättest Du auf der Konsole auch nicht, wenn beide Datenströme direkt dorthin gehen.)
Zum einen will ich die Parent-Prozesse sehen. Also nicht den einen, sondern alle Elternprozesse bis ganz nach oben.
Aha, das habe ich in Deinem Py Script nicht erkannt.
Ich habe die Befürchtung, dass `exec "$@"` zwar meist funktioniert, aber es Sonderfälle gibt, bei denen es nicht klappt. Wenn zB das Argument ein Dollar, Semikolon oder Newlinezeichen enthält.
exec "$@" sollte immer funktionieren, egal, wie die Argumente aussehen, es kommt drauf an, wirklich "$@" zu schreiben, nicht $@ oder '$@' oder auch nicht "$*" bzw. andere Varianten von $*.
Aus bash(1) That is, "$@" is equivalent to "$1" "$2" ...
Wenn ich `#!/bin/sh` sehe, dann werde ich total nervös. Dass kann ja alles mögliche sein. Eine Bash, eine Dash, unter Solarix/AIX noch mal etwas anderes.
Das sollte eine Bourne-Shell sein und das, was ich da als Beispiel hatte, sollte(!) mit jeder Bourne-Shell tun, egal wie oft die wiederbelebt wurde. Das schöne an Bournce-Shell-Skripten ist ja, daß die überall gehen ;), wenn man sich diszipliniert ;)
stdout/stderr sollen ausgegeben getrennt ausgegeben werden, nicht gemeinsam. Außerdem ist die Dopplung des Stroms nötig. Also ins Logfile und auf stdout/stderr (zB mit "tee").
Das kannst Du mit dem Bash-Beipiel von mir auch haben:
- exec 3>/tmp/log + exec 3> >(tee /tmp/log)
Da geht vielleicht das hier:
#!/bin/bash exec 3>/tmp/log exec "$@" 1> >(sed -u 's/^/out: /' >&3) 2> >(sed -u 's/^/err: /' >&3)Man kann auch noch den FD 3 einsparen.
Obige Zeile verstehe ich nicht mehr. Ich schreibe seit langem keine Shell-Scripte mehr.
Ja, letztlich solltest Du es mit der Umgebung lösen, die Dir vertraut ist, aber ich wollte nur zeigen, daß heute viele alte Probleme mit Overkill gelöst werden, weil die alten Lösungen für die alten Probleme vergessen werden.
Vermutlich wird das zeilenweise gepuffert. Es gibt aber Aufrufer, die wollen zB den Fortschrittsbalken auslesen um den dann schön in einer GUI anzuzeigen. Dafür darf der Wrapper nicht puffern
Dein Wrapper puffert - wenn ich es richtig gesehen habe - noch mehr als nur zeilenweise. Oder habe ich die Stelle verpasst, wo es nach dem Lesen aus dem Select sofort wieder auf den entsprechenden Kanal rausgeschrieben wird?
„Mein“ Wrapper puffert zeilenweise, ja, weil sonst die Ausgabe mit den Präfixen durcheinander gerät.
Wenn Aufrufer sich auf den Fortschrittsbalken verlassen, sind sie arm. Das aufgerufene Programm könnte in Abwesenheit eines Terminals beschließen, gar keinen Balken zu malen.
Aber egal, wie Du es löst, Du solltest darauf verzichten, die erzeugte Ausgabe erst komplett in einem Dictionary zu speichern und anschließend auszugeben, es gibt keinen Grund dafür. Du kannst die gelesenen Daten sofort verarbeiten. Für die Ausgabe in das File könntest Du vielleicht kontrollieren, ob eine Zeile komplett ist und wenigstens so lange puffern, aber dann raus damit.
Die Annahme, daß die komplette Ausgabe des Child-Prozesses in den RAM+Swap passen wird, ist optimistisch. Assumptions are the mother of all fuck-ups.
Best regards from Dresden/Germany Viele Grüße aus Dresden Heiko Schlittermann -- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
Hi Heiko und andere,
Am 02.09.19 um 13:12 schrieb Heiko Schlittermann:
Dein Wrapper puffert - wenn ich es richtig gesehen habe - noch mehr als nur zeilenweise. Oder habe ich die Stelle verpasst, wo es nach dem Lesen aus dem Select sofort wieder auf den entsprechenden Kanal rausgeschrieben wird?
Der Aufrufer des Wrappers sieht keinen Unterschied. Die Zeichen kommen zeichenweise. Die Ausgabe für das Log-File wird gepuffert. Das ist für meinen Zweck voll ok.
„Mein“ Wrapper puffert zeilenweise, ja, weil sonst die Ausgabe mit den Präfixen durcheinander gerät.
Wenn Aufrufer sich auf den Fortschrittsbalken verlassen, sind sie arm. Das aufgerufene Programm könnte in Abwesenheit eines Terminals beschließen, gar keinen Balken zu malen.
Der Code des Aufrufer, der den Fortschrittsbalken liest ist nicht von mir, und lässt sich schwer ändern. Ist eben so.
Aber egal, wie Du es löst, Du solltest darauf verzichten, die erzeugte Ausgabe erst komplett in einem Dictionary zu speichern und anschließend auszugeben, es gibt keinen Grund dafür. Du kannst die gelesenen Daten sofort verarbeiten. Für die Ausgabe in das File könntest Du vielleicht kontrollieren, ob eine Zeile komplett ist und wenigstens so lange puffern, aber dann raus damit.
Ich habe meinen Anwendungsfall gelöst und da passt alles prima in den RAM. Aber ich habe deine Bedenken verstanden. Prinzipiell könnten auch mehrere Gigabytes über stdout raus gehen.
Manchmal denke ich mir, dass vieles deutlich einfacher wäre, wenn es nur stdout geben würde, und nicht noch stderr. Diese zwei Ströme machen es manchmal nervig.
Gruß, Thomas
Manchmal denke ich mir, dass vieles deutlich einfacher wäre, wenn es nur stdout geben würde, und nicht noch stderr. Diese zwei Ströme machen es manchmal nervig.
Du meinst das nicht ernst, oder :)
Genau diese zwei Ströme sind genial. Woher kannst Du sonst Betriebsdaten von Fehlermeldungen unterscheiden?
</etc/hosts grep -P '*' | wc -l # eigener Datenstrom für die Fehler vs </etc/hosts grep -P '*' |& wc -l # alles zusammen
Ich bin kein Nachrichtentechniker, geschweige denn Informatiker, aber in-band und out-of-band signallig kommen mir da in den Sinn. Ob das hier paßt, weiß ich nicht. Aber die Ausgabeströme zu verwursten kommt mir sehr falsch vor. Denn dadurch verlierst Du Information, die Du später gut brauchen könntest.
Andere non-shell Beispiele:
# C errno = 0; // to be safe int d = get_delta(); // how to declare failure? if (errno) perror("delta")
# Perl $d = get_delta(); # return undef on failure, details in $@ if (not defined $d) { die $@ };
# Go d, err := get_delta() // return err != nil on error if err != nil { fmt.Fatal(err) }
Du schlägst gerade etwas vor, was dem von „C“ entspricht. (Nicht falsch verstehen, ich finde „C“ eine super Sprache, sollte jeder lernen, der was mit Programmieren tut.)
-- Heiko
Heiko Schlittermann hs@schlittermann.de (Mi 04 Sep 2019 16:45:03 CEST):
Manchmal denke ich mir, dass vieles deutlich einfacher wäre, wenn es nur stdout geben würde, und nicht noch stderr. Diese zwei Ströme machen es manchmal nervig.
Du meinst das nicht ernst, oder :)
Diesen Satz würde ich gerne streichen, der Rest aber bleibt. -- Heiko
Am 04.09.19 um 16:45 schrieb Heiko Schlittermann:
Manchmal denke ich mir, dass vieles deutlich einfacher wäre, wenn es nur stdout geben würde, und nicht noch stderr. Diese zwei Ströme machen es manchmal nervig.
Du meinst das nicht ernst, oder :)
Doch, ich meine das Ernst. Continuous Integration hat mich geformt und das ist gut so. Entweder alle Tests sind ok, oder ein oder mehrere Tests sind nicht ok. Das ist binär, da gibt es kein "vielleicht, naja, mal sehen".
Genau diese zwei Ströme sind genial. Woher kannst Du sonst Betriebsdaten von Fehlermeldungen unterscheiden?
Es ist für mich binär: Es war erfolgreich (keine Warnungen) oder es war nicht erfolgreich, dann gibt es (neben der Fehlermeldung) keinen Output (du nennst es Betriebsdaten).
http hat sich durchgesetzt. Da gibt es klare return-codes. Wenn man eine 200 bekommt, dann passt es und ich kann die Nutzdaten verarbeiten. Wenn ich zB eine 404 bekomme, dann weiß ich, dass in den Daten nur eine Fehlermeldung steht, also keine Betriebs/Nutzdaten.
Das ist etwa wie "Shell vs Programmiersprache". Bei der Shell gibt es eine Warnung auf stderr und dann wird lustig die nächste Zeile ausgewertet. Da werde ich zum Autist. So kann ich keine zuverlässigen Produkte erstellen. Die Shell wird bei mir nur noch interaktiv verwendet. Wichtiger sind aber automatisierte Tests. Wenn es davon genug gibt, dann ist es eigentlich egal wie die Implementierung arbeitet.
</etc/hosts grep -P '*' | wc -l # eigener Datenstrom für die Fehlervs </etc/hosts grep -P '*' |& wc -l # alles zusammen
Ich bin kein Nachrichtentechniker, geschweige denn Informatiker, aber in-band und out-of-band signallig kommen mir da in den Sinn. Ob das hier paßt, weiß ich nicht. Aber die Ausgabeströme zu verwursten kommt mir sehr falsch vor. Denn dadurch verlierst Du Information, die Du später gut brauchen könntest.
Andere non-shell Beispiele:
# C errno = 0; // to be safe int d = get_delta(); // how to declare failure? if (errno) perror("delta") # Perl $d = get_delta(); # return undef on failure, details in $@ if (not defined $d) { die $@ }; # Go d, err := get_delta() // return err != nil on error if err != nil { fmt.Fatal(err) }Du schlägst gerade etwas vor, was dem von „C“ entspricht. (Nicht falsch verstehen, ich finde „C“ eine super Sprache, sollte jeder lernen, der was mit Programmieren tut.)
In meinem Kontext werden bei Fehlern in der Regel Exceptions geworfen.
Gruß, Thomas
Thomas Güttler guettliml@thomas-guettler.de (Do 05 Sep 2019 13:01:36 CEST):
Es ist für mich binär: Es war erfolgreich (keine Warnungen) oder es war nicht erfolgreich, dann gibt es (neben der Fehlermeldung) keinen Output (du nennst es Betriebsdaten).
http hat sich durchgesetzt. Da gibt es klare return-codes. Wenn man eine 200 bekommt, dann passt es und ich kann die Nutzdaten verarbeiten. Wenn ich zB eine 404 bekomme, dann weiß ich, dass in den Daten nur eine Fehlermeldung steht, also keine Betriebs/Nutzdaten.
Das verstehe ich jetzt nicht. Command Line Applications haben eine klare Konvention, was Return Codes angeht. Und es liegt an Dir, Daten, die auf STDOUT erscheinen, zu ignorieren und Daten auf STDERR dann als beschreibende Details zum Fehler zu verstehen.
Und es ist gut, daß diese Dinge nicht jeder selbst implementieren muss, sondern daß genau dafür die Shell da ist, die unerwünschte und nicht unterdrückbare Betriebsausgaben nach /dev/null schickt.
Also ich verstehe das Problem noch nicht. Die Unix-Idee mit der Shell gibt mir die Flexibilität und schränkt mich nicht ein.
Das ist etwa wie "Shell vs Programmiersprache". Bei der Shell gibt es eine Warnung auf stderr und dann wird lustig die nächste Zeile ausgewertet. Da werde ich zum Autist. So kann
Shell *ist* Programmiersprache. Was Du mit nächste Zeile meinst, weiß ich jetzt nicht, ob im Script oder bei der Verarbeitung der Daten. Die Shell¹ kennt „set -e“. Sehr nützlich.
ich keine zuverlässigen Produkte erstellen. Die Shell wird bei mir nur noch interaktiv verwendet. Wichtiger sind aber automatisierte Tests. Wenn es davon genug gibt, dann ist es eigentlich egal wie die Implementierung arbeitet.
Ob zuverlässig oder nicht, hängt sicher von der Aufgabenstellung ab. Ich denke, für Dein Eingangsproblem ist die Shell zuverlässig genug :)
Und ich erkenne nicht, wie diese zwei Ausgabekanäle Deine automatisierte Auswertung erschweren - im Gegenteil, sie wird vereinfacht, weil Du eben Betriebsdaten (die Du vielleicht nicht unterdrücken kannst) von anderen Daten trennt.
# C errno = 0; // to be safe int d = get_delta(); // how to declare failure? if (errno) perror("delta") # Perl $d = get_delta(); # return undef on failure, details in $@ if (not defined $d) { die $@ }; # Go d, err := get_delta() // return err != nil on error if err != nil { fmt.Fatal(err) }Du schlägst gerade etwas vor, was dem von „C“ entspricht. (Nicht falsch verstehen, ich finde „C“ eine super Sprache, sollte jeder lernen, der was mit Programmieren tut.)
In meinem Kontext werden bei Fehlern in der Regel Exceptions geworfen.
Das „die()“ im Perl Beispiel kann wie eine Exception behandelt werden. In Go könnte man statt fmt.Fatal() mit panic() arbeiten, aber man hat da eine etwas andere Einstellung zu Fehlern. Nur die wirklichen „this should not happen“ sollten eine Panic erzeugen, andere sollten als diskreter Fehler an den Aufrufer zurückgeliefert werden. Aber das ist eine andere Baustelle als Dein Eingangsproblem, denke ich.
-- Heiko
Am 05.09.19 um 13:51 schrieb Heiko Schlittermann:
Thomas Güttler guettliml@thomas-guettler.de (Do 05 Sep 2019 13:01:36 CEST):
Es ist für mich binär: Es war erfolgreich (keine Warnungen) oder es war nicht erfolgreich, dann gibt es (neben der Fehlermeldung) keinen Output (du nennst es Betriebsdaten).
http hat sich durchgesetzt. Da gibt es klare return-codes. Wenn man eine 200 bekommt, dann passt es und ich kann die Nutzdaten verarbeiten. Wenn ich zB eine 404 bekomme, dann weiß ich, dass in den Daten nur eine Fehlermeldung steht, also keine Betriebs/Nutzdaten.
Das verstehe ich jetzt nicht. Command Line Applications haben eine klare Konvention, was Return Codes angeht. Und es liegt an Dir, Daten, die auf STDOUT erscheinen, zu ignorieren und Daten auf STDERR dann als beschreibende Details zum Fehler zu verstehen.
Meine Meinung: Ein Ausgabekanal würde das deutlich einfacher machen. Es ist mir aber klar, dass das sich niemals nie mehr ändern wird. Ähnliche wie die Zeichenketten- terminieriung mit \0 in der Programmiersprache C. In meinem Kontext gibt es viel mehr http-Aufrufe als Aufrufe von Subprozessen deren stdout/stderr man auswertet.
Und es ist gut, daß diese Dinge nicht jeder selbst implementieren muss, sondern daß genau dafür die Shell da ist, die unerwünschte und nicht unterdrückbare Betriebsausgaben nach /dev/null schickt.
Linux und Shell sind zwei getrennte Dinge. Dank systemd ist es gar nicht so unvorstellbar einen Server zu betreiben auf der gar keine Shell installiert ist. Fände ich cool.
Also ich verstehe das Problem noch nicht. Die Unix-Idee mit der Shell gibt mir die Flexibilität und schränkt mich nicht ein.
Wenn man einen Subprozess hat und nur einen Kanal hat, dann kann man einfach mit read() lesen und warten bis alles da ist. Bei zwei Kanälen klappt das eben nicht. Da muss man dann mit select oder sonstigen async-io Spaß arbeiten. Alles machbar, aber deutlich mehr Aufwand.
Das ist etwa wie "Shell vs Programmiersprache". Bei der Shell gibt es eine Warnung auf stderr und dann wird lustig die nächste Zeile ausgewertet. Da werde ich zum Autist. So kann
Shell *ist* Programmiersprache. Was Du mit nächste Zeile meinst, weiß ich jetzt nicht, ob im Script oder bei der Verarbeitung der Daten. Die Shell¹ kennt „set -e“. Sehr nützlich.
ich keine zuverlässigen Produkte erstellen. Die Shell wird bei mir nur noch interaktiv verwendet. Wichtiger sind aber automatisierte Tests. Wenn es davon genug gibt, dann ist es eigentlich egal wie die Implementierung arbeitet.
Ob zuverlässig oder nicht, hängt sicher von der Aufgabenstellung ab. Ich denke, für Dein Eingangsproblem ist die Shell zuverlässig genug :)
Und ich erkenne nicht, wie diese zwei Ausgabekanäle Deine automatisierte Auswertung erschweren - im Gegenteil, sie wird vereinfacht, weil Du eben Betriebsdaten (die Du vielleicht nicht unterdrücken kannst) von anderen Daten trennt.
# C errno = 0; // to be safe int d = get_delta(); // how to declare failure? if (errno) perror("delta") # Perl $d = get_delta(); # return undef on failure, details in $@ if (not defined $d) { die $@ }; # Go d, err := get_delta() // return err != nil on error if err != nil { fmt.Fatal(err) }Du schlägst gerade etwas vor, was dem von „C“ entspricht. (Nicht falsch verstehen, ich finde „C“ eine super Sprache, sollte jeder lernen, der was mit Programmieren tut.)
In meinem Kontext werden bei Fehlern in der Regel Exceptions geworfen.
Das „die()“ im Perl Beispiel kann wie eine Exception behandelt werden. In Go könnte man statt fmt.Fatal() mit panic() arbeiten, aber man hat da eine etwas andere Einstellung zu Fehlern. Nur die wirklichen „this should not happen“ sollten eine Panic erzeugen, andere sollten als diskreter Fehler an den Aufrufer zurückgeliefert werden. Aber das ist eine andere Baustelle als Dein Eingangsproblem, denke ich.
Ja, das stimmt.
Gruß, Thomas
-- Heiko
Hallo Thomas,
On Fri, Sep 06, 2019 at 15:31:27 +0200, Thomas Güttler wrote:
Linux und Shell sind zwei getrennte Dinge. Dank systemd ist es gar nicht so unvorstellbar einen Server zu betreiben auf der gar keine Shell installiert ist. Fände ich cool.
Und irgendwann loest systemd dann auch den Kernel ab. Nein danke.
Ein Linux-System ohne Shell ist zwar denkbar, aber sobald auch nur ein Binary (oder eine Library) die libc-Funktionen popen() oder system() verwendet, ist zumindest /bin/sh wieder notwendig.
Und die Vorstellung, etwa Bootprobleme ohne eine Shell zu debuggen, finde ich ziemlich gruselig.
Gruss, Christian
Am 06.09.19 um 15:49 schrieb Christian Perle:
Hallo Thomas,
On Fri, Sep 06, 2019 at 15:31:27 +0200, Thomas Güttler wrote:
Linux und Shell sind zwei getrennte Dinge. Dank systemd ist es gar nicht so unvorstellbar einen Server zu betreiben auf der gar keine Shell installiert ist. Fände ich cool.
Und irgendwann loest systemd dann auch den Kernel ab. Nein danke.
Ich finde systemd super. Und dass es den Kernel ablösen soll, das ist vermutlich nicht von dir ernst gemeint, oder?
Ein Linux-System ohne Shell ist zwar denkbar, aber sobald auch nur ein Binary (oder eine Library) die libc-Funktionen popen() oder system() verwendet, ist zumindest /bin/sh wieder notwendig.
Und die Vorstellung, etwa Bootprobleme ohne eine Shell zu debuggen, finde ich ziemlich gruselig.
Wenn das Image nicht läuft, dann wird ein neues erstellt. Das Image (bzw der Container) wird erstellt, verwendet, verworfen. Es gibt keine Updates mehr.
Also auch wenig Bootprobleme.
Sicherlich wird es noch per Hand gepflegte Linux Installationen geben, aber vieles wird in dem SaaS Sog aufgelöst.
Gruß, Thomas
Thomas Güttler guettliml@thomas-guettler.de (Mo 09 Sep 2019 15:42:44 CEST):
Und die Vorstellung, etwa Bootprobleme ohne eine Shell zu debuggen, finde ich ziemlich gruselig.
Wenn das Image nicht läuft, dann wird ein neues erstellt. Das Image (bzw der Container) wird erstellt, verwendet, verworfen. Es gibt keine Updates mehr.
Soweit die Theroie. Hört sich alles total easy peasy an. Aber z.B. das Debuggen eines Containers, der aus einem minimalistischen Image abgeleitet wurde, ist PITA.
Oder eben mal die Config ändern, um zu gucken, ob der gewünschte Effekt dann eintritt, ist ebenfalls PITA, weil die Config möglicherweise von außen ein r/o bind Mount ist.
Alles *irgendwie* lösbar, ja, aber genau das ist der Unterschied zwischen den Zeitschrifen, die die Manager lesen und die wiedergeben, was da so bei Docker und Co publiziert wird, und der bitteren Realität in der Ebene.
-- Heiko
Am Montag, den 09.09.2019, 15:59 +0200 schrieb Heiko Schlittermann:
Und die Vorstellung, etwa Bootprobleme ohne eine Shell zu debuggen, finde ich ziemlich gruselig.
Wenn das Image nicht läuft, dann wird ein neues erstellt. Das Image (bzw der Container) wird erstellt, verwendet, verworfen. Es gibt keine Updates mehr.
Soweit die Theroie. Hört sich alles total easy peasy an. Aber z.B. das Debuggen eines Containers, der aus einem minimalistischen Image abgeleitet wurde, ist PITA.
Leider ja, eigene Erfahrung. Die Java/Spring Boot-Komponenten können wir gewöhnlich über Java und Remote-Debugging debuggen. Bei allem anderen bricht es sich meist wieder darauf herunter, eine bash an einen laufenden Container zu hängen und zu schauen, was dort drin passiert. Dafür ist das Tooling noch längst nicht dort, wo es sein sollte oder könnte.
Viele Grüße, Kristian
Hallo Thomas,
On Mon, Sep 09, 2019 at 15:42:44 +0200, Thomas Güttler wrote:
Ich finde systemd super. Und dass es den Kernel ablösen soll, das ist vermutlich nicht von dir ernst gemeint, oder?
Nein, damit war nur die Tendenz gemeint, dass systemd immer mehr Dienste assimiliert, die nichts mit einem Initsystem zu tun haben.
Und die Vorstellung, etwa Bootprobleme ohne eine Shell zu debuggen, finde ich ziemlich gruselig.
Wenn das Image nicht läuft, dann wird ein neues erstellt. Das Image (bzw der Container) wird erstellt, verwendet, verworfen. Es gibt keine Updates mehr.
Die IT-Welt besteht nicht nur aus Containern. Ich rede von einem System, das auf wirklicher Hardware laeuft. Das brauchst Du auch, wenn Du Container/VMs/whatever benutzt.
Also auch wenig Bootprobleme.
Nur wenn man sich echte Hardware wegdenkt. Die hoert deswegen aber nicht auf zu existieren.
Sicherlich wird es noch per Hand gepflegte Linux Installationen geben, aber vieles wird in dem SaaS Sog aufgelöst.
Und so kommt Layer ueber Layer, Abstraktion ueber Abstraktion und wenn es irgendwo kracht, lassen sich Fehler kaum noch nachvollziehen. Das KISS-Prinzip, was unixoide Systeme eigentlich ausmacht, wird gerade so richtig verkackt.
So viel schlechte Laune zum Montagabend, Christian
Hoi @all;
da hier gerade eine "Meinungsumfrage" statt findet wollte ich auch mal meine präsentieren.
Ich habe in einem Unternehmen gearbeitet, welches fast ausschliesslich physische Server "vermietet" hat, sprich jeder Server war schlichweg komplett Hardware. Es gar zu diesem Zeipunkt (etwa 2015) auch einige Virtuelle Server, aber die Masse waren Hareware-Server.
Ich habe dieses Konstrukt lieben gelernt und was ebenfalls skeptisch gegenüber Virtuellen Servern (docker gabs damals bestimmt schon, war aber nicht wirklich verbreitet).
Dann habe ich etwa 2016 meine derzeitige Firma gewechselt, wo ca. 95% der Server virtualisiert waren. Ich habe die Vorteile der Virtualisierung (wie auch die Nachteile) kennen gelernt und bin für mich persönlich zum Schluss gekommen, dass Virtualisierung durchaus seine Vorteile hat. Ich habe also diese "andere" Technologie gelernt zu mögen.
Seit geraumer Zeit kommt auch bei uns das Thema "docker" ins Spiel und eine andere Abteilung ist schon deutlich weiter, die arbeiten fast nur mit Docker.
Auch hier lerne ich die Vorteile wie auch die Nachteile (und die gibt es immer) kennen und versuche einen Weg zu finden. Auch bei unseren Docker Containern (mit der hohen Automatisierung) existiert die Idee, diese komplett ohne SSH an den Start zu bringen. Warum? Weil viel Zeit und Know-How in die Container geflossen ist. Die LogFiles werden zentral auf einem Logserver geschrieben werden (wo man mittels Shell noch mit cat / grep / etc. drauf los laufen kann), aber auch das wird mittlerweile durch Splunk ersetze (cat und grep und dergleichen sind zwar mächtige Werkzeuge, aber Splunk auch).
Mit dem Spiel handelt man sich sicherlich neue Probleme ein (wenn ich nur an die Frage denke, die unsere Security gern los lässt: auf welchem Server läuft Software XY; was wir per Container problemlos einzeln konfigurieren können). Aber auch diese sind lösbar.
Was ich damit sagen will ist: Ich unterstütze die "ich will einen Server auf Hardware laufen lassen, VMs sind mir zuwider". Ich kann aber die VM Menschen genau so verstehen. Und die Container Typen auch.
Alles hat seine Vor- und Nachteile. Und in einer "wir müssen schnell auf Änderungen reagieren" Welt (man nennt das heute "agil") muss man halt Kompromisse schliessen.
Also bitte, ärgert Euch gegenseitig nicht. Jeder hat entsprechende Anforderungen an ein Setup, Anforderungen die mit Hardware / VM / Containern unterschiedlich erreichbar sind. Daher sollte jeder für sich selber entscheiden, was für ihn das richtige ist.
Ich persönlich mag auch keine VMs, auch keine Container, aber beide Technologien haben definitiv Ihre Vorteile (und auch Nachteile) und aufgrund der bereits langen Zeit wie sie existieren offensichtlich auch ihre Daseinsberechtigung. Zu Hause kann ich machen, was ich möchte; auf Arbeit habe ich andere Anforderungen, die u.a. mit reiner Hardware oder VMs nicht umsetzbar sind.
Gruß Maddin
Am 09.09.19 um 20:24 schrieb Christian Perle:
Hallo Thomas,
On Mon, Sep 09, 2019 at 15:42:44 +0200, Thomas Güttler wrote:
Ich finde systemd super. Und dass es den Kernel ablösen soll, das ist vermutlich nicht von dir ernst gemeint, oder?
Nein, damit war nur die Tendenz gemeint, dass systemd immer mehr Dienste assimiliert, die nichts mit einem Initsystem zu tun haben.
Und die Vorstellung, etwa Bootprobleme ohne eine Shell zu debuggen, finde ich ziemlich gruselig.
Wenn das Image nicht läuft, dann wird ein neues erstellt. Das Image (bzw der Container) wird erstellt, verwendet, verworfen. Es gibt keine Updates mehr.
Die IT-Welt besteht nicht nur aus Containern. Ich rede von einem System, das auf wirklicher Hardware laeuft. Das brauchst Du auch, wenn Du Container/VMs/whatever benutzt.
Also auch wenig Bootprobleme.
Nur wenn man sich echte Hardware wegdenkt. Die hoert deswegen aber nicht auf zu existieren.
Sicherlich wird es noch per Hand gepflegte Linux Installationen geben, aber vieles wird in dem SaaS Sog aufgelöst.
Und so kommt Layer ueber Layer, Abstraktion ueber Abstraktion und wenn es irgendwo kracht, lassen sich Fehler kaum noch nachvollziehen. Das KISS-Prinzip, was unixoide Systeme eigentlich ausmacht, wird gerade so richtig verkackt.
So viel schlechte Laune zum Montagabend, Christian
Am Montag, den 09.09.2019, 21:45 +0200 schrieb Martin Schuchardt:
Also bitte, ärgert Euch gegenseitig nicht. Jeder hat entsprechende Anforderungen an ein Setup, Anforderungen die mit Hardware / VM / Containern unterschiedlich erreichbar sind. Daher sollte jeder für sich selber entscheiden, was für ihn das richtige ist.
Ack. Ich sehe es (leider) pragmatisch, bzw. muss es so sehen: Mir wäre Bare Metal lieber, aber gegenwärtig ist es nahezu unmöglich, Personal zu bekommen, das imstande und willens ist, Infrastruktur zu administrieren. Mithin dienen die verschiedenen Layers vorrangig als Einkaufsabstraktion, die man versucht, so weit "oben" als möglich zu ziehen, damit das eigene (teure, knappe) Personal sich auf die Dinge fokussieren kann, die sich aus fachlichen Gründen nicht auslagern lassen. Und an dem Punkt ist es im Extremfall eben schon eine Rechnung, ob ich drei Leute brauche, um Linux-Infrastruktur zu betreiben, oder die drei Leute Anwendungen bauen lassen kann, die etwa auf irgendwelchen Droplets bei Digital Ocean laufen.
Viele Grüße, Kristian
Am 09.09.19 um 21:54 schrieb Kristian Rink:
Am Montag, den 09.09.2019, 21:45 +0200 schrieb Martin Schuchardt:
Also bitte, ärgert Euch gegenseitig nicht. Jeder hat entsprechende Anforderungen an ein Setup, Anforderungen die mit Hardware / VM / Containern unterschiedlich erreichbar sind. Daher sollte jeder für sich selber entscheiden, was für ihn das richtige ist.
Ack. Ich sehe es (leider) pragmatisch, bzw. muss es so sehen: Mir wäre Bare Metal lieber, aber gegenwärtig ist es nahezu unmöglich, Personal zu bekommen, das imstande und willens ist, Infrastruktur zu administrieren.
Sehr interessanter Punkt. Der fähige Admin vor Ort, der in einer kleinen Firma tätig ist ... das ist am Aussterben.
Nicht schön, aber nachvollziehbar. Wäre ich Admin (ich bin eher Software-typ), dann würde ich lieber in einer Firma arbeiten die tausend Server hat, nicht nur zwanzig. Also finden die kleinen Firmen keinen fähigen Admin.
Und SaaS ist billig und macht keinen Urlaub.
Wir suchen schon lange einen fähigen Linux-Admin. Aber das ist nicht zu finden. Software-Entwickler findet man eher.
Ich stelle das nur fest und finde es schade. Aber so ist es.
Mithin dienen die verschiedenen Layers vorrangig als Einkaufsabstraktion, die man versucht, so weit "oben" als möglich zu ziehen, damit das eigene (teure, knappe) Personal sich auf die Dinge fokussieren kann, die sich aus fachlichen Gründen nicht auslagern lassen. Und an dem Punkt ist es im Extremfall eben schon eine Rechnung, ob ich drei Leute brauche, um Linux-Infrastruktur zu betreiben, oder die drei Leute Anwendungen bauen lassen kann, die etwa auf irgendwelchen Droplets bei Digital Ocean laufen.
Viele Grüße, Kristian
Gruß, Thomas
Am Dienstag, den 10.09.2019, 12:04 +0200 schrieb Thomas Güttler:
Nicht schön, aber nachvollziehbar. Wäre ich Admin (ich bin eher Software-typ), dann würde ich lieber in einer Firma arbeiten die tausend Server hat, nicht nur zwanzig. Also finden die kleinen Firmen keinen fähigen Admin.
Richtig. In den meisten kleinen Firmen hast Du zudem die Herausforderung, tagtäglich eine nervige Menge an Handarbeit auf dem Schirm zu haben, aber an einer Schwelle, an der sich die Investition in beispielsweise Infrastruktur- und Konfigurationsmanagement, in Dinge wie puppet oder ansible, gerade noch nicht lohnt. Ergebnis: Du bleibst auf ewig verdammt dazu, dort in Handarbeit immer wieder diesselben Probleme zu lösen, die längst besser/robuster/meist auch wirtschaftlicher gelöst sind, nur eben nicht für Organisationen Deiner Größe und Dich als Einzelkämpfer, der dann im schlimmsten Fall (eigenes Erleben) auch schon mal aus dem Urlaub zurückkommt, weil in dem Fileserver das RAID ausgefallen ist und sich niemand, auch von den Dienstleistern drumherum, mit Debian auskennt...
Das Problem ist zudem ja: Es hört bei den Anforderungen, die in 2019 an Infrastruktur stehen, nicht bei dem einen Admin auf. Du brauchst mindestens zwei, weil der eine auch mal Urlaub machen möchte. Und dann hast Du sofort die gesamte Baustelle auf dem Tisch, die sich mit Wissens- und Change-Management beschäftigt, um sicherzustellen, daß die Admins, nun, denselben Wissens-Stand haben, den sie brauchen, um das System betreiben zu können. Das musst Du schaffen, das braucht Geld und Wissen. Und schlimmstenfalls hast Du dann einen komplexen Prozess und zwei Admins, die sich bei Dir langweilen, weil die Handvoll Server im Regelfall laufend genau so viel Aufwand verursacht, daß man es nicht ignorieren kann, aber nicht so viel, daß es die verfügbaren Menschen auslasten, geschweigedenn ganztägig mit halbwegs anspruchsvollen Tätigkeiten versorgen könnte.
Lesenswert dazu (weiß nicht, ob das hier schon mal rumgeflogen ist) ist der Thread von Kristian Köhntopp auf Twitter, siehe dies hier:
https://twitter.com/isotopp/status/1009364595084025856
Wir suchen schon lange einen fähigen Linux-Admin. Aber das ist nicht zu finden. Software-Entwickler findet man eher.
Wir finden leider beides nicht im Moment. :(
Ich nehme dafür bei unseren Marktbegleitern sehr oft wahr, daß dort Leute sind, die ganz massiv und fokussiert auf Kunden losrennen, die sich genau auf ihre Fachdomain konzentrieren, ihren Kram auf AWS oder eben DO deployen und die Energie, die wir selbst noch brauchen, um Infrastruktur zu streicheln, voll und ganz in ihre Produkte stecken können. Ich fürchte, als KMU verliert man dieses Rennen irgendwann.
Viele Grüße, Kristian
Am 10.09.19 um 12:27 schrieb Kristian Rink:
Am Dienstag, den 10.09.2019, 12:04 +0200 schrieb Thomas Güttler:
Nicht schön, aber nachvollziehbar. Wäre ich Admin (ich bin eher Software-typ), dann würde ich lieber in einer Firma arbeiten die tausend Server hat, nicht nur zwanzig. Also finden die kleinen Firmen keinen fähigen Admin.
Richtig. In den meisten kleinen Firmen hast Du zudem die Herausforderung, tagtäglich eine nervige Menge an Handarbeit auf dem Schirm zu haben, aber an einer Schwelle, an der sich die Investition in beispielsweise Infrastruktur- und Konfigurationsmanagement, in Dinge wie puppet oder ansible, gerade noch nicht lohnt. Ergebnis: Du bleibst auf ewig verdammt dazu, dort in Handarbeit immer wieder diesselben Probleme zu lösen, die längst besser/robuster/meist auch wirtschaftlicher gelöst sind, nur eben nicht für Organisationen Deiner Größe und Dich als Einzelkämpfer, der dann im schlimmsten Fall (eigenes Erleben) auch schon mal aus dem Urlaub zurückkommt, weil in dem Fileserver das RAID ausgefallen ist und sich niemand, auch von den Dienstleistern drumherum, mit Debian auskennt...
Das Problem ist zudem ja: Es hört bei den Anforderungen, die in 2019 an Infrastruktur stehen, nicht bei dem einen Admin auf. Du brauchst mindestens zwei, weil der eine auch mal Urlaub machen möchte. Und dann hast Du sofort die gesamte Baustelle auf dem Tisch, die sich mit Wissens- und Change-Management beschäftigt, um sicherzustellen, daß die Admins, nun, denselben Wissens-Stand haben, den sie brauchen, um das System betreiben zu können. Das musst Du schaffen, das braucht Geld und Wissen. Und schlimmstenfalls hast Du dann einen komplexen Prozess und zwei Admins, die sich bei Dir langweilen, weil die Handvoll Server im Regelfall laufend genau so viel Aufwand verursacht, daß man es nicht ignorieren kann, aber nicht so viel, daß es die verfügbaren Menschen auslasten, geschweigedenn ganztägig mit halbwegs anspruchsvollen Tätigkeiten versorgen könnte.
Lesenswert dazu (weiß nicht, ob das hier schon mal rumgeflogen ist) ist der Thread von Kristian Köhntopp auf Twitter, siehe dies hier:
Ja, so sieht es leider aus.
Wir suchen schon lange einen fähigen Linux-Admin. Aber das ist nicht zu finden. Software-Entwickler findet man eher.
Wir finden leider beides nicht im Moment. :(
Ich nehme dafür bei unseren Marktbegleitern sehr oft wahr, daß dort Leute sind, die ganz massiv und fokussiert auf Kunden losrennen, die sich genau auf ihre Fachdomain konzentrieren, ihren Kram auf AWS oder eben DO deployen und die Energie, die wir selbst noch brauchen, um Infrastruktur zu streicheln, voll und ganz in ihre Produkte stecken können. Ich fürchte, als KMU verliert man dieses Rennen irgendwann.
Wenn man das mit PKWs vergleicht: Fast jede Firma hat einen Furhpark.
Aber kaum eine Firma hat einen KFZ-Mechaniker eingestellt.
Die Kosten der Vertragswerkstatt sind hoch, aber es ist günstiger
als Personal.
Das passiert gerade auch in der IT. SaaS wie office365 ziehen
Aufgaben in die Zentrale.
Etwas gruselig ist das zB bei DATEV. Die Steuerdaten
von verdammt vielen Bürgern in einem Rechenzentrum.....
Ein befreundeter Steuerberater schwärm: Kein Backup mehr
machen, keine Updates mehr einspielen, günstig ist es auch,
nur ein PC mit Internetverbindung ist nötig.
Gruß,
Thomas
Am Mittwoch, den 11.09.2019, 08:19 +0200 schrieb Thomas Güttler Lists:
Wenn man das mit PKWs vergleicht: Fast jede Firma hat einen Furhpark. Aber kaum eine Firma hat einen KFZ-Mechaniker eingestellt. Die Kosten der Vertragswerkstatt sind hoch, aber es ist günstiger als Personal.
Ja, diese Analogie geistert mir auch immer mal durch den Kopf. Ich sehe dort aber nicht mal nur "günstiger als Personal": Das Modell skaliert besser, noch mehr, wenn Dir der Fuhrpark nicht mehr gehört und Du die Autos mietest. Wenn ich zwei Autos mehr brauche, habe ich die zur Hand und bezahle sie. Wenn nicht, bezahle ich sie auch nicht.
Wir hosten VMs auf einer private cloud eines Dresdner Anbieters. Dort gibt es CPU, RAM, Storage als Parameter, plus noch optional Service- Level. Das ist im Wesentlichen linear und vergleichsweise dynamisch: Wenn ich mehr VMs brauche, bezahle ich mehr. Wenn ich weniger VMs brauche, zahle ich weniger (Hardware, Wartung, Klima, Personal eingeschlossen). Damit kann ich, wenn weniger Last anliegt und/oder meine Infrastruktur nach Optimierung kleiner wird, auch mal Kosten reduzieren. Mit gekauftem Blech und fest angestellten Administratoren fällt das eher schwer.
Insgesamt halte ich das auch nichtmal für schlecht, auch als Techie nicht. Ich backe auch (im Regelfall) mein Brot nicht mehr selbst, pflanze den Hopfen für mein Bier nicht selbst an - Spezialisierung gibt es überall, und im Allgemeinen nehmen wir die selbstverständlich hin. Und aus anderer Perspektive (mit Blick auf Energieverbrauch und Klimawandel) sehe ich, was etwa Google in ihren Rechenzentren bezüglich Energie-Effizienz tun, und weiß, daß ich davon als KMU *meilenweit* entfernt, im Vergleich dazu vermutlich schreiend ineffizient bin.
Aber (siehe auch das DATEV-Thema) es braucht, glaube ich, gleichermaßen mehr und stringentere Regeln, wie das zu funktionieren hat. Und es braucht möglicherweise auch einen größeren, anderen Markt. Mein größtes Problem damit ist, daß, wer von "Cloud" spricht, im Wesentlichen über Azure, AWS et al mit den dortigen Möglichkeiten spricht. Das ist gänzlicher Kontrollverlust bei im Allgemeinen maximaler Abhängigkeit. Und dort wundert mich dann und wann auch, daß das leichthin durch Risiko-Betrachtungen rutscht bzw. einfach so in Kauf genommen wird.
Anyway, genug gerantet für den Morgen. :) Viele Grüße, Kristian
Hallo Christian,
Am 09.09.19 um 20:24 schrieb Christian Perle:
Hallo Thomas,
On Mon, Sep 09, 2019 at 15:42:44 +0200, Thomas Güttler wrote:
Ich finde systemd super. Und dass es den Kernel ablösen soll, das ist vermutlich nicht von dir ernst gemeint, oder?
Nein, damit war nur die Tendenz gemeint, dass systemd immer mehr Dienste assimiliert, die nichts mit einem Initsystem zu tun haben.
Und die Vorstellung, etwa Bootprobleme ohne eine Shell zu debuggen, finde ich ziemlich gruselig.
Wenn das Image nicht läuft, dann wird ein neues erstellt. Das Image (bzw der Container) wird erstellt, verwendet, verworfen. Es gibt keine Updates mehr.
Die IT-Welt besteht nicht nur aus Containern. Ich rede von einem System, das auf wirklicher Hardware laeuft. Das brauchst Du auch, wenn Du Container/VMs/whatever benutzt.
Also auch wenig Bootprobleme.
Nur wenn man sich echte Hardware wegdenkt. Die hoert deswegen aber nicht auf zu existieren.
Für mich existiert an vielen Bereichen Hardware nicht mehr. Und das finde ich super. Unsere Software läuft als SaaS im Rechenzentrum des Kunden. Der hat VMWare und wir nutzen dort die VM. Das läuft seit Jahren super stabil. Sicherlich existiert die Hardware irgendwo. Aber dafür ist jemand anderes verantwortlich.
Sicherlich wird es noch per Hand gepflegte Linux Installationen geben, aber vieles wird in dem SaaS Sog aufgelöst.
Und so kommt Layer ueber Layer, Abstraktion ueber Abstraktion und wenn es irgendwo kracht, lassen sich Fehler kaum noch nachvollziehen. Das KISS-Prinzip, was unixoide Systeme eigentlich ausmacht, wird gerade so richtig verkackt.
Es gibt getrennte Verantwortungsbereiche: Hardware macht Firma x, Linux-VM verwalten macht Firma Y. Es ist auch schön, wenn man mal nicht für alles verantwortlich ist.
So viel schlechte Laune zum Montagabend, Christian
Warum schlechte Laune? Es gibt unterschiedliche Meinungen. Aber das ist doch kein Grund für schlechte Laune, oder?
Gruß, Thomas
Hallo Thomas,
On Tue, Sep 10, 2019 at 11:59:05 +0200, Thomas Guettler wrote:
Also auch wenig Bootprobleme.
Nur wenn man sich echte Hardware wegdenkt. Die hoert deswegen aber nicht auf zu existieren.
Fuer mich existiert an vielen Bereichen Hardware nicht mehr. Und das finde ich super. Unsere Software laeuft als SaaS im Rechenzentrum des Kunden. Der hat VMWare und wir nutzen dort die VM. Das laeuft seit Jahren super stabil. Sicherlich existiert die Hardware irgendwo. Aber dafuer ist jemand anderes verantwortlich.
Die genauen Verantwortlichkeiten werden im Fehlerfall vom Kunden aber nicht unbedingt erkannt. Wenn die VM oder das System, auf dem sie laeuft ein Problem hat, koennten Support-Ticket oder Bugreport trotzdem bei Dir landen. Dann geht eine Menge Zeit fuer (erfolgloses) Nachstellen des Fehlers mit Eurer Software drauf, bevor der Kunde dann irgendwann kleinlaut zugibt, dass es "vielleicht" doch an seiner Infrastruktur liegt, die durch VMs/Container und Orchestrierung so komplex geworden ist, dass er sie nicht mehr ueberblickt.
Wir verwenden auch VMs, aber hauptsaechlich zu Testzwecken. Das darin getestete System muss im spaeteren Einsatz beim Kunden aber auf echter Hardware laufen, aus Performancegruenden und damit es die alleinige Kontrolle ueber die Hardware hat.
Es gibt getrennte Verantwortungsbereiche: Hardware macht Firma x, Linux-VM verwalten macht Firma Y. Es ist auch schoen, wenn man mal nicht fuer alles verantwortlich ist.
Solange dabei Daten verarbeitet werden, fuer die es egal ist, ob sie wegkommen, mag das funktionieren. Immerhin gibt man durch solche Konstrukte die Daten aus der Hand.
Mich stoeren nicht VMs/Container an sich, sondern die oft vertretene Ansicht, dass man Systeme/Services gar nicht mehr anders betreiben kann -- oder "weil man das jetzt so macht".
Gruss, Christian
Hallo Christian,
Am 10.09.19 um 17:01 schrieb Christian Perle:
Hallo Thomas,
On Tue, Sep 10, 2019 at 11:59:05 +0200, Thomas Guettler wrote:
Also auch wenig Bootprobleme.
Nur wenn man sich echte Hardware wegdenkt. Die hoert deswegen aber nicht auf zu existieren.
Fuer mich existiert an vielen Bereichen Hardware nicht mehr. Und das finde ich super. Unsere Software laeuft als SaaS im Rechenzentrum des Kunden. Der hat VMWare und wir nutzen dort die VM. Das laeuft seit Jahren super stabil. Sicherlich existiert die Hardware irgendwo. Aber dafuer ist jemand anderes verantwortlich.
Die genauen Verantwortlichkeiten werden im Fehlerfall vom Kunden aber nicht unbedingt erkannt. Wenn die VM oder das System, auf dem sie laeuft ein Problem hat, koennten Support-Ticket oder Bugreport trotzdem bei Dir landen. Dann geht eine Menge Zeit fuer (erfolgloses) Nachstellen des Fehlers mit Eurer Software drauf, bevor der Kunde dann irgendwann kleinlaut zugibt, dass es "vielleicht" doch an seiner Infrastruktur liegt, die durch VMs/Container und Orchestrierung so komplex geworden ist, dass er sie nicht mehr ueberblickt.
Ja, die Bedenken kann ich nachvollziehen. Hatten wir auch schon.
Der VM wird bei einem Update weniger RAM/CPU gegeben und
dann wundern sich die Andwender warum alles so träge ist.
Klar, dass die zuerst bei einem anrufen. Der Anwender kennt/versteht
diese Trennung nicht und das ist auch voll ok.
Wir setzen etckeeper ein und haben ein Tool, dass die Parameter
der VM in ein Verzeichnis in /etc/ schreibt. So werden per git/etckeeper
Änderungen an der Virtualisierung protokolliert.
Nur die IO-Performance ist noch nicht festgezurrt.
Wir verwenden auch VMs, aber hauptsaechlich zu Testzwecken. Das darin getestete System muss im spaeteren Einsatz beim Kunden aber auf echter Hardware laufen, aus Performancegruenden und damit es die alleinige Kontrolle ueber die Hardware hat.
Klar, wenn deine Anforderungen so aussehen - wenn der Kunde
das so will. Bei uns ist es genau anders: Die Kunden haben
ein kleines Rechenzentrum und wollen Virtualisierung.
Es gibt getrennte Verantwortungsbereiche: Hardware macht Firma x, Linux-VM verwalten macht Firma Y. Es ist auch schoen, wenn man mal nicht fuer alles verantwortlich ist.
Solange dabei Daten verarbeitet werden, fuer die es egal ist, ob sie wegkommen, mag das funktionieren. Immerhin gibt man durch solche Konstrukte die Daten aus der Hand.
Das Wort "wegkommen" kann hier mind zwei Bedeutungen haben.
Du meinst sicherlich "Datendiebstahl" und nicht Ausfallsicherheit/Backup.
Der Kunde ist König. Du handelst anders als ich, weil wir unterschiedliche Kunden haben.
Mich stoeren nicht VMs/Container an sich, sondern die oft vertretene Ansicht, dass man Systeme/Services gar nicht mehr anders betreiben kann -- oder "weil man das jetzt so macht".
Virtualisierung ist aus meiner Sicht kein Hype mehr. Hype ist nun Kubernetes und Container.
Und da bin ich aktuell auch sehr entspann. In meinem aktuellen Kontext kommen
wir auch prima ohne Container aus.
Wichtig ist ein ordenliches CI mit ausreichend vielen Tests und auch
dem Verstänis/Willen automatisiertes Testen als Teil der täglichen Arbeit
anzusehen.
Gruß,
Thomas
Hallo Thomas,
On Wed, Sep 11, 2019 at 08:11:15 +0200, Thomas Güttler Lists wrote:
Wir setzen etckeeper ein und haben ein Tool, dass die Parameter der VM in ein Verzeichnis in /etc/ schreibt. So werden per git/etckeeper Änderungen an der Virtualisierung protokolliert.
Das ist schonmal gut.
Solange dabei Daten verarbeitet werden, fuer die es egal ist, ob sie wegkommen, mag das funktionieren. Immerhin gibt man durch solche Konstrukte die Daten aus der Hand.
Das Wort "wegkommen" kann hier mind zwei Bedeutungen haben.
Sorry, das war CCC-Sprech. Ja, gemeint war Datendiebstahl.
Gruss, Christian
lug-dd@mailman.schlittermann.de
-
Christian Perle -
Heiko Schlittermann -
Kristian Rink -
Martin Schuchardt -
Thomas Güttler -
Thomas Güttler Lists