X-Git-Url: http://git.tuebingen.mpg.de/?p=aple.git;a=blobdiff_plain;f=OS-Level_Virtualization.m4;h=47d5bad22ae2fd52397ef2444d6ec76f807c088c;hp=aa5c4e5409772ae739ba588556740a620ac34188;hb=afc22623c916f058fbefd86788b0e790f0723adf;hpb=7dbb0871ecb9deb0ed777a9f2de4e4a0d74b66cf diff --git a/OS-Level_Virtualization.m4 b/OS-Level_Virtualization.m4 index aa5c4e5..47d5bad 100644 --- a/OS-Level_Virtualization.m4 +++ b/OS-Level_Virtualization.m4 @@ -16,9 +16,8 @@ Linux OS-level virtualization and their virtual machines called containers. Container platforms for Linux are built on top of namespaces and control groups, the low-level kernel features which implement abstraction and isolation of processes. We -look at both concepts in some detail. One of the earliest container -platforms for Linux is LXC (Linux containers) which is -discussed in a dedicated section. +look at both concepts in some detail. The final section discusses +micoforia, a minimal container platform. ») @@ -105,7 +104,7 @@ simplicity and its performance. The only disadvantage is the lack of flexibility. It is simply not an option if some of the VMs must run different operating systems than the host. -Examples: LXC, Singularity, Docker. +Examples: LXC, Micoforia, Singularity, Docker. EXERCISES() @@ -296,7 +295,7 @@ is created with unshare(2) or clone(2). The UID and GID of a process can be different in different namespaces. In particular, an unprivileged process may have UID 0 inside an user namespace. When a process is created in a new -namespace or an process joins an existing user namespace, it gains full +namespace or a process joins an existing user namespace, it gains full privileges in this namespace. However, the process has no additional privileges in the parent/previous namespace. Moreover, a certain flag is set for the process which prevents the process from entering yet @@ -616,9 +615,9 @@ HOMEWORK(« ») -SECTION(«Linux Containers (LXC)») +SECTION(«Linux Containers») -Containers provide resource management through control groups and +

Containers provide resource management through control groups and resource isolation through namespaces. A container platform is thus a software layer implemented on top of these features. Given a directory containing a Linux root file system, starting the container @@ -631,80 +630,99 @@ by calling exec(2). When the last process in the newly created namespaces exits, the namespaces disappear and the parent process removes the cgroup. The details are a bit more complicated, but the above covers the essence of what the container startup command -has to do. - -Many container platforms offer additional features not to be discussed -here, like downloading and unpacking a file system image from the -internet, or supplying the root file system for the container by other -means, for example by creating an LVM snapshot of a master image. -LXC is a comparably simple container platform which can be used to -start a single daemon in a container, or to boot a container from -a root file system as described above. It provides several -lxc-* commands to start, stop and maintain containers. -LXC version 1 is much simpler than subsequent versions, and is still -being maintained, so we only discuss this version of LXC here. - -An LXC container is defined by a configuration file in -the format described in lxc.conf(5). A minimal configuration which -defines a network device and requests CPU and memory isolation has -as few as 10 lines (not counting comments). With the configuration -file and the root file system in place, the container can be started -by running lxc-start -n $NAME. One can log in to the -container on the local pseudo terminal or via ssh (provided the sshd -package is installed). The container can be stopped by executing - halt from within the container, or by running -lxc-stop on the host system. lxc-ls and - lxc-info print information about containers, and -lxc-cgroup changes the settings of the cgroup associated with -a container. - -The exercises ask the reader to install the LXC package from source, -and to set up a minimal container running Ubuntu-18.04. +has to do.

+ +

Many container platforms offer additional features not to +be discussed here, like downloading and unpacking a file system +image from the internet, or supplying the root file system +for the container by other means, for example by creating an +LVM snapshot of a master image. In this section we look at micoforia, +a minimalistic container platform to boot a container from an existing +root file system as described above.

+ +

The containers known to micoforia are defined in the single +~/.micoforiarc configuration file whose format is +described in micoforia(8). The micoforia +command supports various subcommands to maintain containers. For +example, containers are started with a command such as micoforia +start c1 where c1 is the name of the +container. One can execute a shell running within the container +with micoforia enter c1, log in to a local pseudo +terminal with micoforia attach c1, or connect via ssh +with ssh c1. Of course the latter command only works +if the network interface and the DNS record get configured during +container startup and the sshd package is installed. The container can +be stopped by executing halt from within the container, +or by running micoforia stop c1 on the host system. The +commands micoforia ls and micoforia ps +print information about containers and their processes.

+ +

The exercises ask the reader to install the micoforia package from +source, and to set up a minimal container running Ubuntu Linux.

EXERCISES() -HOMEWORK(«Compare the features of LXC versions 1, 2 and 3.») - SUPPLEMENTS() SUBSECTION(«UTS Namespace Example») @@ -769,51 +787,6 @@ SUBSECTION(«PID Namespace Example») -SUBSECTION(«Minimal LXC Config File») -
-	
-		# Employ cgroups to limit the CPUs and the amount of memory the container is
-		# allowed to use.
-		lxc.cgroup.cpuset.cpus = 0-1
-		lxc.cgroup.memory.limit_in_bytes = 2G
-
-		# So that the container starts out with a fresh UTS namespace that
-		# has already set its hostname.
-		lxc.utsname = buru
-
-		# LXC does not play ball if we don't set the type of the network device.
-		# It will always be veth.
-		lxc.network.type = veth
-
-		# This sets the name of the veth pair which is visible on the host. This
-		# way it is easy to tell which interface belongs to which container.
-		lxc.network.veth.pair = buru
-
-		# Of course we need to tell LXC where the root file system of the container
-		# is located. LXC will automatically mount a couple of pseudo file systems
-		# for the container, including /proc and /sys.
-		lxc.rootfs = /media/lxc/buru
-
-		# so that we can assign a fixed address via DHCP
-		lxc.network.hwaddr = ac:de:48:32:35:cf
-
-		# You must NOT have a link from /dev/kmsg pointing to /dev/console. In the host
-		# it should be a real device. In a container it must NOT exist. When /dev/kmsg
-		# points to /dev/console, systemd-journald reads from /dev/kmsg and then writes
-		# to /dev/console (which it then reads from /dev/kmsg and writes again to
-		# /dev/console ad infinitum). You've inadvertently created a messaging loop
-		# that's causing systemd-journald to go berserk on your CPU.
-		#
-		# Make sure to remove /var/lib/lxc/${container}/rootfs.dev/kmsg
-		lxc.kmsg = 0
-
-		lxc.network.link = br39
-
-		# This is needed for lxc-console
-		lxc.tty = 4
-	
-
- SECTION(«Further Reading»)