Galley：為基于Docker架構的本地開發與測試提速
現如今，Docker已經成為了很多公司部署應用、服務的首選方案。依靠容器技術，我們能在不同的體系結構之上輕松部署幾乎任何種類的應用。在洛杉磯時間2015年10月21日于舊金山展開的推ter Flight開發者大會上，來自Fabric的工程師Joan Smith再次談到了這一點。
她提到，盡管我們在部署應用的時候將容器技術應用得淋漓盡致，但是在開發和測試的時候還是面臨著很多問題。在從前，她所在的團隊的本地開發方案是用Vagrant和Chef來支撐的。Vagrant是基于虛擬機的一套本地開發方案，而Chef是一套IT架構自動化部署方案。
Joan認為，使用類似Vagrant、Chef的方案來部署本地開發方案會很浪費開發時間（Engineering Time）。她的理由主要有三點。
第一：微服務盛行。這一趨勢的直接影響之一就是，每個服務自身的配置會不斷變動，互相之間的依賴關系也會不斷變動。今天的一個服務，明天就可能被拆分成三個服務。那么，如果你要在本地啟動開發環境，那么你就需要知道所有服務之間架構的信息才能夠讓應用在本地跑起來。
然而大部分時候，我們在開發一個服務的時候是不需要知道整個架構的。例如，當我們在測試下圖中www和www-db之間的一些功能的時候，我們其實根本可以不用關心crash service是怎么樣的。
所以，更多時候在微服務的世界里，我們只關心我們應該關心的部分。對于不關心的部分，例如crash service，我們有一種方案就是可以用Mock來代替它。
第二：Chef之類的架構自動化部署方案是疊加式（additive）的。往你的現有架構上面加東西很容易，但是想要拿掉一些東西的時候就很困難。
第三：在持續集成的環境中，Vagrant不具備可擴展性（Vagrant on CI just doesn’t scale）。由于Vagrant是基于虛擬機的，在運行過一次CI上的Pipeline任務之后，虛擬機就會被污染（polluted），無法用于下一 次的任務執行。
基于對現有本地開發普遍方案的這些問題，Joan提出了她的看法：我們為什么不利用好Docker這個平臺，讓它在本地開發、測試的時候也能跟線上 保持一致呢？但是如果直接用Docker命令行來啟動應用，手動管理依賴，那么時間成本也很大。Docker Compose確實能夠勝任一次性啟動多個容器的任務，但是它依然不夠靈活。
隨后，Joan介紹了Galley，一個為本地開發、測試而設計的組合并協調（orchestrating）Docker容器的命令行工具。
她還風趣地提到，Vagrant的意思漂泊的，Chef的意思是廚師，而Galley的意思就是漂泊的廚師（原意是船上的廚房）。
Galley最大的優點就是能讓工程師在本地基于自己的代碼構建鏡像并運行，這些本地構建的代碼是他們當前在完成的特性所關心的部分；而對于他們不 關心的部分，例如上面提到的crash service，Galley則自動改用Docker Hub（或者私有的Hub）中已經構建好了的鏡像來直接運行。
Galley采用一個集中的Galleyfile描述整個應用的架構。Galleyfile是一個JavaScript文件，它的module.exports對象即為你所有服務容器的描述。例如下面就是一個合法的Galleyfile的例子。
module.exports = {
CONFIG: {
registry: 'docker-registry.your-biz.com'
},
'config-files': {},
'beanstalk': {},
'www-mysql': {
image: 'mysql',
stateful: true
},
'www': {
env: {
RAILS_ENV: {
'dev': 'development',
'test': 'test'
}
},
links: {
'dev': ['www-mysql:mysql', 'beanstalk'],
'test': ['www-mysql']
},
ports: {
'dev': ['3000:3000']
},
source: '/code/www',
volumesFrom: ['config-files']
}
};</pre>
在上面，我們定義了所有容器來源的Registry。一般情況下，這會是你自己公司內部的私有Registry。另外，我們還定義了四個容器 config-files、beanstalk、www-mysql和www。這四個容器都是在上面指定的Registry可以下載到的。
假設www容器是我們正在開發的服務，那么我們一般會用”galley run www.dev --rsync -s .” 命令啟動www容器，并且是在dev環境。在Galley里有兩個環境，一個是dev，一個是test。這時候Galley會為我們做幾件事情：
- 將source屬性指定的文件夾（在容器內）和當前galley run指定的目錄同步。Galley的支持使用rsync將源碼拷貝到Docker所在的機器中。這對于在Mac下開發的人們來說是個很好的特性，因為Docker的volume支持默認采用VirtualBox的Shared Folder功能，而這一功能的效率很低。
- links屬性中的dev屬性指明了在dev環境下www應用的依賴項。Galley會為我們將這些依賴的容器全部pull到本地并且啟動，并 自動和www鏈接在一起。在這里，Galley就會pull并link兩個容器，一個是www-mysql:mysql，一個是beanstalk。對于 在volumesFrom（對應Docker的volumes-from）指定的容器，Galley也會自動pull并部署。
- 應用環境變量。在這里，www是一個小型Rails應用，于是我們可以應用一些Rails應用的環境變量。
- 進行端口映射
</ol>
更完整的配置方法可以參考Galley的官方文檔。
我們可以注意到，在第二點中，Galley只會幫我們獲取我們當前開發所關心的服務，其他不相關的服務，Galley不會獲取并部署它們。
默認情況下，galley run每次都會重新創建我們當前正在開發的應用的容器。對于依賴項，在滿足一定條件的時候也會重新創建（見文檔）。我們注意到www-mysql容器是 stateful（有狀態的）的，因為它是一個數據庫容器。對于stateful的容器，Galley不會自動重新創建它們，保證開發用的數據不會因為重 新創建容器而丟失。
Galley另外一點很有趣的地方是可以創建附加項（Addons）。所謂附加項就是允許開發者通過命令行來手動指定一些容器的行為。這樣說很抽象，我們來看一個例子。下面是一段Addons的配置。
module.exports = {
…
ADDONS: {
'beta': {
'www': {
env: {
'USE_BETA_SERVICE': '1'
},
links: ['beta', 'uploader']
},
'uploader': {
env: {
'USE_BETA_SERVICE': '1'
}
}
}
}
…
}; 在用galley run運行的時候，加入-a beta參數，那么在ADDONS.beta對象里面的所有配置也會被應用。例如，在這里www服務就被應用了額外的環境變量USE_BETA_SERVICE，而且還應用了額外的link containers。
聰明的讀者可以猜猜，USE_BETA_SERVICE這個環境變量的作用是什么？啟動Mock模式！在前面我們提到，很多時候我們可以使用 Mock的方式來模擬一個正常運作的服務（一般是依賴項），從而我們最多只需要關注直接依賴項，而不需要關注依賴項的依賴項。當然了，從筆者本人的角度來 看，Mock這種方法并不是銀彈。即便如此，在一些情景下它也能縮小我們所要關心的范圍。
基于Vagrant開發的又一問題是，Docker的Vagrant配置是Hostonly網絡，也就是說你沒有辦法直接從除了你自己本地機器外其 他的地方很容易地連接到你的Docker容器。對此，Galley的進程還啟動了TCP Proxy，將發往本地機器端口的流量代理到Docker的Vagrant虛擬機，這樣即便你是在調試手機應用，也可以輕松、直接地訪問到自己的機器了。
最后Joan還展示了Fabric團隊自身使用Galley進行開發的示例，可以看到Galley確實在一定程序上極大地簡化了Fabric團隊本地開發和測試的工作流。
建議感興趣的讀者可以自己使用Galley體驗一下，感受它所帶來的方便和潛在的痛點。如果它確實在你自己的應用體系中能夠很完美地勝任協調本地開發、測試的容器依賴協調工作的話，那么何樂而不為呢？
來自： http://www.infoq.com/cn/news/2015/10/Docker-推ter-Flight
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！