- Newest
- Most votes
- Most comments
These docs provide info on best practices as it relates to using Wordpress on AWS, and I'd highly recommend you take a look: https://docs.aws.amazon.com/whitepapers/latest/best-practices-wordpress/welcome.html (I would ignore the reference architecture diagrams though, those are a bit overkill for your use case).
I would not use session persistence as you described (i.e. to direct traffic to instances with the newer software version during deployments), since session persistence is not designed to be used in that way. The more conventional approach is to take down a subset of your instances (for example, half of your instances), deploy the newer software version to those instances, and then bring them back up to handle traffic; then repeat the process for your remaining instances. This way, you'll be able to deploy your updates without significantly sacrificing availability (since multiple instances will always be available to handle traffic).
However, this means that at a certain point during the deployment, some of your instances will be serving traffic with the new code and some serving traffic with the old code, and for a brief period of time it's possible that requests may hit both old and new instances. You mentioned that this may cause issues; could you provide more detail? This may mean that the updates you're making to your software are not backwards- or forwards-compatible, and should be changed such that they are.
Instead of the manual process you've described to make changes to your webservers, I'd recommend taking advantage of CodePipeline/CodeDeploy to automate the deployment process. Here's a blog post with details on an example setup that uses CodePipeline/CodeDeploy to automatically deploy changes to a Lightsail instance whenever you push changes to a GitHub repo, and may be a good starting point: https://aws.amazon.com/blogs/compute/using-aws-codedeploy-and-aws-codepipeline-to-deploy-applications-to-amazon-lightsail.
Hope that helps!
Relevant content
- Accepted Answerasked 4 years ago
- asked 2 years ago
- asked a year ago
AWS OFFICIALUpdated a year ago- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
Hi, @Invex09 Where and how is your DevOps pipeline built? Are you planning to destroy them all once?
@iwasa thanks for the reply, really not concerned about the transition from the old system to the new one. And the current system is insanely low-fi, probably not even worth calling "DevOps". We just have the whole site in a git repo and scaled down to one instance whenever we pull code changes into production/live. We have a staging environment for testing and going from local up through staging is fine. Its just pulling changes into production that's the issue because traffic is really too high where we shouldn't be scaling down to just one instance ever anymore. Because even for 5-10m, being scaled down to one instance spikes the CPU usage of that one instance to almost 100% very quickly