Hi! I'm trying to use the PostgreSQL module along ...
# general
a
Hi! I'm trying to use the PostgreSQL module along with creating the PostgreSQL db itself and I'm getting a bit of an ordering problem, here's my script: https://gist.github.com/anaisbetts/e59b9af4c2300043cfb711a058e63afc
b
something like:
Copy code
const db = new pg.Database('MyCoolDatabase',{},{dependsOn: [pgContainer]});
might help.
s
The other way to do this is to create a first class Postgres provider to encode the dependency. I’ll post an example shortly
a
I think
dependsOn
is the piece I was missing
Hm, no dice on
dependsOn
It also seems like despite setting
sslmode
(and strangely,
sslMode
, both of which are valid), it demands TLS to be set up on my localhost-only database
s
This is more like what I meant: https://gist.github.com/jen20/0f265fa8c8ffb66c6d3e12a1821e4b39 - constructing the provider using an output of the container, it encodes the dependency relationship.
Setting
sslmode: "disable"
should get rid of the TLS requirement too
a
This is getting closer! Setting
host: pgContainer.ipAddress
gets the ordering right but blows up later, because that IP address is only valid from inside the container network
But if I hardcode it to
127.0.0.1
, we're back to trying to run it too early
Hm I take it back, the IP address works fine
I wonder if it's just jumping the gun and trying to connect to postgres too early
Yep, sure enough - if I re-run
pulumi up
it works fine
s
we are doing much more complicated postgres work already, it does work alright
and we actually connect to this through an ssh jump box
someone once said to me "infra will never be clean, there will always be hacks"
a
You might just be happening to win the race, because I'm doing it all on local Docker the ordering is a bit tighter
w
I would guess that the issue is with
docker.Container
not waiting for the container to be fully booted (I don’t even think docker has any robust notion of that). And then the
Postgres.Provider
not having a built in retry. Either/both of those could be considered bugs in the providers. Alternatively, you can manually inject delays if needed - along the lines of this (though can probably be much simpler for your use case): https://gist.github.com/lukehoban/fd0355ed5b82386bd89c0ffe2a3c916a
a
Alright! This lolzy hack seems to work On My Machine:
Copy code
function stallThenReturn<T>(timeout: number, value: T): Promise<T> {
  return new Promise((res) => setTimeout(() => res(value), timeout));
}

const pgProvider = new pg.Provider('pg', {
  host: pgContainer.ipAddress,
  username: cfg.require('pguser'),
  password: cfg.requireSecret('pgpass'),
  sslmode: stallThenReturn(5 * 1000, 'disable'),
});
s
Ah right yeah we're using a managed pg db so that probably won't have timing issues
b
@ambitious-ram-5811, nice trick