這次受邀擔任 PHPConf 2016 的工作坊講師，負責一場「自動化與持續整合」的實作工作坊，除了有事先預備了 Local VM 提供參與者事先安裝設置之外，要特別感謝微軟贊助本工作坊，每位學員都會擁有一組 Azure Pass 一個月內有限額的 Azure 試用，讓學員可以直接在 Azure 上建立工作坊的實作環境。
此文即是紀錄在 Azure 上要如何建立實作環境。
（2017/8/5 註記：此文的一些資訊已經過期，你也知道工具是會不斷更新的。）
環境描述 再重複一次我們會需要用到下面四種 Server：
CI Server：這次工作坊會以 GitLab 作為主要的 CI Server。 CI Worker：即是 GitLab Runner。 Web Server：標準的 Nginx + Php-fpm，而且要開放可以 SSH Login。 Selenium Server：測試案例中會用到 Selenium。 在 Azure 上，其實有各種方式可以組合出實作環境，但既然我們有 Azure 免費試用，當然可以選一種相對簡單，但又很奢侈的建置方式，即是「建立多台 VM 並安裝好 Docker，讓每台 VM 都只用 Docker 建立 1~2 種 Service。」 如此一來由多台 VM 各自負擔工作，不用擔心資源不足，也不用煩惱 IP 的問題。 所以讓我們再次感謝微軟的大力贊助！
不過我想 Azure 專家們應該會跳出來說，Azure 明明就有很多好作法，所以我只好維持一樣的回答，此文不是 Azure 教學文啊，只是想用最簡單的方式建構出本次工作坊的實作環境，就請專家們睜一隻眼閉一隻眼嘍。
當然，你也可以開一台超大超強的 VM，然後和上一篇文章的 Local VM 一樣，在一個 VM 內用 Container 提供多種服務的方式建置環境，做起來也不難，但這就留給有心人自己去嘗試了。...
這次受邀擔任 PHPConf 2016 的工作坊講師，負責一場「自動化與持續整合」的實作工作坊，因為希望工作坊的過程中能將網路與實作環境的問題減少到最少，所以事先預備了 Local VM 提供參與者事先安裝設置。
此文即是紀錄這個 Loacl VM 是如何建立的。
（2017/8/5 註記：此文的一些資訊已經過期，你也知道工具是會不斷更新的。）
環境描述 因為考慮到不是每個人都會有頂規的電腦設備，同時也為了方便設置，因此在 Local VM 的規劃上，不打算實際建立多台 VM，而是以單一 VM 並在其中透過多個 docker container 的方式來模擬多 VM 的情況。
我們會需要用到下面四個 Server：
CI Server：這次工作坊會以 GitLab 作為主要的 CI Server。 CI Worker：即是 GitLab Runner。 Web Server：標準的 Nginx + Php-fpm，而且要開放可以 SSH Login。 Selenium Server：測試案例中會用到 Selenium。 基於以上四項都要放在同一台 虛擬 VM 裡，並用多個 Container 來實現，在經過實驗之後建議運行此 VM 的電腦或筆電(host機)至少需要： 超過 2GB 的記憶體。因為 GitLab 與 Selenium 都滿吃 Ram，因此分配給 VM 的 Ram 至少要 2GB， 預留 10 ~ 20 GB 硬碟空間。因為運行 Docker 環境其實也滿吃硬碟空間的，硬碟空間能留越多是越好啦！ VM 與 host 機將對映幾個 port 分別是 80、2222、10122、10180 為了簡化環境建置的難度，作為此 VM 的 OS 我們即選用 ubuntu 14....
延續上一篇 iThome Container Summit 2016 Day 1 簡易筆記心得，當然繼續補完 Day 2 的內容。
首先再貼一次 iThome 建立的線上聊天區及共筆區，講者簡報也開始陸續提供下載了。
Gitter 線上聊天區 共筆區 Container Summit 官網下載簡報 2016.10.14 補充：Container Summit 官方已釋出錄影 Keynote: Docker 集群編排方案 這場是由真正來自 Docker 公司的講者陳東洛（去年加入的）為大家分享「Docker 集群編排方案」。說真的我一開始也不知道這個中文「編排」所指的是？聽了一段之後才知道是指很難翻譯成中文的 “Orchestration”。
本場的重點即是 Docker 的 Container Orchestration，所以在開場講者先快速的說明了一些背景因素，像是這幾年的軟體開發架構變化，與 Docker 解決了哪些問題及沒解決哪些問題。由此點出為何 Docker 也要推出他們家的 Container Orchestration 工具。
其中我覺得說得很好的一點是「Orchestration 並不是一個新的議題」，在沒有 Docker 之前就已有 Orchestration 需求，只是既有的 Orchestration 工具並不是這麼適合 Docker (Container)，畢竟 Docker 也不過是這幾年才出現並熱門。也因此 Docker 當然要做自己的 Orchestration 工具，而且其實 Docker 一直有從開源社群、用戶那得到回饋，也一直有在研究 Orchestration 這方面。
接著就進入正題 Docker 的 Orchestration 工具，這可用 Docker 1....
今天參加了 iThome 舉辦的 Container Summit 2016，以下是 Day 1 的簡易心得筆記。 iThome 這次也有建立線上聊天區及共筆區，簡報也開始陸續提供下載了。
Gitter 線上聊天區 共筆區 Container Summit 官網下載簡報 2016.10.14 補充：Container Summit 官方已釋出錄影 Keynote: The Kubernetes API & Next Generation Automation Tools 又是來自 Google 的 Ian Matthew Lewis，今年到底見過這位講者幾次呢？我想至少有三次以上吧。當然這次依然是講 k8s 的相關主題，前半場依然有些 k8s 的基礎介紹，像是 k8s 到底幫你解決了建立 Container Cluster 需要處理哪些麻煩的細節。
雖然說是基礎但卻是不得不介紹的內容，因為必須要先理解 k8s 的基本運作及 k8s 的 controller 是如何運作，接著才能理解後半場有關 k8s API 及 Custom Controllers 的 DEMO。 再看講師 後半 DEMO 時，一開始有些閃神（這就是一邊偷看共筆與聊天的缺點），沒搞懂為何忽然開始寫 Go，接著才理解這邊可是火力展示！DEMO 與前面的說明相呼應，讓你理解 k8s API 及 controller。
G 社的講師向來都是不開放簡報下載與錄影，所以閃神沒仔細聽的部分就沒辦法補課，有些可惜，但總之因為 k8s API 讓我對於 k8s 的好感又加了數分。...
今晚 DevOps Taiwan 舉辦了 Meetup #2 。感謝葉秉哲與 Erica Liu 兩位講師的鼎力相助，以及五倍紅寶石出礦坑贊助場地，讓本次 Meetup 能順利舉辦！
本次活動報名人數 45，實際到場人數約 30，看來免費活動常見的通病依然再次發生。有限名額被占據，但未能到場參加活動，導致其他很想參予的社群朋友沒有名額。這樣的情況實在很可惜，因為今晚的活動真的很精彩，希望能讓更多人可以現場參予。
這次 Meetup 的主題是「思維引導、持續改善，引發團隊改變新契機」。
延續 iThome DevOps Summit 2016 的熱度，我們計畫邀請葉大再次分享在 Summit 中大獲好評的講題「從限制理論看 DevOps」，並期望能讓講題更有感，所以規劃加入小遊戲，透過實際體驗的方式，讓大家能更有所收穫。畢竟觀念很容易聽，但要做卻是不易，特別 DevOps 與團隊文化有關，而人並不是這麼容易被改變的。
主題一：「從限制理論看 DevOps」 同樣的題目「從限制理論看 DevOps」，但本次 Meetup 可是獨家擴充版！比起 iThome DevOps Summit 2016 講得更慢更多更詳細。講題由葉大從多場 Ansible Workshop 中收集到的 DevOps 痛點開始說起，將痛點歸納成 11 大項之後，接著該怎麼解決它們呢？
一般的想法大概是各個擊破吧？但這樣做正確嗎？會不會是治標不治本？另外，這些問題似乎彼此牽連，好像並不是這麼容易各個擊破的，那該如何處理呢？於是切入本主題的核心重點「高德拉特的『限制理論』」。
葉大藉著一步一步的解釋他如何運用高德拉特的理論來推導前面 11 個痛點的因果關係，讓聽眾彷彿跟著走了一遭，相信有認真聽講的朋友，應該不時在心中點頭，並且腦袋也跟著一起運轉了一回。
當透過推導畫出 CRT 圖表之後，再拿它對照原本的 11 個痛點，恐怕大家都會希望自己的團隊中，也能經歷這樣的過程，將單一的問題轉化成有系統的 CRT 圖表，讓問題可以像串肉粽一樣的產生關聯，找出真正的肉粽頭，從源頭解決核心問題。
這場分享並未到此打住，接著再回到另一個重點「老闆主管都是豬頭嗎？」，我們應該正面一點，「老闆主管不一定是豬頭，他們只是遇到了無法解決的『衝突』。」
什麼樣的衝突？如果要持續的交付客戶滿意的軟體，到底團隊該將資源投入在「產品研發」還是「DevOps」上呢？在資源有限、資源搶奪的狀況下，主管當然很苦惱阿！所以主管不一定是豬頭，而是碰到了無法解決的衝突。
而偉大的高德拉特博士依然有解！面對衝突要找出其中的「錯誤假設」。難道投入研發就對「改善團隊體質 (DevOps)」沒有幫助嗎？反之難道投入 DevOps 就對「提供優質產品」沒有幫助嗎？這是值得思考的！
這場分享個人覺得值得多次回味，對於沒有接觸過高德拉特及 TOC 的人來說，應該是一個很好的魚餌，能讓人稍微一窺這些理論工具並非只是空談，吸引你更深入的了解認識它，甚至學習運用它。
葉大已經將今晚的分享錄影釋出，也寫了一篇導讀，對此主題有興趣者，可以深入閱讀。 http://school.soft-arch.net/blog/157917/devops-a-toc-perspective
主題二：「持續改善：找出流程中的瓶頸與浪費」 這場分享我們邀請到泰迪軟體的 Erica 來帶大家用小遊戲的方式進行。...
延續前文，這一系列的文章是將我之前在 C.C. Agile #37 分享的簡報《DevOps: 建造開發維運的跨界之橋》轉換成文章的形式，一方面讓簡報內容能更完整地被分享，另一方面也讓我有地方可以補充一些後續又吸收到的新內容。
本文繼續來談談到底 “What is DevOps”，關於「什麼是 DevOps」目前我看到最多的標準答案是「這個問題目前沒有標準答案。」（2016/9/3 補充更多內容）
於是你就會看到有人開玩笑說「你問十個軟體、資訊領域的專家，什麼是 DevOps，那你會得到十個不一樣的答案。」（來自葉秉哲的演講「Docker 對傳統 DevOps 工具鏈的衝擊」）
而目前的情況也似乎就是如此，你可以在 wiki 上找到 DevOps 的條目，你可以在 Gartner 的報告中看到 DevOps 的相關趨勢，你也能找到各廠商宣稱自己的產品是 DevOps 必備的工具。

但若仔細比較它們對於 “What is DevOps ?” 的描述，你只會得到許多十分類似但卻有些不同的答案。於是又有另一個玩笑出現了「DevOps 是一種 92 共識，認真你就輸了」。

我個人最近在看 DevOps 的新聞與文章，發現了一個現象，早期談 DevOps 的文章，當談到什麼是 DevOps 時，都會直接給一個答案 DevOps 就是 ooxx ⋯⋯；但現在的文章則比較模糊一點，不再那麼斬釘截鐵，甚至有看到文章直接補一句「關於什麼是 DevOps，目前還有許多爭議⋯⋯各家都有自己的意見與詮釋⋯⋯ 」。
所以我才會開玩笑的說「什麼是 DevOps」，標準答案就是「這個問題目前沒有標準答案。」
但各家的定義依然值得我們參考，例如前面提到 Gartner，他們的定義即是
“Gartner defines DevOps as a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach....
續前兩篇試過了 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 檔，後面也有機會用到。）...