Docker

Raisons

Dans le cadre de ce projet nous avons décidé d'utiliser Docker pour quatre grandes raisons:

• Décomposer le projet en micro-services, pour les isoler et configurer séparément.

• Faciliter le déploiement en production.

• Avoir toujours le même environnement, tant en développement que en production et peu importe l'OS.

• Pouvoir mettre en place un environnement isolé pour effectuer les tests.

Avec l'aide de docker-compose les environnements suivants ont été mis en place :

Environnement de production

Postgres

La base de données nécessaire à l'application. Elle ne sera utilisée que par l'API et n'a donc pas besoin d'être exposée.

Caddy

Le service caddy est simple et ne demande que la configuration Caddy pour fonctionner. Et un Dockerfile pour créer une image avec.

Il sera le point d'entrée pour notre application et donc on y expose les ports 80 et 443.

Backend

La partie backend a besoin de Python et de ses dépendances pour tourner. Dans le Dockerfile on les installe et on se sert d'uvicorn pour servir notre application.

Frontend

Nous utilisons Vue.js pour notre frontend avec des fichiers .vue qui doivent être compilés.

En production on a un build à deux étapes, d'un côté on a une étape où l'on prends tous nos fichiers source et on les compile, avec des optimisations supplémentaires nécessaires seulement en production.

Les fichiers qui résultent de cette compilation sont simplement inclus dans une autre image qui ne contient que nginx, pour minimiser sa taille.

Environnement de développement

En développement on pourrait changer le code source, recréer les images production et lancer l'application pour vérifier qu'elle marche comme il faut. Mais ceci deviendrait fastidieux, à cause du temps de compilation. De plus, on n'aurait pas accès aux outils de débogage Vue de cette façon.

Backend

En backend, pour éviter de devoir recréer l'image à chaque petit changement on fait deux choses:

• On fait un bind mount du dossier source, pour que le container ait toujours accès aux fichiers de l'hôte et puisse voir les modifications.
• On active le mode "reload" dans uvicorn, qui va relancer l'application dès qu'il y aura un changement dans les fichiers ou suite à un crash. Avec ceci, il ne suffit de build/lancer le container qu'une seule fois, les changements seront automatiquement pris en compte.

Frontend

Quelque chose de semblable est utilisé pour le frontend.

• On fait un bind mount du dossier source, pour les mêmes raisons que le backend.
• Au lieu de compiler nos fichiers et les servir avec nginx, on va directement utiliser le serveur web Vue ce qui nous permet d'avoir les outils de développement sur le navigateur et la recharge automatique dès qu'il y a un changement.

Environnement de testing

Backend

Semblable à l'environnement de testing, au lieu lancer l'application on se sert de pytest pour effectuer les différents tests pour le backend (unitaires + intégration)

Frontend

Semblable à l'environnement de testing, au lieu lancer le serveur web on se sert de jest pour effectuer les tests unitaires frontend

E2E

L'environnement end2end est déjà en place et utilise Nightwatch, mais pour le moment aucun test n'y a été rédigé.

Fichier .env

Un fichier .env est nécessaire pour lancer notre application, on y retrouve des valeurs qui peuvent changer de hôte à hôte (nom de domaine, ports pour l'application...) mais aussi les valeurs sensibles (clé privée pour JWT, identifiants pour la db...)