讓我們來回憶下上次你是怎麼發佈你的代碼的: 1. 先把線上的代碼用ftp備份下來 2. 上傳修改了的文件 3. 測試一下功能是否正常 4. 網站500了,趕緊用備份替換回去 5. 替換錯了/替換漏了 6. 一臺伺服器發佈成功 7. 登錄每一臺執行一遍發佈操作 8. 加班搞定 9. 老闆發飆 ... ...
讓我們來回憶下上次你是怎麼發佈你的代碼的:
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、運維感興趣的同學都可以加進來,我在這等你們 :)