原文: https://blog.coding.net/blog/GitHook-for-delivery-and-deployment
软件发布是一个令人头痛的过程,非常耗时且风险很高。对于小团队来说一般分为两种:“签入时交付”和“定时交付”。
“签入时交付”策略的优势在于马上产生的满足感。根据代码库的规模,从签入新功能代码到能够在交付准备服务器上测试,一两分钟就够了。
这种方式的主要问题在于:交付准备服务器会被蹂躏得不稳定。很多时候,我见到有人试图测试某个功能,突然新的版本推到交付准备服务器上了,破坏了正在运行的测试。更糟糕的是:交付准备服务器常常作为演示服务器使用,在某些重要的演示时,很可能出现严重的后果。
定期交付策略更易于预测。所有人都知道交付何时启动,并可以规划自己的代码签入是在交付之前还是之后进行。典型做法是一天构建 /交付一次或两次。
由于架构的特殊性,服务器将会越来越多。试想一下你要在几十台服务器上更新代码是一件多么繁琐的事情。对于我们公司来说面临着严重的如何更快交付和部署代码的问题。
我们需要将经历过测试的代码能够迅速部署到服务器上,本来考虑过 jekins ,但 jekins 对我们来说又太过繁琐。
目前我们使用的是阿里云服务,阿里云服务有个很方便的地方就是镜像,一次制作整个集群都可以使用。
工程师将代码上传到开发环境的库中,通过 GitHook 自动让测试用的服务器更新代码,测试完成后只要将相关的代码稍稍修改为生产环境的配置并上传到生产环境的 Git 库,通过 GitHook 所有与这个库有关的服务器都会自动更新代码。
测试的具体过程就不在此论述了。
我们来看下官方解释:
钩子(hooks)是一些在"$GIT-DIR/hooks"目录的脚本, 在被特定的事件(certain points)触发后被调用。当"git init"命令被调用后, 一些非常有用的示例钩子文件(hooks)被拷到新仓库的 hooks 目录中; 但是在默认情况下这些钩子(hooks)是不生效的。 把这些钩子文件(hooks)的".sample"文件名后缀去掉就可以使它们生效了。
简单地来说有点类似回调,就是特定事情完成后回调执行事件。
我们公司使用的是 coding 、服务器上是已经装好 jetty 的 ubuntu ,不过 github 、 gitlab 跟这个的配置方法类似。
*Git-SSH*
首先现在 coding 上建立一个代码库,然后在生产环境上的代码部署的地方 git clone 刚刚新建的代码库。
没有 git 的要安装 git , ubuntu 下是apt-get install git
为了让 git 能够自动更新代码库而不需要输入账号密码,这时候就需要用到 git-ssh 了。
如果是第一次使用要先设置 git 的名字和邮箱(自己随便取个名字和邮箱就行):
git config --global user.name "test"
git config --global user.email "test@zomake.com"
然后通过上一个命令输入的邮箱来生成密钥
ssh-keygen -t rsa -C "test@zomake.com"
如果不需要设置密钥的密码的话,直接三个回车。然后你就在命令行上看到生成了两个文件: id_rsa 和 id_rsa.pub 。
(如果不是第一次的话执行命令会提示 overwrite ,输入 y 就行。)
然后我们把密钥交给 ssh-agent 来管理,可以通过eval "$(ssh-agent -s)"
看看是不是正常运行,是的话会输出它的 pid 。
ssh-add ~/.ssh/id_rsa
用上面这个命令将刚刚生成的私钥交给 ssh-agent 。路径填你在终端上看到的。
登录 coding ,点击账户-SSH 公钥-添加。将之前生成的 id_rsa.pub 里的内容复制进去。
最后进到之前 clone 下来的代码库中修改.git 文件夹下 config 中的 url ,改为远端仓库的 SSH 访问地址,如 git@git.coding.net:t-baby/test.git
这样一来在服务器上 git 就无需输入账号密码了。
*准备 update.sh*
cd /
vi git_update.sh
然后将下面的东西复制进去并保存:
```
#!/bin/bash
cd /opt/jetty/webapps
git remote update -p
git checkout -f origin/master
git submodule update --init
service jetty restart
```
第二行和最后一行根据需要自行更换,因为我们的代码是 Java 的,放在 jetty 中运行。将第二行的 cd 改成你自己的代码所在目录。而最后一行代码是用来重启 jetty 服务器的,你可以去掉或加上自己服务器的重启代码。
保存后给这个脚本文件 777 的权限。
*准备 githook.php*
由于一些原因,为了方便我们使用了 php 作为 GitHook 回调的地址。
先装好 PHP 环境并修改端口为 8080 , apache 默认文件夹为 /var/www ( 80 已经被 jetty 占了,具体安装方法见我另一篇文章)
在 /var/www/中新建一个叫 githook.php ,然后放入以下代码:
shell_exec('cd /var/www && php gitpull.php');
然后再在当前文件夹下建个 gitpull.php
$pid = pcntl_fork();
if ($pid == -1){
} else if ($pid > 0){
$fs = fopen('./git_hook.log', 'a');
fwrite($fs, 'Request on ['.date("Y-m-d H:i:s").']'.PHP_EOL);
$json = file_get_contents('php://input');
$data = json_decode($json, true);
fwrite($fs, 'Data: '.print_r($data, true).PHP_EOL);
fwrite($fs, '======================================================================='.PHP_EOL);
$fs and fclose($fs);
pcntl_wait($status);
} else if ($pid == 0){
exec('sudo sh /git_update.sh &');
}
`
执行 git_update.sh 更新 git 仓库。
为什么要这样做呢。因为 coding 的 webhook 的等待时间是写死的,要 5 秒内有反应,这就会导致包含一些需要时间的命令会让 webhook 的地址验证不成功,从而在 push 后不回调到地址上。
所以我们用了多进程来让其中一个执行日志的记录,另一个负责执行 sh 文件。
*填入回调地址*
紧接着我们在 coding 中打开部署用的代码库,左侧点击设置-WebHook 。比如我们刚刚的是
http://111.111.111.111:8080/githook.php
( ps :直接填写 IP 可以减少域名解析所耗费的时间)
*给 apache 权限*
聪明的朋友们测试的时候肯定发现了问题, exec 里面的代码并不执行怎么办?其实很简单是因为 apache 的权限不够,只要给予权限就行。
我们可以先通过lsof -i:80
看看 apache 的执行用户是谁。
比如我这里是 www-data 用户,然后执行 visudo 。
然后找到图片上的位置修改成图片上那样,后面那行 www-data 是要自己添加的。接着保存。保存的话就是 ctrl+x 然后回车。
这样就可以让 apache 不需要密码就可以用管理员权限执行了。
赶紧测试下看看是不是成功了!
现在只要你一更新仓库的代码,就会自动回调到 githook.php 从而让服务器自动更新代码。即使多几台服务器也是一样的,最简单的方法就是利用公有云服务的镜像功能做成镜像装在集群中的其它机器,然后在 coding 的 WebHook 那里加上这些服务器的 IP 就行。
这应该是全网最完善的相关教程了吧。自己靠着百度到很多不完整的资料琢磨了一天然后写下此教程。找教程。。。最后别太相信百度到的,血的教训~。
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.