J’utilise le dépôt discourse_docker avec le script launcher pour exécuter une instance Discourse interne. J’aimerais changer de façon permanente la politique de redémarrage de always à unless-stopped afin de pouvoir maintenir les conteneurs Docker arrêtés lors des mises à niveau / redémarrages du système d’exploitation.
Je vois que la politique de redémarrage est une variable dans le script launcher, mais comment conserver au mieux ce paramètre lorsqu’un nouveau conteneur est construit ? Cela devrait fonctionner à la fois via « launcher rebuild » et via docker_manager via /admin/upgrade.
Je ne me souviens pas que quelqu’un d’autre ait jamais posé cette question, et je ne vois pas de moyen évident. Je pense que votre meilleure option est de faire un
./launcher destroy app
si vous voulez qu’il reste arrêté et de le redémarrer avec
./launcher start app
Cela détruira le conteneur, donc toutes les modifications que vous avez apportées à l’intérieur (comme les mises à niveau de docker_manager) seront détruites.
Oh, mais voici ceci :
en bref : faites un docker update --restart=unless-stopped app après chaque reconstruction.
Oui, je sais ça La mise à jour de Docker est ce que je suis en train de faire. Mais j’ai peur de l’oublier lors de certaines des prochaines reconstructions. D’où la question de savoir comment la rendre persistante.
Une autre option serait de simplement modifier le script de lancement et d’espérer ne pas avoir trop de conflits de rebase lors du pull
La seule fois où j’ai eu des problèmes avec les redémarrages après un démarrage, c’est si je suis passé de app.yml à web_only.yml et que j’ai oublié de détruire le conteneur app. Je fais régulièrement des mises à niveau et des redémarrages de Docker sans aucun problème avec les autostarts. FWIW, je n’ai vu personne d’autre s’en préoccuper au cours des 5 dernières années. À moins que vous n’ayez des éléments en jeu que j’ignore, peut-être ne vous en inquiétez pas ?
Eh bien, aujourd’hui, le problème était que je voulais faire une nouvelle installation car j’avais une étrange version 2.4.0-betaXYZ qui ne se mettait pas à jour toute seule. J’ai fait un test sur une autre VM avec une installation propre et restauré la sauvegarde vers la version 2.7.12, ce qui a parfaitement fonctionné (j’ai également séparé le conteneur de données en redis et postgres).
Maintenant, le serveur principal exécutait encore un ancien Ubuntu et un ancien Docker, donc je voulais :
faire une sauvegarde
arrêter Discourse
faire des manipulations de mise à niveau de l’OS sans me soucier de Discourse, y compris plusieurs redémarrages
faire une nouvelle installation
restaurer la sauvegarde
Je voulais juste garder les conteneurs désactivés et ne pas les supprimer tout de suite, car je n’étais plus sûr si j’avais besoin de quoi que ce soit d’eux que j’aurais pu oublier lors de mon test. Et je me suis juste dit, hé, unless-stopped est pour moi la politique de redémarrage parfaite car elle garantit que les conteneurs démarrent automatiquement après un redémarrage, sauf si vous les arrêtez manuellement. C’est généralement exactement ce que je veux, alors je me suis dit pourquoi ne pas essayer de le rendre permanent.
Ce n’est pas grave si ce n’est pas possible. Je vais juste faire la mise à jour de docker (ou si je l’oublie trop souvent, faire la mise à jour de docker via cron toutes les 5 minutes )
La mise à jour de Docker est ce que je suis en train de faire. Mais j’ai peur de l’oublier lors de certaines des prochaines reconstructions. D’où la question de savoir comment la rendre persistante.
Je vais juste faire la mise à jour de docker (ou si je l’oublie trop souvent, faire la mise à jour de docker via cron toutes les 5 minutes