-
-
Notifications
You must be signed in to change notification settings - Fork 49
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.
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
refactor: Make postgres host port configurable #847
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- I don't know if
refactor
is the correct scope to use, but it seems to fit the bill the closest. - Where would I document this environment variable?
- I left any other ports hardcoded, because in many cases I was unsure what to name them. I'm happy to expand the PR to make all the host port forwardings configurable with the currently hardcoded values set as defaults.
@@ -60,7 +60,7 @@ services: | |||
timeout: 5s | |||
retries: 5 | |||
ports: | |||
- "5432:5432" | |||
- "${FORMANCE_POSTGRES_PORT:-5432}:5432" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If FOMANCE_HOST_PORT
is not set, docker compose
will fall back to forwarding to port 5432
, resulting in the same behavior as without this change for anyone not using this configuration option. The -
tells docker compose
to also use the default, if the environment variable is available but left empty.
I'm open to suggestions for the naming. If there is any existing convention I'd be happy if you could point it out to me.
DESCRIPTION
When also running a
postgres
daemon on a machine, it's easier to reconfigure the docker host port passthrough, than reconfiguring that daemon and all the services depending upon it. The rest of the containers don't use the host port forwarding, so this change is supposed to be completely opaque to the other services running within the stack.TESTS
I did run the stack with a port other than
5432
set up. The logs did not look any different from when forwarding the database port on host port5432
. From what I can tell the web interface is perfectly usable.I don't know if the host port is used for anything but manually connecting to the database for introspection.