I recently created a redis instance in Google Cloud Platform Memorystore and was trying to connect to it using Cloud Shell.
telnet 10.0.0.3 6379
Trying 10.0.0.3...
telnet: Unable to connect to remote host: Connection timed out
But always I'm getting a connection timeout issue. As per the documentation it states the compute instances which are in the same project should be able to connect to the instance. Did anyone also encounter the same issue ? and are there any resolutions for testing it locally ?
Cloud Shell is very limited. The port that you are trying to connect to is not allowed for outgoing connections. The documentation you shared is referring to a GCE (Google Compute Engine) VM instance, yes Cloud Shell provides a temporary instance but it is very limited. At the moment you can only access it from Compute Engine VM instances, Kubernetes Engine clusters, and App Engine (flexible & standard) as well as Cloud-Functions, you will need to create a GCE VM and follow the documentation that you mentioned.
Related
I am trying to reach our Postgres SQL server running as a GCP Cloud SQL instance from the PgAdmin 4 tool on desktop. For that you have to whitelist your IP address. Until this point it was working fine, the whole team used IPV4 addresses, but I moved to a new country where my new ISP assigned an IPV6 address to me, and it seems like GCP doesn't allow IPV6 addesses to be whitelisted, thus you can't use them to connect.
Here's a picture of the Connections/Allowed Networks tab:
Is there any kind of solution to this?
Or do they expect me to only have ISPs who assign IPV4 addesses to me?
Thank you.
Alternatively, you could just use the Cloud SQL Auth Proxy directly. You'll have to run an instance of it on your local machine and then PgAdmin can connect to the proxy on localhost.
Yes, there is a workaround for this but not using the UI, instead you need to use the Cloud SDK.
This has recently been added to cloud SDK beta. So as you can see in the documentation for gcloud sql connect:
If you're connecting from an IPv6 address, or are constrained by certain organization policies (restrictPublicIP, restrictAuthorizedNetworks), consider running the beta version of this command to avoid error by connecting through the Cloud SQL proxy: gcloud beta sql connect.
I couldn't find any Feature Requests for this being implemented into the UI at the moment, so if you'd like to have this changed I would suggest you to open one in Google's Issue Tracker system.
I have a Node API deployed to Google CloudRun and it is responsible for managing external servers (clean, new Amazon EC2 Linux VM's), including through SSH and SFTP. SSH and SFTP actually work eventually but the connections take 2-5 MINUTES to initiate. Sometimes they timeout with handshake timeout errors.
The same service running on my laptop, connecting to the same external servers, has no issues and the connections are as fast as any normal SSH connection.
The deployment on CloudRun is pretty standard. I'm running it with a service account that permits access to secrets, etc. Plenty of memory allocated.
I have a VPC Connector set up, and have routed all traffic through the VPC connector, as per the instructions here: https://cloud.google.com/run/docs/configuring/static-outbound-ip
I also tried setting UseDNS no in the /etc/ssh/sshd_config file on the EC2 as per some suggestions online re: slow SSH logins, but that has not make a difference.
I have rebuilt and redeployed the project a few dozen times and all tests are on brand new EC2 instances.
I am attempting these connections using open source wrappers on the Node ssh2 library, node-ssh and ssh2-sftp-client.
Ideas?
Cloud Run works only until you have a HTTP request active.
You proably don't have an active request during this on Cloud Run, as outside of the active request the CPU is throttled.
Best for this pipeline is Cloud Workflows and regular Compute Engine instances.
You can setup a Workflow to start a Compute Engine for this task, and stop once it finished doing the steps.
I am the author of article: Run shell commands and orchestrate Compute Engine VMs with Cloud Workflows it will guide you how to setup.
Executing the Workflow can be triggered by Cloud Scheduler or by HTTP ping.
We have a GCE VM with MySQL server. Firewall rules deny incoming connections from external IP. Our cloud build process requires to perform DB migrations so it needs to connect to MySQL from Cloud Build. I want to add a Firewall rule to allow only cloud builder to connect through 3306 from the external IP address.
Cloud Build does not run on internal network so there is no way to connect from the internal IP.
I tried adding a rule for service account scope but I can't see cloud build service account in the list.
Currently, as mentioned by #guillaume blaquiere, there is a Feature Request. I recommend you to follow it (star) to receive all the updates there. Seems that the FR has been sent to the Cloud Build engineering team and they will evaluate it. Also note that there is not yet an ETA of the implementation.
I am checking Cloud SQL Private IP connections from different types of clients. I could successfully make a connection from an application hosted in a GKE cluster which was created as a VPC-native cluster as described here. Having already done this, I was expecting it would be easier to connect to the Private IP from the same application (which is a simple Spring Boot application) hosted in a GCE VM. Contrary to my expectations this does not appear to be so. It is the same Spring Boot application that I am trying to run inside a VM. But it does not seem to be able to connect to the database. I was expecting some connection error but nothing shows up - no exception thrown. What is strange is I am able connect to the Cloud SQL Private IP via mysqlcommand line from the same VM but not from within the Spring Boot application. Anyone out there who faced this before?
Issue was not related Cloud SQL Private IP. As mentioned in my earlier comment, I was passing active profile info via Kubernetes pod configuration. So the Dockerfile did not have this info. To fix the issue, I had to pass active profile info when the program was initialized outside Kubernetes. This has a lot of helpful answers how to do this. If the program is being started via a docker run command the active profile info can be passed as a command line argument. See here for a useful reference.
So to summarize, Cloud SQL Private IP works fine from a CE VM. No special configuration required at GCE VM end to get this working.
I have a project with Cloud Composer and Cloud SQL.
I am able to connect to Cloud SQL because i edited the yaml of airflow-sqlproxy-service and added my Cloud SQL instance on cloud proxy used for the airflow-db, mapping to port 3307.
The workers can connect to airflow-sqlproxy-service on port 3307 but i think the webserver can't connect to this.
Do i need to add some firewall rule to map the 3307 port so the webserver or the UI can connect to airflow-sqlproxy-service?
https://i.stack.imgur.com/LwKQK.png
https://i.stack.imgur.com/CJf7Q.png
https://i.stack.imgur.com/oC2dJ.png
Best regards.
Composer does not currently support configuring additional sql proxies from the webserver. One workaround for cases like this is to have a separate DAG which loads Airflow Variables with the information needed from the other database (via the workers which do have access), then generate a DAG based on the Variable which the webserver can access.
https://github.com/apache/incubator-airflow/pull/4170 recently got merged (not currently available in Composer), which defines a CloudSQL connection type. This might work for these use cases in the future.