Fix metabase app template's compose file (networking setup)

[jimkring]

metabase service (not postgres) should be on dokploy-network

[Siumauricio]

Why do you remove the network from the database?

[jimkring]

Shouldn’t the services be on the internal network? Postgres only needs to be accessible to the metabase service right? And metabase will be exposed externally?

[gnpaone]

Since metabase needs to access postgres both should be in same network isn't it?

Something like:

version: "3.8"
services:
  metabase:
    image: metabase/metabase:v0.50.8
    volumes:
      - /dev/urandom:/dev/random:ro
    environment:
      MB_DB_TYPE: postgres
      MB_DB_DBNAME: metabaseappdb
      MB_DB_PORT: 5432
      MB_DB_USER: metabase
      MB_DB_PASS: mysecretpassword
      MB_DB_HOST: postgres
    healthcheck:
      test: curl --fail -I http://localhost:3000/api/health || exit 1
      interval: 15s
      timeout: 5s
      retries: 5
    networks:
      - dokploy-network
  postgres:
    image: postgres:14
    environment:
      POSTGRES_USER: metabase
      POSTGRES_DB: metabaseappdb
      POSTGRES_PASSWORD: mysecretpassword
    networks:
      - dokploy-network

networks:
  dokploy-network:

[nktnet1]

@gnpaone I think @jimkring's point is that the services in the compose should run on the same, internal (private) network, rather than be exposed to other compose services in other Dokploy projects/apps on the external dokploy-network.

At the moment though, when you add a domain to a service (e.g. metabase frontend), dokploy will automatically inject the dokploy-network part (you can preview the compose in the UI to see this).
This means metabase can no longer talk to the database after adding a domain, since there's an explicit networks entry, unless the database is also expose on dokploy-network.

I wrote a bit more about this here:

• Warn users in the UI about needing to add "dokploy-network" to all services when configuring a domain #1067

My suggestion in the linked post is to inject a private network for all services by default, and optionally (opt-in) expose them to dokploy-network.

[jimkring]

@nktnet1 Yes, that was exactly my issue -- I started up this app template compose system and it interfered with other running services on my dokploy server (specifically, it appeared to try to use a postgres service on a different project). I'm still not 100% clear about best practices for isolating the various services in a docker-compose file/project, since docker-compose will create networks automatically, give them namespaces/prefixes, etc (same with container/service/volume names).

[jimkring]

My suggestion in the linked post is to inject a private network for all services by default, and optionally (opt-in) expose them to dokploy-network.

Yes, that's sort of what I would expect/like to see.

I want each compose's services isolated from the rest of the system, by default, and then I want to only expose a a single service (via a single port) to the "outside world".