5 ms·
Ask HN: Is anyone using GCP CloudRun in prod?
UPDATE/EDIT: turns out the issue is that CloudRun only works with Docker images built with the "--platform linux/amd64" flag and I am using an M1 Mac.
======
My team has a web server in a Docker image. There is an ENV variable for the Postgres URL address. Locally, this has the form: "postgres://$USER:$PASSWORD@localhost:5432/$DB_NAME". When this server starts up, it uses that ENV variable and connects to Postgres.
We tried to deploy this to GCP. GCP CloudRun is the stop-gap between Functions ( one HTTP request handler, rather than an app with many ) and GKE ( multiple containers at once). We've used GKE before but we have simpler architecture in this case and CloudRun is, in theory, intended for this use case where you just have a single container. There's AppEngine but CloudRun appears to be more barebones.
We thought we'd use CloudSQL for managed Postgres. You fill out the webform, it creates a machine running Postgres that has some kind of URL address. From the above local example, there's really just two values to consider: the port ( probably the default 5432 ) and the host (which in this case is the IP, rather than "localhost").
On the CloudRun side, we upload our Docker image and specify the environment variable for the Postgres address.
Turns out this exceedingly difficult. It's not obvious at all how to establish this simple connection. After drudging through a dozen form questions, half a dozen rabbit-holes of gibberish docs, and side-questing to enable half a dozen APIs, it seems your CloudRun app can't actually talk to your CloudSQL. You have to go create a default VPC because it is not created by default. Then apparently you have to go create a "VPC connector". After half a dozen attempt at creating these networking resources, you finally succeed. You back to attempt provisioning CloudRun but discover you can't because the VPC connector is not in the same region as the CloudRun instance. So you backtrack once more.
After doing all of this, the CloudRun "service" / Docker image fails to start. We seek clues whether we should investigate that we've incorrectly specified the Postgres address or whether our network config insufficiently provided visibility. We're told something went wrong with the container and there will be clues in logs. We open up the logs viewer and the only errors are from GCP's implementation detail and Daemon. "terminated: Application failed to start: Failed to create init process: failed to load /usr/local/bin/docker-entrypoint.sh: exec format error" rather than the one from our application log. Now CloudRun is in an infinite loop / pending state, so we'll just have to delete it and try all over again.
How are people using CloudRun in production if you can't tell what made the container fail?
- rozenmd 4y agoEdit: nevermind.
- diceduckmonk 4y agoThis seems like the product-market fit.... In the 10 minutes since reading your comment, I breezed through documentation, downloaded the CLI, authenticated, tweaked the code in 2 places: (1) the ENV variable key for the Postgres url and (2) the port of the app from 3000 to 8080. Ran `go build` and in theory, based on the way we structured our app, the one Go binary file is ready to go. I have confidence this might "just work", compared to the 3 hours I already sunk into GCP and who knows how much longer. However, I'm blocked on needing credit card access / friction to proceed further due to my overseas CC. Would be great if someone from Fly.io is reading this and can provide free credits ( in exchange for user research ). We'll see how pricing scales. Maybe GCP/AWS scales at higher scale, but the minimum requirements of GCP to run this single "serverless" container has already involved provisioning half a dozen VMs ( the VPC connector alone needs a minimum of 2. This feels like GCP's problem rather than the customers if they are promoting uploading a container and it "just works". ).
- verdverm 4y agoYou might want to slow down & step back from the problem at hand. Go through basic cloud & DevOps tutorials. There is no need for VMs in a CloudRun + CloudSQL setup. (technically the sql has a VM, but that is abstracted and won't be in your list) Or another way, you should see zero VMs running, no VPC connector is needed.
- diceduckmonk 4y agoUPDATE: Indeed, it turns out that the issue is I built the Docker container on an M1 and CloudRun only works if you built your container with "--platform linux/amd64" ====== > no VPC connector is needed. That's not true. It's enough that Google has released 2 forms of docs on this matter. Additionally, the webform to provision CloudRun also includes a section on VPC Connectors. You need to provision a VPC connector in order for CloudRun, Functions or App Engine to "see" CloudSQL with private IP. https://codelabs.developers.google.com/connecting-to-private-cloudsql-from-cloud-run#0 https://codelabs.developers.google.com/connecting-to-private... The VPC connector is a product which is backed by VMs. Its provisioning / validation rules require at least 2 VMs. You can see the web form yourself: https://console.cloud.google.com/networking/connectors/add?project=$YOUR_PROJECT_ID https://console.cloud.google.com/networking/connectors/add?p... > but that is abstracted and won't be in your list Yes, that's abstracted but you are billed for the vCores. You can see the price sheets and minimum monthly costs here: https://cloud.google.com/sql/pricing https://cloud.google.com/sql/pricing In the case of CloudSQL, sure, it's abstracted, but CloudRun is revealing its leaky abstraction. Here are implementation details you have to know about: https://cloud.google.com/run/docs/container-contract https://cloud.google.com/run/docs/container-contract. For example, it seems my issue could be related to building the container on an M1 mac. https://stackoverflow.com/questions/66127933/cloud-run-failed-to-start-and-then-listen-on-the-port-defined-by-the-port-envi https://stackoverflow.com/questions/66127933/cloud-run-faile...