Sympa la vidéo, c'est super clair ! Un petit détail tu pull les image avec la commande alors que juste en lançant run ça pull l'image tout seul si tu ne l'as pas.
Pourquoi il faut dissocier la base de donnees de l'application? personellement, j'aime mieux quand tout est en un container car cela fait vraiment un package unique avec l'application.
C'est une fausse bonne idée. Car dès lors que l'on veut soit utiliser une base de données externe/managé ou scaler l'application, on est coincé. De toute façon, il n'y a aucun surcout à juste démarrer deux conteneurs (base + app) si on veut vraiment avoir les deux colocalisés.
@@inpulsetvfr c'est la que j'ai du mal a comprendre : l'idee du conteneur c'est justement de "contenir", l'avantage d'une application conteneurisée c'est de pouvoir s'affranchir des dépendances avec les problèmes du genre "a mais tu as cette lib en v1.8, il faut la v2.0 pour que ca marche" car tout est justement packagé. Du coup, si on separe la base de donnees, on en revient au probleme qu'il faut que la base soit a la version qu'il faut pour que ca marche. Je peux comprendre que pour scaler, il y a des fois ou l'on gagne a separer la DB, mais de la a en faire une regle generale alors que dans 90% des cas, tout en un seul container est largement suffisant, je suis etonne.
@@memestra-11 Bonjour! C'est une discussion très intéressante et je vais essayer de vous expliquer les différentes raisons qui peuvent pousser à "tout intégrer" ou au contraire à "séparer la base de données", voire à "diviser une application en plusieurs conteneur". Voici plusieurs scénari : Scénario 1 : une application ou site statique qui a une toute petite DB, et le contenu de la base de donnée n'est jamais modifié C'est le scénario qui colle avec l'application de notre épisode ruclips.net/video/MIxyr43FmIU/видео.html. Les Menus-du-jour d'un Restaurant ne changent jamais, et le contenu de la base est vraiment négligeable en terme de stockage. Dans ce cas vous avez tout à fait raison. Nous aurions tout intérêt à considérer la DB comme un composant 'statique" de l'application, comme le serait un fichier de conf ou une librairie. Scénario 2 : Les données vont changer Imaginez que le restaurateur veuille changer le contenu du Menus-du-jour presque chaque jour. Il va donc nous demander de développer une autre application, ou au moins une fonctionnalité "administrateur", auquel il sera le seul à accéder. Peut être aussi que à l'avenir on va enregistrer les commandes des clients, des comptes clients etc etc. Dans ce cas la base de donnée va devenir dynamique. C'est le cas dans le cas de l'épisode que vous avez vu ci dessus: des articles de blogs peuvent être ajouter chaque minute par les utilisateurs. Et pourtant, chaque fois qu'on déploie un conteneur, on en fait la copie telle qu'elle était quand on a créé l'image de l'application. Dans notre exemple ci dessus, une base de données vide. Donc dans ce cas on va préférer séparer les données de l'application. La raison est simple : les données vont changer chaque jour, et l'application va peut être changer à chaque version (imaginons que une fois par mois - le développeur livre des nouveautés). Le fait d'avoir posé la base de donnée dans un autre conteneur va donc nous permettre de déployer de nouvelles versions de l'application quand on veut, sans écraser les données. De même, si on a un système comme Kubernetes qui permet de "déplacer" un conteneur d'un serveur à l'autre (ou d'un hébergeur à l'autre) avec un simple click de souris, il faut savoir que "déplacer un conteneur" va effectivement déployer un nouveau conteneur (copie de l'image originale livrée par le développeur, avec sa DB vide) et supprimer l'ancien conteneur. On voit tout de suite que le premier défaut des conteneurs "basiques" est que dès qu'on veut que les données survivent à un conteneur (ne soient pas supprimées quand on supprime ou remplace le conteneur) il manque quelque chose. En réalité ce n'est pas un défaut mais une option a ajouter : la persistance. Quand je dis une "option", je devrais plutôt dire "les options", car il y a plein de possibilité de persistance avec des prix et des complexités bien différentes. C'est donc quelque chose qui devra être adapté aux particularités de l'application : taille des données, localisation, vitesse, temps d'indisponibilité acceptable en cas de panne matérielle. etc etc... ça nécessite un épisode entier. On préfère donc se poser ces question UNIQUEMENT pour les morceaux de l'application qui nécessitent la persistance. Sachant que la partie "Code" de l'application n'en a presque jamais besoin: 95% des conteneurs n'ont pas besoin de persistance. On ne va donc se poser toutes ces questions que pour la partie qui en a besoin (ici la base de données). Et vous allez voir dans le scénario 3 que c'est absolument nécessaire de se poser la question, et que malgré ce "défaut" (qui n'en est pas un) les conteneur restent un truc génial. Scénario 3 : Des milliers de visiteurs : victime de votre succès ? Vous avez développé une application dont les données ne changent jamais Comme dans le scénario 1. Il y a certes beaucoup de données (des vidéos, des images, des milliers de pages de texte), mais comme elles ne changent jamais, vous avez intégré ces données à l'image du conteneur, et ça ne vous a jamais dérangé que la base de données reparte dans son état original quand vous deviez changer de serveur : dans cette situation, comme il y a quand même beaucoup de chose dans la base, déployer le conteneur prend 15 minutes, mais bon vous faites ça la nuit donc pas de soucis. Et dans ce scénario vous avez dû changer de serveur plusieurs fois déjà. Au début un petit serveur à 10€ par mois parce que personne ne connaissait votre application, et petit à petit les gens apprécient l'application et le Traffic a augmenté. Vous avez donc changé de serveur chaque mois (chaque fois un peu plus gros, et chaque fois un peu plus cher). Et grâce à votre Containerisation, c'est une opération qui ne vous prend que 15 minutes. Votre facture hébergeur est désormais de 10.000 € par mois, mais tout va bien, l'application en rapporte 12.000... Mais le Traffic augmente encore et vous êtes arrivé au plus gros serveur dispo... vous êtes bloqué. Imaginez en plus que dans 3 semaines un célèbre youtubeur va parler de vous et là vous vous attendez à une explosion du trafic (et de vos revenus) mais il est impossible de prévoir de combien il sera supérieur au Traffic actuel. Et si à cette occasion votre service crashe, vous aurez perdu l'occasion de décoller et de faire des millions ^^ Il existe des solutions. elles se composent de "répartiteur de charge", "pay-per-use", "serverless" etc etc... mais pour faire simple : quand il y a du traffic, des conteneurs doivent se déployer sur de nouveaux serveurs en moins d'une minute pour les traiter, et quand le traffic redescend les conteneurs en trop sont supprimés, et on arrête de payer pour ces serveurs inutiles (du côté de votre hébergeur, vous avez une facturation à la minute de serveur utilisée : c'est le Cloud.) (On aborde un peu ces problématiques dans les épisodes sur Kube - abonnez vous ^^ ) Bref je pense que vous voyez où je voulais vous conduire. En séparant la base de données et l'application, vous permettez de déployer (et de commencer à payer) un nouveau serveur de base de données (par exemple) chaque fois que le traffic augmente de 200% (parce que ça prend 15 minutes à déployer), mais la partie application elle se déploie quand le traffic augmente de 10% (parce qu'elle se déploi en moins de 3 secondes). En faisant ça votre facture Hébergeur vient instantanément de passer de 10K à 5 K par mois :) puisque la nuit personne n'utilise votre application, et qu'un tout petit serveur est suffisant. C'est pour ça que les architectes logiciels vont toujours diviser les applications en composants les plus indépendants et les plus petits possibles on parle alors d'architecture en "micro-services". Comme on ne sait jamais a quel moment une application va décoller, il est toujours utile de se demander : "que se passera-til si j'ai subitement du succès", et les conteneurs (et leur grand frère l'Orchestrateur de conteneur) vont alors devenir une évidence. Merci encore à vous pour vos encouragements
@@inpulsetvfr Merci pour le retour tres detaille. Je ne parlais pas d'integrer la base de donnees avec les donnees dans le conteneur (le scenario 1, c'est un site/une appli statique), mais juste le moteur de BDD, les donnees elles memes sont dans un volume persistant. Je comprend mieux votre position maintenant, vous vous positionnez en tant que dev d'une application qui peut eventuellement arriver a un succes enorme et vous ne voulez pas changer d'architecture de conteneur lorsque cela arrivera, du coup, vous commencez directement par un conteneur unique pour la BDD et des conteneurs multiples derriere un load-balanceur pour la partie application. J'etais plus du point de vue utilisateur: je veux une appli qui est simple a administrer, je deploie un docker avec son volume et boum, ca marche. mon application peut etre un outil interne pour mon entreprise avec 50 ou 100 utilisateurs max (NextCloud par exemple), un service de monitoring (uptime-kuma par exemple)... bref, rien qui ne necessitera un load-balanceur D'ailleurs, pour vos conteneurs qui se lient a une base de donnees externe, il faut bien configurer cette connexion, vous le faites donc en hard-coded dans l'appli (vu que celle ci n'a pas de persistence...)? Vous faites comment pour la distribution? De mon point de vue, on devrait plutot se poser d'abord la question du potentiel de l'application: Est-ce que je construis une application qui sera potentiellement a super gros succes avec des millions d'utilisateurs sur une instance unique que j'administre (un Facebook ou un Twitter) et du coup je dois partir sur une architecture avec BDD separee, ou est-ce une appli qui sera pour un nombre restreint d'utilisateurs mais avec potentiellement de multiples instances en production administrees par mes utilisateurs (Nextcloud par exemple), et dans ce cas une BDD integree (mais donnees persistantes) serait preferable a mon sens.
aux temps pour moi, je viens de realiser que j'ai completement occulte la connexion BDD via les variables d'environnement, donc pas de probleme de manque de persistence ni de besoin de hard-code (stupid me). Mais cela ne remet pas en cause l'essentiel.
C'est superbe ça, merci. La qualité de la démo est un masterclass, j'aime.😆🤤.
Un grand merci 😁
Très synthétique et pédagogique, c'est pas mal pour débuter. Merci..
Merci beaucoup pour ton retour, ça fait plaisir 🙏
Sympa la vidéo, c'est super clair !
Un petit détail tu pull les image avec la commande alors que juste en lançant run ça pull l'image tout seul si tu ne l'as pas.
C'est bien vrai. Ca a été fait de cette façon pour bien dissocier l'étape pull de l'étape run :). Mais merci pour cette remarque !
Super ce tuto docker, merci !
Avec plaisir 🙂
Très bonne vidéo progressive qui donne une très bonne idée du sujet par un ex concret .. top !
Merci beaucoup pour ce retour , c'est très gentil ! :)
Merci pour cette vidéo !
Avec plaisir 🙂
Merci pour ton contenu.
Merci à toi pour ton commentaire 😀
Super intro, elle est ou la suite ???
Incessamment sous peu :)
Pourquoi il faut dissocier la base de donnees de l'application? personellement, j'aime mieux quand tout est en un container car cela fait vraiment un package unique avec l'application.
C'est une fausse bonne idée. Car dès lors que l'on veut soit utiliser une base de données externe/managé ou scaler l'application, on est coincé. De toute façon, il n'y a aucun surcout à juste démarrer deux conteneurs (base + app) si on veut vraiment avoir les deux colocalisés.
@@inpulsetvfr c'est la que j'ai du mal a comprendre : l'idee du conteneur c'est justement de "contenir", l'avantage d'une application conteneurisée c'est de pouvoir s'affranchir des dépendances avec les problèmes du genre "a mais tu as cette lib en v1.8, il faut la v2.0 pour que ca marche" car tout est justement packagé. Du coup, si on separe la base de donnees, on en revient au probleme qu'il faut que la base soit a la version qu'il faut pour que ca marche.
Je peux comprendre que pour scaler, il y a des fois ou l'on gagne a separer la DB, mais de la a en faire une regle generale alors que dans 90% des cas, tout en un seul container est largement suffisant, je suis etonne.
@@memestra-11 Bonjour! C'est une discussion très intéressante et je vais essayer de vous expliquer les différentes raisons qui peuvent pousser à "tout intégrer" ou au contraire à "séparer la base de données", voire à "diviser une application en plusieurs conteneur".
Voici plusieurs scénari :
Scénario 1 : une application ou site statique qui a une toute petite DB, et le contenu de la base de donnée n'est jamais modifié
C'est le scénario qui colle avec l'application de notre épisode ruclips.net/video/MIxyr43FmIU/видео.html. Les Menus-du-jour d'un Restaurant ne changent jamais, et le contenu de la base est vraiment négligeable en terme de stockage.
Dans ce cas vous avez tout à fait raison. Nous aurions tout intérêt à considérer la DB comme un composant 'statique" de l'application, comme le serait un fichier de conf ou une librairie.
Scénario 2 : Les données vont changer
Imaginez que le restaurateur veuille changer le contenu du Menus-du-jour presque chaque jour. Il va donc nous demander de développer une autre application, ou au moins une fonctionnalité "administrateur", auquel il sera le seul à accéder. Peut être aussi que à l'avenir on va enregistrer les commandes des clients, des comptes clients etc etc. Dans ce cas la base de donnée va devenir dynamique. C'est le cas dans le cas de l'épisode que vous avez vu ci dessus: des articles de blogs peuvent être ajouter chaque minute par les utilisateurs.
Et pourtant, chaque fois qu'on déploie un conteneur, on en fait la copie telle qu'elle était quand on a créé l'image de l'application. Dans notre exemple ci dessus, une base de données vide.
Donc dans ce cas on va préférer séparer les données de l'application. La raison est simple : les données vont changer chaque jour, et l'application va peut être changer à chaque version (imaginons que une fois par mois - le développeur livre des nouveautés).
Le fait d'avoir posé la base de donnée dans un autre conteneur va donc nous permettre de déployer de nouvelles versions de l'application quand on veut, sans écraser les données.
De même, si on a un système comme Kubernetes qui permet de "déplacer" un conteneur d'un serveur à l'autre (ou d'un hébergeur à l'autre) avec un simple click de souris, il faut savoir que "déplacer un conteneur" va effectivement déployer un nouveau conteneur (copie de l'image originale livrée par le développeur, avec sa DB vide) et supprimer l'ancien conteneur.
On voit tout de suite que le premier défaut des conteneurs "basiques" est que dès qu'on veut que les données survivent à un conteneur (ne soient pas supprimées quand on supprime ou remplace le conteneur) il manque quelque chose.
En réalité ce n'est pas un défaut mais une option a ajouter : la persistance.
Quand je dis une "option", je devrais plutôt dire "les options", car il y a plein de possibilité de persistance avec des prix et des complexités bien différentes. C'est donc quelque chose qui devra être adapté aux particularités de l'application : taille des données, localisation, vitesse, temps d'indisponibilité acceptable en cas de panne matérielle. etc etc... ça nécessite un épisode entier.
On préfère donc se poser ces question UNIQUEMENT pour les morceaux de l'application qui nécessitent la persistance. Sachant que la partie "Code" de l'application n'en a presque jamais besoin: 95% des conteneurs n'ont pas besoin de persistance. On ne va donc se poser toutes ces questions que pour la partie qui en a besoin (ici la base de données).
Et vous allez voir dans le scénario 3 que c'est absolument nécessaire de se poser la question, et que malgré ce "défaut" (qui n'en est pas un) les conteneur restent un truc génial.
Scénario 3 : Des milliers de visiteurs : victime de votre succès ?
Vous avez développé une application dont les données ne changent jamais Comme dans le scénario 1. Il y a certes beaucoup de données (des vidéos, des images, des milliers de pages de texte), mais comme elles ne changent jamais, vous avez intégré ces données à l'image du conteneur, et ça ne vous a jamais dérangé que la base de données reparte dans son état original quand vous deviez changer de serveur : dans cette situation, comme il y a quand même beaucoup de chose dans la base, déployer le conteneur prend 15 minutes, mais bon vous faites ça la nuit donc pas de soucis.
Et dans ce scénario vous avez dû changer de serveur plusieurs fois déjà.
Au début un petit serveur à 10€ par mois parce que personne ne connaissait votre application, et petit à petit les gens apprécient l'application et le Traffic a augmenté. Vous avez donc changé de serveur chaque mois (chaque fois un peu plus gros, et chaque fois un peu plus cher). Et grâce à votre Containerisation, c'est une opération qui ne vous prend que 15 minutes.
Votre facture hébergeur est désormais de 10.000 € par mois, mais tout va bien, l'application en rapporte 12.000...
Mais le Traffic augmente encore et vous êtes arrivé au plus gros serveur dispo... vous êtes bloqué.
Imaginez en plus que dans 3 semaines un célèbre youtubeur va parler de vous et là vous vous attendez à une explosion du trafic (et de vos revenus) mais il est impossible de prévoir de combien il sera supérieur au Traffic actuel. Et si à cette occasion votre service crashe, vous aurez perdu l'occasion de décoller et de faire des millions ^^
Il existe des solutions. elles se composent de "répartiteur de charge", "pay-per-use", "serverless" etc etc... mais pour faire simple : quand il y a du traffic, des conteneurs doivent se déployer sur de nouveaux serveurs en moins d'une minute pour les traiter, et quand le traffic redescend les conteneurs en trop sont supprimés, et on arrête de payer pour ces serveurs inutiles (du côté de votre hébergeur, vous avez une facturation à la minute de serveur utilisée : c'est le Cloud.)
(On aborde un peu ces problématiques dans les épisodes sur Kube - abonnez vous ^^ )
Bref je pense que vous voyez où je voulais vous conduire. En séparant la base de données et l'application, vous permettez de déployer (et de commencer à payer) un nouveau serveur de base de données (par exemple) chaque fois que le traffic augmente de 200% (parce que ça prend 15 minutes à déployer), mais la partie application elle se déploie quand le traffic augmente de 10% (parce qu'elle se déploi en moins de 3 secondes).
En faisant ça votre facture Hébergeur vient instantanément de passer de 10K à 5 K par mois :) puisque la nuit personne n'utilise votre application, et qu'un tout petit serveur est suffisant.
C'est pour ça que les architectes logiciels vont toujours diviser les applications en composants les plus indépendants et les plus petits possibles on parle alors d'architecture en "micro-services".
Comme on ne sait jamais a quel moment une application va décoller, il est toujours utile de se demander : "que se passera-til si j'ai subitement du succès", et les conteneurs (et leur grand frère l'Orchestrateur de conteneur) vont alors devenir une évidence.
Merci encore à vous pour vos encouragements
@@inpulsetvfr Merci pour le retour tres detaille.
Je ne parlais pas d'integrer la base de donnees avec les donnees dans le conteneur (le scenario 1, c'est un site/une appli statique), mais juste le moteur de BDD, les donnees elles memes sont dans un volume persistant.
Je comprend mieux votre position maintenant, vous vous positionnez en tant que dev d'une application qui peut eventuellement arriver a un succes enorme et vous ne voulez pas changer d'architecture de conteneur lorsque cela arrivera, du coup, vous commencez directement par un conteneur unique pour la BDD et des conteneurs multiples derriere un load-balanceur pour la partie application.
J'etais plus du point de vue utilisateur: je veux une appli qui est simple a administrer, je deploie un docker avec son volume et boum, ca marche. mon application peut etre un outil interne pour mon entreprise avec 50 ou 100 utilisateurs max (NextCloud par exemple), un service de monitoring (uptime-kuma par exemple)... bref, rien qui ne necessitera un load-balanceur
D'ailleurs, pour vos conteneurs qui se lient a une base de donnees externe, il faut bien configurer cette connexion, vous le faites donc en hard-coded dans l'appli (vu que celle ci n'a pas de persistence...)? Vous faites comment pour la distribution?
De mon point de vue, on devrait plutot se poser d'abord la question du potentiel de l'application: Est-ce que je construis une application qui sera potentiellement a super gros succes avec des millions d'utilisateurs sur une instance unique que j'administre (un Facebook ou un Twitter) et du coup je dois partir sur une architecture avec BDD separee, ou est-ce une appli qui sera pour un nombre restreint d'utilisateurs mais avec potentiellement de multiples instances en production administrees par mes utilisateurs (Nextcloud par exemple), et dans ce cas une BDD integree (mais donnees persistantes) serait preferable a mon sens.
aux temps pour moi, je viens de realiser que j'ai completement occulte la connexion BDD via les variables d'environnement, donc pas de probleme de manque de persistence ni de besoin de hard-code (stupid me). Mais cela ne remet pas en cause l'essentiel.