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.
Related
Currently, I have followed the google docs quick start docs for deploying a simple cloud run web server that is connected to AlloyDB. However, in the docs, it all seem to point towards of having to utilize VM for a postgreSQL client, which then is connected to my AlloyDB cluster instance. I believe a connection can only be made within the same VPC and/or a proxy service via the VM(? Please correct me if I'm wrong)
I was wondering, if I only want to give access to services within the same VPC, is having a VM a must? or is there another way?
You're correct. AlloyDB currently only allows connecting via Private IP, so the only way to talk directly to the instances is within the same VPC. The reason all the tutorials (e.g. https://cloud.google.com/alloydb/docs/quickstart/integrate-cloud-run, which is likely the quickstart you mention) talk about a VM is that in order to create your databases themselves within the AlloyDB cluster, set user grants, etc, you need to be able to talk to it from inside the VPC. Another option for example, would be to set up Cloud VPN to some local network to connect your LAN to the VPC directly. But that's slow, costly, and kind of a pain.
Cloud Run itself does not require the VM piece, the quickstart I linked to above walks through setting up the Serverless VPC Connector which is the required piece to connect Cloud Run to AlloyDB. The VM in those instructions is only for configuring the PG database itself. So once you've done all the configuration you need, you can shut down the VM so it's not costing you anything. If you needed to step back in to make configuration changes, you can spin the VM back up, but it's not something that needs to be running for the Cloud Run -> AlloyDB connection.
Providing public ip functionality for AlloyDB is on the roadmap, but I don't have any kind of timeframe for when it will be implemented.
I currently develop a small Java web application with following stack: Java 8, Spring Boot, Hibernate, MariaDB, Docker, AWS (RDS, Fargate, etc.). I use AWS to deploy and to run my application. My java web application runs inside of the docker container, which is managed by AWS Fargate; this web application communicates with Amazon RDS (MariaDB instance) via injected secrets and doesn't need to go through public internet for this kind of communication (instead it uses VPC). My recent problems have begun after I've managed to roll out an software update, that enforced me to make some manual database changes with use of MySQL Workbench and I could not perform this because of local connectivity problems.
Therefore my biggest problem right now is the connectivity to the database from the local machine - I simply can't connect to the RDS instance via MySQL Workbench or even from within the IDE (but it used to work before without such problems). MySQL Workbench gave me following error message as a hint:
After check of given hints from MySQL Workbench I've also checked that:
I use valid database credentials, URL and port (the app in Fargate has the same secrets injected)
Public accessibility flag on RDS is (temporarily) set to "yes"
database security group allows MySQL/Aurora connections from my IP Address range (I've also tested the 0.0.0.0/0 range without further luck)
Therefore my question is: what else should I check to find out the reason of my connectivity failure?
After I've changed my laptop network by switching to the mobile internet the connectivity problem was solved - therefore I suspect, that my laptop was not able to establish the socket connection from the previous network (possibly the communication port or DNS was blocked).
Therefore also don't forget to check the network connectivity by establishing a socket connection like it is described in this answer.
I am trying to simulate an on-premises solution on GCP.
I am not able to bridge with the GCE NIC and get DHCP working on that.
I have isolated the issue and also successfully tests the similar thing on a sandboxed Vagrant (VirtualBox) setup.
Both approaches are scripted and available on the following repos:
https://github.com/htssouza/ovs-gcp-issue
The DHCP functionality for Compute Engine only provides and manages the IP address for the instance itself. It does not function as a general purpose DHCP server for other clients running hosted inside the instance.
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.
I have one instance of a Windows Server 12 R2 VM on google cloud that's working properly and I have connected to it successfully using RDP. I have tried to replicate it by creating a snapshot out of it and creating an instance from the snapshot. According to the platform the instance was created, but i can't seem to connect to it or to get a password. When I click "Get windows password" I get this:
forever. When i try to connect to it, I get
I have no idea what to do, any help would be appreciated.Thanks
The password creation tool from the console only works for images builted from the official image repo. In this case your source is a previous VM through a snapshot. In that case, and also in migrations all the previous credentials are kept in the new VM. You can download the GCP RDP agent here and access using the credential you used to have in your source VM.
Connecting to a Windows Instance
https://cloud.google.com/compute/docs/instances/windows/connecting-to-windows-instance
-----------Update----------------
In the case you can not get to enter the VM, it seems to be a firewall rules issue. By default the port tcp:3389(RDP access) is open to all VM at the default network, check your VM is in that network or check if the firewall rule has a tag to be applied.
If not, apply a tag to your new machine and create a firewall rule tobe applied to that tag.
Hope it help. Keep us posted!