Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+2 −2
Open

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions apps/dokploy/templates/metabase/docker-compose.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,11 +16,11 @@ services:
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
Comment on lines -25 to -26
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you remove the network from the database?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

Copy link
Contributor

@nktnet1 nktnet1 Jan 21, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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:

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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".