LaravelConf Taiwan 2018 - 如何正確佈署 Laravel 專案 紀冠宇 (芥龍) - 希幔科技 Backend Engineer 芥龍在自己使用 Laravel 做專案開發的這一段時間裡發現，雖然官方文件上有約略提到如何部署 Laravel 應用程式。但可能是因為這些提示四散在各章節內，官方也沒有針對部署提出最佳實踐的指南。造成許多不熟悉 Laravel 設計的開發者在部署時，常因設定失誤而造成資安疑慮，讓原本很安全的 Laravel 應用程式敗在這最後一哩路上。

1. 如何正確佈署 Laravel 應用程式
Laravel Conf TW 2018
Vincent Chi

2. 大綱
● 單機佈署
○ 佈署時的注意事項
● 叢集佈署
● 現代 DevOps

3. 單機佈署： Web Server
● 必須支援
○ FCGI：php-fpm
○ 具有 PHP Runtime Extension：Apache
● 建議支援
○ SSL/TLS：為了 HTTPS
○ IPv6
○ HTTP/2
● 可選
○ IIS
○ Apache、LiteSpeed、OpenLiteSpeed
○ Caddy
○ Nginx

4. 單機佈署：PHP Runtime
● PHP >= 7.1
○ Laravel 5.6 系統需求
● Extension （官方說明）
○ OpenSSL：加解密（AES-256-CBC）
○ PDO：資料庫存取介面
○ Mbstring：多位元字元（multiple bytes string）支援，如 UTF8
○ Tokenizer：Artisan Tinker 使用
○ XML：PHPUnit 使用
○ Ctype：字元檢測（C 語言的 type.h）
○ JSON：對 json 的支援

5. 單機佈署：PHP Runtime
● Extensions（實際上可能會用到的）
○ memcached：需從 pecl 安裝，用於 memcached 快取
○ opcache：速度 PHP 應用程式執行
○ gd：理論上僅在開發時期使用，於 Test Case 建立 fake image
○ bcmath：若需要建立 orderedUuid 時需要
○ pcntl：使用 queue 時，在 PHP 7.1 下有使用 pcntl 對異步執行做優化
○ zip：composer 必須
● Redis 連接方式
○ predis：以 PHP 實現的 Redis Client
■ 僅支援 TCP
○ php-redis：以 C 實現的 Redis Client extension
■ 支援 TCP 與 PIPE 模式

6. 單機佈署：資料庫
● 官方
○ MySQL：會自動針對 MySQL 8.0 做連接初始化校正
○ PostgresQL
○ SQLite
○ MS SQL
● 理論上
○ 有支援 PDO 的都可以使用
○ 但要注意各 Database 的特性
■ MySQL 5.6（含）以下不支援 json data type
■ in-memory database 不支援 transaction

7. 單機佈署：Queue
● 注意事項
○ 務必建立 failed_jobs 資料表
■ 「重試失敗任務」 feature 的根基
○ 務必注意 retry 及 sleep
■ 避免因任務失敗無限循環
○ 建立系統服務，保證 Queue Worker 執行
■ Supervisor
■ Systemd

8. 單機佈署：Cron Job
● 注意事項
○ 避免使用時區功能
■ 因部份時區有夏令時間，可能造成任務不執行或執行兩次
○ 建議設定 Cache
■ OnOneServer 的 Feature 是建立在 Cache 能夠正常執行的前提下

9. 佈署時的注意事項：應用程式進入點
● 進入點永遠位於 public/index.php
○ 「絕對」不要將 nginx root 或 apache root 放在應用程式目錄下
■ 可讓敏感文件被讀取
● .env
● .git/
● composer.json
● node_modules/

10. 佈署時的注意事項：權限
● 需讓 php-fpm 有可讀可執行的權限
○ 整個 Laravel 資料夾
● 需另外讓 php-fpm 再加上可寫權限
○ bootstrap/cache
○ storage/

11. 佈署時的注意事項：加速應用程式
● composer 端
○ -o：建立 class map，當 class 不在的時候再去檔案系統中尋找
■ 在 PHP >= 5.6 的情況下，且 Opcache 為 enabled 時，效果不彰
○ -a：建立 class map，當 class 不在 map 中，直接丟出 NotFound 的例外
■ 不可與 --acpu-autoloader 混用
● Laravel 端
○ config:cache
■ 為 .env 及 local environment 建立 config/ 資料夾下的單一設定檔
■ 會讓 config/ 之外的 env() 函式直接 return null
○ route:cache
■ 將路由序列化（serialze）並編譯為 Symfony Routing Class，加速路由分配
■ 若路由中存在 callback 則會失敗
○ view:cache
■ 編譯 blade 模板為 PHP 檔案

12. 叢集佈署：分離資料庫
● 方法一：Laravel Connection Feature
○ 原理：利用不同的 Connection 去連接不同的資料庫
○ 缺點：需更改程式碼
● 方法二：ProxySQL for MySQL
○ 原理：利用 ProxySQL 進行連線，讓 Laravel 連線就像對單一 DB 做存取
○ 優點：可設定較複雜的讀寫、防火牆等規則
○ 缺點：不支援 Laravel 中使用的 Prepared Statement
■ 可加入 PDO 參數 PDO::ATTR_EMULATE_PREPARES = true 解決

13. 叢集佈署：分離快取與其它服務
● 快取
○ Local Cache
■ 需要高速回應的內容，不希望經由連線再去其它服務上 查詢
■ 必須為 Stateless ，避免與其它 Cache 產生 race condition
○ Global Cache
■ 可以接受一點點延遲的 內容
■ 可為 Stateful，例如 Session
● 其它服務
○ 連線只要有 Restful API 或 TCP 基本上問題不大
○ 通常問題在於「如何保持服務高可用」

14. 叢集佈署：分離核心應用
● 將會產生的問題
○ Cron Job 重複執行
■ 解法一：只在一個核心應用執行 Cron Job
■ 解法二：在每一個核心都執行 Cron Job，但依賴 onOneServer 特性避免重複執行
○ Queue Worker 資源閒置
■ 解法參考：分配 Queue/non-Queue 策略
● 當有需要 Queue 處理時，丟給有 queue worker 的應用程式伺服器
○ 無法正確取得 Client IP
■ 記得配置 Trusted Proxies，以嘗試取得正確的使用者 IP
● 有使用 CloudFlare 的話也記得要將 cloud flare 的 IP 記錄進 trusted proxies 中

15. 現代化 DevOps：容器化的迷思
● PHP 天生不適合容器化？
○ 理由
■ FastCGI 必須綁定 Web Server
■ 檔案結構複雜許多，不利容器運作
○ 思路
■ PHP FPM 特性在於「快速啟動，快速銷毀」，思想上其實與微服務有一定程度的類似
■ 將 FPM 視為一個服務，並讓 Web Server 介接
● 在 Microservice 時代，PHP 終將被淘汰？
○ 優勢：快速開發、效能有一定程度的保障、具有大量套件
○ 劣勢：無型別、VM 化、垃圾回收等效能有待加強
○ 個人結論：PHP 還會活一陣子

16. 現代 DevOps：走向現實
● PHP-FPM 與 WebServer
○ 是否應該與 Web Server 置於同一個容器？
■ 同生共死
● 降低 DevOps 負擔
● 對高可用的要求較低時可以考慮
■ 「一個容器一個程式」原則
● DevOps 負擔較重，但具有高可用的優勢
● 原始碼應該 copy 或 mount
○ mount：快速抽換程式，但 I/O 效能較低
○ copy：每發佈版本就要建立新 Image，I/O 效能高
■ 推薦有完整 CI/CD 流程使用