Use docker compose override

[Quintasan]

I was wondering if we could NOT expose ports for services in docker-compose.yml by default.

The current docker-compose.yml has the following disadvantages:

1. You can't have a PostgreSQL database running on the host.
2. The db, plausible_events_db services are reachable from external IP addresses (this probably not a thing we want).
3. You can't have an HTTP server running on the host.
4. You need to be root to expose to port 80.

My proposition would be to:

1. Disable port exposure on db, plausible_events_db services
2. Disable port exposure on plausible service
3. Create a docker-compose.override.yml which would expose all ports
4. Add docker-compose.custom.yml to .gitignore

This way if someone doesn't care about all of that they can still docker-compose up -d and in case someone wants to perform advanced setup they don't have to deal with stashing changes etc.

[ukutaht]

Thanks for the suggestions. I agree that exposing ports like this is not ideal.

I'm trying to understand better how this setup would be used.

If someone wants to change the port setup, would they copy the contents of docker-compose.override.yml over to docker-compose.custom.yml and then use docker-compose -f docker-compose.yml -f docker-compose.custom.yml up -d to run the app?

This would need to be documented here. I'm happy to do it when I understand how you intend this setup to be used

[Quintasan]

@ukutaht By default, Compose reads docker-compose.yml and an optional docker-compose.override.yml files, and so

1. If you don't care and want the default setup then you just docker-compose up. This works because both docker-compose.yml and docker-compose.override.yml are read automatically.

2. If you want to customize anything then you can create docker-compose.custom.yml and use docker-compose up -f docker-compose.yml -f docker-compose.custom.yml and it will read docker-compose.yml and merge options from docker-compose.custom.yml

The main problem with overriding is that multi-value options (ports, volumes, etc.) are concatenated when merging Compose files so I'd rather have them in docker-compose.override.yml instead of the base docker-compose.yml

Does this explain the mechanism sufficiently?

[ukutaht]

Thanks. It does explain it well. I will merge this and add to the documentation.

[Quintasan]

@ukutaht I'm perfectly willing to update the docs as well. Let me create a MR for it.

[ukutaht]

@Quintasan Port exposure issue was brought up in #4 as well.

I think we should just remove the ports sections for databases. There is also a PR #1 that allows the user to control which port the webserver is exposed at. These two changes in combination seem to address all of your original concerns in the PR. What do you think about making these changes instead of adding the override file?

[Quintasan]

@ukutaht well, this would solve the problem of being able to change the port being exposed but it doesn't change the fact that you would be exposing the port on 0.0.0.0 which might be not suitable for everyone and leaves you with no way to override it save for creating your own docker-compose.yml.

[ukutaht]

Fair enough, that makes sense.

Let's go with the override file. I'll merge this once the docs are ready

[patschi]

To be honest I don't like this approach of using docker-compose.override.yml. My approach is having following setup:

1. Cloning hosting repo via git
2. Adjusting docker-compose.override.yml for manual changes (for example for Watchtower labels)
3. Adjusting plausible-conf.env with manual settings
4. Starting up the stack

This allows simply git pull-ing the hosting repo without having local merge conflicts. When the override-file is in the repo, the main benefit of this file is basically gone, wouldn't it?

[bhavin192]

I agree with @patschi, that's how my workflow is / going to be (having issues with podman-compose when merging configs, not related to Plausible).

[tckb]

Some thoughts here:

I initially wrote the compose file as an example and recommended to write one for yourself (https://github.com/plausible/analytics/commit/5eb8929929d82cd974f6705aa1c0f14ed786a514#diff-e3aeb729186667c90ce5407d900edeb4dbe5060c1f04d2347539f436ac44c287R10) I still do! production environments differ by and large and highly depended on how you configure your machine, some docker-fu is needed. having said that,

I still like your thought but I dislike the idea of using "overrides" - this makes it a bit cumbersome to maintain. How about using environment variables? this is a bit clean solution. You can change port, credentials etc using environment variables. https://docs.docker.com/compose/environment-variables/