Clouds
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:
- Amazon AWS *
- Microsoft Azure *
- Google GCE *
- Oracle *
- Rackspace *
- LXD (local) *
- LXD (remote)
- Kubernetes
- VMware vSphere
- OpenStack
- MAAS
- Manual
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
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 Juju administrators 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 |
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
Last updated 1 year, 1 month ago.