,
4 tweets,
1 min read
Read on Twitter
Wow, lots of interest in my shitty cron deploys. Ok, here's how they work (or how I wired them up three years ago anyway):
CI/CD does its thing on each commit. As a last step, it uploads version stamped artifacts to S3.
CI/CD does its thing on each commit. As a last step, it uploads version stamped artifacts to S3.
Every service runs in an ASG named after the service that runs there. Every 30 min or so from cron, a shitty bash script runs that checks s3 for a newer artifact for its service name.
If it finds one, it sleeps random seconds and then fetches and installs it.
If it finds one, it sleeps random seconds and then fetches and installs it.
The script is smart enough to revert and start back up the old version if the new one can't start up for some reason.
You can also invoke a rolling restart by just using dsh to run the deploy script instead of waiting for cron.
You can also invoke a rolling restart by just using dsh to run the deploy script instead of waiting for cron.
Db migrations need to be run by a human. Deploy won't succeed if migrations out of date.
Service name gets interpolated from terraform config into everything to hostname, ec2 tags, chef role, asg config, deploy target, binary, log file name, you name it. Hella. Useful.
Service name gets interpolated from terraform config into everything to hostname, ec2 tags, chef role, asg config, deploy target, binary, log file name, you name it. Hella. Useful.
