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
If you would like to run Kubernetes workloads on your computer with Juju, we recommend MicroK8s with the MicroK8s cloud.
If you are looking to connect to a LXD server, rather than accessing LXD installed locally, then read Adding a remote LXD cloud.
About LXD
LXD is an open source hypervisor that is secure, lightweight, and very easy to use. For Juju users, LXD makes it easy to create a cloud in your laptop.
It provides secure system containers based on the LXC functionality within the Linux kernel and virtual machines via QEMU.
Need to install LXD?
See LXD’s Getting Started page at linuxcontainers.org for installation instructions for Windows, macOS, and Linux.
Why not Docker, Vagrant or another option?
Docker containers are a great solution for running a single application within a container.
Its model has some weaknesses when used more widely.
LXD focuses on system-level virtualization, offering an operating system-like environment within a container.
More importantly though, LXD offers greater security.
LXD does not require privileged containers, unlike Docker.
Vagrant requires resource-intensive virtual machines.
This can make it difficult to simulate large models.
Setting up the localhost cloud
The localhost cloud requires minimal setup. Neither registering LXD with Juju, nor security credentials are required.
Configure 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.
Configure Networking
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
Deploying workloads
Workloads live within a “model” that is managed by the “Juju controller”.
Creating a controller
Use the juju bootstrap command to provision a machine within LXD and create a controller running within it.
juju bootstrap localhost
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.
Adding a model
A model is a workspace for a set of inter-related applications. It houses machines and applications (often referred to as “workloads”), as well as associated resources such as firewall rules and storage volumes.
juju add-model <model>
Models are tied to Juju user accounts. This allows Juju administrators to create fine-grained access controls over the infrastructure used by their team.
Adding a model does not create compute resources. They are provisioned on-demand with the juju deploy and juju add-machine commands.
Deploying a workload
The 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
Next steps
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
Use 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
Common Questions
How do I find charms to deploy?
Visit the Charm Store.
How do I access help?
We recommend creating an account in the Juju Discourse forum.
How do I inspect the model?
Use the juju dashboard and/or the juju status command.
How do Juju machines correspond to LXC containers?
There is a 1:1 correspondence between machine and container. From the command-line, we can request that Juju report the list of machines within the controller model:
juju machines -m controller
Machine State DNS Inst id Series AZ Message
0 started 10.243.67.177 juju-c795fe-0 bionic Running
The “Inst id” column corresponds to the “NAME” column from LXC’s output:
lxc list
+---------------+---------+----------------------+------+------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+---------------+---------+----------------------+------+------------+-----------+
| juju-c795fe-0 | RUNNING | 10.243.67.177 (eth0) | | PERSISTENT | |
+---------------+---------+----------------------+------+------------+-----------+
Considerations with the localhost cloud
Juju aims to abstract away the differences between individual cloud providers. LXD offers the following differences:
Constraints
Constraints are applied differently to containers. When deploying containers, constraints are interpreted as resource maximums as opposed to minimums. See Constraints and LXD containers for further details.
Advanced usage
LXD tips
For more information relating to an optimal experience with LXD—especially in cases where there might be unique requirements—read the Additional LXD resources page. It covers:
- Using LXD with custom container images
- LXD and group membership
- Adding non-admin user credentials
- Useful LXD client commands
- Using the LXD snap from Ubuntu Server older series
- Accessing LXD log files directly
Juju-specific advice
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