Hi! I have done this before with EasyEngine v3 (pretty much the same as WordOps). I gave a talk about this (video: https://wordpress.tv/2016/11/22/russell-heimlich-scaling-up-wordpress-on-amazon-web-services/, slides: https://slides.russellheimlich.com/scaling-wordpress-on-aws/#/)
The biggest thing to consider to get this to work is you can't rely on the local storage of the server. You need to distribute everything because if you bring up/kill servers they will get out of sync. I'll explain.
1) Be prepared to have an external database. If you have multiple servers they can't each have their own copy of a database on it. Amazon RDS service is well worth the money. The service is managed and scalable to meet your needs without you needing to do anything. I had no problems with Amazon Aurora (it's MySQL compatible and cheaper pricing) https://aws.amazon.com/rds/aurora/?aurora-whats-new.sort-by=item.additionalFields.postDateTime&aurora-whats-new.sort-order=desc
2) Store uploaded media in an S3 bucket. A free plugin like https://github.com/humanmade/S3-Uploads works great. When media gets uploaded to the media library the media is copied to an S3 bucket and the plugin rewrites the URLs for you automatically. This way you don't need to worry about keeping the local hard drives of your servers in sync with uploaded media items.
3) If you're going to use page caching WordOps is great for this with their Redis caching option. All of the servers in your cluster can use the same cache. Amazon's Elasticache service is great for this (https://aws.amazon.com/elasticache/) You can get by with the smallest instance too.
4) Be prepared to not use the typical plugin update from within the WordPress admin. Why? When you update a plugin the files will be copied to whatever server you happened to visit when you performed the update. One server will have an updated plugin file but other servers won't. In my situation it was ok that the entire site was version controlled and plugin updates were done locally, committed, and then deployed to the live servers.
5) You need a Continuous Integration/Continuous Deployment (CI/CD) pipeline in place in order to get changes to your servers. My favorite approach to this was to have a build-specific version of your repo. When you push a commit to the main branch in your repo a process would kick off to
- Compile Sass/JavaScript files
- Update any dependencies from Composer or NPM
- Commit the compiled assets directly to the build repo
- Trigger the process of letting each server know there is an update and they should do a git pull to bring down the latest changes.
I also gave a talk about how this CI/CD pipeline worked
- Video:
- Slides: https://slides.russellheimlich.com/circleci-aws/#/
Once you get everything set up it is great to be able to setup rules to have your servers grow and contract based on traffic needs. If you have any questions or need any help feel free to reach out: kingkool68 at the gmail.