Hosting on Cloud Run

[steren]

I am the Product Manager for Google Cloud Run (https://cloud.run), a platform allowing to run containers in a fully managed environment.

I am wondering if open-match can run on Cloud Run.

• If it does, could this be documented?
• if it does not, could you share what's blocking?

[syntxerror]

Hi @steren,
I just had this conversation with someone less than an hour ago and it is something I am going to start exploring before the end of the year. If you'd like, I can follow up with some feedback and share with the wider community as well.

[steren]

Great to hear. Yes, please capture in this issue your findings and progress, and more importantly, any blocker.

[Kiddinglife]

Hey I am wondering if it is possibly to host open match and agones in cloud run and any other db service from gcloud ? self-hosted redis db is not a stable and production choice.

[joeholley]

Hey I am wondering if it is possibly to host open match and agones in cloud run and any other db service from gcloud ? self-hosted redis db is not a stable and production choice.

We're investigating running OM in Cloud Run currently. If you want managed Agones, please take a look at Google Cloud Game Servers. Redis is the only supported state storage for OM today, but you can configure OM to use a managed, HA Redis instance from your favorite cloud provider if you're not comfortable managing your own Redis DB on k8s with the provided images.

[kakugirai]

Hi there, we are also investigating running OpenMatch in Cloud Run and there are several issues we want to share about,

Here is a sample Cloud Run config we use to deploy open-match-frontend.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: open-match-frontend-gen1
  labels:
    cloud.googleapis.com/location: <region>
  annotations:
    run.googleapis.com/ingress: internal
spec:
  template:
    spec:
      serviceAccountName: <service-account@project-name.iam.gserviceaccount.com>
      containers:
      - image: gcr.io/open-match-public-images/openmatch-frontend:1.3.0
        ports:
        - name: h2c
          containerPort: 50504
        resources:
          limits:
            cpu: 1000m
            memory: 512Mi
        volumeMounts:
        - name: secret-matchmaker_config_default
          readOnly: true
          mountPath: /app/config/default/
        - name: secret-matchmaker_config_override
          readOnly: true
          mountPath: /app/config/override/
      volumes:
      - name: secret-matchmaker_config_default
        secret:
          secretName: matchmaker_config_default
          items:
          - key: latest
            path: matchmaker_config_default.yaml
      - name: secret-matchmaker_config_override
        secret:
          secretName: matchmaker_config_override
          items:
          - key: latest
            path: matchmaker_config_override.yaml
  traffic:
  - percent: 100
    latestRevision: true

1. Cloud Run does not support ConfigMap mounting. Although the problem can be solved by mounting ConfigMap storing in the Secret Manager, there is no other better solution we can come up with.
2. While we could successfully mount ConfigMaps via the Secret Manager, there are some system calls in open-match-frontend blocked by Cloud Run (gVisor container sandbox).

Container terminated due to sandbox error.

A workaround we found to bypass this issue is to switch to the second gen execution environment of Cloud Run.

run.googleapis.com/execution-environment: gen2

However, it is a preview feature so we would not consider to use it in the production environment.
We are still investigating if there is a way to trace what system calls in Open Match are blocked by gVisor.

[steren]

Thanks for sharing.
Yes, we expect the second generation execution environment to implement all Linux syscalls.

In the first generation execution environment, the unimplemented syscalls should appear in the container logs with a DEBUG severity.