| |||||||||||||
OpenVZ OS Templates and rBuilderOpenVZ OS Templates and rBuilderPosted Aug 8, 2008 22:14 UTC (Fri) by michaelkjohnson (subscriber, #41438)In reply to: Outputing OpenVZ compatible .tar.gz files for use inside of containers by dowdle Parent article: Building custom appliance distributions with rBuilder
OpenvZ OS Templates are subsets of those mostly with unneeded software and services removed. In a nutshell, that's also essentially what appliance images created on rBuilder are. I'll provide more detail. There are two key Conary technology concepts that matter here, flavors and groups. I'll start with groups. In legacy packaging systems, you have lists of packages, which may be nested and/or grouped in various ways. Examples include RH/Fedora "comps.xml" and Debian "tasks". In all of these cases is that this list is essentially a form of source code. There is some client software that process that list and makes install-time decisions about versions of each individual package -- rather like compiling at install time, but the thing that is being compiled is a list instead of program source code. By contrast, Conary builds lists of packages into a complete list of exact versions of all the contents, and so a single version of a "group" tells you the exact contents of every single file on the filesystem. So Conary compiles the list source code into a binary representation as a packaging action and stores it on the repository server; it's not a client install-time action. Flavors describe all the different things that can happen when building a version. This includes things like x86 vs. x86_64 (instruction set architecture) and configuration characteristics that can include whether the binary is built for (say) VMware or Xen, as well as whether tcpwrappers, kerberos, and/or emacs support should be built into binaries. The combination of all these configuration elements is called a flavor. Putting this together: Individual packages have flavors, and so do groups. Because a group specifies all the files included in the image, building an additional flavor of a group not only has a QA cost, but also simply takes significant build time; it adds complexity all around. This means that we do not lightly add new group flavors to the set of flavors we explicitly provide as part of our base operating system. rBuilder can already create a .tar.gz file of a fairly minimal installation. We've been building images with "Just Enough OS" since before the "JeOS" term was coined. The normal way that you create a group that defines your own image is to say that you want a minimal functional operating system, plus the things you need, plus whatever is needed to satisfy the requirements of the things that you list explicitly. This means that the images are already quite small. One of the features of the second version of our operating system is that we cut roughly in half the size of the base functional operating system. In fact, we don't include a normal desktop in that version of our operating system at all -- we have GNOME bits only as needed to be able to build the Anaconda installer. However, we don't have a set of groups of our base operating system that are missing the kernel entirely. You can, when building your own groups that define your own images, specify a flavor that explicitly omits elements that are normally part of the base platform, such as the kernel, in order to optimize them for deployment as OpenVZ OS Templates. So, from the information you've given me here, our images are actually pretty good bases to be deployed under OpenVZ, and if someone wants to further optimize versions of their images to be deployed under OpenVZ, they need merely to add a few lines in their group definitions and build an additional "flavor" or two, and build tarball images to match. Hope that helps, and nice to (virtually) meet you!
(Log in to post comments)
|
|||||||||||||