Je comprends plus ou moins que lorsque c’est fait pour la première fois — ok, soyons honnêtes : je ne comprends pas du tout la différence entre bootstrap et rebuild, mais le tout-puissant IA m’a dit que je devrais faire du bootstrapping lors de la première fois, parce que c’est une sorte de truc de développement bizarre, et qu’après, à chaque fois, rebuild est très bien.
Alors… pourquoi pas ./launcher rebuild web_only et c’est tout ? Parce que si je détruis d’abord, je n’ai rien à redémarrer si le rebuild échoue, n’est-ce pas ?
Je comprends que si je mets tout à jour, je dois d’abord arrêter web_only, puis faire data et le dernier est web_only.
Si vous effectuez une reconstruction, cela arrête le conteneur, puis exécute le bootstrap, puis détruit l’ancien conteneur, puis démarre le nouveau.
La reconstruction ne détruit pas le conteneur existant (jusqu’à ce qu’elle en ait un nouveau pour démarrer à sa place).
Si le bootstrap échoue, vous pouvez redémarrer l’ancien conteneur vous-même.
La première fois, il n’y a aucune raison de ne pas effectuer une reconstruction.
Pour les constructions ultérieures, vous voulez effectuer le bootstrap afin que le conteneur existant puisse continuer à traiter les requêtes pendant que le nouveau conteneur est construit.
Pour le conteneur de données, vous voulez toujours reconstruire car vous ne voulez pas que deux instances de base de données modifient les mêmes fichiers.
Pour la mise à niveau PG, vous voulez tout arrêter (le web ne peut pas fonctionner sans la base de données de toute façon) avant de reconstruire le conteneur de données.
La reconstruction effectue également un « git pull », vous pouvez donc utiliser le bootstrap à la place pour avoir le contrôle sur cela.
C’est comme le disque dur d’un ordinateur entier. Un conteneur est juste un ordinateur entier qui a des moyens limités de s’y connecter (via des ports ou par les fichiers qu’ils mettent à jour et qui sont accessibles au système d’exploitation).