Update Warnung: Abschaltbar??

[Codierknecht]

@haus-automatisierung sagte in Update Warnung: Abschaltbar??:

aber an der Stelle sollte der js-controller im Docker-Umfeld apt in Ruhe lassen

Ich kann Dir nicht ganz folgen.
Meinst Du damit, dass im Docker-Umfeld OS-Updates gar nicht gemeldet werden sollten?

Fände ich suboptimal. Dann kriegt der Anwender das ja wieder nicht mit und lässt seinen Container auf Basis eines veralteten Image verlottern.

Edit
Eine denkbare Alternative wäre dann, auf neue Images hinzuweisen.

[haus-automatisierung]

@codierknecht Korrekt, weil man dann den Stand des Images verändert. Und genau darum geht es doch bei Docker: Eine klar definierte Umgebung.

Manuelle Updates von apt Pakten im Container sind somit gegen das Konzept.

[Codierknecht]

@haus-automatisierung sagte in Update Warnung: Abschaltbar??:

Manuelle Updates von apt Paketen im Container sind somit gegen das Konzept.

Wer verwaltet den Controller? @foxriver76 ?
Dann wäre im Docker-Umfeld vielleicht eine generische Warnung denkbar:
"Für Deine Umgebung sind neue/aktualisierte Pakete verfügbar. Schau nach, ob es eine neuere Version Deines Docker-Image gibt"

[OliverIO]

@codierknecht sagte in Update Warnung: Abschaltbar??:

Der Maintainer gibt regelmäßig aktualisierte Versionen des Image heraus. Die sollte man dann auch verwenden.

Bei iobroker - docker installationen sollte das system dann idealerweise auf neue versionen des buanet images hinweisen und nicht auf neue pakete. da kann der anwender uU ja nix machen solange keine neue version des images herausgegeben wird.

Docker ist nicht zum dauerhaften Betrieb eines Systems gedacht.

das würde ich so nicht unterschreiben wollen. eigentlich schon, aber ich bin mir sicher das du es ein wenig anders gemeint hast wie es jetzt hier steht. mit docker ist es viel einfacher eine applikation mit dazugehörendem image komplett neu aufzubauen. darüber hinaus kann man dann in großen umgebungen das identische system dann entsprechend den anforderung, dan zig mal starten und dann wieder beenden (schwarm)

[tops4u]

@codierknecht
Nun es ist schon etwas komplizierter, weshalb ich das nur ungern tue. Mein Docker läuft auf einem Synology NAS, alleine die Port Mappings immer wieder herzustellen über das GUI ist etwas mühselig. Also möchte ich meinen Container möglichst so lange laufen lassen wie möglich - also mache ich halt auch Node Upgrades etc im Container selbst. Passt für mich.

Ich habe einige Systeme so am laufen z.b. auch Redis sowie diverse DBs da ist das Problem weniger ausgeprägt weil ich keine Customisations gemacht hab.

Es gibt auch sonst manchmal Gründe weshalb man vielleicht ein System nicht upgraden möchte oder muss.
Da ich wie geschrieben Daten auf andere Platformen transferiere habe ich dafür zb. SSH Keys, Scripts, Cronjobs usw. welche ich manuell kopieren muss. Dafür alleine einen weiteren Dockercontainer zu installieren ist etwas overkill - zudem handle ich mir ja da genau das gleiche Problem ein.

[Codierknecht]

@oliverio sagte in Update Warnung: Abschaltbar??:

das würde ich so nicht unterschreiben wollen. eigentlich schon

Naja - uneigentlich auch wieder nicht.
Zumindest nicht so, wie es viele anwenden: Container erzeugen und nach mir die Sintflut.

Ein "normales" System muss ich per apt und Konsorten pflegen.
Eine Docker-Umgebung durch das aktuell-halten der Images, bei denen der Maintainer das Grundgerüst pflegt.
Soll heißen: In diesem Fall ist die Lebenszeit eines Containers mit einer bestimmten Version des Image dann doch wieder begrenzt.
Aber ich denke, wir sind uns da schon recht einig.

Halten wir fest:
Systeme sind aktuell zu halten - auf die ihnen jeweils eigene Art!

[OliverIO]

@tops4u sagte in Update Warnung: Abschaltbar??:

Nun es ist schon etwas komplizierter, weshalb ich das nur ungern tue. Mein Docker läuft auf einem Synology NAS, alleine die Port Mappings immer wieder herzustellen über das GUI ist etwas mühselig

gut ich habe keine synology, aber auch dort sollte es einen einfachen update knopf geben, der das image neu holt (pullt). da musst du ja nix neu erfassen. die portmappings an sich sollten ja ebenfalls stabil bleiben.
https://mariushosting.com/synology-how-to-update-containers-in-container-manager/

noch besser (finde ich) ist alles über docker-compose zu verwalten.
da steht alles in einer datei drin und du musst nix mehr einzeln per gui machen.
https://digitalewelt.at/container-manager-synology-diskstation/

ich persönlich nutze docker compose in portainer, wo das dann stacks heißt.
über docker compose kannst du dann auch auf einen schlag ganze services definieren. bspw bei iobroker ein container mit iobroker, ein container mit redis, redis ist nur für iobroker zu erreichen, da das netzwerktechnisch dann so verschaltet wird.
wie alles definiert in einer datei (bzw textfenster)

meine docker compose für iobroker sieht bspw so aus

version: '3'

services:
  iobrokerprod:
    restart: always
    image: buanet/iobroker:latest
    container_name: iobrokerprod
    hostname: iobrokerprod
    ports:
      - "8081:8081"
    environment:
        SETGID: 1001
        SETUID: 1001
    volumes:
      - /home/iobroker/docker/volume/iobroker_prod:/opt/iobroker
      - /home/iobroker/docker/volume/iobroker_prod_nodemodules:/usr/lib/node_modules
    networks:
      dockerMACVLAN:
        ipv4_address: 192.168.1.85
      iobrokerprod:
  redis:
    image: "redis:alpine"
    volumes:
      - /home/iobroker/docker/volume/redis_prod:/data
    networks:
      iobrokerprod:
    
networks:
  dockerMACVLAN:
    external: true
  iobrokerprod:

auch meine ist nicht ganz perfekt, aber die iobroker configuration für redis habe ich per shell befehle direkt vorgenommen. buanet kann das dann auch über zusätzliche parameter in dieser date

nur weil ich gerade im nachfolgenden post vom hostmode gelesen habe:
ich habe hier macvlan konfiguriert. dadurch bekommt iobroker eine eigene ip-adresse und ich bekomme keine probleme mit dem portmapping auf dem host-rechner, da das alles in sich geschlossen ist. da kommen dann auch die broadcasts im richtigen container an.

[Codierknecht]

@tops4u

Es gibt auch sonst manchmal Gründe weshalb man vielleicht ein System nicht upgraden möchte

Damit handelst Du Dir dann früher oder später genau die Probleme ein, die hier fast täglich aufschlagen, weil das zu Grunde liegende System nach und nach versumpft.

Ich vermute DSM 7?
Da muss ich passen - meine Erfahrungen beziehen sich auf DSM 6.

Die vielen Portmappings ließen sich vermeiden, wenn man den Container im Host-Mode betreibt.
Geht natürlich nur, wenn sich da nicht andere Pakete der Synology in die Quere kommen.

Ob man unter DSM 7 sowas wie Compose verwenden kann, weiß ich nicht. Da sind dann andere gefragt.
Man könnte Portainer und dessen Stacks einsetzen.

Scripte, Keys usw. könnte man in einem Verzeichnis des NAS sammeln und dieses mounten.
Da könnte man auch eine Art "Setup-Script" ablegen, das man bei einem neuen Container einmal ausführt.

Und natürlich kann man auch im Container mit apt selbst Hand anlegen.
Ist natürlich nicht im Sinne des Erfinders und kann im Zweifelsfall zu ganz neuen Problemen führen.
Auf jeden Fall dazu, dass @Thomas-Braun nicht weiterhilft

[OliverIO]

@codierknecht sagte in Update Warnung: Abschaltbar??:

Und natürlich kann man auch im Container mit apt selbst Hand anlegen.
Ist natürlich nicht im Sinne des Erfinders und kann im Zweifelsfall zu ganz neuen Problemen führen.
Auf jeden Fall dazu, dass @Thomas-Braun nicht weiterhilft

könnte man. das ist aber bei der nächsten regeneration des containers weg.
wer zusätzliche betriebssystemkomponenten benötigt, der muss die installationsmöglichkeiten von buanet nutzen. da kann man per parameter dann noch weitere pakete angeben, die dann beim aufbau installiert werden. so bleibt das image auch bei versionswechsel oder gar bei betriebssystem upgrade immer konsistent (sofern es da in den paketen keine upgrade issues gibt)

[Codierknecht]

@oliverio sagte in Update Warnung: Abschaltbar??:

ist aber bei der nächsten regeneration des containers weg

Das wäre eines der Probleme

[OliverIO]

@codierknecht sagte in Update Warnung: Abschaltbar??:

Scripte, Keys usw. könnte man in einem Verzeichnis des NAS sammeln und dieses mounten.
Da könnte man auch eine Art "Setup-Script" ablegen, das man bei einem neuen Container einmal ausführt.

sowas kommt in ein eigenes volume, das einklinken des volumes entspricht ungefähr eines mounts. docker nutzt dazu overlayFS, daher wird das volume über das vorhandene dateisystem überlagert.
aber da geht es jetzt schon zu sehr ins eingemachte, was die meisten gar nicht interessieren muss

[Codierknecht]

@oliverio sagte in Update Warnung: Abschaltbar??:

sowas kommt in ein eigenes volume, das einklinken des volumes entspricht ungefähr eines mounts

Genau so meinte ich das ja auch

[OliverIO]

@codierknecht sagte in Update Warnung: Abschaltbar??:

Genau so meinte ich das ja auch

sorry, will nicht belehrend sein.
versuche nur die richtigen begriffe zu setzen, das jemand bei interesse dann auch im internet weitersuchen kann.