Posts

在之前的文章有稍微提過，目前個人在 Synology NAS 上透過 Docker 架設了許多服務，也算是累積了一些在它上面使用 Docker 的經驗，此文將簡單的記錄一些 Synology NAS 上有關的 Docker 兩三事。 安裝與使用 要在 Synology NAS 上安裝 Docker 非常容易，直接在 Synology DSM 後台的「套件中心」安裝即可。安裝成功即可看到 DSM 中多了 Docker 的 GUI 可以使用。 個人覺得 Synology 做出來的 Docker GUI 其實滿好用的，私心希望他們能將它改寫另外打包成 opensource 釋出。 在 DSM 安裝完 Docker 之後，除了可以透過 GUI 的方式操作 Docker，若你 SSH 登入 NAS，會發現也可以直接在 SSH 中使用 Docker 指令。個人後來要啟動新的 Container 時，幾乎都是直接 SSH 登入，在 command line 中輸入 Docker 指令。 Docker 版本與相關檔案位置 NAS 若是安裝 DSM 5.2，則安裝的 Docker 版本會是 1.6.2。如果最近有升級到 DSM 6....

除了 Jenkins 之外，個人排行第二感興趣的 CI Tool 是 GitLab（GitLab CI 在 GitLab 8.0 之後合併至 GitLab CE/EE）。個人目前被 GitLab 所吸引的地方是它的「單純與便捷」，如同有些人說 Jenkins 太囉唆了，Jenkins 在使用上可以設定的細節超級多（雖然你不一定每一項都會用到）；相較之下 GitLab 單純且便捷，彷彿只要在程式碼中多加一個 yaml 檔即可設定完所有 CI 流程與動作。 但，真的有這麼簡單嗎？ 所以當然要實際架設來玩玩看，才能做出更多的判斷。 2016.11.4 補充，確實就是這麼簡單，GitLab 確實是目前熱門的 CI Tool，功能越趨完整，雖然難免開始肥大化，但是未來發展不容小覷。 另外此文已經有部分過期了，建議各位閱讀之餘，還要對照最新的文件，避免有誤！ 用 Docker 架設 GitLab 現在 Docker 如此盛行，要架設服務最簡單的做法就是先上 Docker Hub 搜尋現成的 Docker Image。GitLab 這種熱門專案當然不意外，一定會有現成的 Image 可以直接取用。在社群朋友的推薦之下，即找到下面這個優質的 Docker Image。 https://hub.docker.com/r/sameersbn/gitlab/ 印象中這個 Docker Image 的作者 sameersbn 是 Docker 圈內的大神之一，除了 GitLab 之外，他也做了其他很多優質的 image，大神出品，品質保證，選用他的 image 准沒錯！ 大神做出來的 Docker Image 備有非常完整的使用說明，根據 Quick Start 的說明，可以直接使用作者貼心的準備的 docker-compose....

在 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 根本是新瓶舊酒，只是將許多舊觀念全部打包再套上一個新詞而已。...