跳转到内容
#0569
AgentContainersCron

Every night a copy of prod gets tomorrow's upgrade

A customer's stack is three runtime versions behind. Upgrading in place is a gamble; rehearsing it used to mean a staging server somebody kept in sync.

At midnight a cron entry starts an agent. It POSTs /containers/{id}/copy to get an independent copy of the production container: same files, same database, its own URLs: and runs the upgrade, the migrations, and the smoke tests there. The first attempt fails on a deprecated config key. The agent fixes it, deletes the copy, copies prod again, retries from clean. The second passes.

At 7am there's a proposal on a todo: the steps that passed, the config change, the test output. You approve. The worker applies the same steps to the real container at 7:30am, when traffic is lowest.

The upgrade that used to need a maintenance window now needs a clone and a night.