CoreOS應用程序容器規范獲得谷歌、Apcera和紅帽的支持

......公司和個人都聚集在一起，確保應用程序容器有一個明確定義的規范，提供指導，以確保堆棧之間的安全性、開放性和模塊化。

這對于Kubernetes項目和更廣泛的容器社區來說，都是向前邁出的重要一步。這為容器的表達力添加了靈活性和選擇，也為Kubernetes開發者帶來了令人信服的新的安全性和性能的保證。

盡 管Apcera的HCOS還繼續是關于安全性和政策，但是Kurma是基礎的容器環境，作為HCOS部署的基石，可以提高運行效率。AppC對我們變得有 吸引力，[......因為......]象網絡本身、圖像發現、圖像驗證和加密、以及應用程序標識這些都是我們關心的議題

這組新的維護人員帶來了各自獨特的視角，使appc成為真正的協作。

Boulle： 自從我們最初開始開發appc規范和rkt，我們就與Apache Mesos的團隊保持密切聯系－－既有在Mesosphere本身的，也有在推ter的，那里也有很多核心的開發工作。他們提供了很多有用的意見，同時也在Mesos本身內部積極地致力于該規范自己的實現。這正好符合他們傾向于把功能集成到Mesos核心中的架構模型。這也恰好是我們試圖要用該規范實現的絕佳例子：明確定義的標準，又有各種不同的、可互操作的實現。把appc直接包含到Mesos的核心中，這意味著所有在Mesos平臺上運行的框架 －－Mesosphere的Marathon、Apache Aurora和其它框架－－都可以利用它了。

我們也在積極地與其它集群管理框架產品討論與appc和rkt的集成，敬請關注！

Boulle： 當最初開發這個規范時，我們特意對這兩個方面保持無關－－特別是網絡，這是個異常復雜的話題，因為每個環境都有其獨特、深奧的要求。我們不想在規范中過多地規定這些，所以我們只是保持在一個很簡單的水平上，只是說運行庫需要為應用程序容器提供可用的第3層網絡接口。

隨著我們自己開始實現規范的工作，我們很明確地需要找到一個具體的網絡解決方案，既要能夠用于rkt，又要能夠提供滿足這些不同需求的靈活性。為此我們與社區（他們提供了很多非常有用的信息！）協作，制定了一個基于插件的網絡提案－－基本想法是，可以開發獨立的插件，與各種不同的網絡后端接口，從云供應商的技術，到最新的 Linux內核功能，比如ipvlan。我們的網絡大師Eugene，也是flannel項目背后的主要開發人員，隨后實現了這個網絡功能，并把它集成到 rkt之中。

但是隨著rkt網絡提案的成熟，來自社區的關鍵反饋之一是，這似乎是超出rkt本身以外的處理網絡更加普遍有用的方式。同時我們開始聽到行業內其他人的聲音－－象紅帽的OpenShift工程師，以及谷歌的Kubernetes團隊－－他們也有興趣嘗試用于他們的項目的、類似的基于插件的解決方案。

你也許知道，在CoreOS這里我們是開放、通用標準的鐵桿粉絲，看到行業內有這樣對看起來可以共享的東西的強烈需 求，促使我們想要為此做些什么。如果我們能夠合并為一個共享的標準，并充分利用通用的、可以互操作的資源，這對整個行業和容器生態環境的成功都將產生難以估量的作用。所以我們最近創建了我們最初稱之為容器網絡接口(CNI，Container Network Interface）的東西，這是一個為Linux上的應用程序容器定義網絡插件的規范。雖然現在我們決定把它發布在GitHub上的appc組織之下， 但是這和appc規范本身完全不同，而且適用范圍要小得多（就說一點，這是很明確的針對Linux的，而appc規范是要跨平臺的）。我們在積極地與谷 歌、紅帽和思科以及社區的其他成員合作，充實規范，并有希望能夠很快達成一致，這樣我們就可以開始把它集成到不同的項目中。

我想強調，雖然這還是一個建議中的規范，很大程度上還處于制定階段，不過我們已經有了一些獨立的具備完整功能的插件了，還有其它幾個正在在積極地開發。實際上，我們已經 非常成功地把rkt本身遷移到使用CNI插件，而且在剛剛過去的幾天中我們已經有一個社區成員為ipvlan添加了插件。

至于存儲，這是我們還來不及有時間專注于其中的領域。現在我只能說，只要有可能，我們希望能夠站在那些從事大型分布式系統的巨人的肩膀上－－象Kubernetes和Mesos－－利用他們的專業知識和經驗，回饋到規范中。

Boulle： 在CoreOS，我們集中精力于建設良好定義的、高效的和高度可組合的組件，我們盡力使它們盡可能的可移植。我們肯定能夠在嵌入式設備或物聯網領域看到容器的一些有趣的應用。社區對這個領域有很大的興趣：我們已經有用戶在ARM設備上使用rkt和appc進行了嘗試，為此我們最近在appc認可的標準架構 集合中添加了ARM v7和v8的架構。因為ARM的生態系統在歷史上就是個很多樣化的架構集，在象Linux那樣的實現中對命名有一些分歧，我們很注意我們做這件事的方式是 正確的，所以我們與ARM的工程師一起工作來確保我們使用了適當的命名。

至于Windows，從一開始我們就希望appc是跨平臺的規范，我們很樂意看到微軟或者Windows社區的人進行實現。在發展規范的同時我們也很努力地實現無關性和可移植性之間的小心、務實的平衡，使規范的核心很通用，而又支持各操作系統特定的部分。

Boulle：appc 規范是開放的項目，我們邀請所有的公司－－真的是所有來自社區的人－－參與討論，并形成規范。任何為規范積極貢獻的個人都有資格被選為維護人員。重要的是，既然我們建立了管理政策，那么CoreOS就無法控制項目的命運，因為大部分維護人員來自（CoreOS）公司外部。

我們絕對歡迎 Docker團隊的工程師參與該項目。開始顯然可以針對規范的當前狀態提出反饋，以及那些對Docker項目不太好的地方，然后可以與現有維護人員一起解決規范中的這些問題，為最終在Docker引擎本身中實現appc的支持而努力。現在有好幾個appc運行庫的實現處于積極開發的狀態－－包括 jetpack、kurma和rkt－－我們已經知道我們能夠共同商定一個規范，協調一致地開發功能各自獨立的實現。所以，再多一組工程師實現規范，參與討論，使之制定得盡可能的完善，這當然是令人歡迎的進步。

我們的目標是形成一個社區，大家都希望看到容器以各種可能使用的創造性的方式達到成功，并確保有一個共同的標準，以滿足所有人的需求。

Boulle： 我要說，我們感到吃驚，因為我們強烈地認為，我們對容器生態系統的總體目標是一致的，我們是希望公開地解決這些問題，并能夠合并成一個共同的解決方案。我們本來可以在第一個拉取請求（#10776）上說得更清楚，更明確地表達，這是一個單純的概念證明，用來指導你提到的問題（#10777）中的討論，并展 示我們是愿意貢獻代碼的。不幸的是，代碼成了焦點，而不是我們希望促進的討論。所以我們不得不承擔一些我們沒有從一開始就盡可能清楚表達的責任。

Boulle： 盡管容器這個領域尚處于（發展的）初期，我們還是相信某些問題在當前的多個實現中是可以標準化和共享的，這些就是我們試圖在appc規范中定義的。圍繞映 像格式、環境、命名、發現、版本控制、壓縮和加密的問題都是熟知的領域，可以由一組工程師獨立實現，分開討論。

在這些問題上達成共識意味著，應用程序開發人員可以寫一個appc容器的映像，在遵循該規范的任何地方運行。這是為什么在容器標準上達成一致是重要的的一個主要原因：使開發人員的工作更輕松，讓他們可以使用各種工具以共通的格式互相操作。然后，要在生產環境中運行軟件時，運營工程師可以選擇任何遵循規范的運行庫，并確信應用程序會 按照預期的方式運行。

的確，現在試圖把容器化的基礎架構相關的一切進行標準化——特別是當這個領域還是如此新興時——會是困難的或者甚至是 不可能的。但是appc并沒有打算把運行庫或網絡這樣的東西標準化到細枝末節。與虛擬機這樣的技術相比，容器包括一系列的實現決策，在規范中我們把這些抽象到更高的層次。我們打算保持appc規范的通用性，集中于當前的領域；象對外的API、資源層次結構的管理、網絡的實現，等等，都肯定超出范圍了。

Boulle：CoreOS 秉持“早發布，常發布”的理念，而且rkt仍是一個早期項目。說了這些，我們還在努力工作，讓它達到我們有把握地認為是適合生產環境的階段。有一點要注意，在v1.0之前，我們故意讓rkt的主/次版本號落后于規范的版本號（明確它要實現哪個版本），所以rkt的發行版本號并不能代表它開發或成熟的進度。這也明顯地意味著rkt依賴于規范的穩定，直到我們可以宣布1.0版本！

至于規范本身：隨著最近任命CoreOS以外的其他維護人員， 我們現在有了其他人的共同幫助來使它完善。最近幾周可以看到來自這些新加入的貢獻者的顯著進展，而且我們開始非常專注于達到1.0版本所必需的東西。當我 們達到這一里程碑時，這將是基于管理委員會的維護者以及更廣泛的appc社區的共同努力。