On Heroku it says that "Apps can connect to Heroku Postgres from Heroku, Google App Engine,...", but how is that possible if App Engine only allows http connections?
App Engine recently added support for Sockets, see:
https://developers.google.com/appengine/docs/python/sockets/
https://developers.google.com/appengine/docs/java/sockets/
Thus is should be possible to use either a pure-Python or pure-Java Postgres client to connect to a Postgres instance.
Related
I have a flask app connected to a local postgres db with SQlAlchemy for dev purposes. I also have a live version of the app running on Google App Engine which is connected to a postgres db on CloudSQL
I am trying to use flask-migrate (which builds upon alembic) to manage database migrations. I can run the migrations fine locally but I am unsure how to manage the migrations for the deployed version?
this answer
has a couple of useful answers. One suggesting getting an IP address and being able to connect directly but I don't know where I would use that URI for migrations?
The other answer suggests running the code as an endpoint in the app itself.
Any pointers would be greatly appreciated
I have a sails js app running on App Engine and a Cloud SQL instance that App Engine is supposed to talk to. I am using the following configuration with Sails v1.0 app:
adapter: 'sails-mysql',
socketPath: `/cloudsql/${process.env.INSTANCE_CONNECTION_NAME}`,
user: process.env.SQL_USER,
password: process.env.SQL_PASSWORD,
database: 'parsley'
All of the env variables are passed correctly but I still get this error:
name=AdapterError, adapterMethodName=create, modelIdentity=admin, name=Exception, code=badConnection, exit=badConnection, errno=ECONNREFUSED, code=ECONNREFUSED
If you are testing the code using the Cloud Shell and using a Cloud SQL Proxy:
Start the Cloud SQL Proxy in a Cloud Shell tab and leave the tab opened
Open a new tab. Try to connect from App Engine to Cloud SQL.
As described here:
Your application communicates with the proxy with the standard
database protocol used by your database. The proxy uses a secure
tunnel to communicate with its companion process running on the
server.
If you don't leave the Cloud SQL Proxy running in a tab, the secure tunnel is not created and is not possible to access Cloud SQL.
There are other issues that can cause this problem but according to the research I did "googling" the error, this looks like the most common.
We plan to use Appengine for our Node.JS REST-API which will serve content for our customers. The data will come from a MOngoDB Cluster (or Replicaset), which will also be hosted on Google Cloud Services. Some of the contents might be cached using the Memcache of AppEngine.
Now my question. Is it neccessary to setup a kind of VLAN or similar, to connect to the DB server? How can we assure that the DB server is connected with a good bandwidth / latency to the AppEngine instances? Or is this no matter of concern at all?
Another question, does Google Cloud have a kind of internal DNS, which can be used? So for example that we have a domainname like "ourmongodb.internal" which can be used in connection string of our REST API? Or how is the most recent approach to connect to our DB server instance?
If you use app engine flex you can setup your nodejs app engine server and the GCE VMs that run the mogoDB cluster in the same network and than connect them both in the internal IP space.
Using the recommended way of connecting a .Net application running in App Engine Flexible .Net to SQL AppEngine Flex (all networks allowed to connect to MySql Instance with SSL) we saw many unauthenticated logon attempts that we assume have caused some of our connection issues recently.
Is there no better(More Secure) way to connect?
Can't we use Google Cloud SQL Proxy to rather connect and limit authorized networks using standard capability?
The fix to using .Net Core apps in AppEngine Flex and connect to your CloudSQL instances is to use a implementation of cloudsql proxy.
I have a rails application deployed on google app engine. I visit myapp.com/resque with a local redis server running and it works. When doing this in production, I cant seem to connect. I have a redis vm instance deployed on google compute engine and I cannot redis-cli -h 123.123.123:6379 into it on any of the servers. It only returns Could not connect to Redis at 11.111.11.1:6379: Connection refused. I've tried using both the internal and external IPs and no luck.
I had the same issue.
It was due to bind in redis conf. By default redis was binded to only 127.0.0.1
It's in redis.conf file
bind 127.0.0.1
As mentioned in redis security link its there so that only trusted clients are allowed to connect and by default its only localhost