I'm working on a website currently organized into two Docker images:, one for the backend and one for the frontend that are uploaded to Google Cloud Containers and deployed to two Cloud Run services that listen to each other's ports. I need to switch the backend to GCP Batch because I need the GPU to spead up some heavy data processing.
I've been reading the documentation of GCP Batch and testing the examples provided by Google, however I couldn't find much about Batch usage with a web server, specifically to tell me what url/port should be used. When the container image is uploaded on Cloud Run, there's a URL associated with the backend service that I can then use to access the API points and trigger changes in the frontend, and vice versa. I'm not sure I could find something similar for Google Batch.
Once the image had been uplaoded to GCP Batch, I could see it was running and access the logs tab, but that was about it. For reference the Dockerfile for the backend does include the line for Uvicorn to start the server and listen on a specific port so when I uploaded the backend on Google Batch to test it out, I checked if it was running on the local host but it'd only show me the "Unable to connect" error page.
Here's what the logs page shows me:
(For this attempt, I haven't started the job using the JSON file that requests a GPU yet. I just wanted to figure out how the frontend could reach the backend from Cloud Run to GCP Batch).
I also looked into the documentation for Google Workflows (how to write the YAML file) and Batch (How to write the JSON file), but they only reference the image URI as far as I can tell.
TLDR; Any idea on how to access the backend on GCP Batch from a Cloud Run service, or if there is a better way to go about this?
Google Batch is a batch service, similar to Cloud Run jobs but with more option in term of duration and hardware.
In short: you create a VM, you run your container until the batch (the job, the process) is over, and delete the VM.
By saying that, you can easily understand that you don't have realtime/interactive service with a webserver. you simply have a process that run in backend.
Cloud Batch (and cloud run jobs) is designed to run async processes in background.
If you want to serve an API with GPU capability, you have no other option than hosting it on a VM (This VM can be managed in a GKE cluster, and it become a NODE in the pool of your cluster).
Maybe a day GPU will be added to Cloud Run, but not sure for now (especially due to the recurrent shortage in GPU availability.)