Update hydra template to pull in a global postgresUrl connection string

[cmbirk]

What this PR does / why we need it:

Note: this is a draft PR. This config is erroring on my current deployment with a connection timeout

This adds the ability to provide a global postgresUrl connection string that overrides the local postgres container - similar to the mongoUrl functionality.

Which issue this PR fixes

(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

• fixes #

Special notes for your reviewer:

Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

• [x] Chart Version bumped
• [ ] Variables are documented in the README.md

[dcrdev]

@cmbirk your change adds a custom url to the running container but not the init container i.e. the container that's responsible for initialising the hydra database and/or performing any migrations on start up. It will time out without modifying the dsn here: https://github.com/slingshotlabs/reaction-oss-helm-chart/blob/8cf8fd90421fc4bb69f98a13ee82c0533b95edc0/templates/hydra-deployment.yaml#L89

[cmbirk]

Aha. Thank you @dcrdev

[cmbirk]

Hmm. It appears I did have that change in my helm charts and it's still having a connection issue

[cmbirk]

I'm able to connect using psql <connection_string, so there seems to be an issue with the container being able to access, not an issue with the connection string. Would the hydra containers need additional ports opened?

[dcrdev]

Works for me locally with postgres outside the cluster.

Couple of troubleshooting questions:

• Is rds and eks on the same vpc?
• If not have you created a bridge between the two vpcs?
• Can you run a traceroute inside the cluster and reach the the rds instance.

[cmbirk]

I'm not sure about the vpc. I'm able to connect via psql and Postico locally, so it should just be able to use the connection string, right?

How would I run a traceroute inside the cluster?

[dcrdev]

When you resolve the the name of your rds instance locally it will resolve to the public address of the gateway, when you do it inside the aws backbone it will resolve to an address on a private subnet, unless you launch an rds instance on a public subnet only; the 'public' option puts an internet gateway infront of your public subnet, by default you will have a public+private subnet.

Communicating securely between two vpcs requires a peering, a bridge (update the route table) and modification to the security group of each vpc to allow tcp/5432 i+o . If your on the same vpc, then it's straightforward.

Traceroute you can ssh into one of the nodes or cheat and get an interactive shell inside of one the existing pods:

kubectl exec -it <pod_name> -- /bin/bash

^ you may have to install the iputils package inside that pod; can't remember what the images are based on, either apk update && apk install iputils or apt update && apt install iputils.

[dcrdev]

There hasn't been activity on this one in a while - I've merged in the latest develop and am going to pull these changes in.