UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[Gelöst] Welche Docker Restart-Policy wird empfohlen?

Informationen über Docker, Verwaltung mit portainer und VMs
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
Antworten

Ersteller
pbm
Reactions:
Beiträge: 201
Registriert: Mo Dez 02, 2019 10:20 pm
Wohnort: Hannover
Hat sich bedankt: 116 Mal
Danksagung erhalten: 114 Mal

Welche Docker Restart-Policy wird empfohlen?

#1

Beitrag von pbm »

Hallo,

nach dem Update auf 1.6.0 IP2 waren alle meine selbst angelegten Docker-Container "stopped".

Die Container "TW-APP-Wiregate..." und "TW-APP-Cometvisu" waren running.


Liegt wohl daran, dass Docker selbst restarted wurde und beim Restart von Docker die Container nicht automatisch gestartet werden.

Alle Container stehen auf "Restart-Policy: Never". Auch die TWS-APP-Container.

Scheinbar ist es notwendig, die Restart-Policy auf Always oder unless-stopped zu setzen, damit diese nach dem Docker-Start auch mitgestartet werden.
--> https://docs.docker.com/config/containe ... matically/


Folgenden Status hatten die gestoppten Container:

- dperson/samba:latest --> exit code 0
- nodered/node-red-docker:latest --> exit code 148
- openhab/openhab:2.5.2 --> exit code 137

Die exit codes weisen darauf hin, das der container zwar gestartet wurde, dann aber ein Fehler auftrat, oder?

Mir ist im Moment nicht ganz klar, was ich tun soll.

Alle Container auf restart politcy: always stellen?

Laufe ich damit Gefahr, dass ein Container ggf im Restart-Loop hängt und mir vielleicht mein Gesamt-System lahm legt?


Was habt ihr als restart policy eingestellt?
Zuletzt geändert von StefanW am Mo Mai 04, 2020 11:37 pm, insgesamt 1-mal geändert.
Schöne Grüße
Peer

TWS 2400 #466 // Wartungs-VPN: aktiv // Reboot: nach Rücksprache
Benutzeravatar

starwarsfan
Reactions:
Beiträge: 1152
Registriert: Mi Okt 10, 2018 2:39 pm
Hat sich bedankt: 744 Mal
Danksagung erhalten: 923 Mal

#2

Beitrag von starwarsfan »

Hi

also das hier:
pbm hat geschrieben: Mo Mai 04, 2020 10:58 pm nach dem Update auf 1.6.0 IP2 waren alle meine selbst angelegten Docker-Container "stopped".
wird durch dieses hier erklärt:
pbm hat geschrieben: Mo Mai 04, 2020 10:58 pm Alle Container stehen auf "Restart-Policy: Never". Auch die TWS-APP-Container.
Allerdings erklärt das nicht, warum die TWS-APP-Container liefen:
pbm hat geschrieben: Mo Mai 04, 2020 10:58 pm Die Container "TW-APP-Wiregate..." und "TW-APP-Cometvisu" waren running.
Aber zur Frage:
pbm hat geschrieben: Mo Mai 04, 2020 10:58 pm Mir ist im Moment nicht ganz klar, was ich tun soll.

Alle Container auf restart politcy: always stellen?

Laufe ich damit Gefahr, dass ein Container ggf im Restart-Loop hängt und mir vielleicht mein Gesamt-System lahm legt?

Was habt ihr als restart policy eingestellt?
Einen genauen Rat kann Dir da keiner wirklich geben. Das kommt ganz darauf an, was die Container machen sollen, wenn der TW rebootet wird.

Ich habe meine Container auf unless-stopped gestellt. Das heisst, wenn der Container läuft, wenn Docker neu gestartet (aka der TW rebootet) wird, wird der Container auch direkt wieder gestartet. Stoppst Du den Container aber manuell und rebootest dann, bleibt der Container gestoppt. Damit fängst Du den Fall ab, dass bspw. nach einem Stromausfall alle Container wieder gestartet werden, da sie ja zum Zeitpunkt des Stromausfalls liefen. Musst Du aber was-auch-immer nach dem Reboot aber vor dem Container-Start machen, kannst Du eben den Container vorab manuell stoppen und er bleibt nach dem Reboot gestoppt.
Kind regards,
Yves

- TWS 2500 ID:159 (VPN offen, Reboot nach Rücksprache) - PBM ID:401 - TWS 3500 ID:618 (VPN offen, Reboot nach Rücksprache) - ControlPro - ProxMox - Edomi (LXC / Docker) - ... -

Ersteller
pbm
Reactions:
Beiträge: 201
Registriert: Mo Dez 02, 2019 10:20 pm
Wohnort: Hannover
Hat sich bedankt: 116 Mal
Danksagung erhalten: 114 Mal

#3

Beitrag von pbm »

Hi Yves,

unter dem von dir geschilderten Gesichtspunkt würde ich dann auch eher zu "unless stopped" tendieren.
Hab das aus den Docker-Docs so nicht rausgelesen, könnte aber so gemeint sein...
(Vielleicht brauche ich auch nur ein englisch-update?!?!)

Ich werde das mal ausprobieren. Aber nicht mehr Heute. :D
Schöne Grüße
Peer

TWS 2400 #466 // Wartungs-VPN: aktiv // Reboot: nach Rücksprache

Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

#4

Beitrag von Robert_Mini »

Hallo zusammen!

Ich hab das seit mehr als einem Jahr auch mit "unless stopped" im Einsatz und noch bei keinem Update ein Problem damit.
Das habe ich aus den Docs auch so rausgelesen und in die KB (app.php/kb/viewarticle?a=51) aufgenommen:
  • no: Der Container wird in keinem Fall automatisch neu gestartet.
  • on-failure: Wird der Container aufgrund eines Fehlers gestoppt (Exit mit Fehlercode > 0), erfolgt automatisch der Neustart des Containers.
  • unless-stopped: Der Container wird immer neu gestartet, außer er wurde manuell beendet (am TWS über Portainer).
  • always: es wird immer versucht, den Container neu zu starten.
Hab's zwar nie getestet, aber ein always würde auch beim Portainer-Neustart Container starten, die vorher gestoppt wurden?!

lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

ms20de
Elaborated Networks
Reactions:
Beiträge: 974
Registriert: Sa Aug 11, 2018 9:14 pm
Hat sich bedankt: 280 Mal
Danksagung erhalten: 498 Mal

#5

Beitrag von ms20de »

Die Container die über die Timberwolf Apps erstellt wurden, werden automatisch von System gestartet oder gestoppt.

Hier bitte keine Änderung der Einstellungen vornehmen.

Viele Grüße,
Matthias
[ Timberwolf Entwicklung ]

TWS 2400 ID:102 VPN offen, Reboot auf Nachfrage

Ersteller
pbm
Reactions:
Beiträge: 201
Registriert: Mo Dez 02, 2019 10:20 pm
Wohnort: Hannover
Hat sich bedankt: 116 Mal
Danksagung erhalten: 114 Mal

#6

Beitrag von pbm »

Robert_Mini hat geschrieben: Di Mai 05, 2020 11:41 am
Hab's zwar nie getestet, aber ein always würde auch beim Portainer-Neustart Container starten, die vorher gestoppt wurden?!
ist so. habe ich gerade ausprobiert.

ms20de hat geschrieben: Di Mai 05, 2020 1:49 pm Die Container die über die Timberwolf Apps erstellt wurden, werden automatisch von System gestartet oder gestoppt.

Hier bitte keine Änderung der Einstellungen vornehmen.
Da lasse ich die Finger von.


Hab meine anderen Container auch auf "unless stopped" gestellt und ausprobiert. Es macht das, was es soll.

Danke für die Infos.
Schöne Grüße
Peer

TWS 2400 #466 // Wartungs-VPN: aktiv // Reboot: nach Rücksprache
Antworten

Zurück zu „Docker, portainer, VM“