Using LXD with Juju
When your computer has LXD installed, Juju can operate the “
localhost” cloud. The localhost cloud provides the experience of working with a public cloud without needing to incur any financial cost.
Reasons to use Juju on localhost:
- 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 incuring 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
Info: If you are looking to connect to a LXD server, rather than accessing LXD installed locally, then read Adding a remote LXD cloud.
Juju uses LXD is an hypervisor that provides secure system containers that are secure, lightweight, and aims to be easy to use.
Info: Need to install LXD? Visit the LXD docs for installation instructions.
Why not Docker?
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.
Setting up the localhost cloud
Juju speaks directly to the local LXD daemon, which also requires lxd group membership.
newgrp lxd sudo adduser $USER lxd
If you have not already done so, you will need to run
lxd init to carry out from post-installation tasks. For most environments, using the default parameters is usually preferred:
lxd init --auto
There are several options, however. See the Getting Started with LXD webpage and the output from
lxd init --help for more details.
Currently, Juju does not support IPv6. Therefore, you will need to request that LXD does not allocate IPv6 addresses for containers and virtual machine instances that it creates.
lxc network set lxdbr0 ipv6.address none
Verify that the localhost cloud is available
localhost cloud is now established. We can verify that by running
Juju should have detected the presence of LXD and has added it as the
[...] localhost 1 localhost lxd LXD Container Hypervisor
Workloads live within a “model” that is managed by the “Juju controller”.
Creating a controller
juju bootstrap command to provision a machine within LXD and create a controller running within it.
juju bootstrap localhost overlord
lxd can be use interchangeably.
Standard practice is to also name your controller, in this instance we called it “overlord”
The bootstrap process is highly configurable, but changing the settings is rarely required while evaluating Juju. See the Creating a controller page for further details.
During the bootstrap process, Juju connects with the LXD daemon, then provisions a machine to install the controller on.
Creating Juju controller "overlord" on localhost/localhost Looking for packaged Juju agent version 2.6.8 for amd64 [...]
Deploying a workload
juju deploy command deploys a charm as an application. To explore how this works, consider following through 1 or more of these tutorials:
- A high-availability PostgreSQL cluster
- A multi-node RabbitMQ cluster
- Nextcloud and Collabora both backed by HTTPS
Juju machines and LXC containers
There is a 1:1 correspondence between machine and container.
Adding a machine without any workload is possible, by doing the following:
juju add-machine -n 1
Querying the available machines will list the newly created machine from the previous command:
The output from the machines query:
Machine State DNS Inst id Series AZ Message 0 started 10.243.67.177 juju-c795fe-0 bionic Running
Notice the “Inst id” column corresponds to the “NAME” column from LXC’s output:
+---------------+---------+----------------------+------+------------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +---------------+---------+----------------------+------+------------+-----------+ | juju-c795fe-0 | RUNNING | 10.243.67.177 (eth0) | | PERSISTENT | | +---------------+---------+----------------------+------+------------+-----------+
Juju constraints can be applied per controller or model workloads in the same way as other clouds. See Constraints and LXD containers for further details.
Info: It’s important to note that with LXD system containers, constraints are interpreted as resource maximums as opposed to minimums.
To help with LXC integration with Juju, additional information and resources about LXC can be found on the topic.
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.
Using LXD profiles from a charm
LXD Profiles allows the defining of a configuration that can be applied to any instance. Juju can apply those profiles during the creation or modification of a LXD container.
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.
Non-admin user credentials
To grant a regular user access to a LXD-based controller a certificate credential is required. This certificate is generated and shared with the user who will then use it as a credential. See Working with multiple users for details on adding users, granting them permissions, and registering controllers.
On the LXD host generate the certificate with the
autoload-credentials command. Use the below sample session as a guide:
Looking for cloud and credential information locally... 1. LXD credential "localhost" (new) Select a credential to save by number, or type Q to quit: 1 Select the cloud it belongs to, or type Q to quit : localhost Saved LXD credential "localhost" to cloud localhost 1. LXD credential "localhost" (existing, will overwrite) Select a credential to save by number, or type Q to quit: Q
A certificate credential will have been created. Export it to a file, say
localhost-credentials.yaml, by typing the following:
juju credentials localhost --format=yaml > localhost-credentials.yaml
Now transfer the file to the user that requires access to the cloud. Once done, on that user’s system, the credential can be added:
juju add-credential localhost -f localhost-credentials.yaml
See Credentials for more details on how credentials are used.
Juju can make use of several advanced features within LXD. They are explained on the Using LXD with Juju - Advanced page. It includes:
- Add resilience to your models through LXD clustering
- Registering a remote LXD server as a LXD cloud
- Charms and LXD profiles
Learn Juju’s core commands
Juju includes lots of functionality (see
juju help commands for a full list). Here is a brief list of the most helpful commands to use when you are getting started:
juju dashboardprovides a real-time web dashboard of all the models managed by the controller
juju statusprovides a view of a model, its applications, their units and other resources
juju deploydeploys a new charm (or bundle) as application(s) within a model
juju sshallows you to access a secure shell into any machine or unit within the model
juju switchallows you to switch between models and controllers
juju help <command> for detailed usage instructions on every command provided by Juju.
Learn Juju’s concepts
Becoming familiar with Juju involves learning some new terminology:
- Models house applications
- Applications are “instances” of charms that are comprised of units. A unit occupies a machine. That machine may be also be used by other units.
- Relations are a data exchange system between applications facilitated by the Juju controller
Last updated 20 days ago.