今天參加了 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 檔，後面也有機會用到。）...
繼上一篇將 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。...
注意！因為 open source 的工具改版的速度非常快速，而本文提到的 ansible-container 更是一個非常新的專案，恐怕不用幾天的時間，本文就會變成過期文章，因此閱讀之前建議先確認一下 ansible-container 目前的最新狀態，避免因為本文而讓你產生誤解。 （謎之音：所以你寫了一篇超短命的文章。）
本文確實已經過期，超短命的！ ansible-container 已經更新好幾回合了，現在按官方文件操作就可以正常試用了喔！
（再次更新，ansible-container 已經 DEPRECATED 了，原本使用它來 build container 的人，請改用 ansible-bender；如果是使用它來 deploy container 至 K8s，則請改用 Ansible Operators。）
Ansible 官方這次更新的 2.1.0.0 版本，其中一個特點就是與 Container 有更好的互動，像官方部落格就特別寫了一篇文《SIX WAYS ANSIBLE MAKES DOCKER-COMPOSE BETTER》來介紹一部分重點。
不僅如此，Ansible 官方其實從五月就悶不吭聲的在 Github 上新建了一個新的工具 ansible-container，目標讓 Ansible 在操控與管理 Container 上能更靈活。
以下就依據目前官方 GitHub 上已釋出的資訊，搶先試用一下 ansible-container。但文章很長，因為記錄了幾個雷，如果你只想要爽爽順順的試用，那可以跳到最後一個段落，我有將最後除雷完後的環境，做一個簡單的記錄。
跳至除雷結果 如果你很有耐心一起除雷，那就繼續往下看吧！
安裝 ansible-container 必須要手動安裝，所以第一步當然是將官方 repo 先 clone 一份回來。
接著是安裝 docker-compose，因為根據官方文件 ansible-container 需要依賴 docker-compose library，因此使用它的前提就是你也必須安裝好 docker-compose。 （但其實不止如此，repo 中還有一個 requirements.txt 請務必閱讀，並將其中所列的 python lib 全都預備齊全為佳，不然可能會踩到雷。）...