少年，是时候换种更优雅的方式部署你的php代码了

Posted 2020-09-13 码王信息

让我们来回忆下上次你是怎么发布你的代码的：

1. 先把线上的代码用ftp备份下来

2. 上传修改了的文件

3. 测试一下功能是否正常

4. 网站500了，赶紧用备份替换回去

5. 替换错了/替换漏了

6. 一台服务器发布成功

7. 登录每一台执行一遍发布操作

8. 加班搞定

9. 老板发飙

...

尤其现在的互联网行业，讲究快速迭代，小步快跑。像bug修复或者小功能的修改几乎每天都发版本，大功能的版本迭代每周也差不多会有一次。相信不少同行们像我上面说的这样发布自己的代码吧。或者可能先进一点，直接去服务器上执行一条类似git pull的命令拖下仓库中的代码，但是如果你的代码运行在集群中呢？每台机器登录一次执行一次git pull吗？如果发现代码有问题需要回滚呢？

如果你还在像我上面说的这种方式部署自己的代码的话，那么我希望你能耐心看完这篇文章，从此摆脱代码部署之痛。

 

其实绕了这么一圈今天是想向大家介绍一下用php写的代码发布工具：deployer。

deployer具有以下吸引人的特性：

- 快速      采用了比如并发发布、ssh通道复用、缓存可用情况下使用缓存等技术加速代码部署

- 原子部署   在新发布的版本内执行所有定义的操作，诸如下载依赖、设置文件访问权限等都不会直接影响线上，只有全部成功后，最后一步设置软链才会真正替换线上代码

- 快速回滚   由于采用了原子部署，所以回滚也只是重新设置一下软链指向

- 并发部署   集群环境下，并发在所有机器上执行相同的部署流程

- 一致性     集群环境下，只有所有机器都执行成功才算成功，一台失败则全部失败

- 内置多个框架发布模板   比如Laravel、Yii、Symfony、CodeIgniter、Zend Framework等

- 易扩展     很容易可以依据自己的项目用Common模板编写发布流程

安装： 

composer global require deployer/deployer

安装完成后，切换到自己的项目目录，执行dep init，按照自己项目使用的框架选择生成的部署模板：

?  tb dep init
Please select your project type (defaults to common):
  [0] Common
  [1] Laravel
  [2] Symfony
  [3] Yii
  [4] Zend Framework
  [5] CakePHP
  [6] CodeIgniter
  [7] Drupal
 > 0

如果你的框架未使用上面列出的任何一个框架，则选择0，然后回车，就会生成通用的发布模板。

执行完这一步应该会在你的项目根目录生成一个deploy.php文件，你所需要的做的一切就是编辑这个脚本，填写一些自己的服务器和项目配置，然后定制一些task。

下面我将用一个具体的配置文件来介绍deployer的使用，配置文件如下：

 

<?php
namespace Deployer;

use Symfony\Component\Console\Input\InputOption;

require ‘recipe/common.php‘;

option(‘tag‘, null, InputOption::VALUE_OPTIONAL, ‘发布的tag‘);

// 全局配置文件   
set(‘ssh_type‘, ‘native‘);    // 登录远程主机使用的方式，有三种：phpseclib（默认方式）、native、ext-ssh2
set(‘ssh_multiplexing‘, true);  // 是否开启ssh通道复用技术（开启可以降低服务器和本地负载，并提升速度）
set(‘keep_releases‘, 10); //    报错10个之前版本，设置为-1表示一直保存历史版本
set(‘repository‘, ‘[email protected]:loc/loc-api.git‘);    // 代码仓库的地址，只支持git
set(‘branch‘, ‘master‘);    // 发布代码时候默认使用的分支
set(‘shared_files‘, []);    // 共享文件列表   这里面列出的文件会被移动到项目根目录的shared目录下，并做软链
set(‘shared_dirs‘, []);     // 共享目录    同上
set(‘writable_mode‘, ‘chmod‘);  // 采用哪种方式控制可写权限，有4中：chown、chgrp、chmod、acl（默认方式）
set(‘writable_chmod_mode‘, ‘0755‘); // 当使用chmod控制可写权限的时候，赋予的可写权限值
set(‘writable_dirs‘, []);   // 可写目录   规定那些目录是需要可以被web server写入的
set(‘clear_path‘, []);  // 设置在代码发布的时候需要被删除的目录
set(‘http_user‘, ‘nginx‘);  // web server的用户，一般不用设置，deployer会自动判断
set(‘release_name‘, function () {   // 设置发布版名称，这里优先使用tag作为名称，不传的话会使用日期+时间表示发布时间
    if (input()->hasOption(‘tag‘)) {
        return input()->getOption(‘tag‘);
    }
    return date(‘Ymd-H:i‘);
});

// 可以设置多个服务器，发布的时候根据设置会同步发往多个服务器
// 针对每个服务器可以单独设置参数，设置的参数会覆盖全局的参数
server(‘prod_1‘, ‘xxx.xxx.xxx.xxx‘)
    ->user(‘root‘)
    ->password(‘xxxxx‘)
    ->set(‘deploy_path‘, ‘/var/www/tb‘)   // 代码部署目录，注意：你的webserver，比如nginx，设置的root目录应该是/var/www/tb/current，
                                          // 因为current是一个指向当前线上实际使用的版本的软链
    ->stage(‘prod‘);  // 标识该服务器类型，用于服务器分组

server(‘prod_2‘, ‘xxx.xxx.xxx.xxx‘)
    ->user(‘root‘)
    ->password(‘xxxxx‘)
    ->set(‘deploy_path‘, ‘/var/www/tb‘)
    ->set(‘branch‘, ‘master‘)   // 指定发往这个服务器的分支，会覆盖全局设置的branch参数
    ->set(‘extra_stuff‘, ‘...‘) // 随意指定其他什么参数
    ->stage(‘prod‘);
    
server(‘beta‘, ‘xxx.xxx.xxx.xxx‘)
    ->user(‘root‘)
    ->password(‘xxxxx‘)
    ->set(‘deploy_path‘, ‘/var/www/test‘)
    ->set(‘branch‘, ‘beta‘)   // 测试环境使用beta分支
    ->stage(‘beta‘);    // 放在beta分组


// 配置的任务
task(‘success‘, function () {
    Deployer::setDefault(‘terminate_message‘, ‘<info>发布成功!</info>‘);
})->once()->setPrivate();   // 增加once调用那么这个任务将会在本地执行，而非远端服务器，并且只执行一次

desc(‘重启php-fpm‘);    // 可以给任务增加一个描述，在执行dep list的时候将能看到这个描述
task(‘php-fpm:restart‘, function () {
    run(‘systemctl restart php-fpm.service‘);  // run函数定义在服务器执行的操作，通常是一个shell命令，可以有返回值，返回命令打印
});     // 聪明如你一定发现了，可以用run函数制作一些批量管理服务器的任务，比如批量重载所有的nginx配置文件、批量执行服务器上的脚本等

after(‘deploy:symlink‘, ‘php-fpm:restart‘); // 钩子函数，表示执行完设置软链任务之后执行php-fpm重启任务

desc(‘发布项目‘);
task(‘deploy‘, [    // 可以设置复合任务，第二个参数是这个复合任务包括的所有子任务，将会依次执行
    ‘deploy:prepare‘,   // 发布前准备，检查一些需要的目录是否存在，不存在将会自动创建
    ‘deploy:lock‘,  // 生成锁文件，避免同时在一台服务器上执行两个发布流程，造成状态混乱
    ‘deploy:release‘,   // 创建代码存放目录
    ‘deploy:update_code‘,   // 更新代码，通常是git，你也可以重写这个task，使用upload方法，采用sftp方式上传
    ‘deploy:shared‘,    // 处理共享文件或目录
    ‘deploy:writable‘,  // 设置目录可写权限
    ‘deploy:vendors‘,   // 根据composer配置，安装依赖
    ‘deploy:clear_paths‘,   // 根据设置的clear_path参数，执行删除操作
    ‘deploy:symlink‘,   // 设置符号连接到最新更新的代码，线上此时访问的就是本次发布的代码了
    ‘deploy:unlock‘,     // 删除锁文件，以便下次发布
    ‘cleanup‘,  // 根据keep_releases参数，清楚过老的版本，释放服务器磁盘空间
    ‘success‘   // 执行成功任务，上面自己定义的，一般用来做提示
]);


after(‘deploy:failed‘, ‘deploy:unlock‘);    // 如果发布失败，则删除锁文件，以便下次重试

 

上面就是一个比较完整的自动化部署脚本配置了，是不是感觉到很简单？ 因为大部分配置工作在你执行dep init的时候就已经帮你做了！

在接下来还需要做的一件事情就是把你要部署的服务器的ssh-key加入到你的git帐号的认证库里面，你也可以创建一个账户，只拥有仓库的git pull和git clone权限，保持最小权限原则。需要注意的是，加完key之后，首次在服务器上执行git clone可能会需要让你输入yes，所以最稳妥的办法是，去每台要部署的服务器上去执行一遍git clone，把仓库代码拖一份到其他目录。

做完上面的事情之后，所有的准备工作就算完成了。接下来就可以进行部署测试了。

首先检查下配置有没问题：

 

dep config:dump beta    // 打印beta环境的配置
dep config:dump prod    // 打印生产环境的配置

打印出来的配置没有问题的话，接着执行发布任务：

dep deploy beta // 发布当前beta分支到beta环境
dep --tag=v1.1 deploy prod // 发布v1.1这个tag的代码到生产环境，可以增加-p选项，并发发往所有服务器

一次成功的部署应该会有类似如下输出：

 

?  tb git:(master) ? dep --tag=v1.1 deploy prod_1
? Executing task deploy:prepare
? Executing task deploy:lock
? Executing task deploy:release
? Executing task deploy:update_code
? Executing task deploy:shared
? Executing task deploy:writable
? Executing task deploy:vendors
? Executing task deploy:clear_paths
? Executing task deploy:symlink
? Executing task php-fpm:restart
? Executing task deploy:unlock
? Executing task cleanup
? Executing task success
发布成功！

查看当前生产环境使用的哪个版本

dep current prod  //这里应该会输出v1.1 

查看当前生产环境使用的哪个版本：

 

dep current prod  //这里应该会输出v1.1 

如果发布到线上之前之后发现有问题，需要回滚，只需要执行：

dep rollback prod   // 实际上只是修改软链指向，所以很快就能执行完成且基本不可能失败

再次用dep current prod应该就可以看到回滚到之前版本了

再比如之前执行出了问题，被中断，再次执行可能会提示：Deploy locked，那么只用执行：

 

dep deploy:unlock prod // 删除锁文件

如果线上磁盘空间吃紧了的话（一般不会），可以执行如下命令删除掉太早以前的版本：

dep cleanup

 

到了这里关于deployer所有你应该都掌握了。虽然第一次配置的确需要花点时间，可能半个小时也可能半天。  不过换来的却是接下来更优雅、快速、安全、易回滚的发布流程，这么想一下是不是还有点小激动呢？

如果在安装使用过程中有什么问题的话可以加群：632109190进行讨论。对php、java、运维感兴趣的同学都可以加进来，我在这等你们 :)