Can be handled either with multiple upstreams in nginx (where putting an app down via php artisan down — returning 5xx — makes nginx use the other upstream) or by atomically swapping a symlink — blue/green strategy.
Some considerations:
- Need some synchronization, can't have deployments running concurrently*
- Migrations need to be backwards-compatible (i.e. DROP only in the n+2nd deployment after n+1 serves all requests)
- Shared assets — file-based cache, SQLite databases, user data storage etc — need to be either symlinked or just use absolute paths to some location outside these deployed versions, perhaps something in
/var
- Could use something like
/srv/site-foo symlinked to /srv/site-foo-{n}
* Technically not unique to zero downtime deployments, good practice overall, but could be riskier here. Implementing this could be as simple as flock -w 100 /tmp/deployment_{sitename} -c "bash deploy.sh"
Can be handled either with multiple upstreams in nginx (where putting an app down via
php artisan down— returning 5xx — makes nginx use the other upstream) or by atomically swapping a symlink — blue/green strategy.Some considerations:
/var/srv/site-foosymlinked to/srv/site-foo-{n}* Technically not unique to zero downtime deployments, good practice overall, but could be riskier here. Implementing this could be as simple as
flock -w 100 /tmp/deployment_{sitename} -c "bash deploy.sh"