开源 | Tony Bai

六月 27, 2011

部门虽然不是做Web开发的，但是部门内部很多服务器也是使用Apache作为Web Server的。不过一直一来我这边都是用一个Apache Server对应一套Web应用。不过今天有了新的要求：在一个已经部署了一套应用的Apache2上再部署另外一套应用。这也让我不得不深入了解一下Apache的配置。不过还好，过程还是顺利的，这里记下此文意在备忘，如果同时也能给大家带来一些有价值的参考那就再好不过了。

Ubuntu下安装好Apache2后(sudo apt-get install apache)，在任何配置都未做修改的初始情况下，我们看到的与虚拟站点有关的Apache2的初始配置如下：

Apache2主配置文件: /etc/apache2/apache2.conf。其最后两行为：
# Include the virtual host configurations:
Include /etc/apache2/sites-enabled/

显然/etc/apache2/sites-enabled下存放着有关虚拟站点（VirtualHost）的配置。经查看，初始情况下，该目录下包含一个符号连接：000-default -> ../sites-available/default

这里又引出另外一个配置目录：/etcc/apache2/sites-available。这个目录下放置了所有可用站点的真正配置文件，对于Enabled的站点，Apache2在sites-enabled目录建立一个到sites-available目录下文件的符号链接。

/etc/apache2/sites-available下有两个文件：default和default-ssl。000-default链接的文件为default，我们就以default为例，看看一个VirtualHost的配置是啥样的：

ServerAdmin webmaster@localhost

    DocumentRoot /var/www

        Options FollowSymLinks
        AllowOverride None


        Options Indexes FollowSymLinks MultiViews
        AllowOverride None
        Order allow,deny
        allow from all

    … …

DocumentRoot是这个站点的根目录，这样Apache2启动时会扫描/etc/apache2/sites-enabled中可用的website配置并加载。当用户访问localhost:80时，Apache2就将default站点根目录/var/www下的index.html作为请求的回应返回给浏览器，你就会欣赏到的就是/var/www/index.html这个文件中的内容了。

Apache2的默认站点我们不要去动它。我们新增站点配置来满足我们的要求。到这里我猜测一下你可能有两类需求：
一是如何配置根据访问的域名区分配置不通的站点？
二是在相同域名地址的情况下，如何通过访问不同的端口获得不同的站点？

我们先来看看第一种需求。第一种需求讲的是我要在一个Apache2服务器上配置两个站点：site1.com和site2.com。好，我们可以按照下面步骤来做：

* 建立配置文件
在sites-available中建立两个站点的配置文件site1_com和site2_com：
sudo cp default site1_com
sudo cp default site2_com

编辑这两个配置文件，以site1_com为例：

        ServerAdmin webmaster@localhost
        ServerName site1.com

        DocumentRoot /var/www/site1_com

            Options FollowSymLinks
            AllowOverride None


            Options Indexes FollowSymLinks MultiViews
            AllowOverride None
            Order allow,deny
            allow from all

        … …

注意上面配置中：ServerName、DocumentRoot和Directory是我们重点关注的配置点。site1的ServerName为site1.com，根目录为/var/www/site1_com，Directory同DocumentRoot。site2_com也做同样的改动。

* 在sites-enabled目录下建立符号链接：
sudo ln -s /etc/apache2/sites-available/site1_com /etc/apache2/sites-enabled/site1_com
sudo ln -s /etc/apache2/sites-available/site2_com /etc/apache2/sites-enabled/site2_com

* 在/var/www下建立site1_com和site2_com两个目录，然后修改目录所有者：
sudo chown -R www-data site1_com site2_com/

* 在site1_com和site2_com中各自创建一个index.html文件，用于测试使用。
以site1_com下index.html为例，其内容为：Welcome To Site1。

* 重启Apache2(sudo /init.d/apache2 restart)使配置生效。
* 修改/etc/hosts文件，便于测试。
添加如下两行：
127.0.0.1 site1.com
127.0.0.1 site2.com

* 打开浏览器，输入http://site1.com，之后不出意外你就会看到”Welcome to Site1“字样。

第二类需求是希望通过端口号来区分虚拟站点。这个也不难，一些配置方法与上面内容雷同，这里就不详说了。

比如以site2为例：我通过80端口访问site2，可看到"Welcome to Site2”，从8080端口访问site2，则会看到"Welcome to Site2 through 8080"。我们如何配置呢？

* 首先我们得让apache2监听端口8080
修改/etc/apache2/ports.conf，增加两行：
NameVirtualHost *:8080
Listen 8080

* 在/etc/apache2/sites-available/下增加site2_com_8080，并在sites-enabled下建立符号连接。
site2_com_8080的主要配置如下：

ServerAdmin webmaster@localhost
ServerName site2.com

        DocumentRoot /var/www/site2_com_8080

            Options FollowSymLinks
            AllowOverride None


            Options Indexes FollowSymLinks MultiViews
            AllowOverride None
            Order allow,deny
            allow from all

        … …

在/var/www下建立site2_com_8080目录，方法同上。

重启Apache2，访问http://site2.com:8080，我们将看到“Welcome to Site2 through 8080”。

让BuildBot服务于多个项目

多数公司不会仅有一个项目，当你为一个项目引入持续集成实践后，其他项目就会接踵而来。这时你会重新考量BuildBot，考虑如何让BuildBot可以服务于多个项目。

如果你有足够的主机资源和人力资源，那为每个项目单独搭建一套CI环境是再好不过的了，每个项目都有专人维护CI环境，各个项目的配置互不干扰。不过对于一些公司来说，这显然有些浪费，BuildBot Master的资源消耗是不大的，我们完全可以使用一套BuildBot Master来服务于多个项目，至少BuildBot是可以支持这样做的。

CI环境中，我们首要关注的就是源码库。多个项目可能各自使用单独的源码库，也可能共享一个源码库并通过目录隔离和识别。无论怎样，我们都可以通过BuildBot Master的配置来满足我们的要求。

如果说多个项目共享一个源码库或是一个项目下的多个子系统放在一个源码库中，这时我们在配置change_source时指定一个变更监测器即可，这个监测器的监测范围从源码库的根路径开始。以Subversion源码库为例，我们可以这样来配置：

c['change_source'] = [SVNPoller("svn://10.0.0.1:3000",
                                svnuser='tony',
                                svnpasswd='tony',
                                pollinterval=60,
                                split_file=change_path_split)]

我们通过change_path_split来拆分变更文件的路径，假设SVN库结构是这样的：
svn://10.0.0.1:3000
       – foo_proj
           – trunk
               – main/main.c
           – branches
           – tags
       – bar_proj
           – trunk
               – main/main.c
           – branches
           – tags

我们可以这样来实现change_path_split：

def change_path_split(path):
        pieces = path.split('/')
        if pieces[0] == ‘foo_proj’ and pieces[1] == 'trunk':
            return ('foo_proj/trunk', '/'.join(pieces[2:]))
        elif pieces[0] == ‘bar_proj’ and pieces[1] == 'trunk':
            return ('bar_proj/trunk', '/'.join(pieces[2:]))
        else:
            return None

不同项目下的文件变更，会导致change_path_split返回不同的值，而change_path_split返回值会被用于匹配不同的Scheduler：

c['schedulers'].append(Scheduler(name="foo-ci-plan",
                                 branch='foo_proj/trunk',
                                 treeStableTimer=5,
                                 builderNames=["foo-redhat-builder", "foo-x86-solaris-builder"])

c['schedulers'].append(Scheduler(name="bar-ci-plan",
                                 branch='bar_proj/trunk',
                                 treeStableTimer=5,
                                 builderNames=["bar-redhat-builder", "bar-x86-solaris-builder"])

上面各个Scheduler的branch属性会与change_path_split返回值元组中的第一个元素匹配，这样foo-ci-plan便是foo_proj的scheduler，而bar-ci-plan则是bar_proj的scheduler。这样某个项目路径下的文件变更只会触发对应的scheduler开始工作，不会出现误触发。

如果多个项目或一个项目的多个模块使用不同的源码库，同理，我们可以为c['change_source']赋予多个SVNPoller，例如：
c['change_source'] = [SVNPoller("svn://10.0.0.1:3000",
                                svnuser='tony',
                                svnpasswd='tony',
                                pollinterval=60,
                                split_file=change_path_split)，

                      SVNPoller("svn://10.0.0.1:4000",
                                svnuser='tony',
                                svnpasswd='tony',
                                pollinterval=60,
                                split_file=another_change_path_split)]

与Scheduler的匹配方式也与上述描述一致，这里就不重复说明了。

不同项目的干系人多不相同，那么集成的结果是如何准确地反馈给项目各自对应的干系人呢？以Mail反馈通知为例，我在BuildBot手册中找到了两种方式，一种方式是通过设置Scheduler的owner属性，然后指定MailNotifier的sendToInterestedUsers=True，意图让BuildBot将Mail通知发到owner list中的每个邮件地址，但经测试后发现，这种方式似乎不好用，不知道是否是BuildBot对该功能的实现上存在问题。

另外一种方式则是配置多个MailNotifier。每个MailNotifier中指定对应builder的名称列表，并通过extraRecipients指定这些Builder对应的项目的干系人Mail地址列表，例如：

c['status'].append(mail.MailNotifier(fromaddr="foo-buildbot@buildbot.net",
                                     extraRecipients=["foo1@buildbot.net", "foo2@buildbot.net"],
                                     builders=['foo-x86-solaris-builder', 'foo-redhat-builder'],
                                     useTls=False,
                                     sendToInterestedUsers=False,
                                     relayhost="smtp.buildbot.net",
                                     smtpUser='tony',
                                     smtpPassword='tony',
                                     smtpPort=25))

c['status'].append(mail.MailNotifier(fromaddr="bar-buildbot@buildbot.net",
                                     extraRecipients=["bar1@buildbot.net", "bar2@buildbot.net"],
                                     builders=['bar-x86-solaris-builder', 'bar-redhat-builder'],
                                     useTls=False,
                                     sendToInterestedUsers=False,
                                     relayhost="smtp.buildbot.net",
                                     smtpUser='tony',
                                     smtpPassword='tony',
                                     smtpPort=25))

这样foo的builders构建的结果将发到foo1和foo2；而bar的builders构建结果将反馈到bar1和bar2。

多个项目共享一套BuildBot Master有利有弊，其不足之处可能有如下几点：
1、项目过多时，可能存在潜在的性能问题
2、Master的配置被多个项目共享，存在潜在的Conflict问题；
3、另外master.cfg可能size过大，也不利于阅读和维护。