Clouds

To Juju, a cloud is a resource which provides machines (instances), and possibly storage, in order for application units to be deployed upon them. This includes public clouds such as Amazon Web Services, Google Compute Engine, and Microsoft Azure as well as private OpenStack-based clouds. Juju can also make use of environments which are not clouds per se, but which Juju can nonetheless treat as a cloud. MAAS and LXD fit into this last category.

This page contains general cloud management information as well as a list of quick start guides for specific clouds.

Connecting Juju to your cloud

The process of connecting Juju to your choice of cloud can be divided into two steps:

  • Add a cloud (optional) - For clouds that are not supported out of the box
    Many of the clouds are known to Juju out of the box. The remaining supported clouds do need to be added to Juju. This process is made simple with the add-cloud command.

  • Add your cloud credentials
    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 with the command add-credentials.

Quick start guides

You can get started right away by selecting your cloud here:

Cloud
Out of the box support:
Amazon AWS
Microsoft Azure
Google GCE
Oracle
Rackspace
LXD (local)
Requires add-cloud command:
LXD (remote)
VMware vSphere
OpenStack
MAAS
Manual

General cloud management

List clouds

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

juju clouds --local --all

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
oracle                4  us-phoenix-1     oci         Oracle Cloud Infrastructure
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.

Cloud regions

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

Default region

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.

Cloud details

To get more detail about a particular cloud:

juju show-cloud --local azure

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 the bootstrap, the add-model commands or changed with the model-config command. See passing a cloud-specific setting for an example.

Synchronise with cloud

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

Updating a cloud

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=<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.


Last updated 4 days ago.