摘要:開發(fā)完項目,免不了要部署上線。進行部署的過程中,項目仍然能夠正常訪問。能十分方便地進行回滾。線上測試與生產使用的是青云的云主機,系統。或者想辦法設置實現免密碼登錄。
開發(fā)完項目,免不了要部署上線。純手動操作,登錄、拉代碼、改配置、清緩存、各種服務重啟等等一條龍下來,人生寶貴的幾分鐘就過去了。而且手動操作十分容易出錯,遺漏部分步驟都有可能產生一些邪門問題。所以我很早就開始尋求一種能輕松部署 Laravel 項目的辦法。
laravel 的官方文檔里介紹了 Envoy,之前用過,能滿足大部分場景,但仍然有一些限制。直到后來看到了 deployer,大有相見恨晚之感!
deployer 的優(yōu)勢真正解放雙手,一條命令完成部署。
進行部署的過程中,項目仍然能夠正常訪問。部署成功完成后才切到新的版本。
能十分方便地進行回滾。
豐富任務鉤子和預置任務可靈活的組合完成各種任務,比如執(zhí)行前端依賴的安裝、構建等。
其它騷姿勢等你發(fā)掘……
使用 deployer 的前提條件本地機器(也就是你執(zhí)行 dep 命令時所在的機器)能夠 SSH 連接到目標機器(代碼要部署到的機器,不管是在線的云主機還是局域網中的虛擬機)
有登錄目標機器并調整一些設置的權限,或者能讓負責人協助調整。(使用過程中可能遇到問題需要調整一些設置,后面會提)
目標主機有拉取項目倉庫的權限。(這個應該都有吧,不然玩?zhèn)€毛?)
足夠大膽、足夠細心、足夠有耐性……
deployer 的使用首先說明下個人實際使用場景。
本人使用 win10 系統,使用 Homestead 作為 PHP 項目的開發(fā)環(huán)境(vagrant v2.1.1, homestead v7.4.1, virtualbox v5.2.8, homestead 的 virtual box 版本為 v5.2)。
本地開發(fā)能完成絕大部分開發(fā)和測試任務,但在部署到生產機之前仍然需要先部署到開發(fā)機上進行測試。線上測試與生產使用的是青云的云主機,Ubuntu16 系統。
以下的操作都是在 homestead 虛擬機里進行操作!
安裝
cd /path/to/your/project composer require deployer/deployer --dev
個人習慣于將其作為項目依賴安裝,當然也可以根據需要或個人喜好全局安裝。
初始化 deployer 配置文件
vendor/bin/dep init
因為我用的是 laravel 輸入項目類型 1 后回車,然后會出現一個讓設置 git 倉庫的,默認是對應項目的 git 遠端倉庫,不需要修改的話確認就可以了。
完成上面的初始化后,項目要目錄下會出現一個 deploy.php 文件,deployer 的配置就靠它了。初始的配置如下,里面顯示了一些基本的配置。
set("deploy_path", "~/{{application}}"); // Tasks // 這算是個自定義任務示例 task("build", function () { run("cd {{release_path}} && build"); }); // [Optional] if deploy fails automatically unlock. // 如果部署失敗,自動解除部署鎖定狀態(tài),以免影響下次執(zhí)行 after("deploy:failed", "deploy:unlock"); // Migrate database before symlink new release. // 執(zhí)行數據庫遷移,建議刪掉,遷移雖好,但畢竟高風險,只推薦用于開發(fā)環(huán)境。 before("deploy:symlink", "database:migrate");
修改配置
默認的配置肯定是不行的,目標主機啥的還不知道呢。下面直接貼上自己用到的配置,并加入了少量說明。
stage("production") ->user("root") ->port(22) ->set("branch", "master") // 最新的主分支部署到生產機 ->set("deploy_path", "/data/wwwroot/xxx") ->identityFile("/home/vagrant/.ssh/id_rsa") ->forwardAgent(true) ->multiplexing(true) ->set("http_user", "www") // 這個與 nginx 里的配置一致 ->addSshOption("UserKnownHostsFile", "/dev/null") ->addSshOption("StrictHostKeyChecking", "no"); // 測試用的主機 host("172.16.3.2") ->stage("debug") ->user("root") ->port(22) ->set("branch", "develop") // 一般是把 develop 分支弄到測試機測試,沒問題再合并 ->set("deploy_path", "/data/wwwroot/xxx") ->identityFile("/home/vagrant/.ssh/id_rsa") ->forwardAgent(true) ->multiplexing(true) ->set("http_user", "www") ->addSshOption("UserKnownHostsFile", "/dev/null") ->addSshOption("StrictHostKeyChecking", "no"); // 自定義任務:重置 opcache 緩存 task("opcache_reset", function () { run("{{bin/php}} -r "opcache_reset();""); }); // 自定義任務:重啟 php-fpm 服務 task("php-fpm:restart", function () { run("systemctl restart php-fpm.service"); }); // 自定義任務:supervisor reload task("supervisor:reload", function () { run("sudo supervisorctl reload"); }); // 自定義任務:部署成功了用 bearychat 發(fā)消息給大佬和自己 task("send_message", function () { run("{{bin/php}} {{release_path}}/artisan deployed"); }); // 自定義任務:緩存路由,recipe/laravel.php 默認的流程里沒有這個,所以加上,息看需要 after("artisan:config:cache", "artisan:route:cache"); // 執(zhí)行自定義任務,注意時間點是 current 已經成功鏈向新部署的目錄之后 after("deploy:symlink", "php-fpm:restart"); after("deploy:symlink", "supervisor:reload"); // 部署成功后重置 opcache 緩存 after("deploy:symlink", "opcache_reset"); // 部署成功后調用 laravel 命令行發(fā)送通知 after("success", "send_message"); // [Optional] if deploy fails automatically unlock. after("deploy:failed", "deploy:unlock");
代碼修改完成后運行部署
修改完成后記得先提交并將代碼推送到遠端倉庫。然后執(zhí)行如下命令進行部署:
vendor/bin/dep deploy debug // 部署到測試機 vendor/bin/dep deploy production // 部署到生產機
過程中如果提示要輸入密碼,則輸入登錄目標主機的密碼。或者想辦法設置 SSH key 實現免密碼登錄。
首次部署后設置 .env,并配置 nginx 站點
默認情況下,首次部署后,.env 文件是不會自動創(chuàng)建的,需要自己創(chuàng)建并修改,同時 nginx 站點配置也需要自己動手。對于 .env 文件,存放于目標主機的 /path/to/project/shared/ 目錄下。
修改 .env 后記得重新緩存配置 php artisan config:cache
另外需要注意的是配置 nginx 站點時,網站根目錄應該為 /path/to/project/current/public。如果使用 supervisor 之類的,相關的目錄在配置時也要注意了。
部署后目錄的結構及相關說明在部署的目標目錄下執(zhí)行 ls -la,可以看到如下結果:
說明:
| projectname |--- @current -> releases/|--- .dep |--- releases 一個文本文件,里面存著各次部署的時間、次數序號(或者說版本號)信息 |--- releases // 目錄下根據配置保存近幾次部署,更早的則會被自動清理 |--- 1 |--- 2 |--- . |--- . |--- |--- 目錄中是項目的實際代碼 |--- 包括 .git, vendor, .env, storage ... |--- .env, storage 實際通過 symlink 鏈接到 shared 目錄下對應的文件上 |--- shared |--- storage // 即 laravel 項目的 storage 文件夾 |--- .env // 即 laravel 項目的 .env
每次部署更新,會在 releases 下新建文件夾如 num,拉取對應的最新代碼,安裝 composer 依賴完成一些其它自定義任務,并將 storage, .env 鏈接到 shared 文件夾下的那兩個上去,然后項目根目錄下的 current 通過 syslink 鏈接到這個新文件夾 num 上,這算是其動作的基本原理,網站在部署過程中能繼續(xù)訪問也得益于此。
.env 和 storage 下的一些未加入代碼庫中的內部,部署時不會自動更新,因此有些情況下需要手動處理。
其它日常使用技巧正常情況下,部署過程中 deployer 會自動完成緩存配置、清理已編譯的緩存等任務。理論上我們不需要自己再動手,但需要時也可以手動執(zhí)行
// 緩存路由 vendorindep artisan:route:cache production // 緩存配置 vendorindep artisan:config:cache production // 清視圖緩存 vendorindep artisan:view:clear production // 執(zhí)行自定義任務,如前面提到的重新載入 supervisor vendorindep supervisor:reload production // ssh 連接到主機,hostname 也可以不輸入,然后從選項里選 vendorindep ssh可能遇到的問題// 列出其它一些可用的命令 vendorindep list
在 deploy 命令后加上 -vvv 選項可以輸出詳細錯誤信息,方便調試。
由于部分 php 函數被禁用而報錯
目標主機 php.ini 里的 disabled_functions 項里配置了一些被禁用的函數,如果 deployer 用到了這些函數就可能報錯,修改 php.ini 解除相關函數的禁用狀態(tài)就可以了。
php 執(zhí)行文件位置引起的錯誤
目標主要通過 apt-get 命令或 oneinstack 一類的一鍵包安裝的 PHP,可執(zhí)行文件通常在 /usr/local/php/bin/php,而 deployer 內使用 /usr/bin/env: php 形式調用,相當于 /usr/local/bin/php。這就可能出錯,一般是報 command -v "php" failed。解決辦法很簡單,只要加個軟鏈接就可以了。
ln -s /usr/local/php/bin/php /usr/local/bin/php
目錄主機不在線或者網絡連接問題
解決辦法當然是打開目錄主機并檢查網絡情況
關于緩存清理
deployer 的 laravel 默認部署流程中,會執(zhí)行 php artisan cache:clear 命令,如果你的項目里使用了 redis 驅動的隊列或者一些強依賴于緩存的業(yè)務邏輯(如緩存文章閱讀數定期再入庫),則需要進行一些騷操作了。
比如,你可以在 config/database.php 的 redis 項中為隊列鏈接指定其它的 database。
或者修改 deploy.php 配置默認的緩存清理任務,跳過緩存清理動作。(通常并不建議這么做,因為項目的緩存,應該是可清理的,如果部分業(yè)務確實十分依賴于緩存,則應該考慮一些緩存持久化的實現了)
// 覆蓋 recipe/laravel 里默認的 artisan:cache:clear 任務,部署時不清緩存 task("artisan:cache:clear", function () { return true; });
原文地址
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規(guī)行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/30751.html
摘要:阿里云效平臺基于理念的私有平臺實踐本文將系統的從個方面,分享互娛運維團隊對于運維平臺實踐經驗及未來展望,希望對大家有一些參考意義。 CI Weekly 圍繞『 軟件工程效率提升』 進行一系列技術內容分享,包括國內外持續(xù)集成、持續(xù)交付,持續(xù)部署、自動化測試、 DevOps 等實踐教程、工具與資源,以及一些工程師文化相關的程序員 Tips 。同步于 flow.ci Blog、微信公眾號、官...
摘要:采用虛擬化的技術來虛擬化出應用程序的運行環(huán)境。安裝成功后,可以通過查看版本號盡量使用最新的穩(wěn)定版本。是鏡像名,是鏡像的版本號,到此你已經成功構建了一個新的鏡像,你可以通過,查看你的鏡像。部署時將此文件到生產環(huán)境服務器上。 Docker docker是一個開源的應用容器引擎,可以為我們提供安全、可移植、可重復的自動化部署的方式。docker采用虛擬化的技術來虛擬化出應用程序的運行環(huán)境。此...
摘要:采用虛擬化的技術來虛擬化出應用程序的運行環(huán)境。安裝成功后,可以通過查看版本號盡量使用最新的穩(wěn)定版本。是鏡像名,是鏡像的版本號,到此你已經成功構建了一個新的鏡像,你可以通過,查看你的鏡像。部署時將此文件到生產環(huán)境服務器上。 Docker docker是一個開源的應用容器引擎,可以為我們提供安全、可移植、可重復的自動化部署的方式。docker采用虛擬化的技術來虛擬化出應用程序的運行環(huán)境。此...
摘要:上海站今天順利進行了,沙龍的四位重量級的嘉賓都和大家分享了深度有趣的是技術內容和別具一格的圓桌討論,從深入實踐,到的產品化實戰(zhàn)經驗,再到最近新熱的和,是一場真正的技術實戰(zhàn)經驗分享。上海站嘉賓分享文檔及圓桌討論 SegmentFault D-Day 2015 上海站 今天順利進行了,沙龍的四位重量級的嘉賓都和大家分享了深度有趣的是技術內容和別具一格的圓桌討論,從 API 深入實踐,到 N...
摘要:來這里看看的工程師如何進行持續(xù)集成與持續(xù)部署。主要介紹了豆瓣移動持續(xù)集成和測試相關實踐,用工具化自動化社會化測試來解決遇到的問題,將打包發(fā)布環(huán)節(jié)自動化。這期的持續(xù)集成實踐分享就到這里。 我們常看到許多團隊和開發(fā)者分享他們的持續(xù)集成實踐經驗,本期 fir.im Weekly 收集了 iOS,Android,PHP ,NodeJS 等項目搭建持續(xù)集成的實踐,以及一些國內外公司的內部持續(xù)集成...
閱讀 1991·2023-04-26 01:41
閱讀 2468·2021-11-24 09:39
閱讀 1922·2021-11-24 09:38
閱讀 1947·2021-11-19 09:40
閱讀 3760·2021-11-11 11:02
閱讀 3294·2021-10-20 13:48
閱讀 3157·2021-10-14 09:43
閱讀 4360·2021-09-02 15:11