Connection Time out while trying to run database migration

Error during migration run:
{ Error: connect ETIMEDOUT ...:5432
at Object._errnoException (util.js:1022:11)
at _exceptionWithHostPort (util.js:1044:20)
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1198:14)
code: ‘ETIMEDOUT’,
errno: ‘ETIMEDOUT’,
syscall: ‘connect’,
address: ‘...’,
port: 5432 }

I am trying to run a database migration using typeORM against a postgres database on AWS RDS. This database is configured for a public connection, and I can run the migration successfully from my local machine. Unfortunately, when I try to have circleCI run the migration i receive the error I pasted above. I am having a hard time researching this issue, and would appreciate any insight anyone could lend to me.

Continuing to investigate I placed this command into my config.yml to see what the out put would be:

nc -zv polarity-customer-portal-qa.cc70rtxmm2gj.us-east-1.rds.amazonaws.com 5432

The connection here also timed out, while again running the same command from my local machine succeeded. Maybe this is some sort of an an issue with the settings on my database?

I should think that the web ports 80/443 would work outbound, but not sure about arbitrary ports. In general, integration testing should use a in-build database, rather than something on an external server.

Can a TypeORM instance be run locally on a CircleCI machine?

Well this is postgres so all the traffic is on port 5432. Also, I’m not trying to do integration testing. I’m trying to automate the deployment of my database migrations.

Can a TypeORM instance be run locally on a CircleCI machine?

You’re asking if I could set up a database inside circleCI with an image and then execute the migration there in that environment? It would probably work, I don’t think the issue here is typeORM, it’s the issue is the network settings between circleCI and AWS.

Ah, beg pardon - I didn’t grok that it is CD. I thought you were doing testing on a remote database.

I expect you could tunnel to your AWS machine using SSH, and then smuggle the PostgreSQL connection through it. I don’t happen to know if PostgreSQL connections are (or can be) encrypted, but if they are not (or cannot be) then SSH would be a good security idea anyway.

Thanks for taking the time and following up. Upon digging further I realized that the new database had been placed into a corporate VPC that had no public availability.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.