與Linux、OpenStack等成熟的技術社區相比，Rancher社區還是處於初級發展階段，一個技術社區的成敗並不是單純的代碼貢獻，而學習文檔的數量和代碼管理作業流程也是非常重要的。如何讓懷揣不同需求的工程師都能在社區中快速找到相應的解決方案，這就需要大家協同合作共同促進社區發展與完善。除了我們所熟知的Rancher & RancherOS，Rancher Labs的開發團隊在實踐中提煉了很多實用的小工具，這些小工具雖然並不會左右Rancher發展的大局，但是在項目標準化和開發效率上給團隊帶來巨大的便捷。這次主要是帶着大家一起來認識一下這些小工具。
Golang包管理工具－Trash
項目地址：https://github.com/rancher/trash
目前主流的編程語言 Python、Ruby、Java、Php 等已經把包管理的流程設計的猶如行雲流水般流暢，一般情況下開發者是不需要操心類庫包依賴管理以及升級、備份、團隊協作的。Golang在1.5版本開始，官方開始引入包管理的設計，加了 vendor目錄來支持本地包管理依賴，但是需要特殊設置GO15VENDOREXPERIMENT=1，在1.6時代這個特性已經是默認的了。可是vendor並沒有統一的版本號管理功能，只是額外提供了project內包的依賴路徑。於是Trash這個工具就應運而生了，Trash的使用非常簡單，只需要有一份依賴包的描述文件即可。
描述文件 trash.conf 支持兩種格式，普通方式和YAML方式，可以直接在其中描述依賴庫的遠程地址、版本號等，一個簡單的例子（我這裏使用普通格式）：
然後在根目錄執行trash，即可獲得相關版本的依賴包：
非常輕量級，非常簡潔。
Golang編譯工具－Dapper
項目地址：https://github.com/rancher/dapper
我們在編譯golang執行程序的時候，因爲涉及到協作開發，這就會碰到一個問題，就是如何保證編譯環境的一致性。環境一致性最好的辦法就是使用容器技術，Dapper就是利用Docker build鏡像的過程中可以執行各種命令生成容器的原理。只需在項目的根目錄下創建 Dockerfile.dapper 文件，這是一個參考Dockerfile標準的文件，執行 dapper 命令即可按照約定規則生成最終的執行程序，通過這種方式統一的編譯環境。
幾乎所有的Rancher項目都是基於Dapper來編譯的，隨意打開一個項目比如rancher-dns就可以看到 Dockerfile.dapper 文件：
DAPPER_SOURCE 指定了容器內的源碼路徑
DAPPER_OUTPUT 指定了編譯後的輸出路徑，bin dist 目錄會自動在項目根目錄下創建
DAPPER_DOCKER_SOCKET 設置爲True相當於docker run -v /var/run/docker.sock:/var/run/docker.sock ...
DAPPER_ENV 相當於docker run -e TAG -e REPO ...
有一點需要注意的是，目前Dapper裝載源碼有兩種方式bind和cp，bind就是直接mount本地的源碼路徑，但是如果使用remote docker daemon方式那就得使用cp模式了。
Golang項目標準化工具 go-skel
項目地址：https://github.com/rancher/go-skel
介紹了包管理工具和打包編譯工具，如果我們在創建一個golang項目時能把這兩個工具整合起來一起使用，那就太讚了。go-skel就是提供了這樣一個便利，我們直接來demo一下。
clone一份go-skel的源碼，創建一個rancher-tour（./skel.sh rancher-tour）的項目:
執行完畢後，會創建一個標準的項目，包含了dapper和trash這兩個工具，同時定義了一份Makefile，我們可以通過make命令來簡化操作：
比如我們要執行一個ci操作，那就可以直接運行 make ci，自動運行單元測試，並在bin目錄下生成最終的可執行程序：
標準項目已經創建了一些初始化代碼，集成了 github.com/urfave/cli ，所以我們可以執行執行rancher-tour：
微服務輔助小工具 Giddyup
項目地址：https://github.com/cloudnautique/giddyup
一個傳統的服務在容器化的過程中，通常我們會將其拆分成多個微服務，充分展現每個容器只做好一件事情這樣的哲學。那麼就會出現我們在Rancher中看到的sidekick容器，數據卷容器，專門負責更新配置信息的容器等等。
實際應用中我們會遇到一些問題，比如這些微服務容器的啓動是無序的，無序啓動會導致微服務之間可能出現連接失敗，進而導致整個服務不可用；再比如我們如何來判定依賴的微服務已經正常啓動，這可能需要一個health check的服務端口。giddyup就是簡化這種微服務檢查工作的利器，它都能做些什麼呢：
Get connection strings from DNS or Rancher Metadata.
Determine if your container is the leader in the service.
Proxy traffic to the leader
Wait for service to have the desired scale.
Get the scale of the service
Get Managed-IP of the container (/self/container/primary_ip)
我們還是創建stack並在其中創建service來體驗一下giddyup的部分功能，service中包含兩個容器分別爲主容器main和sidekick容器conf，他們共享網絡棧：
我們可以在conf內啓動giddyup health，會啓動一個監聽1620端口的http服務，服務路徑是/ping：
此時我們可以在其他服務的容器內查看這個服務 health port的健康狀態，通過giddyup ip stringify獲取服務地址，使用giddyup probe可以查看相關狀態：
可以看到probe返回了OK的信息，說明giddy/main的health port是正常的，如果我們把giddyup health的端口停掉，giddyup probe會如何？
除了開啓health port功能外，還可以sleep等待service內所有容器都啓動，比如剛纔的service，我在main上做wait操作，同時在UI上對service擴容，可以看到爲了等待完成擴容差不多sleep了3s：
更多功能可以去看一看giddyup項目的README文檔，另外也可以看看catalog中的一些項目是怎麼使用giddyup的，參考：https://github.com/rancher/catalog-dockerfiles
Rancher CLI 工具
項目地址： https://github.com/rancher/cli
現在我們管理Rancher的方式包括UI、API方式，爲了能夠和其他工具更好的融合Rancher開發了CLI工具，可以非常輕量級的嵌入到其他工具中。CLI將會在Rancher 1.2-pre2版本中正式放出，兼容性上目前來看沒有支持老版本的計劃，所以在老版本上出現各種問題也是正常的。
直接在 https://github.com/rancher/cli/releases 下載最新版本即可試用，將rancher cli放到PATH中，正式使用前需要初始化：
然後便可以執行各種犀利的操作，比如針對某個service進行scale操作，這比之前需要用rancher-compose cli要簡潔的多：
再比如可以實時監聽rancher events，可以即時查看Rancher中正在發生的各種任務，對協助排查問題，分析系統運行情況都非常有用：
後語
小工具中內含着大智慧，工具文化是工程師Team高效協作的重要標誌，高質量的工具能讓項目開發有事半功倍之效，其背後也蘊藏着深厚的團隊文化理念，就是不計項目KPI利用個人業餘時間爲團隊做貢獻的和諧氛圍。其實國內很多互聯網公司都是有專門設立工具開發工程師的崗位，對工具帶來的生產效率提升，其重視程度不言而喻！
原文來源：Rancher Labs