Shipping best practice with juju charms
Check out Why I don’t host my own blog anymore.
I mentioned it to a friend and he immediately piped in “Oh that guy did it wrong, he shouldn’t care about KeepAlive, he needs FastCGI”.
Ok so the guy “messed up” and misconfigured his blog. Zigged instead of zagged. Bummer.
But it doesn’t have to be this way. Right now we offer Wordpress as a juju charm. This lets us deploy Wordpress with Mysql in 4 commands.
However if you look at the db-relation-hook we don’t do anything special, we create an apache vhost and set it up for you. While this is simple, there’s no reason we can’t make this charm be a turbo charged deployment of Wordpress. Let’s look at some of the recommendations we see on his blog and on HN:
- A simple caching plugin would have quickly fixed this for you.
- In my stacks I always use nginx in conjunction with Apache to handle as much of the static content load as is possible and that lifts a huge weight from Apache. Next up is to always use a bytecode cache like Xcache or APC, these help give a huge boost in performance.
- But then you hit a wall, next up are limitations in WP SQL and MySQL, these can be helped by messing with the queries and using Memcached also helps to significantly boost the DB performance here.
- I had similar nightmares to you for a long time with Apache/PHP/WP, then finally put Varnish cache in front of the whole thing.
- And someone recommends just shoving the thing in Jekyll and serving that.
I’m sure everyone will have an opinion on how to deploy Wordpress. From an Ubuntu perspective, we ship the wordpress and mysql packages, but that only gets you so far. It’s still up to you to configure it, and as this guy proves, you can mess something up. Wouldn’t it be nice if we could collect all the experience from people who are Wordpress deployment experts, put that in our charms and just give people that out of the box?
We could use nginx in the Wordpress charm, with FastCGI, we can certainly add relations to make varnish and memcached know what to do when they’re related to wordpress. And/or just “juju add-relation jekyll wordpress” and have that Just Work.
These are the kinds of problems we’re trying to tackle with juju. Will it be totally perfect for everyone’s deployment? Of course not, that’s impossible, but we can certainly make Patrick’s experience more uncommon. People will always argue about the nitnoid implementation details, but we can make those config options; the point is that we can share deployment and service maintenance as a whole instead of hoping people put the lego blocks together in the right order.
Interested in turning a plain boring charm into something sexy? I’ve filed the bug here, let us know if you’re interested.
See you at SCALE!
I can’t wait to see some people I haven’t seen in years at SCALE, and meet a bunch of new people!
Come find me and Clint, we’ll be doing talks about juju and Ubuntu Cloud all weekend, as well as answering questions the entire time. I’m easy to find, look for a Red Wings hat and an Ubuntu shirt.
Here’s our post about our talks.
Our first Charm School!
We’re holding a Charm School on IRC.
juju Charm School is a virtual event where a juju expert is available to answer questions about writing your own juju charms. The intended audience are people who deploy software and want to contribute charms to the wider devops community to make deploying in the public and private cloud easy.
Attendees are more than welcome to:
- Ask questions about juju and charms
- Ask for help modifying existing scripts and make charms out of them
- Ask for peer review on existing charms you might be working on.
Though not required, we recommend that you have |juju installed and configured if you want to get deep into the event.