亞洲首次的 Ruby on Rails 年會 – Rails Pacific 大會 9/26-27

由 xdite 主辦的 Rails Pacific 年會即將於 9/26-27 展開，目前還在售票中。講師陣容很強大，看得出來是一場國際化導向的專業研討會，最近的技術研討會真是越來越專門啊。

小弟也受邀有一場 45 分鐘的演講，主題是 Exception Handling – Designing Robust Software 例外處理和強健的軟體設計。

In a perfect world, every method call succeeds, users enter correct data and resources are accessible always. But the real world is brutal and failures happen. You will be miserable if you fail to design your software for a production environment.

In this talk, I will explore how to design robust software, the exception handling mechanics of Ruby and Rails, bad smells and best practices of exception handling.

寫 Ruby on Rails 也好多年了，從初學到研究進階用法、從會動到寫的漂亮，最近比較多的痛苦體悟則是在 production 環境上的一堆鳥事考驗。希望這場 talk 可以分享一些 Ruby 例外處理的技巧和錯誤處理的策略，進而達到強健軟體的目的。

ALPHA Camp 10週網路事業實戰營 10/6 開課

ALPHA Camp 是一間很特別的創業學校，跟創辦人 Bernard 聊過之後，我很喜歡他們的辦學理念，既不是電腦補習班，也不是育成中心，甚至還會面試篩選學員。來這裡不一定是因為要創業，而是學習如何將點子實作出來的完整能力，非常適合渴望換跑道進入網路產業的朋友。

我之前也有開過不少次 Ruby、Rails 或 Git 的教學，但都是非常短期一天或兩天的課程。這次有機會能擔任 Web Development Bootcamp 這一班的班導師，在長達十週 full-time 的時間裡，希望不只教會學員 Ruby/Rails 等程式設計的技能，也希望能夠分享好的軟體工程和團隊開發文化。

週四(9/11)晚上還有最後一次的課程說明會，有興趣的朋友可以來聽看看。

SSH agent forwarding 的應用

SSH agent forwarding 可以讓本地的 SSH Key 在遠端 Server 上進行轉送，也就是當你需要在選端 Server 上使用 SSH Key 時，就不需要將你的 key pair 手動複製到 server 上，是個暨方便又安全的作法。

舉例來說，首先 SSH 登入進 Server1，接著在 Server1 上登入 Server2 時，就會自動使用你本地的 SSH Key：

Local ---(SSH)---> Server1 ---(SSH)---> Server2

那要怎麼使用:

首先需要將要 forwarding 的 private key 加到清單裡面:

ssh-add

用

ssh-add -L

可以檢查這個清單。接著：

方法一：每次要 Local 連上 Server 時，加上 -A 參數：

ssh -A user@{you server1 ip}

方法二：修改 ~/.ssh/config 設定，加上 ForwardAgent yes，這樣就不需要每次連都加上 -A 參數。例如

Host server1
  HostName 106.187.36.122
  ForwardAgent yes

實務上有什麼應用呢? 這裡舉兩個常用的例子：

Bastion Host

在 AWS 的架構課中，每次講 VPC 就會提到 Bastion host 的概念，也就是整組內部網路只開放一台 server 可以從外部做 SSH 連線，如果需要 SSH 連線其他機器，都必須透過這一台 Bastion host 轉過去。這樣做的目的當然是為了安全性，我們可以特別加強這一台 Bastion host 的安全，例如鎖外部 IP 或是裝 SELinux 等等，這一台的用途就專門只做 SSH 連線，畢竟越簡單越容易防護，更細節的 OS 防護原則可以參考 OS Hardening Principles。

既然 SSH 連線都必須透過這台 Bastion host，那麼 SSH agent forwarding 這招就很好用了，就不需要、也不應該把 private key 放到 Bastion host 上面。

Git Deployment

如果你有用 Git 版本控制系統的話，你的應用程式佈署也很可能需要在 Server 上把 Source Code 從 repository 拉下來，這時候就會需要 SSH 的權限。

以前小時候不懂事，總是在 Server 上生出一組部署專用的 SSH key pair，然後在 Github 上設定這組 key 可以讀取 repository。後來發現這完全是多餘又增加安全風險。既然有權限佈署，那麼也就表示你應該就有權限可以讀取 source code，那就用你自己的 SSH key 就好啦，就不需要在 server 上擺一組 SSH key pair 了。

如果是用 Ruby 的 capistrano 做部署的話，只要設定一下就可以了：


set :ssh_options, {
  forward_agent: true
}

這樣在佈署程序中就會用到你自己的 SSH key 去 Github 拉 source code 了。

參考資料

談 Git 的開發流程

很高興受邀參加『FED Party 10』GIT的develop與master 論壇成為與談人。其中「協同開發時，master 與 dev branch 如何規劃?」這個問題是我主要講述的部份，分享了團隊用 Git 的開發流程經驗。

2010 年的 GitFlow 是一個很好的開始，它提供了一個很清楚的開發流程，幾乎可說是目前用 Git 的「標準開發流程」。不過流程的目的是為了幫助軟體開發和釋出，而不同團隊有著不同的需求，也就不可能有 “One size fits all ” 的解法。

撇開 Gitflow 比較囉唆(或者你要說它比較嚴謹?)的流程，我認為最大的問題(或天性)是它比較適合搭配 Iteration-based 流程(一批功能完成才進行釋出、週期性佈署)，而不是 Kanban 流程 (一個功能完成就進行釋出、每天多次佈署)。怎麼說呢?

假設團隊這次 iteration 同時在開發 A,B,C 三個 features。在 GitFlow 之中，我們通常不會一個 feature 寫好就開 release branch，而是會等到 A,B,C 都完成了，在一起開 release branch 跑 CI 上 staging server 一起測試。這時候問題就來了，如果 feature A 測試有問題，即使 B,C 沒問題，整個 release branch 也會卡住無法釋出。這一卡可能又拖了好幾天…

理想的 Kanban 流程會希望一個 feature 完成就能推上 production 釋出。這時候 release branch 的設計就顯得礙手礙腳了。那要怎麼達到一個 feature 可以單獨釋出呢? 首先你會需要多重 CI 和 staging servers 的環境。每新開一個 feature branch 就會有各自對應的 CI 和 staging server 可以進行測試，這樣只要該 feature branch 測試完成，就代表可以合併回主幹進行釋出動作。話說回來，這其實就是 GitHub Flow 流程。

實務上，你也可以預先開好數台 staging 機器，然後讓開發者可以佈署 feature branch 上去進行QA測試。這樣就不需要辦到隨時動態開 staging 機器的技術能力。

如果 staging 機器真的有限制只能開一台，另一個變形作法是有一個專門的 staging branch，需要上 staging 機器進行測試的 feature branch 就合併進 staging branch 進行佈署。但是注意到這個 staging branch 並不會合併回主幹，它是永遠平行的。也就是說 staging branch 上可能包含 A,B,C feature branchs，當 feature B 在 staging 上測試完成，就合併 feature B branch 回主幹，而不是 staging branch。這算是一個 workaround 的作法，我們公司就有團隊就採用這個作法，也非常實用。

總之，無論採用何種流程，我的重點在於必須一併考慮如何搭配 CI、Code Review、手動 QA 測試等等整套軟體釋出流程，才是通盤的考量。

參考資料

講個秘訣：加快 git pull 和 git push 速度

SSH 有個功能是可以沿用已經存在的 host 連線，如果再連一次就會比較快。首先編輯 ~/.ssh/config 加上：


ControlMaster auto
ControlPath /tmp/ssh_mux_%h_%p_%r

接著讓我們一直掛著 GitHub 的 SSH 連線……


ssh -N [email protected]

讓我們實驗看看效果如何：

使用前：


> time git pull

real	0m3.117s
user	0m0.055s
sys	0m0.045s

使用後：


> time git pull

real	0m0.765s
user	0m0.037s
sys	0m0.042s

嗯，效果非常好。

出處：GitHub hack: speed up git push and git pull

Systems Operations on AWS 課

這禮拜去參加 Systems Operations on AWS 課程，上課的範圍其實跟上次的 Architecting on AWS 很接近，重點跟細節程度有些差異，操作 Labs 更多有九個，而且不少是用 CLI 操作而非 Management Console。上課也比較注重操作細節，連投影片字也比較多… XD

第一天教 VPC 跟 EC2，Lab1 是操作設定 Public Subsnet+Private Subnet+IGW+NAT，不像上次的課用 Wizard 設定，這次需要一個一個設定進行操作。 Lab2 練習用 AWS command line (CLI) 開 ec2 機器。

第二天教 EBS, Tagging, Monitoring, Backup 等等。Lab3 用 CLI 操作 EBS Snapshot、EBS Prewarn、合併兩個 EBS 成更大的 Logical Volumn。Lab4 用 CLI 操作 Tagging。Lab5 設定 Custom Metric 到 CloudWatch，並設定 Custom Alerm (這可以用來搭配 Auto scaling)、練習整合 Auto scaling 和 3-party Monitoring 工具(當新增或移除機器時，會通知 Monitoring server)。Lab6 則是資料庫的 Backup&Restore，使用 EBS Snapshot 和 RDS 不同方式練習。這裡它特別強調 Consistent snapshots 的概念，需要 pause write 和 flush to disk 並鎖住 DB 才作 Snapshot。Lab 7 是一個用 CLI 抓 RDS 重設密碼事件的小練習。

這一天最大的收穫應該是了解 CloudWatch 可以做 Custom Metric，以來它可以用來搭配 Auto Scaling 使用，以及如何整合 3-party monitoring 工具。

第三天教 Log 管理(因應 Auto Scaling，所以 Logs 有集中管理的需求)、Auto Scaling 跟 Cost 管理。Lab 8 練習設定 Logrotate 把 logs 傳到 s3，以及在 Auto Scaling 的情況下，記得關機前傳 log。Lab 9 練習建立一個 Auto Scaling 環境，也是一樣有一個做好的 PHP 會模擬操 CPU，然後就 scaling 自動開機器。這個練習跟上次上課的很像。最後還有一個不是 Lab 的練習是分析一個 Cost 成本 Excel 表。

對了，我會建議上課記得帶個平板 iPad，他的講義有 App 可以離線閱讀。這樣 Lab 操作時就可以邊看邊操作。