在 Docker 里构造 Meteor 持续集成环境

持续集成由以下环节组成:

      1. 代码版本库 (gitlab)
      2. CI服务 (gitlab-ci/jenkins coordinator)
      3. CI Runner

 

当开发者将修改推送到版本库时,版本库会通知 CI服务,CI服务则会取出一份代码,交给 Runner进行检测,Runner将检测结果汇报给 CI服力。当然,开发者在提交代码之前,应该已经在自己的环境里做过必要的测试了。

 

Meteor已经选定 Velocity做为官方测试框架,通过 meteor run –test可以调用不同的测试工具完成单元测试到集成测试的各种测试,自带 reporter,同时也考虑了对 CI服务的支持。

 

例如https://github.com/dcsan/velo-ci是对接 Travis CI服务的示例,主要工作就是写了个 .trivis.yml放在项目根目录下,这样<通过还不清楚的机制>meteor run –test 运行测试时会将测试结果汇报给 Trivis服务器。Trivis github.com提供的配套云端CI服务,对于开源项目免费,商业项目收费。

 

使用 Gitlab搭建内部的代码库通常是出于价格、网络速度、私有性方面的考虑,因此再搭建一个内部的CI服务也就顺理成章了。不过,其实合理设置内部的 Runner 服务器,使用公有 CI服务也是可行的。

 

服务器有很多选择。Gitlab是比较流行的仿 github 代码服务,它从2013年开始提供配套的 Gitlab-CI,这个CI还比较新,因此功能相对简单一点,界面相应的新颖一些。另一个更为成熟的开源 CI服务是JenkinsGitlab一直没有提供对 Jenkins的支持,倒是 Jenkins社区提供了支持 Gitlab的插件。Gitlab如果内置对 Jenkins的支持,使用起来会更方便,比如 Gitlab内置了对 JIRA的支持,开发者可以在 commit message 里提一下 Closes #MyPrj-7,代码推送到版本库之后,Gitlab会通知 JIRA修改对应的 issue的状态。

 

所以嘛,既然上了 Gitlab,那就 Gitlab-CI吧。麻烦的是,东西太新,资料较少,折腾起来费劲。

 

首先当然是安装环境,如果机器富裕,直接用Omnibus安装包安装就好了,会更容易一点。我这没那么宽裕,所以是在一台 Docker服务器里折腾。

 

首先当然是做好 Docker环境了,然后参照https://peteris.rocks/blog/docker-gitlab-and-gitlab-ci/的说明进行安装。这个说明是能找到的最详细的傻瓜式教程了,不过还是有几个重要细节没提到,半道上出各种问题,还是得回头去看 github上原始的项目,好在sameersbn的说明文档很详细,重要的信息都在。现在看我这个改良版就行了,当然要愿意踩一遍坑加强一下感受,也是群众喜闻乐见的。

 

安装过程如下:

      1. 安装 gitlab,这部分还挺顺。不过 Peteris Rocks 的命令少了几个环境变量,在 Gitlab里创建的项目提示的 repo都是基于 localhost域名的,email用户也没写会发不出邮件的。

另外,所有的容器我都加上了 –restart=”always”,这样机器重起后就不用手工起动容器了。

EMail的话建议给 gitlab专门开一个用户,默认会用 GMail  SMTP,国内的服务器小心连不上。

 

#创建 Redis缓存服务,其实不是必须的。

docker run –name=gitlab-redis –restart=”always” -d sameersbn/redis:latest

 

#创建数据库,喜欢 MySQL的话去 github上看说明,我还蛮喜欢 Postegresql的,有几年工作就跟丫博斗。

docker run –name=gitlab-postgresql –restart=”always” -d \

-e ‘DB_NAME=gitlab’ -e ‘DB_USER=gitlab’ -e ‘DB_PASS=gitlab’ \

-v /opt/gitlab/db:/var/lib/postgresql \

sameersbn/postgresql

 

#终于干正事了,创建 GitLab容器。

#VIRTUAL_HOST=dev.my.com这个环境变量对于 GitLab没用,是给还没安装的 nginx-proxy准备的,后面会说明。

#GITLAB_*是用来生成 GitLab配置文件用的:

#    HOST一定要写外部ip或域名,不然  GitLab 网页上提示的代码库 URL全是 localhost;

#   两个 PORT分别是 web服务和 ssh服务在 docker容器上的端口

#SMTP_*自然是配置怎么往外发邮件的,默认用GMail,我倒是挺喜欢 GMail的,可惜身在墙内呀。

#第一个 -v是将 Docker Host也就是主机上的 /home/git/data目录映射到容器内用来存储数据,不然容器一关数据就没了。

docker run –name=gitlab –restart=”always” -d \

-e ‘VIRTUAL_HOST=gitlab.my.com’ \

-e ‘GITLAB_HOST=gitlab.my.com’ \

-e ‘GITLAB_PORT=10080’ -e ‘GITLAB_SSH_PORT=10022’ \

-e ‘GITLAB_BACKUPS=daily’ \

-e ‘GITLAB_CI_HOST=ci.my.com’ \

-e ‘SMTP_DOMAIN=ym.163.com’ \

-e ‘SMTP_HOST=smtp.ym.163.com’ \

-e ‘SMTP_PORT=25’ \

-e ‘SMTP_USER=gitlab@my.com’ \

  -e ‘SMTP_PASS=<你的密码>’ \

-p 10022:22 -p 10080:80 \

-v /opt/gitlab/repos:/home/git/data \

-v /var/run/docker.sock:/run/docker.sock \

-v $(which docker):/bin/docker \

–link gitlab-postgresql:postgresql \

–link gitlab-redis:redisio \

sameersbn/gitlab

注意:第一次启动 GitLab会在 compile assests之类的环节工作很久,在完成之前访问 10080端口应该会出 502或者503错误,这是正常的!你可以用 docker logs git-lab看看进行到哪了。如果看到下面这一堆就是好了:

2015-04-22 01:46:06,781 INFO success: sidekiq entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

2015-04-22 01:46:06,781 INFO success: unicorn entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

2015-04-22 01:46:06,781 INFO success: cron entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

2015-04-22 01:46:06,781 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

2015-04-22 01:46:06,781 INFO success: sshd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

 

      1. 用默认的 root / 5iveL!fe帐号登录,强烈建议在 profile里把 root用户改个名字。

 

这不是凭空变出来的,安装好 GitLab-CI以后它会提示你用这样一个 url去创建 app,不过ci_dommain_name部分极有可能是 localhost或者 docker internal ip,不要用这个值,不然下一步你会发现 GitLab-CI网站上回 Gitlab进行 OAuth授权的链接都点不开。

 GitLab生成的 AppIDAppSecret都记下来,或者开着这个页面别动也成,一会要用。

 

      1. 安装 GitLab-CI,注意传给新容器的环境变量里有 AppID  AppSecret,值改成上一步记下来的。

Peteris Rocks没提这两个重要的环境变量!如果已经把 GitLab-CI运行起来了,docker rm gitlab-ci重来吧。

#GITLAB_*说明 GitLab服务在哪里,虽然已经  –link了,但是要是不想被一堆奇奇怪怪的 URL困扰,_URL还是写上吧。

#-v让容器把数据库等文件存到 /opt/gitlab-ci/data里,

#   如果练手时 rm gitlab-ci-postgresql了,再创建容器时会报数据库已经存在了,这时可以去这个目录把 db目录删了。

docker run –name=gitlab-ci –restart=”always” -d \

-p 11080:80 \

-e ‘VIRTUAL_HOST=ci.my.com’ \

-e ‘GITLAB_URL=http://gitlab.my.com’ \

  -e ‘GITLAB_APP_ID=刚才生成的ID‘ \

  -e ‘GITLAB_APP_SECRET=刚才生成的密钥‘ \

-e ‘SMTP_DOMAIN=ym.163.com’ \

-e ‘SMTP_HOST=smtp.ym.163.com’ \

-e ‘SMTP_PORT=25’ \

-e ‘SMTP_USER=gitlab@my.com’ \

  -e ‘SMTP_PASS=<密码>’ \

-v /opt/gitlab-ci/data:/home/gitlab_ci/data \

-v /var/run/docker.sock:/run/docker.sock \

-v $(which docker):/bin/docker \

–link gitlab:gitlab \

–link gitlab-ci-postgresql:postgresql \

–link gitlab-ci-redis:redisio \

sameersbn/gitlab-ci

 

它怎么知道 GitLab在哪里呢?创建 GitLab-CI容器的命令里给的环境变更GITLAB_URL呀。

登录、授权之后,浏览器会跳回 GitLab-CI,现在 GitLab-CI就装好了。它会提示你:

Now you need Runners to process your builds.

Checkout the GitLab Runner section to install it

呵呵。

      1. 最后装上 nginx-proxy做为反向代理,这样就可以直接用各个容器的域名直接访问网站,而不用记那些奇怪的端口了。

#这个容器会监视所有的 docker容器的启动,并扫描容器内部的 80端口映到 docker host哪个端口了,然后在 nginx里建对应的虚拟主机,将该容器的域名(由容器内的环境变指定)上的HTTP请求转发过去。

docker run -d –name=”nginx-proxy” –restart=”always” -p 80:80 \

-v /var/run/docker.sock:/tmp/docker.sock jwilder/nginx-proxy

 

      1. 没找到 gitlab-ci-runner-meteor,自己动手做吧。动手前搞清楚 GitLab CI Runner 是怎么工作的非常有必要。

GitLab官方已经把Runner环境程序都弄好了,放在https://gitlab.com/gitlab-org/gitlab-ci-runner项目里了。我们并不需要从头写程序访问 GitLab CI 的 API才能制作 Runner环境。

      1. gitlab-ci-runner.git取一份回来
      2. 在里面 bundle install –deployment 进行安装
        1. 自然需要先把  ruby/gem/bundle 这堆环境都准备好。
        2. 安装后,默认的工作目录:/home/gitlab_ci_runner/gitlab-ci-runner
        3. 配置文件在工作目录里:config.yml

 

      1. 在里面 bundle exec ./bin/setup_and_run完成设置并启动运行。

这一步需要 CI-Runner容器能够顺利访问 GitLab服务器(注意不是GitLab-CI而是GitLab),以便检出代码。以ssh方式的话需要安装信任证书。

      1. (以下是 2015-4-20左右的代码情况,即使有变化原理应该也差不多的)
      1. setup_and_run脚本会读取以下环境变量
        1. CI_SERVER_URLCI服务器地址(http://ci.my.com)
        2. REGISTRATION_TOKEN初次访问 CI 服务器的令牌(http://ci.my.com/admin/runners会显示)
        3. RUNNER_DESCRIPTIONRunner的说明,不提供的话则使用 runner运行环境的 hostname
        4. RUNNER_TAG_LIST还没弄明白
      2. 然后构造一个 json对象, HTTP POST GitLab-CI API

CI_SERVER_URL/api/v1/runners/register.json

BODY:{

    token:REGISTRATION_TOKEN,

    tag_list:RUNNER_TAG_LIST,

    description:RUNNER_DESCRIPTION

}

      1. 注册成功的话,会从 CI服务器取回一个授权令牌,以后用这个令牌与 GitLab-CI通信。
      2. 开始每5秒钟问一次 GitLab 有没有新 Build
        1. 就是把一个只包含注册时得到的 access token的对象 HTTP POST给:

CI_SERVER_URL/api/v1/runners/register.json

      1. 如果 GitLab-CI说有变化了,那么临时生成一个 bash脚本并执行之
        1. 项目源代码会放在工作目录之下:tmp/builds/project-id
        2. git fetch repo (第一次则 clone)
        3. git checkout $ref (ref由服务器返回的信息里提供)
        4. 依次执行 GitLab-CI返回信息里的 commands数组里的每一条命令
          1. 这些命令可以使用以下环境变量来获取必要的信息:
            1. CI_SERVER=’yes’
            2. CI_SERVER_NAME=’GitLab CI’
            3. CI_BUILD_REF, CI_BUILD_BEFORE_SHA, CI_BUILD_REF_NAME, CI_BUILD_ID, CI_BUILD_REPO, CI_PROJECT_ID
            4. CI_PROJECT_DIR(这个是 Runner本地工作目录)
          2. 所有命令要在指定时间时结束,默认是7200秒,GitLab CI 服务器可以为项目指定不同的值。
          3. 命令的 stdout stderr都转向一个临时文件;
          4. 所有命令的输出,以及异常情况都会合并成 trace信息;
          5. 任意一条命令失败,则中止执行,并将执行状态标记为 failed
          6. 所有命令都成功完成,则标记为 sucess状态;
        5.  build的命令执行状态、trace信息发回 GitLab-CI
          1. 就是把 state trace拼成一个 json对象,HTTP POST

CI_SERVER_URL/api/v1/builds/{id}.json”(idGitLab-CI给的build id)

 

 

      1. 总结一下:
        1. GitLab CI Runner是用 ruby做好的一套 Runner环境。
        2. GitLab-CI服务器会把工程信息以及一组命令发给 Runner
        3. GitLab CI Runner 会自动取出源代码,然后执行收到的命令。
        4. GitLab CI Runner会把命令执行的结果、出错时的 trace一起发回 GitLab-CI

所以制作 meteor velocity runner就是要把环境准备好,然后用让项目调用 meteor run –test,用 console reporter输出测试进度,测试失败时meteor run返回一个非0值即可。

话说,GitLab CI Runner其实简单,为此搭上一堆 ruby环境其实挺不值当的,什么时间有空拿 node.js重写一个就完美了。显然我不是第一个这么想的人,https://github.com/evanlucas/gcr已经做了。

 

      1. 要将 meteor velocity runner做成 docker,倒是简单的。

从头写个 Dockerfile也没多麻烦,https://registry.hub.docker.com/u/vdubyna/gitlab-ci-docker-runner/就是个从头写的例子。直接用 docker hub上做好的也有,比如 bobey/docker-gitlab-ci-runner-node就不少人用。我们前面都在用 sameersbn的工作成果,其实也有一个 sameersbn/gitlab-ci-runner。用 Trusted Build派生一个环境多少能省点事。不过既然找到了 gcr,就做一个这样的吧:

      • docker-node:提供 node.js运行环境,跟 sameersbn的几个东东一样基于 ubuntu:latest,虽然  debian会更小一点。
        • docker-gitlab-ci-runner-node:加上 gcr 
        • docker-meteor:加上 meteor 
          • meteor-gitlab-ci-runner:加上 gcr 
      1. 正常运行的 Runner GitLab收到代码之后

gcr info [client] checking for builds…

gcr http 201 http://ci.my.com/api/v1/builds/register.json

gcr info [client] submitting build 1 to coordinator…

gcr http PUThttp://ci.my.com/api/v1/builds/1.json

gcr http 200 http://ci.my.com/api/v1/builds/1.json

gcr info [client] submitting build 1 to coordinator…

gcr http PUThttp://ci.my.com/api/v1/builds/1.json

gcr http 200 http://ci.my.com/api/v1/builds/1.json

gcr info [client] submitting build 1 to coordinator…

gcr http PUThttp://ci.my.com/api/v1/builds/1.json

gcr http 200 http://ci.my.com/api/v1/builds/1.json

gcr info [client] submitting build 1 to coordinator…

gcr http PUThttp://ci.my.com/api/v1/builds/1.json

gcr http 200 http://ci.my.com/api/v1/builds/1.json

gcr info [client] submitting build 1 to coordinator…

gcr http PUThttp://ci.my.com/api/v1/builds/1.json

gcr http 200 http://ci.my.com/api/v1/builds/1.json

gcr info [client] submitting build 1 to coordinator…

gcr http PUThttp://ci.my.com/api/v1/builds/1.json

gcr http 200 http://ci.my.com/api/v1/builds/1.json

gcr info [runner] build success [1]

 

 

 

      1. Velocity自身的 CI模式。

Velocity如果读到环境变量VELOCITY_CI有设置的话,就会以 CI模式运行,具体说就是在development环境里,会对每个已注册的testFramework调用 /reset /run,也就是每次运行时会把所有类型的测试都执行一遍。

!目前碰到的问题是 Mocha client tests不会执行,在Host Ubuntu 14.04里是好的,可见是ubuntu:latest这个环境里有什么不对,还没有找到解决办法。怀疑是 Mocha对于 headless linux支持有问题,但是  mike:mocha里其实有PhantomJS的脚本,不过文档里没有提到类似JASMINE_BROWSER=PhantomJS的选项,代码里也还没找到怎么启用这个脚本。测试下来 Jasmine client unit也有它的问题。

 

测试下来,2G内存的虚拟主机跑这个全 dockerCI环境还是太免强了。还是直接在 VPS里搭环境省心。虽然 Docker具有迁移方便的优点,不过将来把 GitLab/CI/Runner分别迁到自己的服务器里其实也没多麻烦。

– 太长了,英文版先欠着

Leave a Reply

Your email address will not be published. Required fields are marked *