It took me way more time than I’d imagine to add an automated S3-to-EC2 deploy via CodeDeploy & CodePipeline. Such an arduous journey that I’d rather not wish to repeat without the following notes.
The immediate sign of trouble was mysterious differences between A) the ‘revision’ as reported by CodePipeline and stored in its S3 bucket and B) what CodeDeploy received on the target EC2 instance. In other words,
appspec.yml, and the scripts it refered to, differed between target EC2 and what was reported as the latest revision on CodeDeploy’s deployment.
In hindsight, I would’ve rather deployed my own webhooks on target EC2s. Or skipped straight to an EKS deployment for these legacy services as well. The agent is still burdened by memory leaks and plethora of other issues.
All in all, the whole saga left a bitter aftertaste, since 1) I never would’ve expected that, for setting a mere CD pipeline, one would have to read that much documentation, and more importantly, 2) that the CodeDeploy agent can’t gracefully handle manual intervention, such as deleting older deployment
When you do a deployment, it (
codedeploy-agent) will actually use the ApplicationStop from your last successful deployment, not your current deployment.