約在今年 6 月中的時候，iThome 即宣布將在 9 月 1 日 ~ 2 日舉辦 DevOps 2015 研討會，並且開始廣邀徵稿至 7 月 6 日。雖然上次投稿 ModernWeb 2015 沒被選上，但不灰心本次再接再厲再次投稿，想不到還真的有幸被選上，所以除了要上台當講師的時間之外，其他時間則可以免費入場聆聽這兩日的 DevOps 2015 研討會。
網路上似乎已經有一些評論與心得文，所以就不打算重述太多細節，以下就只簡單的記錄個人的幾個心得，針對每一場講題簡短的記錄：
開場致詞 - 吳其勳 / iThome電腦報 總編輯 吳總編輯提到今天的現場約有 300 多人，數量比我個人預期的少？稍微查了一下台大集思的國際會議廳座位有 368 人，首日觀察覺得約 9 成滿，所以人數應該確實是 300 多沒錯，第二天的觀察是約 8 成滿，不知是否大家對於第二日的講題比較沒興趣？
DevOps 運動的全球大趨勢 - 王宏仁 / iThome 新聞主編 王主編再次講了 iThome 網站上已經刊登過的非洲銀行導入 DevOps 的案例，這個案例之所以重要的原因是想要強調就連傳統的銀行業都已經導入 DevOps，那麼身處在軟體、網路、資訊產業你還能不知道什麼是 DevOps 嗎？
CI 伺服器全制霸！活用自動化技術重建「最強」團隊 - 直井 和久 / 樂天 旅遊業務開發維運部 旅遊網站團隊經理 iThome 最近的幾次活動都有找樂天來擔任講者，幾次下來可以理解到樂天的背後確實有強大的技術力，這次來的 直井 和久 先生也是，感覺上在 CI、Jenkins 上的經驗豐富，但實在很可惜因為語言表達的問題，導致這次沒辦法與聽眾們有更多深入的 Q&A 互動，看到他在回答時默默地自言自語說了 How to say 還真是為他捏一把冷汗。不過自己也在自我省察，因為個人在英文的「說」這一方面也是很需要加強，若是在台上遇到英文問題我恐怕也是要冒冷汗了。...
八月初的時候，DevOps Taiwan 社團舉辦了第一次的 Meetup，並邀請了三位講者來分享講題。我有幸能擔任其中一位講者並分享《摩登開發團隊的 DevOps 之道》這個講題。
講題乍看之下似乎太過故弄玄虛了一點，因為這題目原本是用來投稿 iThome 與 Taiwan WebConf 主辦的 Modern Web 2015 所準備的，因此故意在題目命名上誇張了一些，其實講題內容很單純，就是想跟大家聊一聊「什麼是 DevOps？」。
當然很可惜當時投稿沒上，因此在這次 Meetup 就可以直接厚臉皮地拿出來講，反正從來也沒人聽過我講，再者「什麼是 DevOps？」這樣的內容用來作為 DevOps Taiwan 社團第一次 Meetup 的開場講題其實是相當合適的。
摩登開發團隊的DevOps之道 (@DevOpsTaiwan) DevOps 之瞎子摸象 DevOps 到底是什麼？我覺得這實在很難用簡單的一句話來解釋，因此我們會看到有人說 DevOps 就是敏捷開發，也有人說 DevOps 就是持續交付 (Continuous Delivery)，事實上這些說法也不能說它錯，但好像有一點不夠完全，無法完整的描繪出 DevOps 的整體面貌，似乎大家就像是「瞎子摸象」一樣，嘗試勾勒出 DevOps 這隻大象，但是會不會 DevOps 根本不是一隻大象？搞不好其實是一隻恐龍或是其他種類的生物？
毋庸置疑 DevOps 就是潮 但不論 DevOps 到底是什麼，有一件事可以肯定，那就是它絕對是目前非常「潮」的一個詞，因為你隨便 Google 你可以找到一堆文章、報導、教學、報告、服務、工具或職務…等，全都掛上了 DevOps，即便你都還不真正的認識它，但你已經無法阻止自己看到它出現在各個地方。
What is DevOps 延續前面提到的，DevOps 很難很簡單的被解釋，那麼有沒有比較複雜又完整的定義或解釋呢？ 答案是有的，除了 Wiki 之外，只要 Google 「What is DevOps」就可以找到一堆，而若你真的去 Google，你很可能會發現目前有滿多人是用 CAMS 來解釋 What is DevOps。...
本系列心得兼筆記文的最後一篇，即是 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 指令。...