Conjuguer plusieurs docker-compose

Le problème exposé dans ce sujet a été résolu.

Salut tout le monde,

J’ai deux applications que j’installe sur mon VPS via docker-compose. Pour l’instant, j’en ai une d’installée, et je cherche à mettre la deuxième. Problématique : les deux ont des dépendances similaires. Si je lance les deux docker compose séparément, cela va-t-il créer 2 fois les containes avec les services concernés ? Si oui, y a-t-il moyen de simplement connecter les services d’un docker-compose à des containers déjà existants ?

Je vous fais une version plus longue, c’était juste une petite intro.

J’ai un p’tit VPS, et je suis une bille en admin sys. Je me suis dit que plutôt que de galérer à installer (mal) un certain nombre de services, j’allais utiliser des systèmes déjà empaquetés. D’où le choix de Docker, qui permet d’installer les services que je souhaite utiliser : Nextcloud et Mastodon.

J’ai installé Nextcloud parce que c’était le plus simple et à mon avis le plus propre à installer. J’ai simplement installé une version déjà faite du docker-compose qu’on trouve dans les exemples, en l’occurrence la version totale avec nginx et Let’s Encrypt. Son docker-compose se trouve ici.. C’est très simple, il suffit d’indiquer le domaine dans les variables d’environnement et de donner un mot de passe à l’utilisateur de la DB. Ça roule tout seul.

Maintenant, on passe à mastodon. Les fichiers se trouvent par ici. C’est déjà beaucoup plus le bazar. Y a un fichier de conf à éditer avec beaucoup plus d’infos. L’elastic search est optionnel, donc ça je m’en fous. La DB, c’est du postgre, donc je vais laisser ça vu que c’est différent de Nextcloud.

Par contre, les deux utilisent redis, et je ne souhaite pas avoir un 2e container qui tourne avec le même service. Donc si je lance le docker-compose comme ça, il me créera bien une 2e fois le container ? Surtout qu’en plus c’est une image différente qui est utilisée. Comment est-ce que docker-compose gère les connexions entre services ? Dans Nextcloud, il y a juste une dépendance avec redis, mais pas d’informations de connexion ni rien. Dans Mastodon, dans le fichier de conf d’exemple, on voit par contre des informations sur le port et le localhost.

Par ailleurs, pour Mastodon ils font installer nginx à part, mais Nextcloud fait utiliser le container nginx proxy. Si je ne m’abuse, j’ai juste à indiquer les variables d’environnement VIRTUAL_HOST, ainsi que LETSENCRYPT_HOST et LETSENCRYPT_EMAIL pour le compagnon let’s encrypt pour toute la partie proxy web et SSL, donc ça normalement c’est assez facile.

Donc bon, si quelqu’un peut me pointer dans la bonne direction pour comprendre comment interagissent les applications Docker et comment Docker-compose met ça en place, ce serait super ^^'

Merci beaucoup !

+0 -0

Salut !

Alors je ne suis pas du tout un expert avec docker-compose mais pour moi, les fichiers donnés ne sont que des exemples de configuration : en gros, si tu veux les fusionner pour mutualiser les services, il va falloir que tu crées un fichier docker-compose unique qui fusionne les deux confs…

Par contre, les deux utilisent redis, et je ne souhaite pas avoir un 2e container qui tourne avec le même service. Donc si je lance le docker-compose comme ça, il me créera bien une 2e fois le container ? Surtout qu’en plus c’est une image différente qui est utilisée.

Redis étant ce qu’il est, je ne pense pas que l’image joue tant que ça. Si ce qui diffère entre les images est juste -alpine, on s’en fout. Si ce qui diffère est la version, alors je pense que choisir l’image la plus récente fera l’affaire. Par contre quand tu crées deux docker-compose, s’ils ont le même service, tu aura deux conteneurs, oui.

Il faut voir un docker-compose.yml comme un déploiement complet, qui décrit tous les services dont il a besoin.

Comment est-ce que docker-compose gère les connexions entre services ?

Il crée pour cela des "réseaux virtuels" que tu déclares dans ton fichier docker-compose.yml. Si tu ne spécifies rien, tous les services vont être sur un réseau interne, exposé par défaut uniquement aux autres services du docker-compose, et tu peux accéder à chacun d’entre eux (depuis les conteneurs) en utilisant le nom du service comme hostname.

Un exemple avec postgresql : 

version: "3.7"
services:
    # MyApp est mon application, disons un service web.
    myapp:
      container_name: myapp
      image: myapp:latest
      build:
        dockerfile: ./docker/myapp.Dockerfile
        context: .
      environment:
        # note que je reproduis les valeurs de conf du service "db", et que "db" est le hostname
        - MYAPP_DB_URL=postgres://user:password@db:5432/myapp?sslmode=disable
    db:
      container_name: myapp-db
      image: postgres:12
      environment:
        - POSTGRES_USER=user
        - POSTGRES_PASSWORD=password
        - POSTGRES_DB=myapp

Si tu as besoin d’exposer un service sur toute la machine, alors tu peux ajouter une ligne port à la déclaration du service, comme dans cet exemple : 

    mongo:
      container_name: mongo
      image: mongo
      restart: always
      environment:
        MONGO_INITDB_ROOT_USERNAME: *******
        MONGO_INITDB_ROOT_PASSWORD: *******
      ports:
        # Ici, j'expose le port 27017 via le port 27017 de la machine hôte, donc
        # je peux me connecter à ce mongodb depuis l'extérieur de mes conteneurs, 
        # via "localhost:27017".
        - 27017:27017

En dehors de ça, pour tes autres questions, "oui", je confirme. :D

+0 -0

En fait, est-ce que les services ont un besoin indispensable d’etre en commun ? Parce que si ce n’est pas le cas (qu’ils peuvent vivre chacun dans leur coin), je ne considère pas que ce soit spécialement sale de les laisser chacun avec sa petite instance à lui, hormis le fait que ça va coûter plus cher en ressources (CPU et RAM).

+0 -0

Il faut que je sois sûr également en ce qui concerne nginx parce que je peux pas avoir 2 containers sur les mêmes ports ^^'

Phigger

Cas typique justement de devoir coupler les deux dans un seul docker-compose pour pouvoir lancer : Nextcloud, Mastodon, Redis et Nginx (configuration reverse proxy HTTP) en même temps.

En ce qui concerne la configuration Redis, essayes de trouver les identifiants de l’un et de l’autre. Si ça trouve, y’en a pas et Redis est simplement isolé du monde extérieur (--publish=127.0.0.1:6379:6379). Autrement tu peux toujours imaginer un Dockerfile qui récupère l’image de l’un ou de l’autre et qui modifie le mot de passe pour qu’ils soient tous les deux compatibles. Ayant l’habitude de manier Docker, j’ai souvent besoin de ré-écrire mes petites configs perso même si l’image d’origine est propre d’un point de vue fonctionnel ; je compile directement les Dockerfile depuis docker-compose.

Edit : je viens de regarder après coup les docker-compose, y’a effectivement beaucoup de services… tu peux toujours cloner tes deux dépôts GIT puis créer un docker-compose parent qui créera la bonne configuration.

Exemple :

version: '3.1'

services:
  example:
    build:
      context: example_git
      dockerfile: example_git/Dockerfile
    image: example
+1 -0

Ah, c’est intéressant à savoir !

Après réflexion, et après avoir regardé un peu, je me suis dit que j’allais plutôt installer pleroma. L’app est plus simple, il y a moins de services (2, pleroma et la DB), et il y a des explications sur comment l’installer. J’ai tout mis dans un seul docker-compose du coup. Tout fonctionne, sauf le proxy, donc techniquement je ne peux pas y accéder. J’ai tenté de bricoler un peu : j’ai intégré pleroma au network du proxy, et dans le dockerfile j’y ai mis la fonction EXPOSE avec les ports 80 et 443, mais pour l’instant ça ne fonctionne pas. J’investiguerai plus demain.

+0 -0

Pour le routage beaucoup de gens utilisent Traefik. Je n’ai pas encore eu l’occasion de le tester en condition réelle - probablement bientôt car je sens toucher un peu les limites du reverse proxy avec Nginx. Quand par exemple on doit router deux domaines depuis le port 80 vers deux applications différentes dont l’une est un simple site, l’autre une usine à containers … ça complique la config quand même !

+1 -0

Salut,

J’ai essaye Traefik, mais n’ai pas réussi à configurer correctement SSL et Let’s Encrypt. Je suis reparti sur nginx, qui est bien plus simple à configurer. Et en fait, ça été très facile. J’ai combiné le docker-compose de Nextcloud que j’ai linké plus haut, et celui de pleroma trouvable ici. Il faut juste bien suivre les consignes d’installation de pleroma, qui sont vraiment simples.

L’avantage, c’est que les deux ne partagent en l’occurrence aucun service, donc je n’ai pas eu besoin de gérer plusieurs utilisateurs pour les DB par exemple.

Dans le dock-compose, dans la partie de pleroma, j’ai juste eu besoin d’ajouter :

  • Les variables d’environnement pour nginx-proxy et le compagnon let’s encrypt (3 variables, donc)
  • Et un expose sur le port 4000
  • Mettre le service dans les mêmes networks que nginx (proxy-tier et default dans les exemples)

Et c’est tout, ça fonctionne, c’est nickel 😊 On verra pour la charge serveur.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte