Mojo: Juju Service Orchestration distilled

Tom Haddon

on 13 January 2015

Tags: Juju

In Canonical’s IS Department we use Juju for service orchestration. It’s a great tool for quickly spinning up complex services, tying them together and scaling them out or in as needed. We use it for everything from the ubuntu.com website itself to click-packages, the system that underpins the Ubuntu phone. We even use it to deploy the OpenStack instances that these services run on. All in all we have more than 60 Juju environments in production.

We started working with Juju in production in October 2012, and over time, the way in which we’ve chosen to deploy and manage those environments has evolved significantly. We started out with shell scripts with lots of juju deploy commands, followed by juju set commands to configure services, juju add-relation commands, and whatever other steps were needed, such as exposing services, setting up nova security groups, etc..

We realised we needed a better approach that gave us more consistency and clarity, and allowed us to collaborate on service deployments with developers. We also needed something that allowed us to test changes to Juju environments before doing so in production – continuous integration (CI) for Juju. Our best practices for Juju deployments and CI were distilled into Mojo, and we’re happy to now be able to make Mojo available as an Open Source project on Launchpad.

So what is Mojo and how does it fit into the Service Orchestration story for Juju?

Mojo is a system of configuration and tools for verifying the success of Juju environment deployments. It gives you a structured means of having an entirely repeatable deployment process. By “deployment process” here, we mean going from an entirely empty environment with no VMs running to VMs with the services deployed on them, relations established between each, and a fully working service.

Mojo ensures reproducibility of builds by enforcing a separation of collecting build resources from running build steps in a network-isolated environment. It minimises exposure to production secrets (SSL certificates, production passwords, etc.), but maximises exposure to all other production deployment parameters.

It also allows you to test any other operations you may want to do on a Juju environment besides just an initial service deployment, such as scaling out, updating charms, updating code or content on running service units, uploading data into your application or whatever you need.

One specification, multiple environments

By having these steps all defined within a specification, you can test them in one Juju environment, and then run them again in your production Juju environment. This also means developers and sysadmins can more easily collaborate on service changes, because the steps being taken are by definition scripted and tested.

mojo-brand

This diagram shows how you can use the same Mojo specification and manifest with different stages to deploy into three different environments for development, staging and production.

This is the first in a series of three posts about Mojo. Next time around we’ll dive a bit deeper into a Mojo specification branch to see how it fits together, and the final post will go through an example deployment. Stay tuned for those!


About the author

Tom Haddon is a squad lead within Canonical’s IS department. He manages a globally distributed team of senior systems administrators rotating between three functions: Projects, Operations and Webops (devops). He has a strong focus on cloud technologies including OpenStack, Juju and MAAS.

Ubuntu cloud

Ubuntu offers all the training, software infrastructure, tools, services and support you need for your public and private clouds.

Newsletter signup

Select topics you’re
interested in

In submitting this form, I confirm that I have read and agree to Canonical’s Privacy Notice and Privacy Policy.

Related posts

How to harness big data for maximum business value

Are you getting maximum value from your big data? Despite most businesses understanding the power and competitive advantage they could gain from harnessing their big data more effectively and leveraging it more efficiently, it’s not an …

Minimum viable Kubernetes

The appeal of Kubernetes is universal. Application development, operations and infrastructure teams recognise diverse reasons for its immediate utility and growing potential — a testament of Kubernetes’ empathetic design. Web apps, galvanised by the 12 factor …

Running Android in the Cloud with Amazon EC2 A1 instances

Amazon Web Services (AWS) announced the availability of their new Amazon EC2 A1 instances powered by custom AWS Graviton processors based on the Arm architecture, which brings Arm to the public cloud as a first class …