Déploiement d’Omnimor

Je viens de finir le déploiement d’Omnimor !

Ça fait un moment que j’entends parler de Docker, et rendre Omnimor disponible était l’occasion parfaite pour enfin plonger dedans. Au premier abord, certaines notions n’étaient pas évidentes, notamment la différence entre image et container. J’ai regardé la vidéo de Nana (lien ici), et franchement, grosse recommandation. 👌 Après ça, tout était limpide !

Après la théorie, place à la pratique

Une fois lancée, j’ai dû faire face à quelques points un peu flous :

La base de données : où et comment la gérer ?

J’ai utilisé Postgres comme base de données et la question s’est vite posée : dois-je utiliser la base de données créée automatiquement par le conteneur Docker ?

En gros, lorsqu’on lance un container avec Postgres, une base est automatiquement initialisée. J’ai hésité :

1. Est-ce une bonne pratique d’utiliser celle-ci directement ?
2. Ou est-ce mieux de créer et gérer moi-même mes bases via des scripts d’initialisation ?

En regardant d’autres projets, j’ai remarqué que beaucoup utilisent directement la base fournie par Postgres dans le container. Du coup, j’ai suivi le mouvement, mais j’ai encore quelques doutes sur la gestion des données en production. Est-ce que c’est scalable ? Y a-t-il des pièges à éviter ? Si vous avez des retours d’expérience, ça m’intéresse !

Les variables d’environnement : découverte totale

Là, révélation : je ne savais pas vraiment ce qu’était un environnement. 😅

Jusqu’ici, j’utilisais bien un fichier .env pour éviter d’exposer mes variables sensibles (mots de passe, clés API, etc.), mais sans réellement comprendre leur portée ni comment elles fonctionnaient en profondeur. Du coup, quand il a fallu les intégrer dans Docker Compose et mes Dockerfiles, ça s’est un peu compliqué.

Petit à petit, j’ai découvert qu’on pouvait passer les variables d’environnement directement dans docker-compose.yml. Et franchement, c’est super pratique ! Ça permet aux utilisateurs de personnaliser facilement leur setup (par exemple, en définissant leurs propres credentials et accès à leur base de données) tout en gardant ces infos sécurisées et séparées du code.

Et le bonus ? Ces variables d’environnement sont ensuite disponibles côté application, ce qui permet de configurer dynamiquement le comportement de l’app selon l’environnement (dev, test, prod…). Bref, un vrai game-changer pour rendre l’application plus modulable et plus pro !

Le reverse proxy : une option que j’ai mise de côté (pour l’instant)

À un moment, je me suis demandé si je devais intégrer un reverse proxy (exemple NGINX) pour gérer les requêtes entre le frontend et le backend. J’étais curieuse de voir comment ça fonctionnait et si ça pouvait être utile dès maintenant.

Finalement, pas besoin. J’ai décidé de rester focus sur l’essentiel : faire tourner Omnimor avec Docker sans rajouter trop de complexité. Mais c’est un sujet que j’aimerais creuser pour les prochaines versions !

Conclusion

Cette première immersion dans Docker a été vraiment fun ! J’ai découvert plein de concepts et j’ai hâte d’aller plus loin, notamment sur la gestion avancée des bases de données et le déploiement en production.

Et vous, vous faites comment pour gérer vos bases avec Docker ?