Replace a service with a rolling deployment
Create replacement guests, validate readiness, drain old backends, and preserve a rollback path.
A rolling replacement introduces new application instances before removing their predecessors. This procedure combines pinned templates, placement groups, load-balancer readiness, connection draining, and explicit cleanup.
Establish the replacement boundary
Use Compute → Templates → Template → Revisions for the pinned guest definition and Networking → Load balancers → Load balancer → Backends for admission and drain. Track the change at Operations → History using its operation IDs.
Use a stateless web service with at least two backends as the initial pattern. Database schema changes and stateful primary promotion require the application's own compatibility procedure. A rolling guest replacement cannot make an incompatible database migration reversible.
Record the current template revision, backend membership, addresses, image, secret references, and active application version. Establish a health check that opens the dependencies the service needs to handle a real request. A static home page is insufficient when the application requires a database.
Reserve overlap capacity
The project needs quota and eligible hardware for old and new instances at the same time. Required zone spread can constrain which replacement starts first. A fleet can have sufficient final capacity while lacking the overlap required to perform this workflow.
Do not delete an old instance merely to make a preflight green unless the approved availability plan permits the reduced replica count. Add temporary headroom or choose an explicit maintenance outage instead.
Publish and create
Create a new template revision pinned to the tested
image. Keep the service label separate from rollout stage, such as service=web
and rollout=candidate. Use a backend selector that will not register candidates
before their validation is complete.
Deploy one replacement with a unique idempotency key. Poll its operation to a
terminal result, then inspect guest initialization and application readiness.
An infrastructure result of succeeded alone does not establish that application
migration scripts or external credential exchange finished.
If creation fails, inspect retained disks and reservations before starting another request. A new key creates another intended deployment rather than recovering the response to the previous one.
Admit the candidate
Verify application version, dependency access, secret revision, and a representative request on the private endpoint. Add the candidate to the backend group and wait for the configured healthy threshold and applied membership revision.
Observe error rate and request latency before adding the next replacement. A healthy probe with failed real requests requires an application investigation; changing the probe to always pass does not validate the deployment.
Drain one predecessor
Select an old backend and start connection draining. Wait for the membership revision to stop new selection, then observe active connections and application jobs. After completion or the approved timeout, remove the backend and stop the old application.
Keep the old guest stopped with its required disks until the rollback period ends. This retains quota and storage usage. Document that overlap instead of assuming a stopped guest releases every reservation.
Repeat the sequence one predecessor at a time. Keep enough independent healthy members to satisfy the service's availability requirement throughout the change.
Roll back
Stop admitting new candidates. Reactivate a compatible retained predecessor, verify its readiness, and drain failed candidates before removing them. Connections already lost cannot be reconstructed by backend reactivation.
If the new version changed authoritative data, verify that the previous version can read that data before using it as rollback. Otherwise follow the application's forward-recovery procedure. Restoring an older disk snapshot can discard valid writes made during the rollout.
Close the change
Update the blueprint or deployment inventory to the surviving resource IDs. Remove temporary candidates, obsolete disks, and unused address reservations according to retention policy. Verify backup selection and alert selectors against the final labels.
Export the deployment's parent operation and child outcomes when change review requires evidence. Approval, guest creation, backend health, and application validation are separate records of the deployment.