Boîte à outils
Docker Compose — ERPNext 16.33.0
Le modèle directement importable dans un service Docker Compose Coolify pour ERPNext 16.33.0.
- Publication
- septembre 2026
- Langue
- FR
- Thématiques
- Données pour le développement, Technologies pour le développement
Résumé
Cette ressource met en place MariaDB, Redis cache, Redis queue, configurateur, bootstrap, migrateur, backend, WebSocket, deux workers, scheduler et frontend. Profil retenu : site erpnext mono-instance sur frappe v16. Elle accompagne le guide complet de déploiement.
Architecture
Mariadb, redis cache, redis queue, configurateur, bootstrap, migrateur, backend, websocket, deux workers, scheduler et frontend. Le domaine public est attribué au service d’entrée ; les autres composants communiquent sur le réseau interne.
Prérequis
Un serveur compatible avec les besoins de la solution, Docker géré par Coolify, un domaine pointé vers le serveur, un espace de stockage persistant et un accès administrateur à la plateforme. La mémoire, le processeur et le disque doivent être dimensionnés selon les utilisateurs, les données et les tâches de fond. ERPNext est un produit de gestion construit sur Frappe.
Variables, secrets et volumes
Les variables décrivent les domaines et le comportement de l’application. Les secrets sont générés une fois et partagés avec les services qui utilisent la même identité. L’état durable comprend la base MariaDB, le répertoire sites et les fichiers privés et publics de l’instance.
Installation et validation
Créer un service Docker Compose, importer le fichier, attribuer le domaine, compléter les paramètres puis lancer le déploiement. Attendre les initialisations et exercer le parcours suivant : bootstrap, application ERPNext activée, migrations, HTTPS, administration, parcours métier, fichiers, tâches, temps réel, redémarrage, redéploiement, sauvegarde et restauration isolée.
Sauvegarde, restauration et mise à jour
Utiliser la sauvegarde native frappe et conserver ensemble base, configuration du site et fichiers. Avant une mise à jour, produire un point de reprise, tester la nouvelle version dans un environnement isolé et rejouer le parcours d’acceptation.
Lecture du fichier
Le bloc services décrit les conteneurs et leurs responsabilités. Les ancres réutilisent les variables communes sans dupliquer leur définition. Les volumes nommés identifient les états qui survivent aux redéploiements. Les contrôles de santé et les conditions de dépendance organisent le passage de la base vers l’initialisation, puis vers le service courant. Son intérêt vient de modules reliés — comptabilité, achats, stocks, actifs, projets ou ressources humaines — qui partagent rôles, workflows et référentiels.
Avant toute adaptation, repérer le service exposé, le propriétaire des migrations, les travailleurs, les magasins d’état et les fichiers gérés. Modifier ensuite une responsabilité à la fois et conserver un parcours de validation reproductible. L’adoption demande de choisir un périmètre cohérent et d’aligner les données maîtres ; activer tous les modules dès le départ rend les responsabilités plus difficiles à stabiliser.
Exploitation
Après installation, suivre le domaine public, les certificats, la santé des services, l’espace disque, les files et la croissance des bases. Les comptes administrateurs nominatifs remplacent les accès partagés. Les changements de configuration sont relus, datés et accompagnés d’un contrôle fonctionnel. Le déploiement conserve MariaDB, deux rôles Redis, le configurateur, le bootstrap du site, un migrateur, le backend, WebSocket, les workers courts et longs, le scheduler et le frontend.
Adapter sans casser le contrat
Une nouvelle version peut modifier les images, variables, migrations ou chemins persistants. Comparer la composition avec la documentation de la version ciblée, mettre à jour dans un environnement isolé et vérifier les fonctions réellement utilisées. Le modèle reste un point de départ opérationnel, pas un substitut à l’administration du service. Le site Frappe ne suffit pas : l’application ERPNext doit être installée puis vérifiée.
Contrôles avant partage
Vérifier que le fichier ne contient aucun mot de passe ni domaine privé, que les images sont versionnées, que tous les volumes utiles sont nommés et que le service public possède un contrôle de santé. Relire ensuite les instructions d’installation avec une personne qui n’a pas participé à la conception. Cette post-condition empêche de déclarer disponible un framework sain qui ne fournit pas encore le produit attendu.
Points de contrôle du modèle
Le fichier s’appuie sur une identité de site unique et sur des secrets MariaDB cohérents entre producteur et consommateurs. Les commandes intégrées traversent YAML, Compose et le shell ; chaque signe dollar doit être lu dans son contexte plutôt qu’échappé par réflexe. Les volumes sites, base et file durable forment le périmètre de reprise avant réactivation des workers.