harden docker-compose

[0x4r45h]

I did some research on community Namada-Indexer providers, and here’s what I found:

8 teams had Dragonfly exposed on the default port without any credentials.
4 teams had Postgres exposed on the default port with default credentials.
These PRs address these issues by:

• Removing the binding of service ports to host ports (which wasn’t necessary).
• Enforcing users to set a Postgres password
• Adding a Postgres volume for persistent data storage.
• Merging docker-compose-db.yml into the main compose file for better readability and reduced complexity.
• Removing unused variables and Dockerfiles.

[Fraccaman]

I dont get it, this is a docker compose used for development. I feel like infra operator should take this and modify it as they need? This is going to make development more difficult:

• not having ports exposed by default makes debugging more difficult.
• volumes during development are useless and lead only to developers getting confused on whats happening.
• we have 2 docker compose because usually we work on a single service and we dont want to start the entire set of services together.

[0x4r45h]

I dont get it, this is a docker compose used for development. I feel like infra operator should take this and modify it as they need? This is going to make development more difficult:

• not having ports exposed by default makes debugging more difficult.
• volumes during development are useless and lead only to developers getting confused on whats happening.
• we have 2 docker compose because usually we work on a single service and we dont want to start the entire set of services together.

but people are using this in production.
we can create a separate compose file for development. e.g docker-compose-dev.yml
and instead of two separate compose files, we can use profiles to just run database+ Dragonfly.

OR, I can create a separate repository for production deployment using docker and use GitHub images from CI

[sirouk]

I dont get it, this is a docker compose used for development. I feel like infra operator should take this and modify it as they need? This is going to make development more difficult:

• not having ports exposed by default makes debugging more difficult.
• volumes during development are useless and lead only to developers getting confused on whats happening.
• we have 2 docker compose because usually we work on a single service and we dont want to start the entire set of services together.

I disagree. Perhaps there should be a docker-compose-dev.yml which continues to deploy as it does today, while we patch up docker-compose.yml for folks utilizing the template as-is.

[Fraccaman]

sure, we can have two!

[Fraccaman]

@0x4r45h can you split it into dev and prod?

[0x4r45h]

@0x4r45h can you split it into dev and prod?

Yeah, sure, but I suggest keeping the docker-compose.yml for production. If we don’t, infra providers will have to pass the -f docker-compose-prod.yml flag to their commands, which could cause more confusion since most of them aren’t comfortable with Docker. For developers, we can alias it to a just command to make usage easier.
wdyt?