List of supported clouds > LXD
This document describes details specific to using your existing LXD cloud with Juju.
See more: LXD
When using the LXD cloud with Juju, it is important to keep in mind that it is a (1) machine cloud and (2) not some other cloud.
See more: Cloud differences in Juju
As the differences related to (1) are already documented generically in our Tutorial, How-to guides, and Reference docs, here we record just those that follow from (2).
Expand to view some reasons to use a LXD cloud
The LXD cloud, especially when used locally, is great for:
- creating a repeatable deployment: Juju enables you to quickly iterate to construct the optimal deployment for your situation, then distribute that across your team
– local development: Juju’s localhost cloud can mirror the production ops environment (without incurring the costs involved with duplicating it)
- learning Juju: LXD is a lightweight tool for exploring Juju and how it operates
- rapid prototyping: LXD is great for when you’re creating a new charm and want to be able to quickly provision capacity and tear it down
Expand to find out why Docker wouldn't work
Juju expects to see an operating system-like environment, so a LXD system container fits the bill. Docker containers are laid out for a singular application process, with a self-contained filesystem rather than a base userspace image.
| Juju points of variation | Notes for the LXD cloud |
|---|---|
| setup (chronological order): | |
| CLOUD | |
| supported versions: | Juju 2.9.x: LXD 5.0 Juju |
| requirements: | TBA |
| definition: |
local LXD cloud: Already known to Juju. Run juju clouds --all to confirm. (Pre-defined cloud name in Juju: localhost.) remote LXD cloud: Cloud type: If you want to use a YAML file: |
| CREDENTIAL | |
| definition: |
local LXD cloud: If you are a Juju admin user: Already known to Juju. Run juju bootstrap, then juju credentials to confirm. (Pre-defined credential name in Juju: localhost.) Otherwise: Add manually as you would a remote. remote LXD cloud: Requires the API endpoint URL for the remote LXD server. If you want to use a YAML file: |
| CONTROLLER | |
| notes on bootstrap: | – |
| other (alphabetical order:) | |
| CONFIGURATION (model) | |
| cloud-specific: |
project (string) The LXD project name to use for Juju’s resources. |
| CONSTRAINT | With LXD system containers, constraints are interpreted as resource maximums (as opposed to minimums). |
| conflicting: | TBA |
allocate-public-id |
 |
arch |
 Valid values: [host arch]. |
container |
|
cores |
|
cpu-power |
|
instance-role |
|
instance-type |
|
mem |
The maximum amount of memory that a machine/container will have. |
root-disk |
|
root-disk-source |
root-disk-source is the LXD storage pool for the root disk. The default LXD storage pool is used if root-disk-source is not specified. |
spaces |
|
tags |
|
virt-type |
|
zones |
|
| PLACEMENT DIRECTIVE | |
<machine> |
TBA |
subnet=... |
|
system-id=... |
|
zone=... |
If there’s no ‘=’ delimiter, assume it’s a node name. |
|
RESOURCE (cloud) Consistent naming, tagging, and the ability to add user-controlled tags to created instances. |
|
Other notes
Simple bootstrap of a remote LXD server
From Juju 2.9.5, the easiest method for bootstrapping a remote LXD server is to add the remote to your local LXC config then bootstrap with juju.
On the remote server:
# ensure the LXD daemon is listening on an accessible IP
lxc config set core.https_address '[::]'
# give the LXD daemon a trust password so the client can register credentials
lxc config set core.trust_password mytrustpassword
On the bootstrapping client:
# add the remote LXD server to the local LXC config
lxc remote add myremote 11.22.33.44 --password mytrustpassword
# bootstrap juju using the remote name in LXC
juju bootstrap myremote
The bootstrapping client must be able to reach the remote LXD containers. This may require the setup of a bridge device with the hosts ethernet device.
For more advanced setup of LXD with clusters and using Juju remotely see Using LXD with Juju - Advanced.
Non-admin user credentials
See Credentials for more details on how Juju credentials are used to share a bootstrapped controller.
To share a LXD server with other users on the same machine or remotely, the best method is to use LXC remotes. See Simple bootstrap of a remote LXD server above.
Add resilience via LXD clustering
LXD clustering provides the ability for applications to be deployed in a high-availability manner. In a clustered LXD cloud, Juju will deploy units across its nodes. For more, see Using LXD clustering with Juju.
Use LXD profiles from a charm
LXD Profiles allows the definition of a configuration that can be applied to any instance. Juju can apply those profiles during the creation or modification of a LXD container. For more, see Using LXD profiles with Juju.
LXD images
LXD is image based: All LXD containers come from images and any LXD daemon instance (also called a “remote”) can serve images. When LXD is installed a locally-running remote is provided (Unix domain socket) and the client is configured to talk to it (named ‘local’). The client is also configured to talk to several other, non-local, ones (named ‘ubuntu’, ‘ubuntu-daily’, and ‘images’).
An image is identified by its fingerprint (SHA-256 hash), and can be tagged with multiple aliases.
For any image-related command, an image is specified by its alias or by its fingerprint. Both are shown in image lists. An image’s filename is its full fingerprint, while an image list displays its partial fingerprint. Either type of fingerprint can be used to refer to images.
Juju pulls official cloud images from the ‘ubuntu’ remote (http://cloud-images.ubuntu.com) and creates the necessary alias. Any subsequent requests will be satisfied by the LXD cache (/var/lib/lxd/images).
Image cache expiration and image synchronization mechanisms are built-in.