當Docker開展的18個月前，我們就開始了一項任務，以建立“按鈕”的方式，可以使任何應用程序立即持續的運行在任何地點的任何服務器上。
我們的第一個任務是定義一個標準的容器格式，將任何應用程序打包在一個輕量級的容器中，可以讓它運行在任何的基礎框架上。
正是有很多的辛勤工作者參與到了Docker的整個社區，Docker的功能才會變得很強大，我們可以做出一些比較成功的Docker容器，讓其可以運行在所有主要的基礎設施上；因此，我們建立一個強大的生態系統，包括：
超過700個投稿人（其中95%人沒有工作于Docker.Inc.）超過65000個自由dockerized語言、框架和應用程序（服務）支持每個主要DevOps的工具、公共云，和所有主要的操作系統第三方工具建立在Docker一個強大的生態系統上。現在有超過18000個項目在GitHub上標有Docker標題在40多個國家，有超過175個以上的關于Docker的聚會團體Docker用戶已達數百萬在這個過程中，我們構建了一個健壯、開放的設計和治理結構，可以讓用戶、供應商和貢獻者來幫忙指導 Docker 項目的發展方向。
在過去的九個月，我們對 Docker 進行拓展，使之超出餓了一個簡單容器的范疇。不過 Docker 繼續定義著單一容器格式。很明顯，絕大多數我們的用戶和貢獻者以及供應商都希望 Docker 可以支持在運行在多個主機的多個離散容器中分發應用程序。
我們認為，當我們轉向一個多容器、分布式應用的世界時，單個Docker容器應用的簡單、開放的接口，無論何地的可移植性，健壯的生態工具集如果丟失，將是非常令人遺憾的。因此，我們一直在推廣更加全面的編排服務集(set of orchestration services)，涵蓋網絡、調度、組合、集群等功能。更多細節可以在這周阿姆斯特丹舉辦的 DockerCon上獲取到，其中一些設計點值得注意：
多容器編排能力(multi-container orchestration capacibilities) - 與容器標準本身一樣，這種能力應該由基于社區和生態系統內的協作和反饋的開放設計流程(open design process)創建。這些編排功能應該通過開放API來分發，使用開放設計流程進行公開開發這些能力不能是單一龐大的(monolithic)。每個人都應該可以自由使用、修改，或者不使用這些服務及其高層API這些能力和API應該支持插件(plug-ins)，這樣大家可以選取最適合自身情況的調度、集群、日志或者其他服務，而不應該犧牲可移植性，跨基礎設計工作的能力，使用65K+ Docker化的應用或者基于Docker的18K+工具的能力。這個插件模型在執行引擎(比如libcontainer, LXC)和文件系統(BTRFS, 設備映射/device mapper，AUFS,XFS)下工作的非常好。期待下這周更多的發布說明吧。當然，不同的人對開源項目如何開發有不同的看法。如上文提到的，絕大多數的用戶、貢獻者、生態系統內的廠商都希望這個項目支持標準的、多Docker容器的分布式應用。很多廠商，無論大小，都歡迎并正在為此貢獻努力(關于Docker開放治理的更多信息，查看下這篇文章)。
我們仍致力于生態系統內的用戶、廠商和貢獻者。無論大家向Docker貢獻的形式，是作為構建Docker容器格式的獨立項目，還是作為Docker編排API的插件，或者其他形式，我們都希望開放、分層的方法都能給全部相關者提供選擇。但是，一小部分廠商不認可這個方向。有些表達了他們的擔憂，當Docker擴大適用范圍，他們創造差異化、增值業務的空間就變小了。某些情況下，這些廠商甚至希望創建為他們特定基礎設施或業務量身定做的編排方案，因此不歡迎可移植性的概念。當然在另外一些情況下，會有些技術性或者哲學意義上的區別，這些區別看上去與Rocker最近的發布聲明有關。我們希望能在后續的文章中解釋Rocker項目帶來的一些技術爭論。
這里，我們要強調這只是一個健康的，開源過程。就像 Docker 是開源的，并遵守Apache開源協議，人們可以自由使用，修改，或者為了自己的需求進行改造。他們可以只把Docker作為一個簡單的容器。他們可以自由的將更高級別的服務加入到Docker。當然他們也可以自由的推廣另外一種概念作為新標準，就像Rocket團隊已經做的那樣。
盡管我們不同意一些質疑、爭論以及Rocket發布時間，我們希望我們能繼續以用戶和開發者的利益作為我們的共同的導向。
原文鏈接：http://www.oschina.net/translate/initial-thoughts-on-the-rocket-announcement
京公網安備 11010502049343號