You want to deploy an application on Cloud Run that processes messages from a Cloud Pub/Sub topic. You want to follow Google-recommended practices. What should you do?
A.
1. Create a Cloud Function that uses a Cloud Pub/Sub trigger on that topic. 2. Call your application on Cloud Run from the Cloud Function for every message.
B.
1. Grant the Pub/Sub Subscriber role to the service account used by Cloud Run. 2. Create a Cloud Pub/Sub subscription for that topic. 3. Make your application pull messages from that subscription.
C.
1. Create a service account. 2. Give the Cloud Run Invoker role to that service account for your Cloud Run application. 3. Create a Cloud Pub/Sub subscription that uses that service account and uses your Cloud Run application as the push endpoint.
D.
1. Deploy your application on Cloud Run on GKE with the connectivity set to Internal. 2. Create a Cloud Pub/Sub subscription for that topic. 3. In the same Google Kubernetes Engine cluster as your application, deploy a container that takes the messages and sends them to your application.
why c ?
explained>>
You can use Pub/Sub to push messages to the endpoint of your Cloud Run service, where the messages are subsequently delivered to containers as HTTP requests. You cannot use Pub/Sub pull subscriptions because Cloud Run only allocates CPU during the processing of a request.
Here's why Option B might be preferred over Option C:
Service Account Permissions: Option C involves creating a separate service account and granting it the Cloud Run Invoker role.
Direct Subscription Configuration: Option B allows for a direct configuration of a Cloud Pub/Sub subscription to pull messages from the topic eliminating the need to manage service accounts and roles separately.
Standard Practice: Granting the Pub/Sub Subscriber role directly to the service account used by Cloud Run is a standard practice for allowing Cloud Run services to access Pub/Sub topics follows the principle of least privilege by granting only the necessary permissions to the service account.
Push vs. Pull Model: Option C uses a push model where Cloud Pub/Sub sends messages directly to the Cloud Run service. While this model can work, it requires additional setup for configuring the push endpoint
Overall, Option B provides a simpler and more direct approach to integrating Cloud Run with Cloud Pub/Sub, aligning well with Google-recommended practices
it is explicated recommended use " push" :
Note: Google recommends using push subscriptions to consume messages from a Pub/Sub topic on Cloud Run. Although it is possible to use Pub/Sub pull subscriptions, pull subscriptions require you to monitor message delivery latency and manually scale the number of instances to maintain a healthy delivery latency. If you want to use pull subscriptions, use the CPU always allocated setting along with a number of minimum instances.
https://cloud.google.com/run/docs/triggering/pubsub-push
Answer B, I would say is the correct answer for me.
When you want to deploy an application on Cloud Run that processes messages from a Cloud Pub/Sub topic, you should follow Google-recommended practices to ensure that your application can securely and reliably process the messages.
Answer A is not the correct answer because using a Cloud Function to call your application on Cloud Run for every message adds additional complexity and potential points of failure.
Answer C is not the correct answer ALTHOUGH it is possible to create a subscription that uses Cloud Run as the push endpoint, it requires an additional setup that is not necessary for this use case. Additionally, this approach requires your Cloud Run service to be publicly accessible.
Answer D is not the correct answer because it requires deploying a container in a Kubernetes cluster to handle the Pub/Sub messages and forward them to Cloud Run. This adds additional complexity to the architecture, and Cloud Run can directly subscribe to a Pub/Sub topic without needing a proxy service in between.
Therefore, the recommended approach is to grant the Pub/Sub Subscriber role to the service account used by Cloud Run and create a Cloud Pub/Sub subscription for that topic. This approach is straightforward and aligns with Google's best practices for integrating Pub/Sub with Cloud Run.
The advantage of Cloud Run scaling to zero might be a better practice like Shwom suggested.
I also thought B cus of it's straightforward approach, but C seems better now.
Ans is C (push subscription).
I think B (pull subscription) can work, but it does not follow best practices. With pull subscription, you cannot take advantage of scale-to-zero for Cloud Run. Why is this the case? Because you need to keep your subscriber client (Cloud Run in option B) running, otherwise you don't know if there are new messages. (Whereas if you use push subscription instead, you can scale to zero and rest assured that Cloud Run will be "notified" of new messages).
See 3:15 and 4:10 of this video: https://www.youtube.com/watch?v=KObJkda4ZfY
Remember this:
Push subscription -> Pub/Sub server initiates a request to your subscriber client to deliver messages
Pull subscription -> Your subscriber client initiates requests to a Pub/Sub server to retrieve messages
Documentation: https://cloud.google.com/pubsub/docs/subscriber
Ans is C (push subscription).
I think B (pull subscription) can work, but it does not follow best practices. You cannot take advantage of scale-to-zero for Cloud Run. See 3:15 and 4:10 of this video: https://www.youtube.com/watch?v=KObJkda4ZfY
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
Meix
Highly Voted 4 years, 5 months agoChrisBelt5
3 years, 4 months agoBhagirathi
Highly Voted 3 years, 11 months agovarshitag
Most Recent 1 month, 4 weeks agosubha.elumalai
6 months agoDWT33004
7 months, 2 weeks agothewalker
1 year agohanweiCN
1 year, 6 months agoSMR123
1 year, 7 months agodobberzoon
1 year, 7 months agodue
1 year, 8 months agoBuruguduystunstugudunstuy
1 year, 9 months agoBuruguduystunstugudunstuy
1 year, 9 months agospace_cadet
1 year, 9 months agoShwom
1 year, 9 months agoAnirudha077
1 year, 11 months agoPho_King
1 year, 12 months agoaxantroff
1 year, 1 month agoPho_King
1 year, 12 months agoleogor
2 years agoRanjithK
2 years, 4 months ago