在 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。...

有時候我們會需要編寫一些比較小型的 Playbook，例如每次遇到重大漏洞時，用來修補漏洞的 Playbook。這樣的 Playbook 通常 tasks 不多，有時甚至只要 1 ~ 2 個 tasks 即可搞定。但假設你同時管理了 Ubuntu 及 CentOS，兩者分別是用 apt 與 yum 來管理套件，這導致可能需要為不同的 OS 各寫一個 Playbook。 有沒有辦法可以只編寫一個 Playbook，同時將 apt 與 yum 的 task 都寫進去，但能動態的判斷每次執行 Playbook 時該啟用哪一個 task 呢？ 答案當然是可以，這需要用到 Playbook 中的 when 來達成。 基本上 when 就像是一般編寫程式會用到的 if 判斷式一樣，你可以告知 Ansible 在哪些狀況之下才要執行某個 task，藉此我們就能將多種不同情況的 tasks 寫在同一個 playbook.yml 之中，讓 Ansible 來依據狀況執行後續的動作。 回到前面提到的案例： 「編寫一個 Playbook 裡面包含了 Ubuntu 的 apt 及 CentOS 的 yum，當要執行 Playbook 時可以彈性的讓它自動執行正確的 tasks。」 目前比較常看到有幾種寫法： 利用 Variables 自行控制 透過 register 自動註冊新的 Variables 透過 gather facts 取得遠端主機資訊 以下一一說明這幾種寫法。...

在得到「欠筆記文欠過年」的成就之後，硬是擠出一個下午的時間，終於整理完 Agile Tour Taipei 2015 最後一場議程的筆記，壓軸場當然是非同小可，是由絕無冷場的 91 哥為大家帶來「Scrum Estimation Model」這個題目。 同系列所有文章可以點此連結前往《Agile Tour Taipei 2015 筆記與心得》 因為欠筆記文欠太久，91 哥早已將他分享的內容整理成兩篇文章： Scrum Estimation - 如何估算專案時程 Scrum Estimation - Scrum Estimation Model 既然講者都已經把內容寫成文章了，所以老實說我有沒有寫這篇筆記文好像也沒差，那本文就此結束吧。（揍飛） 筆記文由此開始，在一開場 91 哥就直接先用他自己今天的簡報總頁數當作範例，點出本場主題的三大關鍵重點「範圍」、「 時程」與「速率」。 範圍 = 簡報總頁數 時程 = 演講可用的時間 速率 = 每分鐘要講幾頁（才能不超時將內容講完） 基本上這是簡單的數學計算，由「範圍」除以「時程」可得出「速率」，反之你也可以由「範圍」除以「速率」得出「時程」，又或是由「時程」與「速率」得出「範圍」，總之這三個重點是彼此互相關聯的。 但實際上講者講話的速率有限，不可能提升至預期的速率，因此勢必只能延後結束時間或減少簡報頁數。這個開場白其實直接就比喻了專案執行的情況，因為專案執行時也同樣是在「範圍」、「 時程」與「速率」中不斷地協調。 透過開場白 91 哥很快的在聽眾們的心中埋下了「範圍」、「時程」與「速率」的基本概念，整場分享即是完全圍繞著這三大關鍵。 接著 91 哥繼續用「兩個人決定步行前往探視朋友的一段旅程」比喻說明了在專案執行中常見會導致「專案延誤」的意外狀況。 在這個小故事中一樣有「範圍」、「 時程」與「速率」： 範圍 = 交通距離 時程 = 與朋友約定的到達時間 速率 = 一天要移動多少距離 於是隨著小故事的發展，每一天都有不同的意外，但因為「範圍 = 交通距離」是無法變更的（但有可能會錯估），於是故事主角每天都在「 時程」與「速率」中不斷的協調與修正，嘗試要完成這趟旅程。旅程中就發生了各種突發狀況，例如： 錯估交通距離 = 錯估專案範圍 受傷導致行進速度變慢 = 開發速率下降 打電話通知朋友會晚幾天到達 = 嘗試延後 Due Time ⋯⋯等等 藉此案例 91哥再次強調這場分享就是一直圍繞在「範圍」、「時程」與「速率」這三個重點打轉，換句話說這場分享重點就是在講 Burn Down Chart 燃盡圖。 那「範圍」到底是啥？範圍就是專案要完成的工作項目有哪些，你的 product backlog 有多少，估算出來的 story point 有多少。...

Ansible 的 playbook 只需要 hosts 與 tasks 這兩個最基本的參數即可運作。一個最基本的 playbook 的結構會長成下面的模樣。 --- - hosts: myVM tasks: - apt: name=curl state=latest update_cache=yes tasks 設定了這個 playbook 要執行的動作，上面的範例很簡單，它只有一個動作就是透過 apt-get 安裝 curl。 而 hosts 則會與 Inventory file 搭配，Ansible 在執行 playbook 時，會從 Inventory file 中找到吻合 “myVM” 的主機，對它執行 tasks 中的動作。 一般來說當主機越來越多時，就必須用到一些進階 Inventory file 技巧來達到複雜的彈性運用，像是下面的舉例： 設定多個不同的 Inventory file 在執行 playbook 時，直接指定不同的 Inventory file。 例如：公司的主機群放在 Inventory file A，私人的主機群放在 Inventory file B。 設定多個不同的 Groups 在一個 Inventory file 之內，利用 Groups 區分主機群。...

經過了去年一整年的宣傳，雖然熱度可能比不上目前正熱的 Growth Hack，但相信應該多數的人都已聽過 DevOps 這個詞。個人在去年也做了三個與 DevOps 相關的簡報，內容大約都是「Intro to DevOps」的等級，相信對於推廣 DevOps 一詞應該也有提供一些助力吧？ 新年新計劃，首先打算將簡報《DevOps: 建造開發維運的跨界之橋》的內容轉換成文章的形式，一方面讓簡報內容能更完整地被分享，另一方面也讓我有地方可以補充後續又吸收到的新內容。 DevOps：建造開發維運的跨界之橋 (@ C.C. Agile #37) 疑問？ 在開始聊聊 DevOps 之前，我們先來自問幾個問題： 你目前的職務範圍是 Dev、Ops 或你根本是跨職能，甚至是全端？ 你對 Agile、Lean 的熟悉程度？ 你看過《Continuous Delivery》這本書嗎？同時也問你對 Continuous Delivery 的熟悉程度？ 為什麼要問這些問題？其實答案很簡單，因為這些問題都與 DevOps 息息相關。 DevOps 這個詞的出現 What is DevOps？這個問題實在很難用三言兩語回答，既然如此，不如我們先從 DevOps 這個「詞」是從何處出現開始著手，也許了解了「詞」的來龍去脈就能替我們解答 “What is DevOps ?” 這個問題。 詳細的歷史淵源可以參考 iThome 的這篇報導《為什麼會出現DevOps？》，在正體中文的資料中，iThome 這一份內容整理的很詳盡。 簡易版的歷史淵源就如下圖所列，有幾個比較重要的事件： Agile 2008 conference, Andrew Clay Shafer and Patrick Debois discussed “Agile Infrastructure” 這可能是 “Agile Infrastructure” 被開始廣為推廣的開始，同時這也意味著在當時即有許多的人們在思考著如何讓 Dev 與 Ops 更密切的合作。 2009/06/23, O’Reilly Velocity, “10+ Deploys per Day：Dev and Ops Cooperation at Flickr” 延續 “Agile Infrastructure” ，究竟如何讓 Dev 與 Ops 能更密切的合作？想不到 Flickr 在 2009 年就做到了，Flickr 的經驗分享可以說是 DevOps 公開的第一先例。這場簡報撼動了許多人，包括上面那位來自比利時的大大 Patrick Debois，在他的中心種下了舉辦 DevOpsDays 的種子。 2009 - DevOpsDays Ghent in Belgium 於是同一年 Patrick Debois 舉辦了第一場 DevOpsDays，而活動後續的討論在 Twitter 上延燒，為了簡省字數，刪去了 Days，於是 DevOps 一詞正式出現。 2010 - Book《Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation》 延續讓 Dev 與 Ops 更密切合作的概念，接著《Continuous Delivery》也出版，讓這樣的想法更加被傳播也被印證這是確實可行的。 2013 - Book《The Phoenix Project》 最後著名的《The Phoenix Project》出版了。如果你覺得沒有實例無法說服你相信 DevOps，那麼看看《The Phoenix Project》也許是一個好選擇，雖然它只是一個虛構的故事，但卻很真實的呈現了一間企業的導入過程。 由上面的歷史淵源可以看見，DevOps 的出現並不是一個單一事件，同時也隱約能感覺到 DevOps 並不是一個全新的概念，反而是與許多我們已熟知的概念是息息相關。所以也有人說 DevOps 根本是新瓶舊酒，只是將許多舊觀念全部打包再套上一個新詞而已。...

延續去年的盛況，今年 iThome 再次舉辦了 Container Summit。當舉辦的消息剛釋出時，本來是沒有太多興趣的，是一直等到議程公佈，發現有邀請了數位國外講師，包含 Mesos、Rancher 及 DaoCloud⋯⋯等，才改變心意，立馬向公司申請公差決定要來好好朝聖一番。 這次的議程我覺得可以分成三種類型，分別是「大師推坑」、「觀念分享」及「就是來賣產品」。因此並非每一場都需要做詳細的筆記，有些場次只有幾個重點需要記錄，剩下的時間都是在欣賞講者的推坑功力，看看能不能順利讓聽眾們買單。 這次「小城故事不多-科技部」以團體戰術在第一時間就釋出了各場重點筆記，有興趣者可以直接參閱他們的兩篇筆記文，內含每一場的重點筆記。 https://smalltowntechblog.com/2015/12/10/ithome-container-summit-day-1/ https://smalltowntechblog.com/2015/12/11/ithome-container-summit-day-2/ 在這一次的 Container Summit 2015，iThome 依然邀請了葉秉哲（以下簡稱：葉大）為大家分享議程，這次葉大同樣帶來一場屬於「觀念分享」的題目「擁抱或對抗？談 Docker 對傳統 DevOps 工具鏈的衝擊」。 簡報已釋出，可直接線上瀏覽。 開場葉大先用幾則笑話調侃了一下 DevOps 的現況，基本上就是 DevOps 的定義問題、DevOps 涵括太多的領域及 DevOps 的工具種類與數量多而繁雜。 有鑒於 DevOps 目前的現況，因此若想要在一場分享中介紹這麼多 DevOps 相關的內容是不可能的，必須換個角度思考，只能針對有限的關鍵問題分享。 那麼到底在實際面上 DevOps 切身相關的問題是什麼？ 於是葉大借用了 Brian Brazil 在文章中提出的三個嚴肅的問題來回答。這三個問題分別是： How to recreate your system（如何重建你的系統 ） How to safely change your system（如何安全地改變你的系統） When something has gone wrong（你有辦法知道系統出狀況並解決它） 相信 Ops 一定會立刻認同這三個問題的重要性，因為不論是重新打造或修復重建系統，系統建立是 Ops 最基本的關鍵工作。 而系統建立之後，還會遇到需求變更或軟體升級⋯⋯等原因導致系統必須被改變。 最後即便放了綠色乖乖也不代表系統永遠不會出問題，因此系統監測絕對是第三項不可缺少的關鍵項目。 可以說對 Ops 而言若想要提供一個穩定的系統，這三項是絕對逃不了的關鍵問題。所以在談更多 DevOps 的內容之前，不如先好好的討論這三個問題。...

接續同系列文章《Agile Tour Taipei 2015 筆記與心得》，本文繼續記錄 Agile Tour Taipei 2015 下午的議程筆記與心得。 下午選擇的是 Track 2，當時在午飯時間苦惱了一陣子，雖然一度很受到 Track 1「How to apply Agile to Growth Hack - Someda Takashi, 染田貴志」的議題吸引想要先聽 Track 1 再換場 Track 2，但 Track 2 的場地視野不佳、座位也少，考慮到換場一定搶不到好位子，因此最後整個下午都留在 Track 2。 邁向 Scrum of scrums - 杜秉穎 講者簡報已經釋出，可以前往線上觀看。 下午第一場是「邁向 Scrum of scrums - 杜秉穎」，但必須要先自首，因為精神不佳，在這場議程中一度陷入昏迷，所以記錄到的內容超少。 這場議程在劇情上是接續上午「如何在組織內有效引領敏捷變革 - 蕭存喻」的案例，也就是遊戲橘子內部的敏捷變革經驗分享。 首先講者向聽眾問了幾個問題： 團隊類型？ 是新創、公司自開發產品、接外包或其他。 團隊規模？ 5 ~ 50 以上是落在哪一個區間。 開發方法或流程？ 是 Waterfall、Being Agile、Doing Agile或自以為 Agile。 透過問題開場之後，講者開始進入正題，前面的題目也是講者在爲自己鋪梗，因為講者所處的團隊正是經歷由小變大與持續引入敏捷變革的過程。 在他們持續引入的中途遇到了一個狀況，即是乍看之下「團隊好像很 Agile」，感覺該做的都有做 (testing、CI、CD)，但隱約還是感覺有些問題，例如會議時間很長、沒效率且難以達成共識、對 sprint failed 好像沒感覺又好像很害怕。因此驅使他們決定新一波的敏捷改革。...