A cloud engineer needs to execute a gradual canary rollout of a new container image for an existing Cloud Run service named `order-processor`. The rollout must first direct 10% of live traffic to the new revision using a revision tag for testing, verify stability, and finally route 100% of traffic to the new revision. Arrange the following deployment and traffic management steps in the correct operational sequence.
- 1Deploy the updated container image using `gcloud run deploy order-processor` with `--no-traffic` and `--tag canary-v2` to create an isolated, tagged revision.
- 2Execute `gcloud run services update-traffic order-processor --to-tags canary-v2=10` to split production traffic between the main deployment and the canary tag.
- 3Analyze latency metrics and HTTP status code distribution in Cloud Logging filtered by the `canary-v2` revision tag.
- 4Execute `gcloud run services update-traffic order-processor --to-latest` to route 100% of main production traffic to the new revision.
Answer
The correct operational sequence is: 1) Deploy the container image with `--no-traffic` and `--tag canary-v2`, 2) Split 10% of production traffic to `canary-v2` using `gcloud run services update-traffic`, 3) Analyze metrics and error rates in Cloud Logging for `canary-v2`, 4) Shift 100% of traffic to the verified revision using `--to-latest`.
The deployment sequence begins by isolating the new revision using `gcloud run deploy` with `--no-traffic` and `--tag canary-v2`. Next, a canary split is established with `gcloud run services update-traffic --to-tags canary-v2=10`. Telemetry and error logs are then monitored in Cloud Logging specifically for the canary revision. Once stability is verified, all live production traffic is promoted to the new revision using `--to-latest`.
Step-by-Step Solution
Key Concept
Cloud Run revision tagging, traffic splitting, and canary release workflows