4
In Canonical's IS Department we use [Juju](http://juju.ubuntu.com)
5
for service orchestration. It's a great tool for quickly spinning up complex
6
services, tying them together and scaling them out or in as needed. We use it
7
for everything from the [ubuntu.com](http://www.ubuntu.com) website
8
itself to click-packages, the system that underpins the [Ubuntu
9
phone](http://www.ubuntu.com/phone). We even use it to deploy
10
the OpenStack instances that these services run on. All in all we have more
11
than 60 Juju environments in production.
13
We started working with Juju in production in October 2012, and over time, the
14
way in which we've chosen to deploy and manage those environments has evolved
15
significantly. We started out with shell scripts with lots of `juju deploy`
16
commands, followed by `juju set` commands to configure services, `juju
17
add-relation` commands, and whatever other steps
18
were needed, such as exposing services, setting up nova security groups, etc..
20
We realised we needed a better approach that gave us more consistency and
21
clarity, and allowed us to collaborate on service deployments with developers.
22
We also needed something that allowed us to test changes to Juju environments
23
before doing so in production - continuous integration (CI) for Juju. Our best
24
practices for Juju deployments and CI were distilled into Mojo, and we're happy
25
to now be able to [make Mojo available](https://launchpad.net/mojo)
26
as an Open Source project on Launchpad.
28
So what is Mojo and how does it fit into the Service Orchestration story for Juju?
29
----------------------------------------------------------------------------------
31
Mojo is a system of configuration and tools for verifying the success of Juju
32
environment deployments. It gives you a structured means of having an entirely
33
repeatable deployment process. By "deployment process" here, we mean going from
34
an entirely empty environment with no VMs running to VMs with the services
35
deployed on them, relations established between each, and a fully working
38
Mojo ensures reproducibility of builds by enforcing a separation of collecting
39
build resources from running build steps in a network-isolated environment. It
40
minimises exposure to production secrets (SSL certificates, production
41
passwords, etc.), but maximises exposure to all other production deployment
44
It also allows you to test any other operations you may want to do on a Juju
45
environment besides just an initial service deployment, such as scaling out,
46
updating charms, updating code or content on running service units, uploading
47
data into your application or whatever you need.
49
One specification, multiple environments
50
----------------------------------------
52
By having these steps all defined within a specification, you can test them in
53
one Juju environment, and then run them again in your production Juju
54
environment. This also means developers and sysadmins can more easily
55
collaborate on service changes, because the steps being taken are by definition
58
60
This diagram shows how you can use the same Mojo specification and manifest
61
with different stages to deploy into three different environments for
62
development, staging and production.
64
This is the first in a series of three posts about Mojo. Next time around we'll
65
dive a bit deeper into a Mojo specification branch to see how it fits together,
66
and the final post will go through an example deployment. Stay tuned for those!
added
removed
docs/mojo/mojo-insights-article-introduction.md
