Clouds


#1

Juju supports a wide variety of clouds. In addition, many of these are known to Juju out of the box. The remaining supported clouds do need to be added to Juju, and, as will be shown, it is simply done.

Once your cloud is known to Juju, whether by default or due to it being added, the next step is to add your cloud credentials to Juju. The exception is for a local LXD cloud; credentials are added automatically.

This rest of this page covers general cloud management and an overview of how clouds are added. However, you can get started right away by selecting your cloud here:

Those clouds known to Juju out of the box are denoted by an asterisk (*).

General cloud management

To get the list of clouds that the client is aware of use the clouds command:

juju clouds --local

This will return a list very similar to:

Cloud           Regions  Default          Type        Description
aws                  15  us-east-1        ec2         Amazon Web Services
aws-china             2  cn-north-1       ec2         Amazon China
aws-gov               1  us-gov-west-1    ec2         Amazon (USA Government)
azure                27  centralus        azure       Microsoft Azure
azure-china           2  chinaeast        azure       Microsoft Azure China
cloudsigma           12  dub              cloudsigma  CloudSigma Cloud
google               18  us-east1         gce         Google Cloud Platform
joyent                6  us-east-1        joyent      Joyent Cloud
oracle                4  us-phoenix-1     oci         Oracle Cloud Infrastructure
oracle-classic        5  uscom-central-1  oracle      Oracle Cloud Infrastructure Classic
rackspace             6  dfw              rackspace   Rackspace Cloud
localhost             1  localhost        lxd         LXD Container Hypervisor

In versions prior to v.2.6.1 the clouds command only operates locally (there is no --local option).

Each line represents a cloud that Juju can interact with. It gives the cloud name, the number of cloud regions Juju is aware of, the default region (for the current Juju client), the type/API used to control it, and a brief description.

The cloud name (e.g. ‘aws’, ‘localhost’) is what you will use in any subsequent commands to refer to a cloud.

To see which regions Juju is aware of for any given cloud use the regions command. For the ‘aws’ cloud then:

juju regions aws

This returns a list like this:

us-east-1
us-east-2
us-west-1
us-west-2
ca-central-1
eu-west-1
eu-west-2
eu-central-1
ap-south-1
ap-southeast-1
ap-southeast-2
ap-northeast-1
ap-northeast-2
sa-east-1

To change the default region for a cloud:

juju set-default-region aws eu-central-1

You can also specify a region to use when Creating a controller.

To get more detail about a particular cloud:

juju show-cloud --local azure

In versions prior to v.2.6.1 the show-cloud command only operates locally (there is no --local option).

To learn of any special features a cloud may support the --include-config option can be used with show-cloud. These can then be passed to either of the bootstrap or the add-model commands. See Passing a cloud-specific setting for an example.

To synchronise the Juju client with changes occurring on public clouds (e.g. cloud API changes, new cloud regions) or on Juju’s side (e.g. support for a new cloud):

juju update-public-clouds

The definition of an existing cloud can be done locally or, since v.2.5.3, remotely (on a controller).

For the ‘oracle’ cloud, for instance, create a YAML-formatted file, say oracle.yaml, with contents like:

clouds:
   oracle:
      type: oci
      config:
         compartment-id: <some value>

Here, the local (client cache) definition is modified:

juju update-cloud --local oracle -f oracle.yaml

This will avoid having to include --config compartment-id=<some value> at controller-creation time (bootstrap).

Here, the remote definition is updated by specifying the controller:

juju update-cloud oracle -f oracle.yaml -c oracle-controller

If you specify a controller without supplying a YAML file then the remote cloud will be updated according to the client’s current knowledge of that cloud.

Adding clouds

Adding a cloud is done with the add-cloud command, which has both interactive and manual modes.

Adding clouds interactively

For new users, interactive mode is the recommended method for adding a cloud. This mode currently supports the following clouds: MAAS, Manual, OpenStack, Oracle, and vSphere.

Adding clouds manually

More experienced operators can add their clouds manually. This can assist with automation.

The manual method necessitates the use of a YAML-formatted configuration file. It has the following format:

clouds:
  <cloud_name>:
    type: <cloud type>
    auth-types: [<authenticaton types>]
    regions:
      <region-name>:
        endpoint: <https://xxx.yyy.zzz:35574/v3.0/>

The table below shows the authentication types available for each cloud type. It does not include the interactive type as it does not apply in the context of adding a cloud manually.

cloud type authentication types
azure service-principal-secret
cloudsigma userpass
ec2 access-key
gce jsonfile,oauth2
joyent userpass
lxd n/a, certificate (v.2.5)
maas oauth1
manual n/a
oci httpsig
openstack access-key,userpass
oracle userpass
rackspace userpass
vsphere userpass

To add a cloud in this way we supply an extra argument to specify the relative (or absolute) path to the file:

juju add-cloud --local <cloud-name> -f <cloud-file>

In versions prior to v.2.6.1 the add-cloud command only operates locally (there is no --local option).

Here are some examples of manually adding a cloud:

Managing multiple clouds with one controller

With v.2.6.1 you can add a cloud to an existing controller, thereby saving a machine and the trouble of setting up a controller within that cloud.

Multi-cloud functionality via add-cloud (not add-k8s) is available as “early access” and requires the use of a feature flag. Once the controller is created, you can enable it with: juju controller-config features="[multi-cloud]"

For example, to manage a MAAS cloud with a LXD controller:

juju bootstrap localhost lxd
juju add-cloud --local maas -f maas-cloud.yaml
juju add-credential maas -f maas-credentials.yaml
juju add-cloud --controller lxd maas

The output to the list-clouds command becomes:

Clouds on controller "lxd":

Cloud      Regions  Default    Type  Description
localhost        1  localhost  lxd   
maas             0             maas

The ‘lxd’ controller is said to be a multi-cloud controller.

A limiting factor to multi-cloud controllers is that both controller machine and workload machine(s) must be able to initiate a TCP connection to one another. There are also latency issues that may make some scenarios unfeasible.

New cloud-based ‘add-model’ permissions can be set up via new commands grant-cloud and revoke-cloud.

When adding a model on a multi-cloud controller specifying the cloud name is mandatory. To continue with the example above then, to add model ‘xanadu’ to the ‘maas’ cloud:

juju add-model xanadu maas

Using VMware vSphere with Juju
Using OpenStack with Juju
Using MAAS with Juju
Using Oracle OCI with Juju
Basic client usage - tutorial
Juju documentation
Credentials
Using LXD with Juju - advanced
Application high availability
Getting started with Juju
[Tutorial] Managing credentials
Concepts and terms
Migrating models
A multi-user cloud