@logan and @tad have been making progress on a new approach for providing WordPress services to communities. They’re using docker and something called “main.”
Can you guys give a better explanation and also an update on your progress?
@logan and @tad have been making progress on a new approach for providing WordPress services to communities. They’re using docker and something called “main.”
Can you guys give a better explanation and also an update on your progress?
I guess I’ll start this off.
So, fixing WordPress for our local communities has been a huge priority for the past year and a half or so. Right now, each community has its own, self-maintained installation, usually on shared hosting, with the risk of installing plugins that have vulnerabilities or not updating WordPress frequently enough and putting the servers at risk.
The original solution for fixing this was WordPress Multisite. What originally seemed like a panacea turned out to be the bane of my existence. Issues with domain mapping and incompatible plugins became huge annoyances that forced us to look into alternate ideas.
Docker is the hot thing right now. If you read any tech blog that’s focused on operations, you’ll see a recent post about it. @tad discovered this awesome tool called Tutum that hooks up to your cloud infrastructure and makes it insanely easy to deploy and scale applications in Docker containers, including WordPress.
Working with Tutum has been an absolute breeze, and we’re currently configuring a Dockerfile that will install all of the plugins, themes, and customizations we need and make WordPress completely stateless. When I say “stateless,” I mean that we can redeploy or scale up a given WordPress site, and everything will be the way it was before. You can check out our work in our GitHub repository for the Docker image.
We are trying to work quickly, but we don’t have an ETA at this point. What I can say is that this seems to be a really awesome solution so far, and any snags that we’ve hit have been resolved quite easily. Please let me know if you have any questions, and @tad, please fill in any details that I didn’t get to.
I was checking at the current technical specs for WPaaS and have some questions/comments.
Are we sure we want to use tutum? They discourage people to use it for production, since it’s still in beta and it lacks many important features (like teams). Since AWS has a PaaS solution itself (Beanstalk) why not use that one instead? It auto-scales, so we don’t need to run many instances for low traffic blogs. We could use this with either docker or php runtime.
I see MaxCDN on specs. I think it’s a bit early to determine if using a CDN is something we’ll need from the very beginning but if we do, why not use AWS’s own CDN (CloudFront)? Keep also in mind that traffic inside AWS is free.
We’ve considered all of those points before, and came to the conclusion that we still want to go with Tutum, and MaxCDN
Tutum may be beta, and they do say to not use in production. But honestly, it’s just docker. If everything crashes and burns at tutum, our docker is still there, and anyways, Tutum doesn’t seem to be on that path. They’re doing well
As for beanstalk… it creates an instance per site. That’s expensive. I also found that it, like most of AWS, wasn’t fun to make changes to once you were running.
CDN absolutely is needed at launch. We want a 700ms response time from Pingdom, or less. Good response time leads to happier users and also better SEO
We chose MaxCDN because CloudFront is a bit difficult to implement for every single site. Takes a while to deploy each distribution, and making changes also takes a while. MaxCDN is instant, and even better… it’s free. We managed to persuade them to sponsor us some time back
Thanks Tad. Just one clarification question.
So does this mean that for low traffic blogs we can setup tutum have more than one Wordpress containers per EC2 instance?
This whole system is clustered.
On one EC2 node, we could be running 20-30 webheads for sites, all duplicated across at least 1 other node for HA
A single site wouldn’t have two containers on one node, but it would always have at least 2 containers across the cluster. Even small sites. Larger sites can be scaled up as needed