Charms, Cloud, juju, Planet, Ubuntu

Deploying OMG! Ubuntu! to the cloud with Juju!

For the last month we’ve been working on getting the perfect charm setup for the OMG! Ubuntu! website. Today we deploy the final version of the charm just in time for the 12.04 release. It’s been a long road, but now that we’ve wrapped this up it’s time to take all the knowledge we’ve gained in the past month about scaling WordPress (from caching to session management) and place it in the stock WordPress charm, making it anything but stock. What has made this otherwise grueling experience easy and enjoyable is Juju. No longer do we have to toil with different environments, upgrade paths, or even major documentation. Since we’ve encapsulated all of our tweaks in the charm, deploying and performing large upgrades is relatively streamlined.

To demonstrate how easy it is to get OMG! Ubuntu! running I’ve recorded the latest deployment on where I created a new environment, bootstrapped it, deployed, then re-pointed the IP address in AWS. What you see in the terminal cast is what’s running OMG! Ubuntu! right now. Compared to traditional deployments, the process is effortless. This terminal cast outlines the deployment of OMG! Ubuntu! from nothing to a running blog. Since it takes about 10 minutes to do the first deploy (imagine having to pull down about 5-10 GB worth of assets, database dumps, etc then import those in to MySQL), I decided to cut there and create this additional short video on how to scale out the deployment.

It’s a fantastic thing. Sure we’ve been rushing around trying all these different methods, but at the end of the day that time was well invested. Now deployments for OMG! Ubuntu! (and WordPress) are easy. In minutes you have a battle ready, tried and true blogging software deployed to the cloud.

  • Jef Spaleta

    Can you put a number in terms of manhours spent in the experimenting rushing around phase that led to the optimized deployment?

    My question is how much of that rushing around and experimentation can now be avoided in future OMG unrelated service spin-ups? How much of this is lessons learned that can become best practises for a new from scratch site or service initiation? Or is that time experimenting basically a (site/service specific) sunk cost for every new service/site as part of optimization the specific technology setup for that service/site? Is this re-usable beyond OMG’s needs without re-optimization? Or the OMG optimization a starting that still requires the same amount of manhour experimentation to re-optimize as part of re-use?


    • It’s hard to say, in the begging we were spending 10 hour days for the first four days getting OMG! Ubuntu! moved and able to handle the amount of traffic it saw (see Jorge Castro’s blog post: Since then we’ve spent on average 10-12 hours a week tuning a testing. What will happen in the next week we’ll rip out all the OMG! Ubuntu! specific things (custom themes, database dumping, etc) and that will become the new WordPress charm.

      A lot of this time was spent optimizing this charm to handle the amount of traffic (80k+ a day minimum). The majority of this will only really apply to OMG! Ubuntu! However, given the state of the current WordPress charm there is a lot to be improved. Things like fetching the latest stable WordPress, employing Nginx for load balancing, pre-configuring some plugins like WP Super Cache that will be highly beneficial for the WordPress charm that we will be implementing now that we know how to run a high scale WordPress install.

      • Jef Spaleta

        Does it make sense to make wordpress plugins part of the wordpress charm? Or is it better to have it be its own charm? The cache plugin you speak of, is that something that low traffic wordpress instances will find detrimental? The level of plugin customization that can be tweaked seems pretty complex. Do you need different wordpress configs for low and high scale?


        • The caching plugin we employ is from the WordPress Plugin directory (WP Super Cache). What we’ll likely be doing is including this and a good default configuration for it in the charm but not having it enabled in the WordPress admin area. That way it’s available with sane defaults if you want to enable it, but won’t slow you down if you’re just starting out.

          All of the additional machine level adjustments (like APC PHP Object caching) will be configurable via the charm itself. So, by default apc will be turned off until you run juju set wordpress use-apc=true at which point the Charm will make sure APC is properly enabled.

  • Pingback: Deploying OMG! Ubuntu! to the cloud with Juju! | Marco Ceppi | Pici's Ubuntu Blog()

  • Pingback: Deploying OMG! Ubuntu! to the cloud with Juju! | Marco Ceppi | Linux Blog()