DevOps之Puppet

Puppet在一款自动化系统配置管理的工具,它可以让你在很短的时间内对大量硬件和系统基本类似的系统,进行统一的系统配置管理。

说的简单点,就像开网吧,你需要对网吧的每一台机器安装操作系统,配置完全一样的软件,比如QQ和360,供网友上网,在系统和软件有损坏时,很简单的一个恢复操作就可以让机器回到刚刚安装好操作系统和软件的状态。

Puppet就是可以干这个事儿的,不同在于,Puppet是给网络管理员用的,而针对的系统多是*nix系统,因为Puppet目前对Windows支持的很少,但这不妨碍Puppet成为DevOps实现过程中的利器,另外一个类似的工具是Chef

Puppet本身基于Ruby实现,但即使没有Ruby的经验也没甚大碍。Puppet自己提出了所谓Puppet Language,是一种DSL(Domain Specific Language)语言,用直白而描述性的语言,定义系统应该具有的状态,比如一个简单的例子tmpfile.pp:

file { 'testfile':
    path => '/tmp/testfile',
    ensure  => present,
    mode    => 0640,
    content => "I'm a test file.",
}

在安装了Puppet了机器上运行:

puppet apply tmpfile.pp

结果就会在/tmp下新增加一个testfile,内容是This is a test file。
这个例子太简单。除了file这种类型外,Puppet提供了大量的资源类型,供对系统的状态进行描述,比如打开(如果不存在会自动下载)某项服务,自动增加一个用户。当管理的机器成百上千,这样的自动化服务达到的效果就很可观了。

puppet apply是Puppet在单机上运行和测试的工具,真实的使用情景会是,一台机器(master)专门保留所有机器配置管理的状态信息,而每台机器(agent)会在指定的时间向master发起查询,从而更新自己的系统状态,以期与指定状态保持一致。

 

 

IFrame带来的Session问题

客户原来有个Web App系统A,我们要基于A开发一个系统B,但不希望B对A依赖太重,所以B被实现为一个独立的Web App(war)。A和B部署在同一个Weblogic server上,在A中可以导航到B,两个系统看起来像是一个系统。

有个小需求是,在B中希望显示一个页面,根据参数能展示出不同的信息。这个页面在A中已经存在,所以自然而然最快的方法就是在B中创建一个iframe来指向那个A中的页面,配以不同的参数,多快好省!

问题很快出来了,QA发现那个iframe中的A页面很快就会session timeout,然后会提示用户输入登陆用户名和密码,而iframe外的B session并未过期的。

问题在于A和B实际上还是两个Web App,各自有各自的session。因为不能简单地修改A的页面,让它保持session不会timeout,所以剩下的办法只好是控制B的session timeout时间要早于A了。还有什么更优雅的方法呢?

如果给我一次重新实现的机会,我宁愿自己画一个属于B的页面,而扔掉iframe。

另外一个需求是,A和B是各自独立的Web App对于用户是透明的,用A的用户登陆进来可以直接进入B,反之则不可以。解决办法有点tricky,A的contextRoot设为/,B的contextRoot设为/XXX,这样二者的servletContext为同一个,即可实现A把自己的loginToken放到servletContext中后由B访问到,从而在请求B页面时,检查是否能取到servletContext中的loginToken,如果不能则转向到A的登陆页面,这点由Filter来实现。

this in Selenium’s get_eval() method

At Selenium Ruby site, there is a description for method get_eval(script), as following:

Gets the result of evaluating the specified JavaScript snippet. The snippet may have multiple lines, but only the result of the last line will be returned.

Note that, by default, the snippet will run in the context of the “selenium” object itself, so this will refer to the Selenium object. Use window to refer to the window of your application, e.g. window.document.getElementById(‘foo’) If you need to use a locator to refer to a single element in your application page, you can use this.browserbot.findElement("id=foo") where “id=foo” is your locator.

The special thing here is the this reference, means when invoking method get_eval() to run some javascript snippet, the this reference in snippet would refer to (redicted?) caller Selenium object but not the original belonging object.

This does differ from what we already know for window.eval() method, in which javascript snippt this still refer to the original belonging object, see below demo code:

var a = 0;
window.eval("this.a = 1"); // this refers to window object
alert(a); // a=1
alert(this.a == a) // true

Above code demos this is window object itself.

function A(){};
A.prototype = {
  f1: function(){
    return "f1";
  },
  f2: function(){
    alert(this.f1());
  }
}
var a = new A();
window.eval("a.f2()"); // equals to a.f2(), this in f2 refers to a.

Above code demos this in a.f2() method still refers to a, but not window object.

Generally, eval() is an evil thing.