kvm linux_在Linux KVM上创建ooRexx构建环境
kvm linux
最近，Open Object Rexx项目（ooRexx； 有关更多信息，请参见本文后面的参考资料）将其旧的按需软件构建系统从VMware托管的来宾操作系统转换为Linux内核虚拟机（KVM）托管的来宾。 此更改提供了更有效的构建环境，并减少了用户的构建时间。
ooRexx软件构建系统允许开发人员为多个基于x86的平台和操作系统构建ooRexx软件包。 当前，受支持的客户机操作系统包括Windows®XP（i386），Fedora 10（i386和x86_64）和Ubuntu 8.04（i386）。 这些来宾操作系统可以为Windows（EXE），Fedora和openSUSE（RPM）和Ubuntu（DEB）生成ooRexx安装和文档包。 其他基于x86的操作系统将根据ooRexx的开发人员和用户的要求上线。
本文以ooRexx开发团队的设置为例，介绍了如何创建自己的软件构建系统，并提供了具有ooRexx，Apache和Linux经验的开发人员所需的技巧和指导。 您可以在本文末尾下载服务器和来宾脚本 。 按照设计，该系统专门用于构建ooRexx软件，但是这些概念可以应用于任何软件的通用构建系统。
该系统的广泛要求包括：
- 您需要一个Web界面来生成构建请求。
- 您需要一个Web界面来检索构建结果。
- 您需要支持多个来宾操作系统。
- 来宾操作系统必须执行全自动构建。
- 电子邮件应生成并在构建结束时发送给发出请求的用户。
为了满足这些要求，开发团队和我使用了基于四核Xeon的服务器。 该服务器包含4GB内存和250GB磁盘空间。 我们之所以选择Fedora 10 x86_64发行版作为主要操作系统，主要是因为该发行版使用的KVM的稳定性和最新版本。 您对硬件和软件的选择可能有所不同，但是主要的硬件标准是处理器应具有可用的硬件虚拟化功能，这是使用KVM的必备条件。
设置服务器
设置构建服务器的第一步是确定分区方案。 我们决定将Web存储和来宾操作系统的映像分离到单独的分区中。 我们为Web商店预留了50GB的空间，为/ guest分区预留了150GB的空间（用于放置来宾映像）。 其余部分分为/ home分区和/ root分区。
接下来，我们使用Fedora 10 x86_64发行版安装了主操作系统。 如果您要设置自己的系统，则执行以下操作将为您省去很多麻烦：
- 在开始安装之前，请通过计算机的BIOS启用硬件虚拟化，以便Fedora将看到KVM可用。
- 执行软件组件的自定义安装，以便您可以选择Fedora虚拟化选项。
安装服务器操作系统后，我们将其配置为可供来宾操作系统访问。 这涉及为Windows来宾启用Samba，为Linux来宾启用NFS。 这使来宾可以访问构建结果分区，以便他们可以存储其构建文件以供用户访问。 Samba主共享和NFS主导出都指向所有来宾相同的位置。
接下来，我们配置Apache Web服务器以提供对构建请求系统的访问权限，我将在下面的“构建请求 ”和“构建结果存储库”中进行讨论。
您需要做出的一项配置决定涉及来宾的网络选项。 默认安装配置为为所有来宾提供专用的内部网络。 提供了C类网络以及DHCP服务器，以为访客提供IP地址。 另一种选择是设置系统，以便其中一个网络设备充当与服务器外部网络的桥梁。 这将需要手动配置。 您可以在libvirt Wiki上看到有关如何为此选项配置服务器的示例（ 有关链接，请参见参考资料）。
创建客人
有两种方法可以创建供KVM使用的来宾。 在第一种方法中，您仅创建满足需求所需的来宾。 第二种方法是采用更长远的方法来创建来宾。 这是我们用来创建访客的方法，如果有必要的资源，我们建议将其作为标准方法。
我们首先根据要求确定客人的人数和类型。 我们需要操作系统来创建针对那些环境而构建的软件，并且需要另一个操作系统来创建文档。 事实证明，在我们的案例中，文档和i386 RPM任务可以由单个来宾合并和处理。 以下是来宾和分配给他们的任务：
- Windows XP（i386）：构建Windows安装可执行文件。
- Fedora 10（i386）：构建i386 RPM文件和文档ZIP文件。
- Fedora 10（x86_64）：构建x86_64 RPM文件。
- Ubuntu 8.04（i386）：构建DEB文件。
我们使用的方法将前面提到的来宾创建为可在以后克隆的映像。 因此，每个来宾都有一个供我们稍后克隆的基本版本，以及执行实际构建任务的该来宾的自定义克隆。
克隆KVM guest虚拟机非常容易。 Fedora 10提供的virt-clone脚本可以完全自动化该任务。
清单1. Fedora 10的virt-clone脚本
$ virt-clone --original=Fedora10-i386-Base \
--name=Fedora10-i386-Build \
--file=/var/lib/libvirt/images/Fedora10-i386-Build.img original选项指定虚拟机管理器已知的来宾操作系统的名称。 name选项指定新来宾的名称。 file选项指定来宾的新图像文件的文件名。 这将完全克隆现有来宾，并将其复制到新版本的来宾。 它还将修改新访客的MAC地址以及UUID。 因此，如有必要，将保留原始来宾以进行进一步克隆，并为您的自定义提供一个新来宾。
应该注意有关virt-clone脚本的一件事：如果原始客户机具有未连接的设备（例如CD-ROM），则脚本将失败。 克隆来宾之前，必须删除所有未连接的设备。 如有必要，您可以在克隆操作后重新添加它们。
一旦创建了基本的构建客户机，就可以为构建任务自定义每个客户机。 Windows XP guest虚拟机是该领域中最具挑战性的，因为自定义过程中需要安装Visual C ++编译器和软件开发工具包。 除了在Ubuntu guest虚拟机上安装NFS外，Linux guest虚拟机几乎不需要自定义。
构建请求
所有构建来宾都需要进行另一项自定义：必须在每个安装来宾上安装Open Object Rexx版本3.2。 为什么？ 因为用ooRexx编写的脚本控制着每个来宾的请求和构建过程。 该脚本访问构建计算机服务器上的TCP / IP端口以搜索构建请求。 如果找到请求，则将调用构建过程，并创建一组安装文件（RPM，DEB，EXE）以及构建报告，并将其存储在构建机器服务器上，以供用户通过HTTP访问。
ooRexx构建请求脚本足够聪明，不会复制该软件的已构建版本。 它还通过电子邮件通知用户构建已完成，并提供URL到构建机器服务器上存储该构建的位置。
构建请求是通过构建机器服务器上的CGI脚本生成的。 用户访问HTTP网页，并请求构建他们选择的操作系统。 然后，Apache服务器调用CGI脚本，该脚本将请求放入队列中。 然后，构建客户机负责访问那些请求并执行所请求的操作。 还可以通过该网站下载生成结果。
如上所述，可以从下面下载服务器和构建来宾客户端的代码。 所有脚本都是用ooRexx编写的，应该很容易理解。 包括以下文件：
- buildserver.rex ：此脚本在Web服务器上运行，并维护来宾操作系统用来查找工作的队列。
- buildd.rex ：此脚本在每个来宾操作系统上运行，并访问Web服务器上的队列以查找工作。 每个来宾只有一个负责的队列，因此只会构建一种输出文件。
- simq.cls ：该文件不是脚本，而是buildserver.rex脚本使用的类文件。
- socket.cls ：buildd.rex脚本使用此类文件。
- streamocket.cls ：buildd.rex脚本也使用此类文件。
生成结果
构建的结果由构建来宾放置在网站上。 构建的组织方式使得每个Subversion修订版都有其自己的子目录，以包含该修订版的所有平台来宾构建。 而且，每个平台来宾都会生成一个构建报告，该报告也存储在修订子目录中。
生成报告是所有这些真正起作用的绝对必要条件。 如果在构建过程中发生错误，并且未生成最终的输出文件，则用户必须有一种方法来发现问题所在。 因此，每个来宾上的构建过程始终会生成一个构建报告，并将其存储在构建存储库中。
内部版本库位置将ooRexx软件内部版本与文档内部版本分开。 文档版本会生成大量输出文件，因此将这些版本与软件版本分开是很方便的。
当前，没有自动构建清理过程。 该项目目前无法产生足够的输出。
结论
通过从VMware build guest切换到Linux KVM guest，每个guest的构建时间减少了多达50％。 这意味着ooRexx的开发周期也已缩短。
ooRexx开发团队是迄今为止构建机器的最大用户组，但是在主要版本的alpha和beta周期中，大量的ooRexx用户也使用了该环境。 这使用户可以及时提供有关ooRexx的任何错误修复或增强的反馈。
文档构建器是最常用的构建来宾之一。 所有ooRexx文档都在DocBook中进行了编码。 如果没有在该环境中使用DocBook的经验，这将使文档难以在Windows系统上构建。 对于我们大多数开发人员和用户来说，这都是一个现实问题。 通过提供每个人都可以访问的文档构建过程，我们确保开发人员和用户可以贡献并维护文档。 这样生成的ooRexx文档比大多数开源项目要好得多，这是我们开发团队的骄傲。
翻译自: https://www.ibm.com/developerworks/opensource/library/l-kvm-build/index.html
kvm linux