用veewee创建vagrant的虚拟机

感谢larrycai的投稿。
原文链接:https://github.com/larrycai/blog/blob/master/cn/veewee_create_vm.mkd

简介

虚拟机有很多好处,不仅仅节省硬件资源,而且还可以快速切换系统环境,会在软件开发中起到极大作用。

上一篇vagrant和jenkins的文章中我们说到了vagrant这个工具,你必须要先有一个盒子:vagrant box,它是vagrant对virtualbox虚拟机的进一步封装。将virtualbox虚拟机转变成vagrant的盒子有点麻烦,可以参见vagrant的说明,所以,大家都是找一个现成的盒子来用。

但是,没有更好的办法了吗?现在网络的开放精神真是强大,你能想到的一般都存在了,它就是我要介绍的veewee,它的功能就是从你的ISO光盘开始,准备好你需要的vagrant虚拟机(盒子)。

Continue reading 用veewee创建vagrant的虚拟机

使用vagrant+jenkins来管理虚拟机的技巧

感谢larrycai投稿

简介

虚拟机有很多好处,不仅仅节省硬件资源,而且还可以快速切换系统环境,显然会在软件开发中起到极大作用。

在《持续交付》第十一章(11.7.1)中就提到了虚拟机环境的管理。如下图
持续交付 虚拟机创建环境它描述的是在你的持续集成的Jenkins CI服务器(以下简称jenkins)中,需要各种服务器来测试一个应用。我们可以快速的从虚拟机的VMM模板库中,启动需要的各种类型虚拟机,而不是每个都重新安装(省时),完成测试,产生报告后,也快速消失(省钱)。

让我们一起来看看一种漂亮的实现方案vagrant+jenkins实现技巧。

Continue reading 使用vagrant+jenkins来管理虚拟机的技巧

ControlTier,基于命令的自动化部署工具

现在,服务器集群已经是司空见惯的事情了。随便一个小的互联网应用程序都需要用集群来支撑。而当采纳“持续集成”,尤其是“持续交付”实践时,在各种环境上的部署让你发疯。这些环境包括开发环境、测试环境(包括功能测试和非功能测试)、试运行环境和生产环境。而且,每种环境可能会有多套实例,而不只是一套实例。

曾经接触过的一个团队,其持续集成环境中就有260+台服务器,随着开发人员的提交,不同版本的应用程序在这些服务器上一遍又一遍地被部署、测试、卸载。而且,这些服务器的作用各不相同,有的是web服务器,有的是应用服务器,还有数据库服务器,也许还有消息服务器等等。想象一下,如果由你来管理这样一个团队中的服务器集群的部署,你的状态会是什么样子?

其实,当面对这么庞大的集群时,关键问题不仅在于知道每一步怎么做,而是:如何能够在所有的服务器上能够让所有的步骤都能够正确地被执行,而且要按照你期望的顺序,不至于各节点的执行步骤间互相受到影响。

Big problem for cluster management

其实,已经有很多工具解决这类问题了,ControlTier就是其中之一。它是一个跨平台软件系统,用于在多个服务节点中管理应用程序的相关操作。

它既有命令行工具,又有Web管理界面。用户可以自定义命令组,并重用它们。它与Puppet的一个区别在于:ControlTier是基于“对目标进行操作(Activity)”的工具,而Puppet则是基于“定义目标状态”的工具。所以,Puppet的“部署幂等性”在ControlTier里是很难办到的。它们在这一点上的区别也决定了它们使用层次上的不同。在《持续交付》的“环境管理”章节中,说环境配置管理的层次如下图所示:

而它们所服务的位置如下:

当然,你完全可以在系统层使用ControlTier,也完全可以在应用层使用Puppet,但是它们有各自的专长,在其它层次上使用意味着需要的定制工作量稍多一些而已。

你还等什么,赶快使用这些工具,去打造你的完美“持续交付”环境吧!

 

本文版权归作者乔梁所有,转载请包含作者签名和出处,不得用于商业用途,作者将保留“追究法律责任”的权利!

选择持续集成工具需要考虑的几个因素

目前,持续集成工具多达30种,每种工具都有自己的特点。在国内,软件企业很少为这类产品付费,所以国个目前最流行的包括Hudson(开源),CruiseControl(开源),TeamCity(商业版,买了IntellJ的License就能免费使用)。而在国外,还有两个比较流行的商业软件是AnthillPro和Go(原名为Cruise)。

根据目前软件发展的特点,在选择持续集成工具时需要考虑如下几个方面(不包括金钱投入):

  1. 版本控制工具的支持。在你的企业中,使用哪种版本控制工具(Git, Hg,SVN,ClearCase等等)。
  2. 每个构建是否可以支持指定多个代码源URLs。
  3. 是否支持构建产物管理库。
  4. 是否支持部署流水线,类似于一个或多个构建完成后触发另一个构建。
  5. 是否支持并行构建。
  6. 是否支持构建网格,以及对网格内机器管理的能力。即,能否将多个构建同时分配到多个构建机器上执行,以提高执行速度。
  7. 是否有良好的开放API,比如触发构建API、结果查询API、标准的Report接口等等。
  8. 对于安全性来说,是否支持企业所用的安全机制,如LDAP等等。
  9. 是否有良好的Dashboard。
  10. 与构建工具(如Maven,Make,Rake,Nant等)和测试工具的集成。

另外,“有良好的开放API”是任何工具选择的重要标准。因为,自动化是持续集成的关键。如果一个工具只能通过一个Web界面来操作的话,那简直就是一个噩梦。

详细的工具及特性列表见这里