CODEWITHSUNDEEP
google-cloud-platformgoogle-cloud-run
zino
zino

Reputation: 1612

Cloud Run: Can I get the URL of the exact instance?

Is it possible to get the URL of the exact instance of a Cloud Run process?

I want to use global state in my HTTP server, so that a user can make a second HTTP request with a URL returned from the first request. Both requests should hit the same instance.

Because the second request is immediately after the first, the instance should still be alive.

Upvotes: 1

Views: 1635

Answers (2)

Alexey Zimarev
Alexey Zimarev

Reputation: 19600

It's impossible when using Cloud Run features, but it can be hacked. I am not sure if it's suitable for your case, but here's how it can be done.

On startup, assign a random instance id to a globally accessible static variable. It will be available for the particular instance as long as the container runs.

When making the first call, also return the instance id.

When making the second call, add the instance id to the call (parameter, header, whatever). In the API endpoint code, if the instance id of the request doesn't match the running container instance id, return some pre-defined status code that doesn't indicate success.

The client code needs to handle that status code and retry the call. Eventually, the request will hit the instance you need.

The new session affinity feature makes it more reliable, as the second request will most probably hit the same instance anyway, but I'd keep the check.

Upvotes: 2

Kolban
Kolban

Reputation: 15246

I don't think what you are asking for can be done. I looked at the following documentation on WebSockets and Cloud Run [link] and it states there:

On Cloud Run, session affinity isn't available, so WebSockets requests can potentially end up at different container instances, due to built-in load balancing.

What this tells me is that there is a front-end load balancer that is the public endpoint for a Cloud Run request and the load balancer determines where to send the request. This means which back-end container. I am sensing that these containers literally have no addressable (direct) IP address or other endpoint that you can leverage. There simply is no way to specify in a subsequent HTTP request that it should go back to the same server instances as a previous request.

Is this a limitation? I'd be tempted to say no. The contract for Cloud Run is that it will service a request and scale as needed to service those requests ... but nowhere in the contract does it make any claims about the state of the server from request to request. One should assume that the container is virgin when reached for every request.

So how do you handle Global State? You don't maintain it in your container/WebServer ... instead, you maintain it in a state management service. Examples would be a SQL database (eg. Cloud SQL), a document database (eg. Cloud Datastore) or a REDIS system (Cloud Memorystore). All of those services are "managed as a service" and can be reached from Cloud Run instances.

Upvotes: 4

Related Questions