續前兩篇試過了 GCP、Azure 之後，繼續我的測試之旅，這次的對象是 AWS 的 Elastic Benstalk。
AWS 的文件與參考資料本來就是爆炸多，隨手就能找到一篇《Deploying a Laravel Application to Elastic Beanstalk》 （謎之音：所以你又要偷懶不寫文了？）
不過 AWS 的中文文件目前只有簡中版，所以這篇文應該還是有一點價值啦！ （謎之音：想充版面就說一聲，找一堆藉口。）
預備 Laravel 5.1 程式碼 老樣子，就直接用 composer create-project 建一個乾淨的 Laravel 5.1 來試試。
composer create-project --prefer-dist laravel/laravel trylaravel "5.1.*" 同時先把這一份 code 打包成 zip 壓縮檔，請參考 AWS 官方教學《Deploying a Laravel Application to Elastic Beanstalk》的作法。
cd trylaravel
zip ../laravel-default.zip -r * .[^.]* 也就是打包成 zip 檔時，不要多那一層資料夾，直接把 code 打包。
而且注意噢，我們是連同 vendor、.env 這些檔案全都一起打包在 zip 中了。 （你也可以打包一個不含 .env 的 zip 檔，後面也有機會用到。）...
繼上一篇將 Laravel 部署在 GCP - App Engine，這次要來試用 Azure 的 App Service - Web Apps。

Azure 目前文件增加的速度頗快，所以官方其實已經有一篇《建立、設定和部署 PHP Web 應用應式至 Azure》而且文章很潮的就是用 Laravel 作為範例。 （謎之音：所以你其實也不用寫文了？反正別人已經寫好了。）
不過因為 azure-cli 有改版，所以上面那篇官方教學少寫了一件事，因為個人覺得頗雷，所以我決定先賣個關子，這樣我這篇文似乎還是有點用處，只是不知道能存活多久就是了。
申請試用 目前 Azure 一樣有 Free Trial，提供 30 天內有 NT$6,300 的額度讓你試用，當然與 GCP 相同，在試用方案期間 Azure 對於資源上限會有所限制，所以你一樣沒辦法在試用期建立某些巨大的架構，但若只是要試試 Azure 的各種服務則是綽綽有餘。

試用 Azure 目前比較麻煩有兩件事：
需要 Microsoft 帳號，如果沒有就去註冊一個吧。 需要輸入信用卡資料，沒有信用卡，那就去銀行辦卡吧。 安裝 Azure-cli 操作過程中（可能）需要用到 Azure-cli，請事先安裝完畢，可以參考 MS 官方文件，但如果跟我一樣不想在本機上安裝一堆東西，那上面的 MS 文件中也有提到，MS 作出了 Docker Image - azure-cli 可以直接取用。
這個 Docker Image - azure-cli 內含 curl、git、vim 當然還有 azure-cli，算是一個簡單乾淨的環境，如果覺得還缺了什麼，它是以 debian:jessie 當作 baseimage，所以想要自己補安裝其他軟體也不困難，可以自己動手 build 一個你所需的版本。...
觀望 Google Cloud Platform（以下都用縮寫 GCP）好一段時間了，也曾報名參加過好幾次他們的活動，並去參加了 101 的教學，但遲遲沒有正式開啟試用，這次有個機會需要試用 GCP 的 App Engine，擇日不如撞日於是就有了以下的一點經驗分享，究竟要如何在 GCP - App Engine 上部署 Laravel 5.1 的專案，對於 GCP 與 Laravel 有興趣者再往下看吧。
（但我可以先說一個小感想，如果是 Laravel 專案，可能還是別用 App Engine 吧，因為不見得有比較輕鬆，若非用不可，那建議最好評估一下優缺點，判斷這是否是適合你的最佳方案。）
申請GCP免費帳號 若申請 GCP 免費試用，你將可以在 60 天內擁有 $300 額度隨便你用。在免費試用期間不需填寫信用卡資訊，因此絕對安全不用擔心被意外扣款。 申請方式很簡單，登入你的 Google 帳號，接著進入 GCP - Free trial 網頁，用力地將 TRY IT FREE 按下去就對了。
接著基本上就是同意、下一步、下一步的流程，最後你的 Google 帳號就會與 GCP 的 Console 綁定，之後就能用此 Google 帳號快速登入了。（如果有任何疑慮，請自己看清楚每一頁的內容。）
免費試用畢竟還是有一些資源上限的限制，所以如果你想要在免費期間測試一些超大的架構，要先做好碰壁的心理準備，因為像是 compute engine 就有限制機器能建立的最高等級。
建立首個 Project GCP 與 AWS 在使用上有個很不一樣的地方，GCP 預設會以 Project 來區分資源。假設你實際上有好幾個專案要上線，那你便可以依據專案數量，替每個專案分別建立一個 GCP 的 Project。...
在 2016/03/03 及 2016/03/09 的 Laravel news 分別介紹了 laraedit-docker 及 LaraDock。
Laravel News 的這個舉動似乎引爆了 Laravel 圈內的 Docker 熱潮（我自以為引爆啦），所以藉這個機會也來聊一聊「如何用 Docker 建構出適合 Laravel 的開發環境」這題目。
既然目標是建構開發環境，首先當然要先問 Laravel 的開發環境需求為何？ 根據官網我們可以得知，Laravel 5.2 對環境的需求為： 根據官網文件 https://laravel.com/docs/5.2#server-requirements
這裡面主要的需求是 PHP 版本及 Extension，Laravel 需求爲 PHP >= 5.5.9。那除了 PHP 之外，我們還要預備哪些軟體？我們只好同時參考一下官方的 homestead 看看它安裝了哪些軟體： 根據官網文件得知 homestead 已安裝上述軟體
將上述內容整理並精簡之後，規劃出我個人認為所需的基本環境需求如下：
PHP 5.5.9 Nginx Mysql Beanstalkd Composer 有了需求，接著就開始用 Docker 建置。
關於 Docker 要如何安裝，可直接參閱 Docker 官方網站，那裡有豐富的文件可以參考，不管你是哪一種 OS 官方都有提供安裝步驟，再不然網路上也有很多教學文章可參考，所以我就不再重複說明了。
如果是 Mac OS 可以考慮使用早期比較多人用的 Boot2docekr 或已被 Docker 官方收購並包入 Docker Toolbox 的 Kitematic，再不然也可以考慮使用 docker-machine。...
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 指令。...
去年在 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 比較，我自己測試時因為有不斷的反覆實驗，所以有足夠的暖機，因此數據會比較好看。）...