Managing services with Juju
In the previous recipe, we learned how to install the Juju service orchestration framework. Now, we will look at how to use Juju to deploy and manage a service.
Getting ready
Make sure you have installed and bootstrapped Juju.
How to do it…
We will deploy a sample WordPress installation with a load balancer. The MySQL service will be used as the database for WordPress. Both services are available in the Juju Charm store.
Follow these steps to manage services with Juju:
- Let's start by deploying the WordPress service with
juju deploy
. This should give you the following output:$ juju deploy wordpress Added charm "cs:trusty/wordpress-4" to the model. Deploying charm "cs:trusty/wordpress-4" with the charm series "trusty".
- Now, deploy a MySQL service to store WordPress contents:
$ juju deploy mysql Added charm "cs:trusty/mysql-38" to the model. Deploying charm "cs:trusty/mysql-38" with the charm series "trusty".
- Now, you can use
juju status
to confirm your deployed services. It should show you the deployed services, their relations, and respective machine statuses, as follows:$ juju status
- Now that both services have been deployed, we need to connect them together so that
wordpress
can use the database service. Juju calls this a relation, and it can be created as follows:$ juju add-relation mysql wordpress
- Finally, we need to expose our
wordpress
service so that it can be accessed outside our local network. By default, all charms start as unexposed and are accessible only on a local network:$ juju expose wordpress
You can get the IP address or DNS name of the wordpress
instance with the juju status
command from the Machines
section. Note that in a local LXD environment, you may need a forwarded port to access WordPress.
How it works…
In this example, we deployed two separate services using Juju. Juju will create two separate machines for each of them and deploy the service as per the instructions in the respective charms. These two services need to be connected with each other so that wordpress
knows the existence of the MySQL database. Juju calls these connections relations. Each charm contains a set of hooks that are triggered on given events. When we create a relation between WordPress and MySQL, both services are informed about it with the database-relation-changed
hook. At this point, both services can exchange the necessary details, such as MySQL ports and login credentials. The WordPress charm will set up a MySQL connection and initialize a database.
Once both services are ready, we can expose them to be accessed on a public network. Here, we do not need MySQL to be accessible by WordPress users, so we have only exposed the wordpress
service. WordPress can access MySQL internally, with the help of a relation.
You can use the Juju GUI to visualize your model and add or remove charms and their relations. At this point, if you open a GUI, you should see your charms plotted on the graph and connected with each other through a small line, indicating a relation. The GUI also provides an option to set constraints on a charm and configure charm settings, if any.
Note that both charms internally contain scaling options. WordPress is installed behind an Nginx reverse proxy and can be scaled with extra units as and when required. You can add new units to the service with a single command, as follows:
$ juju add-unit mysql -n 1
There's more…
When you no longer need these services, the entire model can be destroyed with the juju destroy-model <modelname>
command. You can also selectively destroy particular services with the remove-service
command and remove relations with remove-relations
. Check out the Juju manual page for tons of commands that are not listed in the Juju help menu.
See also
- How to create your own charm: https://jujucharms.com/docs/stable/authors-charm-writing
- More about hooks: https://jujucharms.com/docs/stable/authors-hook-environment