• Docker

  • Question docker-compose et bonne pratique

Salut à tous,

J'ai une petite question concernant les "pros" docker, je n'arrive pas à bien réfléchir sur le sujet avec mes maigres connaissances sur le produit.

Cas de figure : j'ai un docker-compose dans lequel j'ai mis plusieurs services (duplicati, nginx proxy manager,bitwarden, ...) et plusieurs de ces services ont besoin d'une base de données.

Actuellement, j'ai monté un service mariadb PAR service.. je ne sais pas vraiment si c'est d'usage et surtout si c'est une bonne pratique.

De plus, je lis parfois qu'il est plutôt recommandé d'avoir un docker-compose par service et non un docker-compose avec tous les services dedans.

Vous avez un avis sur le sujet ?

Merci par avance pour vos lumières 🙂

    qo_op salut,

    Pour les bases de données c'est la bonne pratique docker, pas forcément la bonne pratique des sgbd elles mêmes. Après niveau utilisations ressources ça n'a pas de gros impactes si tu as as plusieurs (quelques 100ene de Mon tout au plus).

    Pour ce qui est des docker-compose, c'est en fonction du nombre de service, tu peux en créer un par service ou un global si tu n'as pas 50 conteneurs.
    Personnellement je préfère la séparation par stack logique (groupe de service cohérent), genre j'ai un pour les applications cloud (nextcloud, vscode, cryptpad etc ...), Un pour le front (traefik, authelia, un dashboard etc ...), Un pour la seedbox (rutorrent, sonarr, radarr etc ...) etc etc ...

      Merci pour ton retour @xataz, j'aime l'idée du regroupement par stack logique, j'avoue ne pas y avoir pensé.

      Pour les BDD OK, c'est donc la logique docker de fonctionner comme ça. Je trouvais ça bizarre car j'ai l'habitude d'utiliser un seul serveur SQL principal habituellement et éventuellement du répliqué. N'étant pas un habitué de docker je trouvais ça vraiment bizarre de faire tourner x services mysql. Me voilà rassuré 🙂.

      Oui une DB/service (plutôt que 1 DB pour tout) n'est pas déconnant, il y a sans doute un overhead mais ça doit être négligeable. Puis dans l'idée ça permet aussi de mieux compartimentaliser avec les réseaux, genre mon MariaDB pour Nextcloud ne sera pas accessible par n'importe quel service mais seulement ceux dans le réseau de Nextcloud.

      Perso sur mes serveurs perso je fous tout dans un seul compose (enfin, pas 1 seul vraiment, je dois en avoir 2-3), ça me permet d'avoir une meilleure vue globale et de tout relancer sur un autre serveur facilement si je dois migrer (déjà été le cas). Mais le mieux serait de séparer par cohérence je pense.

      Hello, j'utilisais le même principe que toi avant puis je me suis vite rendu compte que ça prenais trop de place en RAM car les BDD ne pouvait pas autogérer le cache entre chaque databases. Du coup je suis reparti un mono container qui du coup évite de swapper. Si tu as pas mal de RAM il y a pas de soucis mais une database bien réglé c'est une database qui utilise tout le cache (RAM) quelle a disposition.

      Sur mondedie on a un seul conteneur mariadb pour tous les services.

      Pour les docker-compose y a pas de règle il me semble. L'approche de @xataz est plutôt logique on lance tous les conteneurs qui sont interdépendant en même temps. 🤷‍♂️

      Salut, un seul container MariaDB (et 1 Percona) pour l'ensemble des applicatifs. De nos jours on trouve des serveurs avec 32/64GB de RAM pour pas cher donc en faire un par BDD n'est pas incongru mais pour moi la simplicité de Docker dans ce cas c'est de grouper. Du moment que les backups sont fonctionnels...

      J'aime pas trop docker-compose, je suis une burne en "identation" (Python est un cauchemar) et j'arrive pas à trouver de plugin qui fasse ça tout seul pour SublimeText ou VSCode.
      En fait je me suis fait un fichier BASH à lancer sur un serveur, j'ai qu'à éditer les valeurs (domaine/subs, chemins, variables spécifiques, les "instances" à installer ou non et ça se lance tout seul, à base de "docker run -d \ ...".
      C'est comme un compose avec son .env mais version flemmard/crados.

        Après je trouve que plusieurs service db a plusieurs aspects pratique, après réflexion :

        1. meilleure portabilité (si jamais je dois bouger un service sur un autre serveur et pas du tout le même docker-compose)
        2. possibilité de paramétrage "fin" pour chaque service db en fonction du service qui va l'utiliser

        Il y a surement tout un tas d'autres avantages et j'imagine bien que cela amène aussi son lot d'inconvénient (notamment consommation plus importante de ressource, entre autre). Donc je reste dubitatif ¯_(ツ)_/¯

        Concernant docker-compose je préfère largement pour ma part, c'est ce qui m'a amené à utiliser docker récemment. Sans ça je trouvais la syntaxe trop nébuleuse et j'ai une mémoire (cerveaaaau) très limitée en ce moment, trop de truc en tête 😃

        Merci pour vos retours en tout cas.

        Aerya bizarrement je suis plutôt de l'avis inverse, pour moi docker c'est le fait de pouvoir facilement tout séparer. Par exemple j'ai 2 réseaux nextcloud, un net et un local, et seul nextcloud lui même est sur le réseau net et local, postegre et redis sont local. Et donc postgres et redis ne sont accesible que depuis nextcloud.
        Ça permets selon moi de sécuriser encore plus l'accès au BDd, avec seulement le conteneur qui en a besoin et c'est tout.
        Si un conteneur n'a pas besoin d'internet, un réseau local suffit.
        Ça me fait cependant beaucoup de réseau, minimum 2 par stack, net et local, pour certains j'en ai encore plus cependant

        Pareil pour l'indentation, c'est ce qui me plaît dans le yaml et dans le python, au moins je trouve ça clair, car obligé de respecter cette indentation.

        Comme quoi, y'a pas de bons ou mauvais choix ^^

          C'est intéressant d'avoir vos points de vues sur la question en tout cas. De mon côté ça me fait beaucoup réfléchir (surement trop).

          Oui voilà mon avis c'est le même que xataz, meilleure compartimentalisation = meilleure indépendance des services = meilleure sécurité théorique (pas d'accès non-souhaités). Mais une DB pour tout a l'avantage de ne pas avoir d'overhead, et c'est plus simple pour dump que de se faire chier à penser à backup plein de conteneurs DB.

          À toi de voir. Dans Docker il y a des bonnes pratiques "officielles" et "officieuses". Les conteneurs c'est flexible, on peut faire ce qu'on veut après tout (tant que ça touche pas à la sécurité - dans ce cas ici le gain est théorique, ce n'est pas très gênant de faire 1 conteneur unique je pense). C'est un peu la même chose pour les conteneurs à processus unique ou multi-process, le premier a l'avantage de bien scale (et d'être "la bonne" pratique), le second l'avantage d'être super simple à déployer et homogène.

          Le même débat pourrait se faire avec le conteneur PHP en fait. Dans ce cas là, pourquoi mettre Nextcloud (par exemple) dans un conteneur ? Alors qu'on pourrait avoir une stack Docker nginx + PHP qui servirait toutes nos apps PHP. Mais au final on le fait quand même (enfin je pense).

          C'est juste, y'a du tri à faire entre bonnes pratiques et bon-sens 🙂 Pour moi ça reste du ressort de chacun, à toi de voir ce qui te convient le mieux @qo_op, au final tes services tourneront tout aussi bien 😉

          Je reste de l'avis qu'il vaut mieux séparer les containers pour mysql sauf quand c'est pas possible, pour exemple dans mon cas 2Go de Ram sur un VPS et 4 containers mariadb ça fait 3/4% * 4 alors qu'un seul 8% en moyenne.

          Tout dépend beaucoup du type d'infra que tu as. Tu as des infras avec une seule machine (la plupart des utilisateurs de ce forum), ou bien un K8s avec des pods qui peuvent bouger d'un serveur physique à l'autre. Dans le second cas, il vaut mieux découper les services de façon granulaire pour que l'orchestrateur puisse bien répartir la charge.
          Comme c'est souvent le cas d'usage professionnel, c'est vrai qu'on dit que c'est le "best practice", mais il n'est forcément adapté à un cas d'usage d'un seul hôte.

          Y a aussi le côté maintenance à prendre en compte. Plus tu as de conteneur et plus tu as du boulot et tu multiplies le nombre de problèmes possibles. En réalité c’est un équilibre à trouver je pense.

          Par exemple sur mondedie, si je devais maintenir un conteneur de bdd par service 😱 avec les dumps en plus 😂
          Il faut penser aussi (de mon avis) à la charge de travail que ton infra va te demander.
          Avec du recule plus c’est simple et mieux on se porte 😂😂

          2 mois plus tard

          Bonsoir, j'aimerais savoir si dans "les bonnes pratiques", il n'était pas plus safe de mettre la DB hors docker?
          J'ai fais des recherches sur différents groupes devops/ docker et c'est cette réponse qui est revenue. L'argument principal était qu'en prod, on utilise une DB en dur et non dockerisée.
          Pouvez-vous m'éclairer car j'avoue être perdu. Pour avoir testé les deux méthodes, je n'ai pas vu de différences. Après mes db étaient peu fournies ce qui ne donne pas un bon test je présume.
          Bonne soirée 🙂

          Tout dépend...
          Une DB est quelque chose qui se "tune" pour correspondre à tes besoins (plus de lecture ? d'écriture ? quels sont les volumes ? etc...). Dans 95% des cas, tu n'as pas besoin de ça, et une base de données en docker fait l'affaire (par exemple, une base mysql pour du wordpress, etc...)

          En revanche, sur certaines applis "pros" ou gourmandes, ça ne suffit plus, et il faut externaliser la base. Cela accélère légèrement les I/O et te permet une plus grande maîtrise des éléments, mais ça demande aussi de grandes compétences en admin de base de données.

          5 mois plus tard

          Hello, je réponds avec beaucoup de retard, mais vaut mieux tard que jamais. Donc merci pour cette réponse. Cela confirme mes recherches pour ce sujet. Bonne journée ! 🙂

          Répondre…