Setup Juju

This document describes how to set up a Juju controller on the GARR cloud.

This will allow using Juju for deploying apps in your project defined by charms and bundles.

As an alternative, consider using GARR’s Juju controller through the GARR DaaS service.

Requirements

Setup a private cloud

In order for Juju to orchestrate the deployment of your applications on your project, you need to create a private OpenStack cloud on that project.

Create a Juju environment file

Create a YAML file mycloud.yaml defining an OpenStack cloud called mycloud:

clouds:
  mycloud:
    type: openstack
    auth-types: [access-key, userpass]
    regions:
      myregion:
        endpoint: https://keystone.cloud.garr.it:5000/v3

credentials:
  mycloud:
    default-credential: $USERNAME
    $USERNAME:
      auth-type: userpass
      domain-name: cloudusers
      tenant-name: $MYPROJECT
      username: $USERNAME
      password: $PASSWD

Where $USERNAME and $PASSWD are the username and password of a GARR Cloud user with access to the project $MYPROJECT, where the private OpenStack cloud will be setup.

Please note that setting the project-domain-name parameter can yield issues when using Juju version 2.7.1.

Add the cloud

Add the cloud mycloud to the list of Juju clouds by issuing the following command:

$ juju add-cloud mycloud mycloud.yaml

Add the user credentials for your cloud by issuing the following command:

$ juju add-credential mycloud -f mycloud.yaml

Check the results with:

$ juju show-cloud mycloud
$ juju list-credentials

Create the Juju controller

A Juju controller is used to manage a cloud environment and deal with the models you create to host applications. A model is a group of machines and services deployed on those machines.

For our cloud called mycloud, we will create a controller called mycloud-controller:

$ juju bootstrap mycloud mycloud-controller \
     --config network=default \
     --config use-floating-ip=true

In this example the Juju controller will be attached to the default GARR Cloud network. If you want to create it on another network (e.g your own project network) replace default with the other network name.

The bootstrap process may take a few minutes as OpenStack will spawn a new VM and Juju will install the controller software. You can check the status of the VM with the openstack command or through the GARR Cloud dashboard .

Once the process has completed you can check that the controller has been created:

$ juju controllers

This will return a list of the controllers known to Juju, which at the moment is the one we just created:

Use --refresh flag with this command to see the latest information.

Controller  Model    User   Access     Cloud/Region         Models  Machines    HA  Version
mycloud-controller*        default        admin  superuser  mycloud/myregion          2         1  none  2.0.0

A newly created controller has two models:

  • the admin model, which should be used only by Juju for internal management
  • the default model, which is ready for actual use.

The following command shows the currently active controller, model, and user:

$ juju whoami

In our example, the output should look like this:

Controller:  mycloud-controller
Model:       default
User:        admin

Finally, you can find the URL of the Juju GUI with the following command:

$ juju gui --show-credentials
   Opening the Juju GUI in your browser.
   If it does not open, open this URL:
   https://90.147.163.8:17070/gui/287cb95c-5867-493c-8e8e-84c18dee3a71/
   Username: admin
   Password: <hidden>
   Couldn't find a suitable web browser!
   Set the BROWSER environment variable to your desired browser.

Open the GUI with your browser and log in with the supplied credentials.

Allocate floating IPs

You need to pre-allocate the floating IPs that Juju will assign to the controller and the instances eventually deployed.

This can be done either through the OpenStack dashboard or via the OpenStack CLI. Here are the CLI instructions:

  1. Get the floating IP pool:

    $ openstack ip floating pool list

    In the case of the GARR Cloud the pool name is floating-ip

  2. Create floating IPs by issuing:

    $ openstack ip floating create floating-ip

  3. List the floating IPs:

    $ openstack ip floating list

The result will be something like:

+--------------------------------------+---------------------+------------------+--------------------------------------+
| ID                                   | Floating IP Address | Fixed IP Address | Port                                 |
+--------------------------------------+---------------------+------------------+--------------------------------------+
| 1543606b-17b6-4e04-a19e-7d9efbb4cd75 | 90.147.166.157      | None             | None                                 |
+--------------------------------------+---------------------+------------------+--------------------------------------+
| 3bb1cd20-b298-4653-83de-84be6924acd7 | 90.147.166.154      | 192.168.250.33   | eafa022f-1e96-4433-a14f-abcc4d2074cf |
+--------------------------------------+---------------------+------------------+--------------------------------------+

The allocated and free floating IPs are those not assigned to fixed IPs or ports.

Deploy applications

Juju is now ready to deploy applications from among the hundreds included in the Juju charm store.

Testing the model

It is a good idea to test your new model. Let’s deploy a MediaWiki site:

$ juju deploy cs:bundle/mediawiki-single

This will fetch a ‘bundle’ from the Juju store. A bundle is a pre-packaged set of applications, in this case ‘MediaWiki’, and a database to run it with. Juju will install both applications and add a relation between them - this is part of the magic of Juju: it isn’t just about deploying software, Juju also knows how to connect it all together.

Installing shouldn’t take long. You can check on how far Juju has got by running the command:

$ juju status

When the applications have been installed, the output of the above command will look something like this:

$ juju status
Model    Controller  Cloud/Region         Version
default  mycloud-controller    localhost/localhost  2.0.2

App        Version  Status   Scale  Charm      Store       Rev  OS      Notes
mediawiki           unknown      1  mediawiki  jujucharms    3  ubuntu
mysql               unknown      1  mysql      jujucharms   29  ubuntu

Unit          Workload  Agent  Machine  Public address  Ports  Message
mediawiki/0*  unknown   idle   0        10.200.178.48   80/tcp
mysql/0*      unknown   idle   1        10.200.178.71

Machine  State    DNS            Inst id        Series  AZ
0        started  10.200.178.48  juju-9fb5d2-0  trusty
1        started  10.200.178.71  juju-9fb5d2-1  trusty

Relation  Provides   Consumes  Type
db        mediawiki  mysql     regular
cluster   mysql      mysql     peer

From the status output, we can see that the IP address for the MediaWiki site we have created is 10.200.178.48. Open a browser and enter that address to see the site.

Note

To remove all the applications in the model you just created, it is often quickest to destroy the model with the command juju destroy-model default and then create a new model, by doing juju add-model default.

Add users to Juju

It is useful to add users to Juju and give them grants to the Juju models.

Add a new user:

$ juju add-user alice

The result of this command will be:

User "alice" added
Please send this command to alice:
    juju register <key>

"alice" has not been granted access to any models. You can use 'juju grant' to grant access.

The user will need to issue the juju register command on his/her Juju client. He/she will be asked for a password. He/she will then be connected to the Juju cloud and be allowed log in to the GUI with the supplied password.

The user must have a role on one or more models. In the following example we add the admin role to alice on the default model:

$ grant alice admin default

Additional notes on Juju

  • Juju by default stores its configuration and state locally in the ~/.local/share/juju directory. This includes the ssh subdirectory, which contains the admin SSH keys. This can be useful for e.g. debugging purposes.
  • When Juju deploys its applications, the charms are fetched remotely (from e.g. https://jujucharms.com) but the images are not: Juju queries the local keystone about the product-streams endpoint, which supplies metadata to retrieve the images from the local Glance service. One implementation of the product-streams endpoint is supplied by SimpleStreams.