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
