List of supported clouds > LXD
This document describes details specific to using your existing LXD cloud with Juju.
Expand to view how to get a LXD cloud quickly on Ubuntu
Your Ubuntu likely comes with LXD preinstalled. Configure it as below. Juju will then recognize it as the
lxd init --auto
lxc network set lxdbr0 ipv6.address none
See more: LXD
See more: Cloud differences in Juju
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):
|local LXD cloud: Already known to Juju. Run
juju clouds --all to confirm. (Pre-defined cloud name in Juju:
remote LXD cloud: Cloud type:
|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.
clustered LXD cloud: In Juju, this counts as a remote cloud. You must add its definition to Juju explicitly.
remote LXD cloud: Requires the API endpoint URL for the remote LXD server.
|notes on bootstrap:
|other (alphabetical order:)
The LXD project name to use for Juju’s resources.
|With LXD system containers, constraints are interpreted as resource maximums (as opposed to minimums).
There is a 1:1 correspondence between a Juju machine and a LXD container. Compare
|The maximum amount of memory that a machine/container will have.
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.
If there’s no ‘=’ delimiter, assume it’s a node name.
Consistent naming, tagging, and the ability to add user-controlled tags to created instances.
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
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 126.96.36.199 --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.
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.
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.
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 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 (
Image cache expiration and image synchronization mechanisms are built-in.