本系列心得兼筆記文的最後一篇，即是 2015 Cloud & Datacenter EXPO 下午 DevOps & App 此條議程線的第四、五兩場議程。
上篇傳送門：2015 Cloud & Datacenter EXPO 心得兼筆記文 (上) 中篇傳送門：2015 Cloud & Datacenter EXPO 心得兼筆記文 (中) Docker’s Impact on Data Center Industry - Docker Taipei Meetup 共同發起人 / 郭韋廷 第四場雖然題目是「Docker’s Impact on Data Center Industry」，不過我個人覺得內容其實並未超出 Docker Introduction 的範圍，所以下面就僅用簡短的篇幅記錄。 首先郭韋廷先用了兩種困擾的情境作為開場，帶領聽眾體驗一種擾人的狀況，藉此突顯 Docker 所能帶來的好處。
第一個情境是舊版軟體往往只能安裝在舊的 OS，但是時過境遷，即便能找到舊 OS 、舊軟體及軟體所需的舊版 Library，也不代表一定能順利安裝。接著繼續延伸情境，假設要安裝的舊軟體又有數個版本，也許 A、B 兩版本的 Library 可能不盡相同，因此無法 A、B 同時安裝，會發生 Library 衝突問題，試問這該如何是好？
第二情境則是幫正妹架設 Blog，需要安裝 Apache、Mysql、PHP 及 Wordpress，一開始自已先在 Windows 環境測試安裝，但到正妹宿舍時才發現正妹電腦是 MAC，這該如何是好？延伸情境，假設正妹大紅大紫了，Blog 要搬家到一般的 VPS (Linux)，又是另一種安裝環境。最終假設正妹爆紅了，這下要從 VPS 搬到 AWS 環境，於是又出現另外一種新的安裝環境了。四個需要安裝的軟體 Apache、Mysql、PHP 及 Wordpress 乘以四種安裝情境，面對有可能在任一個組合中踩到安裝地雷，試問這又該如何是好？...
這是說好的 2015 Cloud & Datacenter EXPO 的心得兼筆記文的中篇，這篇僅記錄一場議程，因為同樣的整理一場就夠累人了，所以我真的很佩服這世上的眾多優質部落客，可以一直產出文章。當然更不用說對那些 Code 寫的好、演講講得棒、文章更是寫的呱呱叫的大神們，我根本就是一直跪著在看電腦。
上篇傳送門：2015 Cloud & Datacenter EXPO 心得兼筆記文 (上) 下篇傳送門：2015 Cloud & Datacenter EXPO 心得兼筆記文 (下) 雲端時代不可不知的Micro Services架構 - Gogolook 軟體架構師 / 葉秉哲 第三場議程是由 Gogolook (也就是 Whoscall 的公司) 的架構師葉秉哲帶來的精彩內容，我個人近期已多次聽過葉大上台簡報，每一場都令人讚嘆，講題內容具備深度，內容主軸與架構安排得宜，準確的時間控制，畫面切換的順場，可以說是專業級的講者，能聽到高品質的議程真的是十分享受的一件事。
這場的題目也正好是我個人最近有些困惑的東西「Microservices」，我甚至還去下載了《Building Microservices》 的試讀本。就在我覺得最近資訊量過多，決定先繼續擱置它時，想不到在這次的 EXPO 葉大就開講了，時間點實在是恰到好處！
回到正題，下面就開始筆記這次葉大所講的內容，葉大也已經將簡報釋出，大家可以自行前往觀賞！ https://prezi.com/e-fjaizjyell/microservices/
開場 葉大首先用 Whoscall 作為開場，主要提到了小團隊也能有大成就，而其中的關鍵之一就是善用雲端資源。接著他提到另一個將雲端運用得淋漓盡致的公司 NETFLIX，他引用了一篇報導，他提到 NETFLIX 是一間比 Amazon 還要懂得如何使用 AWS 的公司，據說在 2011 AWS 大當機的時候，很多網站都掛了，但是 NETFLIX 卻僅僅只有速度變慢的影響而已。
不是說只要使用了雲端，就代表你可以跟其他人一樣厲害，因為使用雲端也有雲端需要去面對的問題與挑戰。而雲端的優勢在於彈性，唯有透過「自動化」才能善用這種優勢，例如你需要有基本的 Monitoring、Measurement、auto scaling、rapid provisioning…等，這些綜合起來簡單地說就是你有沒有好的 DevOps 文化！
題外話，葉大也有稍微提到如果覺得資料放在別人家不安全，你可以嘗試加上額外的加密機制，他就有替他們公司設計自己的加密機制。
在 Microservices 之前 前面開場講了一堆雲端，也提到了 DevOps 文化，為什麼要提這些呢？因為這些是繼續談 Microservices 之前的重要前提，在簡報中葉大則是用「體質」來形容這件事。他表示要先具備這樣的體質，才能開始 Microservices，而這樣的投資是值得的，不然你根本無法開始導入 Microservices，也就更不用說要從中獲得好處。...
說好的 2015 Cloud & Datacenter EXPO 心得兼筆記文來了，但此文僅只針對下午 DevOps & App 此條議程線。因為文有些長，因此會分成上下兩篇文章來發佈，目前先整理出上篇。
How Trend Micro adopt DevOps model - 趨勢科技 資深工程師 / 陳彥宏 第一場就是一個亮點，趨勢科技的陳彥宏帶來了趨勢科技的 DevOps 經驗，簡報分為兩大部分，首先當然是 DevOps 基本介紹，第二部分則是趨勢科技目前的 DevOps Practices。
開場 首先陳彥宏先用了 Dev 與 Ops 之間常發生的問題作為開場，常見的案例就是 Dev 的 Code 在開發環境中可以運作的很好，可是上到 Production 之後程式卻炸了，於是 Dev 就冷冷的撒手不管說「在我家跑得好好的，但既然是在你們家出了問題，當然就你們自己處理喔～」
但其實 Dev 這邊的 RD 也不是故意不管問題，而是 Ops 這邊的 Datacenter 有一定的管理，當災難發生時，Dev 這端還需要經過一堆申請手續後，才能進去做救災的動作，而經過一大堆的手續後，往往火都不知道燒到哪裡去了。所以每次要上新的程式就變成了一場可怕的夢魘，為了解決這樣的問題，趨勢科技開始導入 DevOps。
DevOps - CAMS 接著陳彥宏先開始說明何謂 DevOps。提到 DevOps 一般都會從 CAMS 四個角度來解釋，CAMS 分別代表 Culture, Automation, Measurement, Sharing。
Culture 前面提到的 Dev 與 Ops 之間的問題，其實是一個文化上的問題，因為 Dev 與 Ops 之間的距離不夠緊密，彼此之間無法了解對方的想法。...
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。...