Laravel 台灣社群活動 在進入正題之前先幫忙打一下廣告，目前 Laravel 台灣社群每個月固定會舉辦兩次 LaraDiner (Laravel 讀書會)，讀書會不一定會有講題，若有 Laravel 使用上的疑問可以帶到讀書會中詢問大家，讀書會主要是希望提供一個固定的空間與時間讓社群朋友可以彼此認識聊天。
目前讀書會中正在進行「讀書會中的讀書會」，目前閱讀的書是《Modern PHP》，而每次 LaraDiner 則會有成員對書中內容進行導讀。
而本週四(2015/6/4)就是由我負責導讀第七章的內容。
下面是這次為了導讀所製作的簡報，可以對照本篇文章閱讀
Modern PHP Ch7 Provisioning Guide 導讀 第七章主題 Provisioning 因為這是一本關於 PHP 的書，因此並不會過度深入 Provisioning，僅僅點到為止。
同時本章的內容僅適用於 VPS (Virtual Private Server) 或可以自由安裝軟體並設置 config 的環境。
最後，如果你實在不愛使用 Command Line 來管理 Server，基本上我覺得也可以直接快速翻過本章，而書中作者則建議你可以改用 Engine Yard 或 Heroku。
目標 在本章內容中會完成以下幾個目標：
開啓一台 VPS，登入 VPS，並完成基本的安全性設定。 安裝設置 Web Server 來處理 HTTP requests。 安裝設置 PHP processes 來處理 PHP requests。 附帶一提，過去常見的方案是 Apache + Apache mod_php，但現在比較主流的做法是 Nginx + php-fpm。 VPS 作者推薦使用 Linode 或 DigitalOcean，我個人也同樣推薦。除了帳號申請容易及開機方便外，這兩間最小計費單位都是「小時」，因此可以自在的開機玩個幾小時，不必擔心會被一次收取整月費用。...
公司經手的專案中頻繁的使用了 Queue 來進行工作排程，當專案轉交給客戶測試之後，客戶提出了一個新的需求。希望能增加排程併行的數量，假設有 100 個工作要排入 Queues，希望能自動分派給 2 或 4 個序列同時運行，如此來縮短工作時間。
原本在測試環境中上述的架構運行都一切正常，但你也知道的，問題往往都在正式環境中爆發！
正式上線後，果不其然 Server 就爆了，查看原因後才發現，只要一透過 Supervisor 啟動 Laravel Artisan Queues，立馬 CPU 就往上飆升至 80 ~ 90 %，也難怪客戶都還沒做什麼其他動作，Server 就自己先掛掉陷入無回應的狀態。
有關 Laravel Artisan Queues、beanstalkd 及 supervisor 的使用，就不在這裡說明，雖然現在已經是 Laravel 5 了，但在 Laravel 4 的時候滿多人推薦可以參考這一篇《Production-Ready Beanstalkd with Laravel 4 Queues》
併行多條 Queues 序列 在 Laravel 的 config 中預設了 default 的序列，但將工作推到 Queues 時，其實是可以自行指定要推到哪一條序列，在前述的案例中，其實就是在工作排程時，自動分配至數個序列。 真正的 CPU 消耗者 將大量的工作排入 Queues 並不是消耗 CPU 的兇手，真正的元凶其實是 supervisor 配上不恰當的 Queue listen 或 Queue worker 指令。...
Docker 的熱潮不用說明，大家都已經耳熟能詳，最近也有越來越多的 Production 案例出現，前一陣子更已推出 1.6 版，我個人的評估認為現在是一個滿好的時間點，可以由資訊收集、觀望，轉變進入測試及實用。
於是決定就用 php 常見的一個問題來當作我個人第一個 Docker 實作的題目， 那就是「如何建立一個舊版本的 php 工作環境」
評估環境需求 首先評估舊專案環境需求，發現舊專案只能運行在 php 5.2 的環境，在伺服器上要安裝舊版本 php 其實已經有好幾種解法，但既然要改用 Docker 來實現，於是思考的方向便偏向希望能將 php 5.2 獨立運行在一個 container 之中， 於是環境需求便規劃為 Nginx + php-fpm 5.2 + mysql。
安裝 Docker 如何安裝 Docker 這基本動作已經有太多教學文件可以參考，其實直接看官網文件就已足夠。
取得 image 正式實作的第一步驟當然是先搜尋有沒有前人已經建立好的 Docker repository 可以直接運用。
基本上只要在 Docker hub 搜尋 php、phpfpm、php 5.2…或其他相關的關鍵字，會跑出來的 repository 多到不可數，稍微評比之後，選用 helder/php-5.2 作為我的 php image。
會選擇它有幾個原因：
作者有提供原始的 Dockerfile，假如不滿意，還可以自己微調再重新 build。 這是 php-fpm，可以單獨運行為一個 service。 被下載次數有破百，代表還算有些人氣，通常有人氣的東西比較不會有問題。（非絕對，使用前還是要自行判斷。） 有了 php，接著還需要 mysql 及 Nginx，一樣的做法直接上 Docker hub 搜尋，這次就直接選用官方建立的 mysql 及 Nginx repository。...
目前在網站開發時，已有固定的開發部署流程，我們會依據 development -> staging -> production 的順序部署。在比較小型的專案，有時為了節省資源，會將多個 development 網站部署在同一台 VPS，透過給予不同的專案 domain，再配合 Nginx 做出 virtual host 來運行。
其實 Nginx 在 Config 檔案之中，可以使用一些簡易的判斷式及變數，因此雖然是多個專案使用同一台 VPS，但也只需要設定一次 Nginx Site Config 檔即可。
實作的方式如下： 首先規劃出固定的 domain 及 folder 路徑規則。
domain 規則為 XXXXX.dev.site 舉例：projectA.dev.site、projectB.dev.site
Folder 規則為 /var/www/XXXXX/ 舉例：/var/www/projectA/ 、 /var/www/projectB/
接著在 Nginx 中，建立一個 Site Config，並其中有兩個地方要使用變數，分別是 server_name、root，可以參閱下面的範例。
server_name ~^(.*)\.dev\.site$; set $project $1; root /var/www/$project/; 如此一來，只要是從任何吻合此正規表達式的 domain 進來，Nginx 會將 domain 的第一個單字丟進變數 $1，接著再新增變數 $project = $1，第三行告知 Nginx 要去何處取得此網站檔案，檔案路徑中則包含了變數 $project。
假設是從 abc.dev.site 進來，則 $project 就會等於 abc。...
去年在 Laravel 台灣 歡慶翻譯里程碑（@創業酒吧 - 2014/10/4）獻醜了一個小講題《體驗HHVM》。因為是小講題，所以並沒有打算要長篇大論或深入剖析 HHVM，只是一個拋磚引玉的動作，介紹一下如果想要嘗試使用 HHVM，有一個輕易的方法，即是透過 Laravel 的 homestead。
下面爲當時的簡報：
體驗HHVM 上面的簡報與現況已經有些距離，因為目前 homestead 已經進入 2.0 版，有了一些變動，特別是安裝路徑及操控指令，我個人還是比較喜歡 1.X 版，有關 homestead 的詳細介紹可以參考我另一個簡報《快快樂樂用 homestead》。
如果你已經是 Laravel 或 homestead 的使用者，我想不用多說，你應該可以立即體會要啟用 HHVM 是多麼的容易，你只需要編輯 homestead.yaml，對想要啟用 HHVM 的 site，開啓 HHVM 的設定即可。
接著你只要重新 vagrant provision 或 homestead provision，你所設定的 site 就會是運行於 HHVM。
若你還不認識或未使用過 homestead，那麼你需要克服的難關就多了一些，首先你要先認識並安裝 Vagrant，接著再安裝 homestead，然後你有可能會在 homestead 的安裝流程或觀念上卡關，等到你突破一切之後，就可以一起來體驗 HHVM 了！
當初在準備講題之前，自己有先試著簡單的比較使用 php-fpm 及 HHVM 的效能差異，雖然不是很正統的測試，但是數據上 HHVM 的表現確實有比較好，但是等到 Laravel 台灣活動當天上台 Live Demo 時，HHVM 的數據卻沒有比較好，這是否也是因為 Live Demo 魔咒的影響呢？ （後來經過 Ricky Su 大大的說明，了解到因為 HHVM 會需要經過類似暖機的過程，暖機之後才能真正發揮它的威力，所以與 Live Demo 比較，我自己測試時因為有不斷的反覆實驗，所以有足夠的暖機，因此數據會比較好看。）...
如果你現在問我「如果要建立開發 website 的工作環境，有沒有什麼推薦的方案？」，二話不說我會直接推薦使用 mac + Vagrant + Laravel Homestead。
首先你會納悶為何第一個關鍵字是 mac，我只能說在我有限的觀察中，看到太多人（包含我自己在內），在 windows 的開發環境設定踩到莫名其妙的地雷，而偏偏 mac 上要建立相同條件的環境，踩到的地雷就是比較少。而且我推薦的第二及第三個關鍵字 Vagrant + Laravel Homestead，在 windows 上更是一堆地雷，很多人雖然能順利安裝 Vagrant 及 Homestead，但卻始終無法順暢的透過 Command Line 操控它。
接著再介紹 Vagrant 之前，你一定聽過 Virtual Box，如果你已經覺得 Virtual Box 用來建立與管理 Virtual Machine 已經很夠用了，那你一定會愛上 Vagrant。
Vagrant 是一套 Command Line Tool ，它讓你透過自訂的 vagrantfile 來更便利的建立、管理及使用 Virtual Machine，透過一個 vagrantfile 你就能輕易的設定 VM 需要的硬體資源、synced folders…等，甚至你還能在 vagrantfile 中寫入 ruby 語法，一次創建多台 VM 。Vagrant 還提供了 VagrantCloud（已轉移至 atlas），讓大家可以將自己的 Box 放上 Cloud 交流。假如對於某些軟體的安裝苦手，也許你可以試著上 VagrantCloud 搜尋，因為也許早已有人上傳了合適的 Box 可以直接取用。...
某天被人出了一個題目「如何知道 Web Site 實際發出的 Request 數量？」
其實這個題目有好幾種解法，例如：
直接查看 Cloud Host 的報表 開啓 Web Server 的 access.log，再透過 Log 分析來取得 安裝 Network Traffic Analyser 來記錄與分析 其實上述的方法都可以 Google 找到現成的解決方案，但自己卻沒來由的突發奇想，想知道「是否可以由封包記錄中取得這樣的資訊？」經過一番研究，還真的做的到，而且實作起來並不困難，以下就簡單的分享經驗。
實作方式其實很簡單，首先透過 Linux 的指令 tcpdump 過濾並記錄某種特別的封包，並將封包接收資訊另存為 Log File，最後再透過 Parser 去分析 Log 即可。
tcpdump 的指令詳解，可以參考鳥哥的網站，或者自己直接在 command line 去問 man。
$ man tcpdump
最終會使用的 tcpdump 指令如下
$ tcpdump -i eth0 -n 'tcp[tcpflags] & (tcp-push) != 0 and dst net xxx.xxx.xxx.xxx and port 80' -q > requests.log
簡單說明所使用到的選項與參數...