[A JuJu Adventure] Splitting my charm out

In my previous post, Jorge Castro commented that a new super wordpress charm is in the works, and I want to keep working on my blog site configuration (theme and plug-ins) without missing out on any updates. This means that I needed to stop forking the wordpress plugin and find a way to just use the one in the charm store and then ,onto the same instance, roll-out my configuration.

I mentioned that I might try splitting my configuration out into a Subordinate service, and that is what I done 🙂 It was actually pretty easy.

I created a new charm called wordpress-conf.  I set the metadata.yaml file to contain:

name: wordpress-conf
summary: "WordPress configuration"
subordinate: true
description: |
Provides configuration for wordpress blogs
- Plugin:
- WordPress importers
- super cache plug-in
requires:
logging:
 interface: logging-directory
 scope: container
juju-info:
 interface: juju-info
 scope: container

As you can see it has a line calling out that this charm is a subordinate, and has two requirement.  The two requirements are for testing purposes really. The “logging” requirement is an explicit requirement that the charm that you are “subordinating” to must have defined, while “juju-info” is an implicit requirement that is define for all charms. What this mean is that using “juju-info”, I can deploy my charm against any service. The key is to define the scope as container.

The magic happens not when you deploy a subordinate charm, but when you add a relationship to another service. For example the following commands result on a wordpress instance setup following the WP charm in the charm store, but with my plugin and theme set up:

juju bootstrap
juju deploy wordpress
juju deploy mysql
juju add-relation wordpress mysql
juju expose wordpress
juju deploy --repository=~/mycharm local:precise/wordpress-conf
juju add-relation wordpress-conf wordpress

Pretty cool, eh!? I should be able to upgrade the two charms now independently

Ubuntu ARM Server AMI on Amazon EC2

Reposting here the blog entry that I uploaded to blog.canonical.com

Have you been wondering if your Web application will work with the new generation of Hyperdense ARM Servers? Now you can easily find out by using Ubuntu and Amazon Web Services. Canonical has made available in Amazon Web Services an AMI image for developers wishing to experiment with Ubuntu ARM Server. Dann Frazier is the engineer behind this initiative. I took some of his time today to asking a few questions:

How did this came about?
We were wanting to do some internal functional testing of the 12.04 release across our global team without shipping hardware around. We had a QEMU model with us and using cloud systems to host it seemed like an excellent way to grow our (emulated) machine count.

Can you give me some examples of what could I do with it?
Basically, anything you can do with Ubuntu Server. You can install packages, deploy Juju charms, test your web applications, etc. However, I would strongly suggest not using it for any production work or performance testing – being an emulated environment, you will notice some overhead.

Who do you expect will use this new AMI?
Developers looking to test their applications on ARM, people wanting to test Juju charm deployments in a multi-architecture environment, and anyone just looking to kick the tires.

This is all great, How do I get my hands on it?
Canonical has published an AMI on Amazon EC2. You will need an Amazon Web Services account, then just go into your Management Console for EC2 and launch a new instance.  Select “Community AMIs” and look for AMI ID ‘ami-aef328c7’. (We’ll keep the latest AMI ID posted at http://wiki.ubuntu.com/ARM/Server). Or click here.

Are there any limations compared to a real hardware box?
The AMI provides an Ubuntu 12.04 (‘armhf’) system running on an emulated hardware system. Performance is limited due to the emulation overhead. This AMI requires the use of an m1.large instance type due to memory requirements.

Once again, thanks to Dann and the Canonical team for sharing this neat tool with the community. It sounds great and easy to set up. So, What are you waiting for?

[A JuJu Adventure] Baby Steps into WordPress Charm

For a while now, I have being toying with the idea to move away from a WordPress.com hosted site for this blog. The main reason: I am not really happy to have to pay for every single simple stuff.. add an additional URL to the site, take aways advertising, edit a CSS… it really stops me from playing 🙂

What had prevented me from doing this in the past was that I haven’t really got much experience setting up WordPress or MySQL. What I really needed was a save (and free) sandbox to try changes to my site, until I was happy with it, and then easily deploy it live… Can you say Juju?

With Juju you can do all your playing locally using LXC, save all the changes into a Charm and then just deploy them into a public cloud. Perfect!

 

The first thing I did was to set-up an Amazon AWS account and configure my juju environment to deploy to the public cloud. My rationale here was: if I can’t get vanilla WordPress in a live public site, then there is little point continuing with the experiment.

This was actually pretty easy, I just followed the Getting Started guide. The only stumbling block was that I was using my travel laptop at the time that didn’t have my launchpad ssh keys. You need to create ssh keys to use Juju, but apparently you also need to publish them into your launchpad account. Once this was done, I had a public WordPress instance in just 5 commands.

Next step: destroy the environment and stop paying 🙂 Now I needed to bring up my cheap sandbox.

Again this is pretty easy to setup, just follow the Getting Started guide. I hit another road block once my deployment instances seemed not be doing much, “juju status -e local” showed them in pending state and the logs did not display any activity…A bit of Googling later , I found that Jorge Castro had hit the same problem and found the solution in Ask Ubuntu.

With my WordPress local instance now fully up and running, now I needed to upload my own content. To do this, I just needed to upload the wordpress importer plugin. Fairly trivial to get gone by hand, thanks to the very useful “juju scp” and “juju ssh” commands, but how to do it via a Charm. I wanted to make sure that the next time a deploy wordpress, it would have already this plugin install. Crudly this is what I did:

  • Using the charm-tools I got the wordpress charm loc ally (charm get wordpress)
  • I then edited the install file under hooks/ to include:
    apt-get -y install wordpress pwgen wget unzip
    wget http://downloads.wordpress.org/plugin/wordpress-importer.0.6.zip
    sudo unzip wordpress-importer.0.6 -d /usr/share/wordpress/wp-content/plugins/
  • redeploy using locally stored charm. juju deploy –repository=~/charms local:precise/wordpress -e local

Guess what, it worked. I did get some warnings (WARNING Charm ‘.mrconfig’ has an error) that I am yet to iron out, but when the wordpress instance came up the new plugin was there:

That is all for today, and before I go, one last useful hint courtesy of James Page: Add “default: {name of your env}” if you have multiple environments  but you normally always use one. Save me having to type “-e local” all the time.

Towards The Green Cloud

I was aware that data centers around the world were starting to be talked about as an environmental problem, but perhaps the statistic that data centers have the same carbon footprint than the aviation industry (about 2% of the global carbon footprint pie) really put things in perspective for me.

The Open Data Center Alliance “Carbon Footprint Values” document starts its executive summary with:

According to market research and consulting firm Pike Research, data centers around the world consumed 201.8 terawatt hours (TWh)
in 2010 and energy expenditures reached $23.3 billion. That’s enough electricity to power 19 million average U.S. households. The
good news is that, according to Pike Research, the adoption of cloud computing could lead to a 38% reduction in worldwide data center
energy expenditures by 2020.

The prediction that cloud computing will lead to large savings of energy consumption can be justified by economies of scale. Todays’ enterprise data centers average 20-30% computing power utilisation. The same data center serving Infrastructure As A Service (IaaS) is expected to run at 80-90% occupancy. This plus the opportunity for enterprises to transform a fix cost of ownership into a flexible service subscription will lead to consolidation of data centers. Continue reading “Towards The Green Cloud”