Configurazione persistente di restart-policy

Ciao,

Sto usando il repository discourse_docker con lo script launcher per eseguire un’istanza Discourse interna. Vorrei cambiare in modo permanente la policy di riavvio da always a unless-stopped per poter mantenere i container Docker fermi durante gli aggiornamenti / riavvii del sistema operativo.

Posso vedere che la policy di riavvio è una variabile nello script launcher, ma qual è il modo migliore per mantenere questa impostazione quando viene creato un nuovo container? Dovrebbe funzionare sia tramite “launcher rebuild” che tramite docker_manager tramite /admin/upgrade

Grazie in anticipo,
Saluti
.sascha

1 Mi Piace

Non ricordo che qualcun altro abbia mai chiesto questo e non vedo un modo ovvio. Penso che la tua migliore opzione sia eseguire

  ./launcher destroy app

se vuoi che rimanga fermo e riavviarlo con

  ./launcher start app

Questo distruggerà il container, quindi eventuali modifiche apportate al suo interno (come gli aggiornamenti da docker_manager) verranno distrutte.

Oh, ma ecco questo:

in breve: esegui un docker update --restart=unless-stopped app dopo ogni rebuild.

2 Mi Piace

Sì, lo so :wink: L’aggiornamento di Docker è quello che sto facendo attualmente. Ma temo di dimenticarlo in alcune delle prossime ricostruzioni. Quindi, da qui la domanda su come renderlo persistente.
Un’altra opzione sarebbe semplicemente modificare lo script di avvio e sperare di non avere troppi conflitti di rebase al momento del pull :wink:

L’unica volta che ho avuto problemi con i riavvii dopo un avvio è stato se sono passato da app.yml a web_only.yml e ho dimenticato di distruggere il container app. Eseguo regolarmente aggiornamenti e riavvii di docker senza problemi con gli avvii automatici. Per la cronaca, non ho visto nessuno preoccuparsi di questo negli ultimi 5 anni. A meno che tu non abbia qualche elemento in gioco che non conosco, forse non preoccupartene?

Oggi il problema era che volevo fare un’installazione pulita poiché avevo una strana versione 2.4.0-betaXYZ che non si aggiornava da sola. Ho fatto un test su un’altra VM con un’installazione pulita e ripristinando il backup a 2.7.12 che ha funzionato perfettamente (ho anche separato il container dei dati in redis e postgres).

Ora il server principale eseguiva ancora una vecchia versione di Ubuntu e Docker, quindi volevo:

  1. fare un backup
  2. spegnere Discourse
  3. fare delle manipolazioni per l’aggiornamento del sistema operativo senza preoccuparmi di Discourse, inclusi diversi riavvii
  4. Fare un’installazione pulita
  5. Ripristinare il backup

Volevo solo mantenere i container spenti e non eliminarli subito, poiché non ero più sicuro se avessi bisogno di qualcosa da essi che potessi aver dimenticato durante il mio test. E ho pensato, hey, unless-stopped è per me la politica di riavvio perfetta poiché assicura che i container si avviino automaticamente dopo il riavvio, a meno che tu non li fermi manualmente. Di solito è esattamente quello che voglio, quindi ho pensato perché non provare a renderlo permanente.

Non è un grosso problema se non è possibile. :slight_smile: Farò solo l’aggiornamento di docker (o se lo dimentico troppo spesso farò l’aggiornamento di docker tramite cron ogni 5 minuti :wink: )