Stratus Guides - Zero Downtime Deployment
Autoscaling must be enabled to use Zero Downtime Deployment (ZDD). Learn more about Autoscaling.
How it works
ZDD consists of two Webscale STRATUS CLI commands, the zerodowntime.init command followed by the zerodowntime.switch command.
Prior to running any of the commands, you should enable Autoscaling and the Zero Downtime Deploy option on the Autoscaling page in the Webscale STRATUS panel. Enabling ZDD may take up to a minute of downtime.
With autoscaling enabled, you can now perform zero downtime deploys. An example flow:
- Deploy your updated code to your STRATUS environment.
- Run any needed M2 commands
- Run the init CLI command stratus zerodowntime.init
- Wait for the init to complete
- Run the switch command to switch over to the new code base stratus zerodowntime.switch
The init command creates additional PHP-FPM containers with your current code base. When you call the switch command, Nginx is updated to point to the new containers, and the old containers are gracefully terminated. Any remaining connections are allowed to complete on the older codebase. During the init stage, the code you see within the SSH shell or over SFTP is not live, other than files in directories marked as Shared in the autoscaling configuration. Autoscaling and the init phase copy your code to the PHP-FPM containers directly separate from what you see via SSH. Even after the switch, changing code via SSH will not be reflected live without redeploying via ZDD or the stratus autoscaling.reinit command to copy the code back out to the PHP-FPM containers
Detailed Example deployment
A detailed example of a deployment example is located in our Gitub
Short Example deployment
Below is a short & simple example of a deployment script. At the beginning, all commands that edit or update the file system (the code base) like deploying static content etc should run. After that, the init command deploys the code to new PHP-FPM containers. Once the initialization is complete, then you can switch over to the new code base (zerodowntime.switch). Then all the caches are cleared. Clearing the PHP Opcache is not necessary since new PHP-FPM containers are created.
/usr/share/stratus/cli crons.stop
### PUSH NEW CODE/UPDATES HERE
### git pull etc
/usr/local/bin/php -dmemory_limit=8000M bin/magento setup:upgrade;
/usr/local/bin/php -dmemory_limit=8000M bin/magento setup:di:compile;
/usr/local/bin/php -dmemory_limit=8000M /usr/local/bin/composer dump-autoload --no-dev --optimize --apcu;
/usr/local/bin/php -dmemory_limit=8000M bin/magento setup:static-content:deploy --jobs=$(nproc);
/usr/share/stratus/cli zerodowntime.init;
/usr/share/stratus/cli zerodowntime.switch
echo "\e[41m****Flushing Magento, Varnish, Redis and CloudFront CDN cache at this stage****";
/usr/local/bin/php -dmemory_limit=8000M bin/magento cache:flush;
/usr/share/stratus/cli cache.cloudfront.invalidate
/usr/share/stratus/cli cache.varnish.clear;
redis-cli -h redis flushall && redis-cli -h redis-config-cache -p 6381 flushall;
echo "\e[41m****Deployment Finished Site Enabled and tested****";
status_code=$(curl -kI --header 'Host: {yourhost}.com' --write-out %{http_code} --silent --output /dev/null 'https://nginx/')
if [[ "$status_code" -ne 200 ]] ; then
echo "Site not active $status_code please push script again"
else
echo "\e[41m****Beginning Indexing****";
n98-magerun2 sys:cron:run indexer_reindex_all_invalid;
n98-magerun2 sys:cron:run indexer_update_all_views;
/usr/share/stratus/cli crons.start
Note on symlinks
When using a deployment tool such as Jenkins, Capistrano, Deployer or similar where deployment changes/recreates a new symlink, please note that you should clear the var/cron directory afterward and empty the cron_schedule table in the database.
Note on split crons
Your cron pod will restart automatically with ZDD commands.
Feedback
Was this page helpful?
Glad to hear it! Have any more feedback? Please share it here.
Sorry to hear that. Have any more feedback? Please share it here.