Add option to customize ports for cable and queue

[mononoken]

🔗 Issue

n/a

✍️ Description

Right now, our docker-compose.yml has these ports mapped:

  postgres:
    ports:
      - 54320:5432
  ...
  cable:
    ports:
      - 54321:5432
  ...
  queue:
    ports:
      - 54322:5432

However, our database configs do not use these local ports nor have a way to allow their use. This config change would allow a user to set env variables to pick what ports they want locally instead.

One use case would be to set these local ports so that you can run postgresql, cable, and queue in Docker compose but run the app locally with these set:

export DATABASE_PORT=54320
export CABLE_HOST=localhost
export CABLE_PORT=54321
export QUEUE_HOST=localhost
export QUEUE_PORT=54322

I prefer a setup like this, since I like running the database in the Docker container, but I prefer just running the app locally.

This won't affect running the whole app in docker compose, since it keeps the same default ports.

📷 Screenshots/Demos

n/a

[kasugaijin]

Thanks @mononoken
Should be update the Readme accordingly?

[mononoken]

@kasugaijin Thanks for taking a look! I noticed the local development without Docker required more configuration than it used to. I fiddled with some other configs so that I think it should be fairly seamless for both use cases. With these changes, if you aren't using docker, you just need to setup your environment variables for your PostgreSQL role, and you should be good to go.

I'm not sure we need to add any comments for the initial change I proposed. We have docs for both Docker and for pure local. I added a little customization to allow someone to do a hybrid approach, but I think that should not be something we document and recommend to do but allow people to do it if they know how to and want to.

Let me know what you think, or if you have any objections or suggestions to any of these changes. Thank you!

[mononoken]

I think these defaults should be optimized for local development without Docker. Docker is another dependency for a dev that they may not know or may not want to use.

That said, I think we should set the hosts to localhost as the default, and we can use the environment variables to set them in the compose for Docker.

[mononoken]

Set defaults for Docker in here instead of in database.yml.

[mononoken]

I'm not sure why this was necessary at some point, but I think we can get rid of it. Devs should be able to use the default or set an environment variable for customization.

[kasugaijin]

This is for anyone running the app on WSL

[mononoken]

I am very skeptical this is actually necessary for WSL. Are you running on Windows? I don't have a Windows machine to test but am fairly confident this new config will work fine for WSL.

[jmilljr24]

@mononoken I'm on mobile for this week so I can't test anything out but I'm just a bit confused about some of the changes. Forgive me if any of my questions are dumb.

You mentioned the ports in your description but there's no changes to those lines?

For context, in docker-compose.yml, 54321:5432 was required because we are setting up three different containers each with their own postgres database. They each need a different port on your local machine (54321, 54322 etc.) Those ports are mapped to the containers port of 5432.

I don't see a problem with allowing a dev to set a different port but I'm not sure of the use case for postgres running in a container. Nothing else should be running in the container that would conflict with the default and most commonly used port of 5432.

Did you confirm changing the hosts for cable and queue didn't affect running a full docker setup (vs. your hybrid approach). For a new local setup the host variable is being set in application.yml to localhost. If I remember correctly, doing a full docker setup required having the host set different for each container to connect properly.
I just saw how you switched it. That makes sense to have local development as the default and then define the different hosts for docker compose!

[mononoken]

@kasugaijin I made some updates to the README. Let me know if you have any other suggestions. I also opened #1358. We will need to merge that first for the Standard job to run on this branch. Hoping to make tomorrow's meeting too if you would prefer to discuss any of this real time.

[jmilljr24]

I merged the workflow changes but the "standard" job is failing. We might need to add these under "standard" in this workflow as well.