Exercise 6 - Changing the Filesystem

All of that is well and good. However, containers are great because they allow us to package and distribute software. All we’ve done is isolate some Linux processes. Where’s the beef?

Containers get their root filesystem from a container image file. This is typically pulled from a registry. This file is, essentially, a TAR archive with the root filesystem contents and some metadata. Those contents are then made available to the running container through use of an Overlay Filesystem. The Overlay Filesystem mechanism allows the container to use the files provided by the image and make ephemeral changes to those files.

This is how Overlay Filesystems work. There are four directories: LOWER, UPPER, WORK, and MOUNT. The LOWER directory contains the filesystem’s initial state. This is the contents of the container image and can be read only. The UPPER directory is where runtime changes will be stored and must be read/write. The WORK directory is where runtime changes are staged and must be read/write. Finally, the MOUNT directory is simply a directory where the OverlayFS is mounted and presented as a single filesystem. This is the directory we will chroot our container into.

Strictly speaking, there are other backend storage methods that can be used with containers. However, OverlayFS has become quite popular lately and it is the one used by podman.

For these exercises, we will need two things: Fuse and Skopeo. Run the following command as root.

Fuse is a Linux utilty that allows Filesystems to be run in user space instead of Kernel space. This allows non-priviledged users to create and mount filesystems. Skopeo is a utility for interacting with remote container registries without the need to a container runtime engine.

Now we want to download the contents of the Fedora image stored on Docker Hub.

If you have worked with containers before, you will have a general notion of image files. However, you have probably never seen one. They usually get stashed away in /var/lib/containers or /var/lib/docker and you interact with them only through the orchestration of your container engine. Today we will change all that. We have downloaded the fedora:31 image and saved it to a folder called fedora. Change into this directory and list the contents.

Here we have a few files: - version contains the OCI file format spec information for this image - manifest.json contains information regarding the contents of the image - f085…​ contains the image metadata. We know that because it is small in file size. - d318…​ contains the image layer. This image contains only one layer, but some will contain more than one. These layers get stacked to create the base filesystem. We know this is a layer because its file size is quite large.

Now let’s extract the contents of the layer.

What we have just extracted is a Fedora 31 system’s root filesystem!

Now let’s use the LOWER directory we just populated to create an OverlayFS.

Now you can explore the ROOTFS directory. You’ll notice it is a replica of the LOWER dir. As you make changes to ROOTFS, those changes will appear in UPPER.

Let’s add a chroot to our namespace skills to create a container.

And there we have it. A bona fide Fedora container! Feel free to poke around the container a bit. Because the Fedora image is very barebones, you won’t be able to do much. Type exit when you are done.

×

Workshop Details

Domain
Workshop
Student ID

Student ID 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

Domain lab-emergent360.com

Workshop

Enter Default

Workshop Details

Domain
Workshop
Student ID