Skip to content

New arbo enzo

Fournet Enzo requested to merge enzo_frnt/FlOpEDT:new-arbo-enzo into 118-solver-tests-2

Documentation techniques

Makefile

Résumé des commandes du Makefile :

Le Makefile a été simplifié pour faciliter le déploiement et la gestion de l'application en environnements de développement et de production. Voici un résumé des principales commandes disponibles :

Commandes Générales

  1. check-health

    • Description : Vérifie l'état de santé du conteneur backend.
    • Utilisation : make check-health
    • Résultat : Affiche si le conteneur est "healthy" ou indique son statut actuel.

  2. is-backend-container-running

    • Description : Vérifie si le conteneur backend est en cours d'exécution.
    • Utilisation : make is-backend-container-running
    • Résultat : Confirme que le conteneur est en cours d'exécution ou affiche une erreur.

  3. wait-for-backend-health

    • Description : Attend que le conteneur backend soit en état "healthy".
    • Utilisation : make wait-for-backend-health
    • Détails : Vérifie périodiquement l'état du conteneur jusqu'à ce qu'il soit prêt.

  4. load-dump

    • Description : Charge les données du dump dans la base de données.
    • Utilisation : make load-dump
    • Prérequis : Le backend doit être en état "healthy" (utilise wait-for-backend-health).
    • Note : Fonctionne uniquement en environnement de développement.

  5. bootstrap-dev

    • Description : Initialise l'environnement de développement en démarrant les services et en chargeant les données du dump.
    • Utilisation : make bootstrap-dev
    • Étapes :
      • Démarre les services avec make start-dev.
      • Charge les données avec make load-dump.
    • Attention : Le backend peut mettre du temps à démarrer. Si la commande échoue, relancez simplement la commande.

Commandes pour l'Environnement de Développement

  1. start-dev

    • Description : Démarre les services en environnement de développement.
    • Utilisation : make start-dev
    • Détails : Lance les conteneurs définis dans deployment-dev/docker-compose.yml.

  2. build-dev

    • Description : Construit les images Docker pour l'environnement de développement.
    • Utilisation : make build-dev
    • Note : Nécessaire après des modifications du code source.

  3. rebuilt-dev

    • Description : Reconstruit et redémarre l'environnement de développement.
    • Utilisation : make rebuilt-dev
    • Étapes :
      • Arrête et supprime les conteneurs avec make down-dev.
      • Construit les images avec make build-dev.
      • Démarre les services avec make start-dev.

  4. stop-dev

    • Description : Arrête les services de développement sans supprimer les conteneurs.
    • Utilisation : make stop-dev

  5. down-dev

    • Description : Arrête et supprime les conteneurs, réseaux et volumes associés.
    • Utilisation : make down-dev

Commandes pour l'Environnement de Production

  1. start-prod

    • Description : Démarre les services en environnement de production.
    • Utilisation : make start-prod
    • Détails : Lance les conteneurs définis dans deployment-prod/docker-compose.yml.

  2. build-prod

    • Description : Construit les images Docker pour l'environnement de production.
    • Utilisation : make build-prod

  3. rebuilt-prod

    • Description : Reconstruit et redémarre l'environnement de production.
    • Utilisation : make rebuilt-prod
    • Étapes :
      • Arrête et supprime les conteneurs avec make down-prod.
      • Construit les images avec make build-prod.
      • Démarre les services avec make start-prod.

  4. bootstrap-prod

    • Description : Initialise l'environnement de production en démarrant les services.
    • Utilisation : make bootstrap-prod
    • Étape :
      • Démarre les services avec make start-prod.

  5. stop-prod

    • Description : Arrête les services de production sans supprimer les conteneurs.
    • Utilisation : make stop-prod

  6. down-prod

    • Description : Arrête et supprime les conteneurs, réseaux et volumes associés en production.
    • Utilisation : make down-prod

Notes Importantes

  • Temps de Démarrage du Backend : Le backend peut prendre du temps à démarrer en environnement de développement en raison de la configuration de logging. Si une commande échoue parce que le backend n'est pas prêt, relancez simplement la commande.

  • Construction des Images : Les commandes make start-dev et make start-prod ne reconstruisent pas les images Docker si elles existent déjà. Si vous avez apporté des modifications nécessitant une reconstruction, utilisez make build-dev ou make build-prod en conséquence.

  • Chargement des Données : La commande make load-dump est spécifique à l'environnement de développement et permet de charger des données préexistantes pour les tests.

Django Settings

Les paramètres de Django sont configurés de manière à être gérés de façon automatique autant que possible.

Qu'est-ce que cela veut dire ?

Cela veut dire que les variables qui changent doivent être configurées dans les fichiers .env qui correspondent à votre environnement : docker dev, docker prod, local dev, local prod ou packaging (installation via un paquet apt par exemple) seulement en prod. Cela évitera de devoir modifier les fichiers de paramètres de Django à chaque fois que vous voulez changer une variable d'environnement et aussi d'avoir des configurations déjà globalement adaptées à votre environnement. Cela permet aussi d'unifier la configuration de Django et d'utiliser des fichiers .env partout qui sont directement utilisés.

S'il est nécessaire de modifier les fichiers de paramètres de Django, il faudra vérifier si les autres environnements sont toujours fonctionnels ou nécessitent eux aussi une modification.

Fonctionnement

Arborescence du répertoire des settings de Django :

settings/
├── __init__.py
├── base.py
├── dev.py
├── prod.py

Le fichiers __init__.py choissis le fichier de settings à utiliser en fonction de la variable d'environement ENV qui est définie dans le fichier .env sur dev, test, prod ou tout autre environement que vous avez défini.

Ensuite, le fichier base.py contient les paramètres communs à tous les environnements et chaque fichier .py correspondant à un environnement spécifique contient les paramètres spécifiques à cet environnement et ceux-ci importent les paramètres de base.py pour les paramètres communs.

Attention : Il est donc possible d’ajouter facilement des environnements. Admettons que nous voulons ajouter l’environnement bob, il suffira de créer un fichier bob.py qui importera les paramètres de base.py et de mettre la variable ENV du fichier .env sur bob pour que les paramètres de bob.py soient utilisés de façon automatique par le fichier __init__.py.

Il faut aussi savoir que dans un environnement conteneurisé, normalement la variable d’environnement DOCKER_ENV est définie sur true pour qu’elle puisse être utilisée dans les settings de Django pour mettre en place des paramètres spécifiques à l’environnement conteneurisé si nécessaire.

À savoir que pour récupérer les variables d’environnement dans des environnements dits locaux (donc aussi en packaging), les fichiers .env sont chargés par base.py avec le module python-dotenv de manière intélligente par exemple sera chargé automatiquement .bob.env si la variable ENV est définie sur bob.. Une variable d’environnement pour changer l’emplacement des fichiers d’environnement est disponible (NON IMPLÉMENTÉ CAR PAS DE PACKAGING POUR LE MOMENT). Voir le déploiement local pour plus de détails.

Deploiement

Docker

Le déploiement conteneurisé de l'application se fait via docker ou podman et se fait soit via des commandes make soit directement via des commandes docker compose qui seront détaillées dans les sections suivantes.

Les environement conteneurisé sont gérés par des fichiers .env qui sont situés dans le dossier deployement-{env} où env peut être prod ou dev. Dans ces fichier .env on retrouve deux variables importantes ENV et DOCKER_ENV qui permettent de définir l'environement de l'application. Pour plus de détail se référer à la section sur les settings de Django, attention toute fois à ne pas supprimer ces variables des fichiers .env car sant elles l'application ne fonctionnera pas correctement.

Une différence notable comparé à précedemment est que les conteneur sont directement pret aprés le build. Cela veut dire que plus aucune commande inermédiaire n'est nécessaire pour lancer l'application. Et ce même sans utiliser le make. Cela veut dire que un simple docker compose up -d --build suffit pour lancer l'application. Dans les repertoires deployement-{env} evidemment.

A noter que le conteneur du back peut avoit un statut dit "healthy" grace à un petit ajout dans le dockerfile de celui-ci. Cela permet de savoir si le conteneur est fonctionnel ou non et donc de lancer le dump de la base de donnée seulement si le conteneur est fonctionnel.

Noter aussi que l'utilisation du module python django wait for db permet d'attendre que la base de donnée soit prête avant que le conteneur execute les migration et le serveur. Cela permet de ne pas avoir un conteneur qui crash car la base de donnée n'est pas prête.. Cela sera probablement aussi utile pour le déploiement packaging.

Production

Ajout d'un proxy nginx configurer via le service de tempmlate proposer par l'image de nginx qui reproduit le comportement du du servuer vite vuejs en dev.

Developpement

Rien à ajouter pour le moment.

Package (seulement en prod)

(PAS ENCORE IMPLEMENTÉ)

Local

Prérequis :

  • poetry installé et le plugin poetry-plugin-dotenv : poetry self add poetry-plugin-dotenv

Pour déployer l'application en local, nous utiliserons poetry pour gérer les dépendances. Pour gérer la configuration de l'application en local, nous utiliserons des fichiers .env qui sont situés dans le répertoire back/flopedt-django. Il y en a 4 :

  • .env : qui définit l'environnement que nous utiliserons. Il contient la variable ENV qui prend deux valeurs dev ou prod pour définir si nous sommes en développement ou en production.
  • .env.dev : qui contient les variables d'environnement pour l'environnement de développement et qui est utilisé automatiquement par les settings de Django en fonction de la valeur de la variable ENV du fichier .env.
  • .env.prod : qui contient les variables d'environnement pour l'environnement de production et qui est utilisé automatiquement par les settings de Django en fonction de la valeur de la variable ENV du fichier .env.
  • .env.test : qui contient les variables d'environnement pour l'environnement de test et qui est utilisé automatiquement par les settings de Django en fonction de la valeur de la variable ENV du fichier .env.

(D'autre peuvent être ajouté pour d'autre environnement, voir la section sur les settings de Django pour plus de détail)

Tutoriel d'exécution locale :

Pour l'exécution du frontend ou de la base de données, rien ne change par rapport à avant. Il suffit simplement de se déplacer au bon endroit pour lancer les commandes. Répertoire du front : front/flopedt-vue.

$ cd back/flopedt-django

$ poetry self add poetry-plugin-dotenv 

$ poetry install --no-root --only main


#### Development

```bash
$ poetry install --no-root --only dev

$ poetry run python manage.py runserver

Production

$ poetry install --no-root --only prod

$ daphne ...

À noter qu’en production, l’application est maintenant déployée via daphne et WhiteNoise pour les fichiers statiques. Cela permet de ne plus avoir besoin de serveur web comme nginx pour servir les fichiers statiques. La configuration de Django en production est faite pour servir les fichiers statiques correctement.

Inconnu et non traité

  • SOLVER
  • PACKAGING
  • CONFIGURATION (Faite de façon trés globale sans rentré dans les détails donc probablement des choses à ajouter/retirer/modifier)
  • CI DE TEST UNIT PYTHON (Probablement en rapport avec le solver)
  • REDIS
  • MAILDEV et mail en prod
  • SSL EN PROD HTTPS Et peut-être d'autres choses que je n'ai pas vu ou pas compris.

Good luck !

Merge request reports