Intro to go here explaining LXD versus LXC and why you want to use it. For now, key bullets,
- LXD sits on top of LXC and uses a higher level set of commands
- REST API to orchestrates containers locally and remotely
- Allows moving and copying between hosts
- Takes advantage of advanced file systems (in particular ZFS)
- Improves on security specifically running as unprivileged hence root inside container does not get root on host
On your host system, either install LXC or install LXD. Though LXD setups an LXC subsystem, If found that the packages are different.
A key feature of virtualization technology is taking snapshots and cloning. With traditional file systems, this is expensive in terms of storage and speed. The next generation volume manager and file system ZFS solves many of theses problems and it is recommended by Ubuntu to install and use with LXD,
The other key feature to use with LXD is network bridging. By it's nature, the containers created by LXD exist in their own network. The network bridge utils allow you to expose your container to the rest of the network,
Finally install LXD,
Before using LXD you need to to do an initial configuration.
The configuration is evolving and you will notice differences between versions of Ubuntu. Because the material is rather tough, we'll archive the older Ubuntu lxd init and keep the most current release here,
LXD Init for LTS
For the most part you will be able to hit Enter and accept defaults. Some options you may go back and change but others will require lots of work so take your time.
I'll go over some of the more confusing options,
LXD allows management over the network. This is useful in an environment with multiple host LXDs and you want the ability to centrally manage. In this article, I am choosing yes because we'll later use Virtual Machine Manager to show GUI management,
LXD init will configure a bridge. In order to say yes to this you must have the bridge utils installed. In this article we covered that so say yes
You will be prompted with a "text ui" interface. Use your arrow keys to pick the buttons.
The default bridge name is lxdbr0. It's just a name but suggest you leave as default. To get to the button, use the down arrow key,
Go with IPv4 unless you have some special need to use IPv6,
You will be assigned a random subnet. For the purposes of this article, think of a subnet as a way of naming your postal code. It's the difference between Canada and US postal code. When given time I'll provide more description and write or link to a good article on subnets,
IPv4 address. This prompt is not very clear. Going to go back and check shortly. It is either reserving this IP address or asking you for a sample to determine the subnet.
A valid CIDR mask. (e.g. 24),
Initial IP Address Range does not matter unless you want to use a lot of static IP addresses. I need to think about this a bit more... the idealism behind cloud is not require static, but reality (at least for now), I still find static useful and in some application designs (stateful apps, older PKI's... ect...) absolutely necessary.
Pick default for the last address,
The DHCP leas number should be default unless you went and changed the range. If so you should adjust to match. Yeah I know the numbers do not add up (254 - 2 = 252) but I believe there is some fancy math for that... look up and link to my LXC articles.
For almost all networks this will be Yes. Tin google or to talk to Dickson or Andrew though at some point to put explanations here.
Unless you really need IPv6 say no,
After this you will be taken out of the Text UI. The warning message is due to network bridge setup,
I hate doing this in Linux, but let's reboot to make sure the lxd service is ok,
Add Users to the lxd Group
By default, users cannot yet use LXD until you add them to the reserved group. In this example, I'm adding my account,
Reminder that if you use your own account, you need to log out then log back in.
Verify LXD is Working
Basic test to verify lxd is working and it will also generate your random client certificate (used by LXD to secure calls) on your account,
At this point we have no LXD images.
Basic LXD Commands
To view your bridge information.
Notice the following,
What we see here is that the containers will be handed IPs from the LXD bridge and exist within the LXD network.
Cached Images in Image Store
List images currently cached in the image store. There should be none to start,
LXD has 3 image server lists by default,
|Image Server LIst||Purpose||Comment|
|ubuntu:||Ubuntu stable images.||We'll be working with this one.|
|images:||All Linux distriibutions.||For example you can load a RedHat Linux alternative distrobution.|
Pulling Image Server Lists
Let's look at the ubuntu: list,
The output table from list is not very clear. What you reference when using the "launch" command is the main part of the ALIAS name ignoring anything in brackets. For example to install and launch other distrobusions based off of the images: list which has all Linux distributions,
|Example "launch" Command Reference||Column||Note|
|ubuntu:16.04||This will download from the Ubuntu image server grabbing the latest 16.04 matching your machines architecture, in my case amd64.|
|ubuntu:6041c5e200b6||FINGERPRINT||Will specifically reference the specific image in the list.|
|Go against the "images" image server, download the latest cantos version 7 matching your machines architecture.|
|images:centos/6/amd64||Specifies the latest version 6 and the architecture to use.|
At this point LXD is all setup and ready to use.
Spinning Up an LXD Container
Creating and starting a container can be done with one command,
This command does the following simultaneously,
- References the ubuntu: Image Server List
- Looks for 16.01 images
- Matches the current architecture of the machine you are on (in my example
- Checks the cache Image Store for the required image
- Download (if not in Image Store) the target image
- Setup Container called container01 with default settings
- Install the target image into container01
- Start container01
Replace launch with init if you would like the container to not start by itself.
We can see the downloaded target image,
Now instead of empty, we see the downloaded image which matches our architecture.
Also, let's look at the running container. The commands are only slightly different than using straight LXC,
For illustration of flexiblity and preparing for the next section, we will update and setup Apache inside of container01.
Remotely execute update of the container from the host which are run as root,
And now we'll actually create a bash to simulate going in as a console. Notice the prompt change indicating you are root inside of container01,
Now we install Apache and then exit back to our host,
Managing Containers Between Hosts
The most compelling reason to use LXD is ability to transport between containers. Setup a second LXD host on the same network. In this example we end up with two hosts,
|myhost01||Where we setup container01 with Apache running inside.||This will be the host we can to copy the container from also called remote host.|
|myhost02||Just empty at the moment.||This will be the client also called the local machine.|
Expose Remote Host
In order for the local machine to connect, the remote host needs to be setup to be exposed on the network with a password. Following the instructions here, that work has been done while initializing LXD.
Configure Local Machine
myhost02 (local machine) needs to be made aware of the remote host. I suppose there are multiple ways of doing this and interested in if there is automatic discovery. For now, I'm going to use direct IP address.
Now the list has been updated to have myhost02 as an entry,
Interacting with Remote Host
Interaction is exactly the same as a local container except you specify the registered lxd host name,
Also keep this concept in mind even when referencing cached images.
Copying Containers Between Hosts
We will now copy myhost01, container01 (which is running Apache into) into myhost02. The copy is identical except no snapshots and volatile keys are regenerated. For example, the MAC address will be reset and a new host name embedded.
There are two key methods. Clone semi-live using snapshots and shutting down first.
Investigate if cloning between different lxd versions is supported and to what extent.
Log into myhost02
A copy of container01 has been copied to myhost02 and given the container name web01. Everything is the same except for (...),
Snapshots are a great way to backup a container before upgrading or changing any files that will break a container.
Using lxc list will show that your container now has a snapshot.
The snapshot name can be viewed using the lxc info command
To restore a snapshot
Renaming a snapshot
Creating a container from a snapshot
Deleting a snapshot
With copy, the new container is identical in every way except no snapshots and volatile keys (ie MAC address and hostnames) will be regenerated.
Creating an exact duplicate or moving a container is a different concept but just as easy.
Current Limitations and Considerations
- Consistency of host IDs which impact containers
- Baselining host patches and OS layer
- No concept yet or documentation on Sparse Containers like Solaris...
Advanced Tuning of Containers
Depending on your needs there are advanced configurations options with LXD. Below are key considerations I think about,
- Advanced Networking
- Tunnelling ect... as covered in LXC with Advanced Networking
- Joining LXD host networks together
- Capping Resource Utilization
- Sparse Containers like Solaris...
- Permissions Inside and Outside of Containers
File Transfer with Containers
Files can now be transferred from host to containers or container to container with the new lxc push and pull commands.
If you need to reconfigure the bridge you can by using this command.
Official Ubuntu Documentation - https://linuxcontainers.org/lxd/getting-started-cli/
Try Online Interactive Tutorial - https://linuxcontainers.org/lxd/try-it/
Remote Container Management - https://www.stgraber.org/2016/03/19/lxd-2-0-your-first-lxd-container-312/
Possible Sparse Containers Approach - https://www.hastexo.com/blogs/florian/2016/02/21/containers-just-because-everyone-else/
Live Container Migrations - https://bobcares.com/blog/lxc-live-migration-to-minimize-business-downtime/
Mounting a local folder - https://tribaal.io/nicer-mounting-home-in-lxd.html