Architecture docker pour site web
Résolu/Ferméavion-f16 Messages postés 19249 Date d'inscription dimanche 17 février 2008 Statut Contributeur Dernière intervention 15 juin 2024 - 26 nov. 2022 à 22:58
- Architecture docker pour site web
- Site de telechargement - Accueil - Outils
- Site pour vendre des objets d'occasion - Guide
- Site comme coco - Accueil - Réseaux sociaux
- Logiciel architecture gratuit - Télécharger - Architecture & Déco
- Web office - Guide
8 réponses
Modifié le 17 nov. 2022 à 23:32
Bonjour,
- Une image pour l'application NodeJS
- Une image pour MongoDB (utiliser l'image officielle, à priori suffisante...)
- Une image pour le front-end public (une image basée sur le Nginx officiel)
- Une image pour le front-end d’administration (une image basée sur le Nginx officiel)
Le but des images OCI (Docker / Podman / Kubernetes) étant d'être des composants indépendants remplissant une fonction spécifique, tout en contenant le nécessaire pour assurer leur propre rôle. Cela permet notamment de multiplier le nombre d'un seul composant en fonction du besoin.
Bonjour,
Tout d'abord, je te remercie d'avoir eu la gentilesse de répondre à ce topic 
.
Merci pour ta vision architecturale, j'ai eu un autre retour qui me conseille l'architecture suivante :
"trois containers différents ;-) Surtout bien garder en tête le concept de l'isolation. Toujours bien isoler chaque application...Tu vas orchestrer le tout avec des fichiers docker-compose.yml.
un dossier pour le backend, un autre dossier pour un second backend (imaginons ton admin ici), un troisième dossier pour le frontend, etc.
L'important ce que chaque fichier docker-compose.yml (tu en auras donc trois) définissent un network qui sera strictement le même. C'est ultra important car cela va dire à Docker : mes trois applications vont pouvoir se parler. Mon frontend va pouvoir faire une requête API p.ex. sur mon backend. Crucial d'avoir le même network pour l'ensemble.
C'est une excellente idée de dockeriser le tout toutefois gaffe au temps que cela va prendre : c'est ultra gourmand en compétences, il faut comprendre si pas maitriser tant de concepts comme la notion de containers, d'isolation, savoir programmer des fichiers Dockerfile, gérer les appels du front vers le back, causer le linuxien, faire que tout le monde puisse se parler; ... Si tu débutes, déjà félicitations et ... courage. Tu as une montagne à gravir.
Une fois en haut; le monde est merveilleux (Docker est une merveille) mais attends-toi à des prises de tête, des cheveux gris et à devoir éplucher tout le net pour trouver une réponse à tes problèmes."
Qu'en penses tu ?
En te remerciant par avance,
18 nov. 2022 à 18:32
Bonjour,
Je ne comprends pas vraiment pourquoi utiliser trois fichiers docker-compose.
Un seul fichier docker-compose.yml permet de lancer à la fois l'API (NodeJS), le frontend, le backend et la base de données.
Encore merci pour ton retour avion-f16.
Donc si je comprends bien, je dois créer :
- Un docker pour l'application NodeJS
- Un docker pour la base MongoDB
- Un docker pour le front-end (développé en Réact sous une image Nginx)
- Un docker pour le front-end d’administration (développé en angular sous une image apache)
- Un seul fichier docker-compose.yml pour orchestrer les 4 dockers.
- 4 dockerfiles (un dockerfile par docker).
Je penses ne rien oublier...
L'application gere les mails transactionnels via un fichier de conf SMTP sur le port: 587 (via le service gmail pour le moment). Cet élément doit etre mentionné sur le docker-compose ?
Une autre question, lorsque l'ensemble des conteneurs ont été crées, orchestrés, et déloyés sur un serveur web (public cloud d'ovh par exemple) pour que le site web soit en ligne et fonctionnel, si je souhaites modifier des fichiers du code source pour apporter des corrections ou modifier le code html, comment cela fonctionne avec docker ?
Dans l'exemple ou la marketplace serait sur un serveur cloud (sans docker), il me suffit tout simplement de me connecter sur le serveur, aller sur le repertoire, modifier le code dans le fichier concerné (index.js par exemple) et le tour et joué.
En te remerciant par avance ;).
19 nov. 2022 à 13:57
Bonjour,
Donc si je comprends bien, je dois créer :[...] Je penses ne rien oublier...
Oui c'est ça, 4 applications = 4 images Docker = 4 Dockerfile. Et un seul docker-compose.yml pour tous les lancer en même temps.
L'application gere les mails transactionnels via un fichier de conf SMTP sur le port: 587 (via le service gmail pour le moment). Cet élément doit etre mentionné sur le docker-compose ?
Il y a plusieurs façons de passer des configurations vers l'application :
- (déconseillé) Inclure le fichier de configuration lors de la construction de l'image, à l'intérieur de celle-ci
- Créer un montage entre le fichier de configuration stocké sur l'hôte, vers le container lors de son démarrage
- Passer des variables d'environnement lors du démarrage du container et utiliser ces variables directement dans l'application NodeJS
- Passer des variables d'environnement lors du démarrage du container et inclure un petit script dans le container (lors de son build) qui lit ces variables et génère un fichier de configuration.
Une autre question, lorsque l'ensemble des conteneurs ont été crées, orchestrés, et déloyés sur un serveur web (public cloud d'ovh par exemple) pour que le site web soit en ligne et fonctionnel, si je souhaites modifier des fichiers du code source pour apporter des corrections ou modifier le code html, comment cela fonctionne avec docker ?
Une fois la nouvelle version de l'application testée, il faut générer une nouvelle image docker, la poussée vers le registry. Côté serveur, il faut "pull" la nouvelle image, et relancer le container avec la nouvelle image. Cela peut être automatiser avec les méthodes devops (CI / CD).
Dans l'exemple ou la marketplace serait sur un serveur cloud (sans docker), il me suffit tout simplement de me connecter sur le serveur, aller sur le repertoire, modifier le code dans le fichier concerné (index.js par exemple) et le tour et joué.
C'est une mauvaise façon de faire, on ne modifie pas une application directement sur un serveur.
Bonjour,
Top je te remercie pour tes conseils ! Ils vont m'etre très utiles !
"Il y a plusieurs façons de passer des configurations vers l'application :
- (déconseillé) Inclure le fichier de configuration lors de la construction de l'image, à l'intérieur de celle-ci"
Pourquoi cela est déconseillé ? En sachant que le code source sera dispatché sur 3 dockers :
- Docker pour l'application NodeJS (le dossier de code qui contient la partie nodejs).
- Un docker pour le front-end (le dossier de code front-end = réact + nginx)
- Un docker pour le front-end d’administration (le dossier de code qui contient la partie admin développé sur angular).
Ne serait-il pas préférable de créer un docker avec le fichier d'app SMTP ? (5 dockers au total). Si la config du fichier change, il me suffirait de créer une nouvelle image docker et la pousser dans le registry. qu'en penses tu ?
"C'est une mauvaise façon de faire, on ne modifie pas une application directement sur un serveur."
J'ai oublié de spécifier qu'il s'agissait d'un serveur de test bien évidemment, et non de prod ;-)
En te remerciant
20 nov. 2022 à 01:13
Bonjour,
Pourquoi cela est déconseillé ? En sachant que le code source sera dispatché sur 3 dockers :
Pour la même raison que tu utilises un fichier de configuration pour placer les différents paramètres (accès BDD, SMTP, ...) plutôt que de "hard coder" les paramètres dans le code source.
Les images Docker doivent être considérées autant que possible comme des "applications" ou un "binaire" si tu préfères, et une application ne contient pas ni le contenu qu'elle manipule, ni sa configuration.
Inclure la configuration dans une application Docker, est équivalent à écrire les paramètres dans le code source d'une application non-Docker.
L’intérêt est d'obtenir des images réutilisables autant que possible, dans des environnements potentiellement différents. Et c'est souvent l'environnement qui fournira les différents paramètres à l'application.
https://medium.com/@mccode/dont-embed-configuration-or-secrets-in-docker-images-7b2e0f916fdd
Si la config du fichier change, il me suffirait de créer une nouvelle image docker et la pousser dans le registry. qu'en penses tu ?
Voilà justement une illustration de pourquoi il ne faut pas inclure la configuration dans l'image Docker. Tu ne trouves pas ça lourd de devoir rebuild une image, la push, la pull et redémarrer des nouveaux containers, quand il suffira de modifier une variable d'environnement et redémarrer le container existant ?
J'ai oublié de spécifier qu'il s'agissait d'un serveur de test bien évidemment, et non de prod ;-)
À partir du moment où tu y modifies le code, j'appellerai cela plutôt un serveur/environnement de développement. Ça ne doit d'ailleurs pas être le lieu de stockage permanent/final de ton code source. Le stockage du code source, c'est plutôt le rôle du serveur Git / SVN / ...
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre questionBonjour,
C'est vraiment sympa de répondre à mes questions, encore merci ;)
Je comprends mieux les choses (je ne suis pas expert dans le domaine et amateur dans le dev donc je me renseigne un max).
Finalement, si je comprends bien, le code source devra etre stocké dans le serveur hote et les répertoires (du code source) devront etre renseignés dans le docker-compose afin de monter un volume et définir une variable d’environnement spécifiant le type d’environnement avec lequel on souhaite exécuter l’application (cette notion me paraissait confuse et je pensais au premiere abord qu'il fallait stocker les répertoires du code source dans les dockers associés).
Concernant les mails transactionnels, il s'agit de nodemailer, un module nodejs. Je doute qu'il soit necessaire de créer un docker sachant qu'il s'agit d'un module et non d'une application ? (un docker = 1 application).
Pour résumer, l'architecture dockers :
- Un docker pour l'application NodeJS
- Un docker pour le front-end (react) avec l'application Nginx
- Un docker pour le front-end d’administration admin (angular) avec l'application apache
- Un docker pour la base de donnée avec l'application mongodb
- 1 seul fichier docker-compose pour orchestrer les 4 conteneurs.
- Le code source sera stockée dans la machine hote (VM cloud) et des volumes seront montés pour indiquer le repertoire de code source associé à l'application docker (3 volumes montées pour les 3 repertoires du code source, sur le backend (docker Nodejs), Admin (docker apache), front end (docker nginx).
Qu'en penses tu ? Ai je oublier un detail ?
L'architecture microservice me semble trop complexe pour le déploiement d'une marketplace, dont l'idée est de perdre le moins de temps possible sur la partie administration/deploiement et se concentrer d'avantage sur le dev. Je prefere donc commencer par le plus simple et le efficace.
22 nov. 2022 à 00:41
Bonjour,
Finalement, si je comprends bien, le code source devra etre stocké dans le serveur hote et les répertoires (du code source) devront etre renseignés dans le docker-compose afin de monter un volume et définir une variable d’environnement spécifiant le type d’environnement avec lequel on souhaite exécuter l’application (cette notion me paraissait confuse et je pensais au premiere abord qu'il fallait stocker les répertoires du code source dans les dockers associés).
Non, dans le cas d'une application NodeJS, le code source doit être intégré à l'image Docker lors de sa construction (via la commande COPY du Dockerfile) car il est nécessaire au démarrage de l'application. Le but d'une image Docker est de contenir ce qu'il faut pour que l'application fonctionne.
Par contre, rien n'empêche de créer une image Docker pour le développement qui, elle, n'intègre pas le code mais sert à l'exécuter, toute la panoplie d'outils (node, npm, ...) étant alors installée dans l'image Docker de dev et non sur l'ordinateur du développeur.
Concernant les mails transactionnels, il s'agit de nodemailer, un module nodejs. Je doute qu'il soit necessaire de créer un docker sachant qu'il s'agit d'un module et non d'une application ? (un docker = 1 application).
Euh non, on ne va pas créer une image Docker par module NodeJS qui peuvent se compter par dizaines.
Bonjour,
Merci pour ton retour.
D'accord je comprends mieux, donc pour mes 3 répertoires de code source, je dois inclure mon code source de la maniere suivante afin d'assurer le fonctionnement de l'application :
- Je dois inclure le code source du répertoire backend (pour l'application nodejs) dans l'image du docker nodejs lors de sa construction.
- Je dois inclure le code source du répertoire frontend admin dans l'image du docker apache.
- Je dois inclure le code source du répertoire frontend utilisateur dans l'image du docker NGINX.
On est d'accord ?
23 nov. 2022 à 01:27
Bonjour,
Oui c'est cela, ton projet assemble quatre applications indépendantes (bien qu'elles communiquent entre-elles), ce qui donne lieu à 4 images Docker pour chacune d'elle, et chaque image Docker doit contenir le nécessaire pour faire fonctionner un composant nécessaire à ton application, et il n'y a aucune raison de contenir autre-chose.
Il n'y a aucune raison pour que l'image Docker pour le frontend user contienne le code source du backend NodeJS.
La question n'est même pas propre à Docker : si à la place de déployer ces 4 applications avec Docker, tu les déployais sur 4 serveurs différents, ça serait la même chose. Lors de la création de l'image Docker, tu dois en fait réaliser les mêmes opérations que si tu déployais l'application sur un serveur vide.
Dans le cas d'une application compilée, on peut faire la compilation dans un Docker, mais inutile de publier le code source dans l'image finale. Cela vaut aussi pour les applications Web avec des traitements sur les CSS/JS via Webpack par exemple, au final c'est le dossier "dist" qui doit être inclus dans l'image Docker de production, et non les sources (TS, SCSS, ...).
Docker permet, via ses Dockerfile, de créer une première image avec les outils de compilation, de faire la compilation, puis de démarrer depuis une nouvelle image vide et copier le contenu généré dans la première, vers la deuxième. Ainsi, la 2e ne contient pas les outils de compilation et peut rester légère.
Tu y verras plus clair en te lançant. Il existe aussi des tas d'exemples / tutos pour utiliser Docker pour déployer une app NodeJS, ou pour déployer un frontend Web, etc.
La question n'est même pas spécifique à Docker
Bonjour,
Merci pour tes explications ! je comprends beaucoup mieux docker.
Avec de la pratique, ça le sera encore plus.
J'ai vue pas mal de tuto sur le net. je vais me mettre à l'oeuvre et m'amuser avec ;)
Je retiens donc pour l'archicture de la marketplace 4 dockers pour les 4 applications (Nodejs, nginx, apache, mangodb).
AWS ou OVH fera l'affaire pour l'hebergement. AWS est apparement mieux conçu.
Tu as été top ! Encore merci.
Bonjour,
J'ai une autre question si tu veux bien ;)
Tu as titillé ma curiosité concernant la création d'un pipeline CI/CD pour automatiser le déploiement, test, etc.
Cela veut dire que si je modifie une page html par exemple (dans un fichier stocké sur github), la modification peut etre automatiquement appliqué sur mon serveur en production ?
cordialement
26 nov. 2022 à 22:58
Bonjour,
Oui c'est exact, tu peux lancer la construction d'une nouvelle image Docker par exemple à chaque nouveau tag (v1, v2, ...) dans une branche (branche "stable" par exemple) et faire en sorte que les services en production basculent vers cette nouvelle image Docker. C'est le « DevOps ».