Deploying web applications using Juju on EC2 (Part 2/3)

The goal of this tutorial series is to demonstrate the power of Juju service orchestration for deploying web applications and infrastructure services.

Juju is a service orchestration framework that is designed to make it very easy for application designers to deploy their applications in an easy, repeatable and logical manner without all that tedious mucking about with custom configurations.

Part 1

In part 1 we set up the Juju environment, the Juju GUI and the Nagios monitoring service.  Then we deployed a web application, wordpress and MySQL database and added it to the monitoring server.

Read the first article

Part 2

This part, I will show you how to add further infrastructure services to the environment to provide centralised logging with rsyslog, package updates from Landscape and graphing using Munin.

Deploy Rsyslog Logging Service

So we would like to add a centralised logging service to our environment so that all our services log to a centralised log server so we can see all the log files in one place.  This can be done by deploying the rsyslog charm and rsyslog forwarder charm.

First we need to deploy the rsyslog server to receive the log information over the network.  We can do this by deploying the rsyslog charm from the command line as follows:

juju deploy rsyslog

or from the Juju-gui as follows:

Search for the rsyslog charm on the top left and click on it and then click on “Add to Canvas”:

Then set any constraints you want, such as CPU, memory or architecture, I’ll leave these blank, and then click “Deploy.”

Then you should see the new service added and a yellow bar indicating that the unit is still pending deployment.

One it has finished deployment, which should take about 5 minutes or so, your environment should look like this:

Now we need to deploy the rsyslog forwarder charm, which is another subordinate charm which works in much the same way as the nagios NRPE charm we deployed in part 1.  That is, you need to deploy it to set the configuration, then add relations to deploy the rsyslog subordinate service to each primary service unit.

So, let’s deploy the rsyslog-forwarder charm.  From the command line this would be:

juju deploy rsyslog-forwarder

From the juju-gui, you would search for the charm and deploy it without setting any options as the defaults should be fine.

Then we need to add a relation to the rsyslog server as follows:

juju add-relation rsyslog-forwarder:syslog rsyslog:aggregator

Now your environment should look like this:

Deploy Munin Graphing Tool

We also want to add a centralised graphing tool such as Munin to allow each of our services to be monitored and graphed over time so we can spot any trends or sudden changes to resource usage.

To deploy the munin graphing tool it is much the same process as deploying the rsyslog tool, so we need to deploy a munin server and a munin-node subordinate charm too.

To do this from the command line you can run the following commands:

juju deploy munin

juju deploy cs:~clint-fewbar/precise/munin-node-2

juju add-relation munin munin-node

juju expose munin

As you will note from the above you can also specify where to grab a charm from if you need a specific branch or version for your environment by specifying where to find the charm.  In this case, we are using the charm store (cs:) and Clint’s branch of Precise and version 2 of his munin-node charm.  This is a powerful way to override the default charm from the charm store and specify a known version or branch, you can even create your own branches if you need to.

Once these commands are run the juju environment should look something like this:

As you can see we now have the munin server installed and ready to start monitoring services.

Let’s have a look at our munin server. Click on the munin charm and then click on the running units list on the right hand side to display the details.  Then copy and paste the server address into a new browser window to connect to the munin web interface.

The web interface will only show the localhost entry by default as we have yet to add the relationships to monitor other services.

Deploy Landscape Client

Now we can also deploy the Landscape-client charm so we can use our Landscape account to look after our new services and make sure they are kept up to date with packages.

If you do not already have a Landscape account then you can sign up for a 30 day trial here:

https://landscape.canonical.com/

Just click on the trial link to request a 30 day trial account.

Once you have your Landscape account details you will need to create a configuration file that contains at least your account name, if you have set a registration password you will also need to provide that too.  You can also add any tags that you want services to be associated with in Landscape, we will use the tag names: “precise, amazon, demo, juju”, so our config file should look like this:

landscape-client:

    account-name: YOUR_ACCOUNT_NAME

    tags: precise, amazon, demo, juju

    registration-key: YOUR_REGISTRATION_PASSWORD

Save this as a file called landscape.yaml and then deploy the landscape-client service as follows:

juju deploy –config=landscape.yaml landscape-client

Now your environment should look like this:

Ready for relating to the services we want Landscape to manage.

Add Relations for the Infrastructure Services

Now we have added the infrastructure services let’s add the relationships to the deployed services.

First let’s add the rsyslog relationship:

juju add-relation rsyslog-forwarder wordpress

juju add-releation rsyslog-forwarder mysql

Now let’s add the Munin graphing relationships:

juju add-relation munin-node wordpress

juju add-releation munin-node mysql

Finally, let’s add the relationships to the Landscape-client service:

juju add-relation landscape-client:container wordpress

juju add-releation landscape-client:container mysql

Now the relationships are added the environment should now look like this:

Notice that with subordinate charms the small box show the number of relationships, but to reduce clutter on the screen they are only displayed if you mouse over the small box like so:

We can now go and look at the munin web interface and see the new monitored services.

We can also see logs being collected to our central logging server to the local syslog. There is no web interface, so you would have to log in to the server with SSH and look at the log files collected in /var/log/.  I will leave that as an exercise for the reader.

We can log into our Landscape account and see 2 new registrations waiting to be approved.

Approve the registrations in Landscape and the services will be added to the Landscape management web interface.

You can now manage the servers via Landscape for package management, maintenance routines, security compliance and auditing.

We also have a Landscape API that can be used to integrate with other infrastructure services, anything you can do in the Landscape web interface can be done via the Landscape API and so many possibilities exist in integration with any 3rd party tools or custom infrastructure tools.

Summary

In part 2 we learnt how to add more infrastructure services to the environment so we could centralise log information using rsyslog and graph our resource usage using munin and manage our package updates from Landscape.

Next time I’ll show you how to expand your existing service to be more resilient and scale out the service under load. We will see how Juju does most of the work for you and the power of an orchestrated environment.

Darryl Weaver

Cloud Sales Engineer, EMEA