Is it possible possible to connect to Fly.io Postgres from a NEXT.js API route served from a Vercel severless function, and if so, how?
I've read and reread the Fly.io Postgres docs, focusing especially on Connecting from outside Fly.io and (since my API routes use Prisma to connect to Postgres) Connecting with Prisma, but it seems I would need to either install flyctl or a set up a WireGuard Tunnel in Vercel, neither of which I could figure out how to do from web searches.
I found essentially the same question on the Fly.io community forum, but unfortunately, no one has answered it after 26 days (as of this writing).
To add a bit more detail, I'm familiar with Heroku Postgres, where a connection string is essentially all that's needed to connect, but it seems connecting to Fly.io Postgres requires a connection string plus a proxy created with flyctl. This was easy to get working on my local machine, but it's not clear how to do this on a remote host like Vercel.
One of the solutions is to allocate an ip address to your app with link here
fly ips allocate-v4 --app <pg-app-name>
Then add these service configurations to the fly.toml file
[[services]]
internal_port = 5432 # Postgres instance
protocol = "tcp"
[[services.ports]]
handlers = ["pg_tls"]
port = 5432
Redeploy your app with fly deploy
Go to your fly dashboard you will be able to see Ip Addresses that you can use as host to connect to the database
Related
I'm running a Superset instance via Docker on a MacBook Air (2019, v11.5.2, Intel i5). I'm trying to set up a remote connection to a PostgreSQL database via an AWS endpoint. I entered the credentials via the dynamic form, as such:
HOST: {dbalias}.{xyz}.us-east-1.rds.amazonaws.com
PORT: 5432
DATABASE: {dbname}
USERNAME: {username}
PASSWORD: {password}
I'm sure that my credentials are valid because I used them to connect from both Databox and DBeaver. But when I try to connect here, Superset tells me that port 5432 is closed. A little digging tells me that this is likely a firewall issue.
I know that our database is set up to only allow connections from allowed IPs, and of course my machine's IP is whitelisted, so I assume I need to whitelist the IP that is sending the connection request (i.e., Superset). However, I cannot seem to find that information. Indeed, even Superset's PostgreSQL connection instructions seem to be incomplete vis-a-vis connecting to an AWS endpoint.
Assuming I've diagnosed the problem correctly (which is by no means a guarantee), the key question is: Where can I find my Superset instance's IP to add to my PostgreSQL IP whitelist? Relatedly, would this IP change next time I launch Superset from Docker, or will it persist?
Many thanks for any consideration.
I have had an issue accessing the local database from Appsmith(docker container or signup from their website https://www.appsmith.com/).
I couldn't connect to my local database.
It sometimes says it can't connect to the specified localhost:5432 and asks me to "Failed to initialise pool. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections" How to solve this?
Method 1:
Actually, one has to tunnel the local database and the Appsmith using tools such as ngrok(ngrok is a cross-platform application that enables developers to expose a local development server to the Internet with minimal effort. The software makes your locally-hosted web server appear to be hosted on a subdomain of ngrok.com) And use that URL as the hostname.
Method2:
When running both the Appsmith and database in docker containers, one has to give the hostname as your database docker container's IP address.
I created a Single Zone postgres db instance on Cloud Sql, and I am trying to connect by cloud sql proxy.
/cloud_sql_proxy -instances=<PROJECT_ID>:us-central1:staging=tcp:5432 -credential_file=./<SERVICE_ACCOUNT_KEY_FILE>
This is running well. But when i run below command,
psql "host=127.0.0.1 sslmode=disable dbname=postgres user=postgres"
the proxy shows this error:
2019/11/14 15:20:10 using credential file for authentication; email=<SERVICE_ACCOUNT_EMAIL>
2019/11/14 15:20:13 Listening on 127.0.0.1:5432 for <PROJECT_ID>:us-central1:staging
2019/11/14 15:20:13 Ready for new connections
2019/11/14 15:20:34 New connection for "<PROJECT_ID>:us-central1:staging"
2019/11/14 15:22:45 couldn't connect to "<PROJECT_ID>:us-central1:staging": dial tcp 34.70.245.249:3307: connect: connection timed out
Why is this happening?
I am doing this from my local.
I've just followed this tutorial step by step and it worked perfectly for me.
I did not have to do any extra steps(whitelisting ip, opening port etc...) and this was done in a clean project.
Are you trying to do this from local with the SDK or from Cloud Shell? Do you have any firewall restrictions in place?
Any further information about specific setup from your side that might affect will surely help.
Let us know.
EDIT:
Make sure your port 3307 is not blocked by anything.
Have a look at this official documentation specifying that.
Make sure you have all the required IAM roles attached to the service account before you connect to it:
For instance, the list of roles for cloudsql can be retrieved from gcloud with:
$ gcloud iam roles list --filter 'name~"roles/cloudsql"' --format 'table(name, description)'
NAME DESCRIPTION
roles/cloudsql.admin Full control of Cloud SQL resources.
roles/cloudsql.client Connectivity access to Cloud SQL instances.
roles/cloudsql.editor Full control of existing Cloud SQL instances excluding modifying users, SSL certificates or deleting resources.
roles/cloudsql.instanceUser Role allowing access to a Cloud SQL instance
roles/cloudsql.serviceAgent Grants Cloud SQL access to services and APIs in the user project
roles/cloudsql.viewer Read-only access to Cloud SQL resources.
If your service account is lacking the appropriate roles, it won't be able to connect to the instance for IAM authentication to work.
The issue is probably that you are not in the VPC network, like when you connect from localhost, so what happens is the cloud proxy showing it cannot connect to the remote IP.
Read this carefully if you use a private IP :
https://cloud.google.com/sql/docs/postgres/private-ip
Note that the Cloud SQL instance is in a Google managed network and the proxy is meant to be used to simplify connections to the DB within the VPC network.
In short: running cloud-sql-proxy from a local machine will not work, because it's not in the VPC network. It should work from a Compute Engine VM that is connected to the same VPC as the DB.
What I usually do as a workaround is use gcloud ssh from a local machine and port forward over a small VM in compute engine, like:
gcloud beta compute ssh --zone "europe-north1-b" "instance-1" --project "my-project" -- -L 5432:cloud_sql_server_ip:5432
Then you can connect to localhost:5432 (make sure nothing else is running or change first port number to one that is free locally)
What should also work is to setup a VPN connection to the VPC network and then run the cloud proxy in node in that network.
I have to say I found this really confusing because it gives the impression the proxy does similar magic like gloud does. It's beyond me why some Google engineers have not wired that together yet, can't be too hard.
I had this issue previously when I didn't specify the port argument to psql for some reason, try this:
psql "host=127.0.0.1 port=5432 sslmode=disable user=postgres"
Don't specify the db, and see if that lets you get to the prompt.
I have an ubunut Compute Engine instance and a postgres Cloud SQL instance, both part of the same project and both in the same zone. I want to connect to the Cloud SQL from the Compute Engine but am having some trouble
My postgres has the default user setup and a new DB added. I have reserved a static IP for my Compute Engine and added this IP to authorised list in postgres. I've tried connecting (from the cloud shell) both with a python script using psycopg2 and directly from bash using psql. The error messages I get in both cases:
Connection timed out
Is the server running on host "xx.xxx.xxx.xx" and accepting
TCP/IP connections on port 5432?
Address omitted, but it is correct. The thing I can't be sure of is whether postgres is listening on the port as there is no (?) config option for this from the dashboard - though I would assume it to be running on 5432 (default)
Is there anything, either postgres or Google Cloud Infrastructure specific that I have missed?
The most resilient and portable way of connecting to a CloudSQL instance is through the CloudSQL Proxy.
There are several options for using the proxy, but in the docs there are specific instructions for using it from a GCE instance. I encourage you to check that option, as it will allow you to move your infrastructure anywhere without the need to change your code, you'll only need to configure the proxy properly wherever you're deploying your app.
I have configured an RDS Postgres micro instance for testing but am having problem connecting. I have created a security group and allow all hosts (0.0.0.0/0) by default to port 5432 but for some reason I am not able to connect. I tried connecting to the port 5432 on the machine but it appears to be closed. Any ideas? I have verified that the security group is using the correct security group.
This is my configuration
TCP
Port (Service) Source Action
5432 0.0.0.0/0 Delete
Here is how I am trying to connect to the rds service
psql -p 5432 -h example.cs945smhrv09.us-west-2.rds.amazonaws.com -U example example
UPDATE
OK feel a little silly after figuring out that rds starts up on a private 172 subnet. I was able to connect from my ec2 instance.
Question now is there a way to put that on a public address that I can connect to? I would like to configure it with a security group that limits the source ip but then be able to connect to it with psql from my desktop.
Update 2
I don't remember all the details when I originally posted this question but it is no longer an issue. We now have a management vpc that we connect to using a vpn server. The management vpc network is trusted by the prod and devel security groups for the rds instances. We have no problem communicating with them without adding any public ips.
Step 4 of the RDS setup wizard ("Additional Config") lets you select whether the DB is Publicly Accessible or not (if it's not, access is limited to within your VPC, regardless of your security group settings). I'd imagine that determines whether the hostname resolves to 54.* vs 172.* .
Your first instance may have been set to private - as far as I can tell this can't be changed after initialization. I had a similar issue and creating a new instance set to be publicly accessible solved it for me.
My company's firewall had blocked outgoing traffic to the default postgres port, 5432. I didn't realise this until I tested the port using netcat in a terminal window, as follows:
nc -zv portquiz.net 5432
Hopefully this saves someone half a day of messing around with AWS security groups.
Absolutely there is. I have pgadmin loaded on my local machine connected to my RDS instance. |
I just confirmed that I can connect using the same syntax you used for psql, although the -U was not necessary for me (I still included both "example" parameters though)
I did edit the "default" security group and added my IP (Ip of the machine I'm connecting from)/32 to be allowed, although I'm sure you could get less restrictive than that, but I'd start there and see if it helps.
This is likely caused by your outbound firewall rules. If you're behind a corporate firewall, they will often block outbound ports above a certain number. You need to setup an SSH tunnel of some kind to avoid this.
http://conoroneill.net/accessing-amazon-rds-instances-from-your-desktop/
I had this problem. This isn't a direct solution but might work for some. I set the Postgres security group to accept connections coming from the server that will be using it (same VPC). I then set up my Postgres client to use ssh tunneling. If I need to use the command line, I simply SSH into that server and then psql from there.
You can simply use workbench recommended by aws but make sure your all postgres availibily is set to everywhere..while adding PostgrSQL 5432
https://aws.amazon.com/getting-started/tutorials/create-connect-postgresql-db/