Multiples instances de pods dans l'environnement Docker

[azmeuk]

Bonjour,

Ceci est une dernière PR en préparation à #1170

Elle introduit divers changements au niveau de la configuration, afin qu'un même dockerfile puisse lancer deux instances distinctes de Pod, utilisant les même services (ElasticSearch, Redis) sans conflit. C'est une étape nécessaire pour pouvoir ensuite tester la fédération entre les deux instances avec ActivityPub. Je mets les modifications dans cette PR afin de rendre la relecture de l'autre plus simple, et plus orientée vers le métier d'ActivityPub.

Aucun changement n'est cassant. Cette PR est juste une mise en place, les modifications apportées sont utilisées ensuite par #1170

Si la PR est acceptée j'en ouvrirai une nouvelle visant la branche main.

Les modifications apportées sont :

• quelques modifications pour rendre les logs moins verbeux, ça m'a aidé pour débugguer :
  • rajout d'une option quiet à la commande collectstatic
  • passage du niveau de log de l'image ElasticSearch à WARN
• les étapes de nettoyage de fichiers de make createDb sont tolérantes aux erreurs (et donc la commande peut être lancée en parallèle par deux instances Pod sur une même base de code)
• Introduction de deux variables d'environnement facultatives POD_INSTANCE et POD_PORT. POD_INSTANCE peut être le nom d'une instance pod (par exemple pod-a, pod-b etc), POD_PORT est le port sur lequel sera lancée l'instance dans le conteneur Docker.
  • dans les entrypoint.sh de l'application Django, le marqueur pour vérifier que l'application a été initialisée n'est plus la détection du fichier .sqlite, mais un fichier .initialized construit à partir de POD_INSTANCE
  • dans les entrypoint.sh de l'application Django, POD_PORT est utilisé pour déterminer sur quel port lancer l'application
  • l'objet Site initial n'est plus initialisé statiquement à partir de initial_data.json mais dynamiquement dans main/apps.py, à partir de POD_INSTANCE et POD_PORT
  • si POD_INSTANCE est défini, la base de données par défaut prendra son nom plutôt que db.sqlite3
  • les queues celery utilisent POD_INSTANCE comme préfix (pour avoir un namespace dédié pour chaque instance de pod)
  • la doc par défaut a été mise à jour pour suggérer l'utilisation de POD_INSTANCE comme namespace pour les caches, les sessions redis, et l'index ElasticSearch ES_INDEX

Before sending your pull request, make sure the following are done

• You have read our contribution guidelines.
• Your PR targets the dev_v4 branch.
• Your PR status is in draft if it's still a work in progress.

[Badatos]

Merci pour cette PR :)
Je n'ai rien vu de bloquant, mais juste quelques remarques :

nb : pour la PR ciblant podV4, il faudra ensuite cibler la branche "dev_v4" et non plus "main" directement. (il faudra qu'on corrige cela dans le pull_request.md)

[LoicBonavent]

Bonjour,
Merci pour ces travaux.
J'ai quand même un questionnement vis-à-vis de la nouvelle fonction load-data dans pod/main/apps.py.
Je n'ai pas testé, mais de ce que j'en comprends, les données initiales ne sont plus sauvegardées dans la base de données lors du createDB mais à chaque fois que Django démarre.
Typiquement, j'ai l'impression que l'adresse du site, dans la table django_site, sera mise à jour à chaque fois.
Dans mon cas - j'imagine que je ne suis pas le seul - je n'ai qu'un site, et j'ai donc la ligne : 1 / video.umontpellier.fr / video.umontpellier.fr

Avec cette modification, au démarrage, cela va changer cette adresse par : 1 / pod.localhost:8000 / pod.localhost:8000 ?
J'ai raté quelque chose ?

Merci