X-Git-Url: http://git.tuebingen.mpg.de/?p=aple.git;a=blobdiff_plain;f=OS-Level_Virtualization.m4;h=47d5bad22ae2fd52397ef2444d6ec76f807c088c;hp=34d351e5160efe8710f80b86b58542ebea75b165;hb=HEAD;hpb=1f971455da2eb8b1e3427198a5eae6cbc993dc32 diff --git a/OS-Level_Virtualization.m4 b/OS-Level_Virtualization.m4 index 34d351e..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() @@ -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()git://git.tuebingen.mpg.de/micoforia
and compile the
+ source code with ./configure && make
. Install with
+ make install
. debootstrap --download-only
+ --include isc-dhcp-client bionic /var/lib/micoforia/c1/
+ http://de.archive.ubuntu.com/ubuntu
. micoforia(8)
. Consult the Link Layer section of the
+ chapter on networking if you would like to understand what you are
+ doing.
- https://github.com/lxc/lxc
, check out the stable-1.0
-
tag. Compile the source code with ./autogen.sh
- and ./configure && make
. Install with sudo make
- install
. /etc/fstab
to configure
+ the cgroup filesystems, create corresponding directories and run
+ mount -a
to mount them. debootstrap --download-only --include isc-dhcp-client bionic
- /media/lxc/buru/ http://de.archive.ubuntu.com/ubuntu
. + none /var/cgroup cgroup devices 0 0 + none /var/cgroup2 cgroup2 defaults 0 0 +-
c1
with echo
+ container c1 > ~/.micoforiarc
. This container will have a
+ single network device and neither CPU nor memory isolation will be
+ enforced for the processes of the container. micoforia --
+ start -F c1
.
- /var/lib/lxc/buru/config
. Adjust host name, MAC address and
- the name of the bridge interface. micoforia stop c1
to stop the container,
+ edit ~/.micoforiarc
and add the following two lines to
+ configure memory and CPU limits.
- lxc-start -n buru
. + cpu-cores c1:1 + memory-limit c1:1 +-
lxc-cgroup
command
- to change the cpuset and the memory of the container while it is
- running.
-
- # 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»)