Google Cloud Run


Are there any instructions for installing OrientDB on Google Cloud Run?


I received a response from Google:

Thank you for contacting Google Cloud Platform Support, I understand you’re having issues deploying an OrientDB container on Cloud Run.

Firstly, I need to mention that Cloud Run [1] is currently in Beta [2] and should not be used for production purposes as it might be changed in backward-incompatible ways, while not subject to any SLA or deprecation policy.

Based on the logs I was able to retrieve, it seems that the deployment is failing because of out of memory (oom) issues [3]. Due to memory constraints in its corresponding container, OrientDB fails to set the ‘storage.wal.maxSegmentSize’ property [4], and the deployment subsequently fails [5].

Additionally, I was also able to observe in the internal logs a few of these errors ‘Container Sandbox Limitation: Unsupported syscall getsockopt(…)’. Although not necessarily an issue in itself, if this specific deployment depends on inbound websockets and gRPC without properly error handling, it will subsequently fail since these are currently not supported [6].

Let me know if this clear things up, and if I can go ahead and close this case. Keep in mind that you can always reopen it within 30 days. It will be my pleasure to assist you further. In any case, I will continue to hold it open until Friday to give you time to review the above.

Kind regards

I don’t think running a database in Cloud Run is probably a good idea anyways. You can set up OrientDB from a container using Compute Engine VMs, or deploy it to Kubernetes.

“I don’t think running a database in Cloud Run is probably a good idea anyways.”

That’s not an answer…

Sorry, I should have expanded on my reasoning.

Google Cloud Run is a stateless, serverless environment. The containers which are run there do not have persistent filesystems and should not rely on any stateful behavior, like writing or reading files.

Databases are stateful servers. They rely on persistent storage and the ability to track state over a long period of time.

For serverless architecture, you want a persistent database or database cluster to store all application state (i.e. Compute Engine or Kubernetes StatefulSets), and then you want all application logic to live inside small, stateless functions (Cloud Run) and read/write all data to/from that persistent database layer. These are complimentary concepts; Cloud Run does not replace stateful databases, it just shifts all the responsibility for statefulness to the database and away from the logic code.

Basically, Cloud Run does the serverless functions part very well. It was not designed to do everything well. For persistent databases, a stable VM or Kubernetes StatefulSet is still the primary tool.

I can’t think of any reliable way to run any database in Cloud Run. The only way I think you could possibly do it is to export the entire contents of the database to external storage at the end of every request, and load them back in at the beginning of the next request. That would be a bad idea. As your database grows, you would experience horrible delays on the start of each request. Plus, as it takes longer and longer to write all the data out, your Cloud Run containers would stay open longer and longer at the end of requests, racking up your bill. On top of that, if you have more than one function running at once (very likely in any serverless setup), you would have to synchronize the reads/writes of the database backup to external storage so they didn’t conflict with one another. I don’t know how that could possibly be managed effectively.