Linux Tips Weekly

– [Instructor] Like virtualization, containers allow us to separate running software into a protected area isolated from other things running on a system but unlike virtualization, containers use the host’s kernel rather than booting a full operating system with its own kernel inside the protected space. This makes them more space efficient but limits them to running the same operating system as the host generally speaking. You can put a Windows container on a Linux host but you can use nearly any flavor of Linux inside a container on a Linux host. To set up a container, we give it a root file system which generally comes from a distro designed to run in a container.

Distros for containers generally are paired down and secured more than regular distros providing only what software running inside a container needs and not a lot of extraneous stuff. Containers operate using namespaces and cgroups, two individual features of the Linux kernel that are combined to isolate processes and control resource usage respectively. We won’t get into the details of that here but I encourage you to explore those features more if you’re so inclined. The container management software we’ll use here on Ubuntu is called LXD or LXD and it provides a suite of tools to well, manage containers.

LXD extends older software called LXC and you’ll see LXC pop up in command names here and there. To install the LXD software, I’ll write apt install lxd. And when that’s done, we need to initialize the LXD system to put in place some of the infrastructure that LCD uses. For that I’ll write lxd init. There’s a few options here and I’ll just accept the defaults.

Depending on your distro and version, how you see this information may vary. Clustering allows you to run LXD on more than one system to manage lots of resources across different machines through one control interface. A storage pool is where disk images that containers use as their file systems are kept. We’ll create a new one because we don’t have one yet. And we’ll accept the default name. We’re not going to connect to a mass server which is Ubuntu’s metal as a service service which can be used to provision machines on bare metal hardware.

You’ll create a new network bridge which allows network access for containers and we’ll accept the default name for that and set the network space it uses to automatic. Depending on your requirements, you may need to set a particular range but my setup here is pretty simple, so we’ll stick with auto. Then we’re asked if we want LXD to be available over the network. This would allow remote clients to connect to the LXD service to manage containers but for now we’ll just use it locally. Remote clients could still SSH in and use the manager locally here.

LXD uses prebuilt images to create containers and this option will refresh once we’ve downloaded and used to keep them up to date for subsequent container creation. And then we can choose whether to see the configuration here in case we want to replicate it somewhere else. I’ll choose now. Now we’re set up to create and manage containers on this host. From here on out we’ll use the LXC command and you can see some information about what it does with lxc –help. To create a container, we’ll use lxc launch and then the name of an image.

This is usually specified as host colon, the image name slash version. You can see some images hosted on linuxcontainers.org at the site images.linuxcontainers.org. And then, for example, to start an Alpine Linux container of version 3.8, we type images:alpine/3.8. If I don’t provide a name for my container, LXC will create one for me.

In this case, it’s easy-catfish. After LXC downloads everything it needs, the container is set up and running and we can see it with lxc list. I can run the container shell over any other particular command in the container with lxc exec, the name of the container and then the path to the executable, in this case, let’s run ash, the Alpine shell and here I am at the prompt within the container. I can do things here that will change the container but not the system like updating the packages, adding software and so on.

Taking a look at the processes here, I can see that I’m isolated from the host system and I can take a look at my networking information where I can see that this container is using the IP range that’s managed by LXD’s network bridge. Okay, to exit that, I can type exit and then be back at my host’s prompt. I can do some other things with containers like copy files into and out of them, list the containers that are running and start and stop containers. Be sure to check out the man page and help for LXD to find out more.

I’ll stop my container here with lxc stop easy-catfish and then I’ll delete it with lxc delete easy-catfish. There’s a lot to container manager including modifying network and storage resources but we won’t get into those here. Container management is a great skill to pick up if you’re a system administrator or a developer.

Leave a Reply