background-size: contain background-image: url(edent-SVGtestcard.svg) class: center, bottom <small> github.com edent/SVGtestcard <br> Copyright (c) 2017 Terence Eden </small> --- class: center, middle .chapterhead[ # Creating Debian and Ubuntu container base images # The old and simple way ] .footnote[Hamish Coleman - hamish@zot.org] ??? - Your notes here --- # What is a base image? - A root filesystem - Or a template for one - eg: Docker, Kubernetes and LXC all will use base image templates ??? - Pretty much all operating systems have a root filesystem - It is the one place that the system expects to exist so it can boot up - All other kinds of Thin VMs - Containers - are no different - The same for Thick VMs - Full System emulators - they have this root filesystem packed into their disk image -- - Not used for "single binary image" containers ??? - There are some container building efforts that build "single binary images" - This talk is not touching on those -- <br> # Where do *your* base images come from? - Provided by your Operating System - Downloaded by your framework -- - "Steve", around the back of the pub? --- # Why build your own? - The three "R"s: - Repeatable - Reliable - Reproducible - Customise the default config to match your needs - Include special packages (private builds or specific versions) - Use one build that can be used for Testing, QA, CI and Production - Building for new architectures or hardware platforms ??? - If you are using services provided by others, it is often important to have both trust in them and a plan for when they stop - Building your own image gives you the ability to prove that you can control your software and work independantly of external changes. - It can also be important if you are incorporating your own local software as that software will not be part of any third party image - Finally, it is sometimes required if you are building for a new machine or architecture that nobody else supports. --- # What options do I have? - debootstrap - Used by the Ubuntu and Debian installers, implements all the package installation internally, so only needs shell, wget and binutils to run - cdebootstrap - A "C implementation of debootstrap", with the same features - multistrap - Uses the normal debian apt and dpkg tools. Supports installing the base system with packages from multiple repositories - vmdebootstrap - Wrapper around debootstrap for building a virtual disk image for VMs - Many more! ??? - debootstrap can be used to install Debian from a completely different OS, without installing anything other than the debootstrap shell script - These four are all easily installable from the Debian and Ubuntu package repositories - There are other packaged options, and even more that are just someones project - I will go into more detail about two of these: - debootstrap since it is the lowest common denominator - multistrap because it is is useful for foreign architecture or multi-repository cases --- # debootstrap <p style="line-height: 99%;"><br></p> <pre class="example"> sudo debootstrap --arch=amd64 \ SUITE \ TARGETDIR \ MIRROR </pre> ??? - Foreign architecture needs a second stage (--foreign and --second-stage) - It is possible to avoid requiring root for much of the build, but that has its own complications (fakeroot permissions preservation, foreign arch emu) -- SUITE is one of the Debian/Ubuntu release code names: - jessie, trusty, stretch, xenial, bionic, buster, etc MIRROR is the package repository URL: - http://httpredir.debian.org/debian - http://archive.ubuntu.com/ubuntu --- # debootstrap <div class="exampleref"> (See also the [example1](example1) files in the repo) </div> <pre class="example"> sudo debootstrap --arch=amd64 \ stretch \ /var/lib/container-example/example1 \ http://httpredir.debian.org/debian </pre> ??? - This will take some time - There are ways to cache the downloads and speed it up - The codenames for both debian and ubuntu are valid here, however a newer debootstrap might sometimes be needed (or a workaround) - Ubuntu would obviously have a different archive URL --- # multistrap <pre class="example"> sudo /usr/sbin/multistrap --arch amd64 \ -f multistrap.conf \ -d TARGETDIR </pre> ??? - stateless - can pickup where it left off - Harder to avoid running as root (fakeroot doesnt work as well here) - needs a postinstall script to properly complete installation - policy.d to avoid packages starting (multistrap runs the "real" package post install scripts - Foreign architecture is still fun -- <br><br> *NOTE:* it needs a config file! --- # multistrap Config file ([multistrap.conf](example2/multistrap.conf)) <pre class="example"> [General] bootstrap=NameOfSectionDefiningRepo aptsources=NameOfSectionDefiningRepo [NameOfSectionDefiningRepo] source=MIRROR suite=SUITE keyring=debian-archive-keyring ubuntu-archive-keyring packages= systemd udev kmod apt </pre> ??? - Some lines left out for berevity - see the example2 folder in the repo for a complete set - keyring defines a package name that needs to be installed on the host build system to allow the correct authentication of packages installed in the target --- # multistrap <div class="exampleref"> (See also the [example2](example2) files in the repo) </div> Install stage: <pre class="example"> sudo /usr/sbin/multistrap --arch amd64 \ -f multistrap.conf \ -d /var/lib/container-example/example2 </pre> <br> Configure stage: (sometimes optional) <pre class="example"> chroot /var/lib/container-example/example2 \ dpkg --configure -a </pre> ??? - Installation does everything it can, up until it needs to run the install scripts - Configure is needed for foreign architectures, or more complex native ones - For clarity, the configure step has been significantly shortened. See the example files (or just read the multistrap man page) for more details --- # Compare the two tools: | | debootstrap | multistrap | |------------------------------------------|:-----------:|:----------:| | Used by the distro installer | <p>✔</p> | | | Can install from multiple package repos | | <p>✔</p> | | Has a Config file | | <p>✔</p> | | Installs packages with the normal tools | | <p>✔</p> | | Can install without runing binaries for the target architecture | <p>✔</p> | | ??? - I use debootstrap for anything simple - especially oneliners - While debootstrap can be customised to do complex installs, I prefer the ability to use the multistrap config file - The config file also allows annotations and git commits to be clear - It is worth noting that multistrap installs less packages by default --- # Immediately Useful - The outputs of these tools can be used as is: <pre class="example"> chroot /var/lib/container-example/example2 dpkg -l exit </pre> -- ## Useful for - Clean build environments - Testing the installation of new packages --- # But not without issues <pre class="example"> chroot /var/lib/container-example/example1 perl -e 'print "hello world\n"' -- perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LC_COLLATE = "C", LANG = "en_AU.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). hello world exit </pre> --- # But not without issues <pre class="example"> chroot /var/lib/container-example/example2 apt install less -- Reading package lists... Done [..omitted..] Need to get 126 kB of archives. After this operation, 284 kB of additional disk space will be used. Err:1 http://httpredir.debian.org/debian stretch/main amd64 less amd64 481-2.1 Temporary failure resolving 'httpredir.debian.org' E: Failed to fetch http://httpredir.debian.org/debian/pool/main/l/less/less_481-2.1_amd64.deb Temporary failure resolving 'httpredir.debian.org' E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? exit </pre> ??? - The chroot also has very little isolation from the rest of the system --- # Improvements <div class="exampleref"> (See the <a href="example3">example3</a> files in the repo for scripts implementing these) </div> Building a reusable template: - fixup - customise - minimise Turning a template into a specific machine: - instantiate ??? - I separate the post debootstrap changes into several categories, each with a specific purpose --- # fixup These are changes that help the image to boot properly or remove (incorrect) identifying information - anything that could be considered "broken" <pre class="example"> shred -fu TARGETDIR/etc/hostname shred -fu TARGETDIR/etc/machine-id shred -fu TARGETDIR/etc/ssh/*_key echo "nameserver 1.1.1.1" > TARGETDIR/etc/resolv.conf </pre> ??? - however, not "networking", since the image will boot without that and your network setup is often custom to your environment. (segway) --- # customise The changes needed for your local configuration - anything that is applicable to all instances of the template. <pre class="example"> echo root:hunter2 | sudo chpasswd -c SHA256 -R TARGETDIR chroot TARGETDIR systemctl enable systemd-networkd chroot TARGETDIR systemctl enable systemd-resolved echo "nameserver 127.0.0.53" > TARGETDIR/etc/resolv.conf </pre> ??? In a non testing environment, this would often have a small list of bootstrap management users - which would then be used by your configuration automation tool to login and perform automated tasks - yes, this overwrites the earlier resolv.conf fix - Additionally, the chroot can be avoided for foreign arch cases, but is used here for simplicity --- # minimise Size reductions on the image <pre class="example"> rm -rf TARGETDIR/usr/share/locale/* rm -rf TARGETDIR/usr/share/doc/* rm -rf TARGETDIR/lib/udev/hwdb.bin </pre> ??? There is often quite a lot of extra space used on these images. Since the base images are generally going to be used on automatically created container systems, there is a lot of documentation that can simply be removed to slim down the space used. --- # instantiate - Some container systems take care of instantiation for you - If the end result is not a container infrastructure, you probably need to do it yourself. <pre class="example"> echo realhostname >TARGETDIR/etc/hostname echo 127.0.1.1 realhostname >>TARGETDIR/etc/hosts chroot TARGETDIR dpkg-reconfigure openssh-server </pre> ??? - Skip the openssh reconfigure if you dont have ssh installed.. --- # Simple boot The systemd-nspawn tool provides a quick and no-fuss way to startup and test containers. <pre class="example"> sudo systemd-nspawn --boot --ephemeral \ --directory=/var/lib/container-example/example2 </pre> `--ephemeral` means that nspawn will copy the template dir and all changes will be lost when the container stops. ??? - if you dont have the systemd-nspawn, install it from the systemd-container package. (This command boots the container with networking shared with the host) -- - login using the root password you set earlier - stop the container: - from inside the guest with: `systemctl poweroff` - from outside on the host with: `machinectl stop name` ??? The nspawn command has lots of other options --- # Using libvirt + LXC <div class="exampleref"> (See [example4](example4) in the repo) </div> <pre class="example"> <domain type='lxc'> <name>newhost</name> <memory unit='KiB'>200000</memory> <os> <type arch='x86_64'>exe</type> <init>/sbin/init</init> </os> ... </pre> - <pre class="example"> virsh -c lxc:/// define newhost.xml </pre> - <pre class="example"> virsh start newhost </pre> ??? The XML in the repo is actually quite short, but it is still long to fit on this slide (see bonus slide) --- # Can also be used to build VM disk images - guestfish - A library and toolset for automatically creating, partitioning, formatting and populating VM disk images. - uefi booting - Can be installed with the addition of a couple of extra files. - packing for qemu - Making sure that the VM disk image is suitable for your virtualisation platform. --- <div class="center middle"><h1>Questions?</h1></div> <br><br><br><br> <div class="center middle"><h1>Example files are in the repository</h1></div> - github project: - https://github.com/hamishcoleman/talk-containers1/ - talk slides: - https://hamishcoleman.github.io/talk-containers1/slides.html <br><br> <div class="right">Hamish Coleman - hamish@zot.org</div> ??? - Finish it all up with a page of links --- <div class="exampleref"> Can I see that libvirt config again? </div> <pre class="example"> <domain type='lxc'> <name>newhost</name> <memory unit='KiB'>200000</memory> <os> <type arch='x86_64'>exe</type> <init>/sbin/init</init> </os> <devices> <emulator>/usr/lib/libvirt/libvirt_lxc</emulator> <filesystem type='mount' accessmode='mapped'> <source dir='/var/lib/container-example/newhost'/> <target dir='/'/> </filesystem> <interface type='network'> <source network='default'/> <guest dev='host0'/> </interface> <console type='pty'> <target type='lxc' port='0'/> </console> </devices> </domain> </pre> --- # How do I do this for RPM based distros? From Debian or Ubuntu, this is a starting point: <pre class="example"> apt install rpm yum HOME= rpm --root=/var/lib/container-example/centos \ --initdb mkdir -p /var/lib/container-example/centos/var/lib mv /var/lib/container-example/centos/.rpmdb \ /var/lib/container-example/centos/var/lib/rpm wget http://mirror.centos.org/centos/7/os/x86_64/Packages/centos-release-7-6.1810.2.el7.centos.x86_64.rpm rpm --root=/var/lib/container-example/centos \ -i --nodeps \ centos-release-7-6.1810.2.el7.centos.x86_64.rpm yum --installroot=/var/lib/container-example/centos \ install -y rpm-build yum --nogpgcheck </pre> <!-- End slides. -->