在上次推送的文章中(傳送門),田琪老師分享了他的DockerCon 2015峯會見聞。在「QCon高可用架構羣」中。田老師分享以後,幾位專家也參與了討論。docker
他們是:markdown
- 閆國旗:京東資深架構師,京東架構技術委員會成員,負責京東雲基礎服務建設。也參加了DockerCon 2015峯會。
- 王淵命:技術極客,協做IM服務@Grouk聯合創始人。也是Docker深度實踐者。
- 陳飛:微博資深架構師,微博平臺Docker容器項目負責人。
首先,閆國旗也分享了他的參會感覺:網絡
此次DockerCon 2015主要環繞着這四慷慨向:開發平臺、擴展、開放標準和商業支持。架構
詳細而言:app
開發平臺如田大師前面提到的內容。回想近兩年Docker在這一方面的努力,及一些產出。框架
Docker Container/Docker
Registry/Docker Compose/Docker Machine/Docker
Swarm等。分佈式這些產品事實上在去年都已上線。事實上咱們你們都也瞭解,本質上Docker的優點就是生態。所採用的技術都是各平臺所提供的,充其量在這裏Docker僅僅能算一個「服務編排者「的角色,固然這個比喻可能不是很是恰當。工具
沒有技術競爭力。被替代的可能性就會很是高,正像Docker同CoreOS的競爭同樣。在這裏都沒有太多的話語權。也許正是因爲如此,纔會走向開放之路。Docker將本身的runtime貢獻給了runC項目,將appc合併進OCF。post
表面看起來是走向融合,但本質上怎樣。Solomen和Alex也許會有不少其它的感觸.ui
只是Docker令我我的最不爽的就是Projet
Orca項目。基本上把會場外面那些基於Docker的創業公司逼向絕路。這是我的最不喜歡的地方。在DockerCon
2015會後,咱們也有幸前往CoreOS的公司作了技術交流。對於Docker向CoreOS隔空喊話。他們也僅僅能表示」呵呵「。
微博平臺Docker容器化項目負責人陳飛也談了他的見解和感覺。
此次DockerCon,以前也僅僅是經過PPT有些簡單瞭解,今天田大師分享後。收益頗多。
如下,談談我的粗淺的感覺:
一是Docker的擴展機制。這個仍是挺激動人心的。剛纔田大師也提到。眼下已經有network plugin和volume
plugin走在前面了。相信你們在這塊是比較糾結的,一方面Docker自己可能不能知足一些場景。需要作一些定製擴展,假設改它源代碼的話,可能會形成與社區脫節的問題,相信有了這個機制,興許擴展會更加方便。
二是Open Container
Project。在必定程度上「應該」會避免容器runtime標準的分化。之後應該可以放心來作容器的調度管理。而不用操心某一天底層執行時鬧革命。只是感受是各家貌合心不合。
三是Shopify使用DNS來作服務發現,以及libnetwork的進展。只是libnetwork提到服務發現會是其基本功能。也是基於DNS實現的,很是cool。只是感受它是否是有點想多了。
另外一個就是此次大會,貌似沒有提Mesos和Kubernates。記得上次大會有提到Swarm和Mesos會有一個親熱接觸,不知道現在進展怎樣了。
大規模集羣調度管理,Swarm仍是處於pre-production的狀態。Docker攻克了單機namespace,cgroup等容器技術組合的複雜性問題,集羣技術怎樣簡化,這裏機會應該蠻多。
Grouk聯合創始人王淵命也談到了他對此次大會的見解和感覺。
你們好。咱們是初創團隊,主要在DevOps方向使用Docker。和持續集成流程打通。
Docker給咱們最大的便利是可以高速地複製出一整套系統,方便幾套環境同一時候進行本身主動化測試。因此個人關注點也比較偏實踐方向。
主要關注網絡以及容器編排工具。
看此次DockerCon,感受這幾方面很是快應該會有成熟的解決方式出來。既然有了標準和插件擴展機制,可以各廠商,各社區一塊兒努力了。本身DIY也easy些。這個很是讓我激動。
另外看到田大師分享的Docker
networking方面的抽象,感受很是符合分佈式系統架構的抽象。各類語言的分佈式框架可以在Docker之上大有做爲,或者分佈式的概念在Docker之上也逐漸標準化?
討論以後是問答環節,幾位專家回答了觀衆的提問。
請問Docker何時可以放心用在生產環境?需要先解決什麼關鍵問題?
田琪:假設是私有云環境。我認爲現在放在生產環境是ready的。網絡和存儲問題相對需要多考慮,網絡這塊國旗可以給你們分享下。國旗是網絡方面的專家。
陳飛:就像田大師說的,Docker基本已經相對成熟了,對於計算型服務的話,應該沒什麼問題。有狀態服務需要考慮一下存儲方面的問題。
Projet Orca是個什麼項目?國旗是否能進一步介紹下。
閆國旗:Project Orca是一套自上而下的整合方案。上層提供面向用戶的GUI,下層管理Docker Engine/Docker Swarm/Docker Compose等等。
功能上支持服務編排、查看集羣或容器狀態、日誌等等。大部分功能基本上和一些Startup的產品一致了。
Docker在當前市場前景以及應用價值怎樣?
閆國旗:就當前環境來講,基於Docker生態的工具鏈,能極大提升生產力,build & ship。在類似的研發生產流程中,都可以引入。
對於IO Bound類的業務。我的認爲Docker仍是沒有準備好的。
固然這裏也不主要是Docker的問題,首先對於底層來講,IO的隔離,眼下作的還不夠。所以也致使了上層的Docker無能爲力,講到這裏,感受又引出了那個話題。容器的將來究竟是OS Container仍是App Container?方向不一樣,就決定着技術的走向不一樣。
我相信國內大多數的小夥伴是因爲Docker Image的特性。纔對Docker感興趣的吧。「Image特性」,可以理解爲Docker鏡像。
但是oveylayfs/dm的介入,會引入不少其它IO層面的問題。從現在的生態圈來看,你們眼下都把方向瞄準了APP Container。
王淵命:國旗的這個問題好。我剛開始用docker的時候就比較迷茫。既然已經在雲上了,雲也支持鏡像,支持API調度,爲啥還要Docker?只是現在我認爲Docker應該是 App Container。
閆國旗:但在這個場景,所謂的OS env,貌似就沒那麼必要了。
陳飛:我的認爲應該是App Container,內核容器技術出來的時候自己目的就是爲了解決App間隔離問題。但是因爲容器自己建立速度快,因此也有當作OS Container的,但是OS Container要解決的網絡、存儲等問題,剛好又是內核容器技術不具有的,因此Docker確定也是弱項。
閆國旗:OS Container的網絡,可以引入SDN來解決,存儲在本地是比較難作的。也許在將來,很是可能OS和APP的界限再也不那麼明顯。
嘉賓們對國內Docker的前景怎麼看?
閆國旗:現階段Docker在國內落地仍是蠻快的。從紅包的案例,到京東的大促,都出現了Docker的身影。
主要也是因爲使用Docker沒有過高的技術門檻。
田大師前文提到「Docker項目現在的狀況和當初的OpenStack有些相像」。 你們認爲Docker會不會也重蹈覆轍?
王淵命:Docker解決的問題沒有OpenStack那麼大,應該不會搞到OpenStack 那麼複雜吧。
洪濤(愛搶購CTO):OpenStack的不成功很是大程度在於架構的複雜性上,想當年。要配置一個可用的OpenStack沒有一週時間是全然搞不定的。光這點就致使不少想玩OpenStack的人被擋在了成功安裝這條線之外。
Docker很是方便部署,咱們現在就把它當作App的容器,Docker怎麼作資源分配?咱們的Docker中有個應用內存泄露。幹了260g內存。不能單獨分配給某個Docker固定的內存或者網絡?cgroup可以限制內存和網絡是嗎?這個是否能作動態改動?比方敲代碼調用他改。
劉斌:Docker網絡分配應該是以daemon爲單位的。就是cgroup改動參數就可以了。
Docker本事沒有此功能,但實現不難。
想問問各位大師,現在Docker都應用在哪些組件上面?是僅僅有無狀態App。仍是DB、Cache和存儲全面應用了?
閆國旗:現在Docker的主要場景依舊仍是無狀態App。像部分Cache也跑在了上面。
一些IO密集型的應用,特別是磁盤IO,使用Docker是否合適?
閆國旗:IO Bound類業務。從現階段的測試結果上看,不是特別理想。小規模的使用問題不大,假設是大平臺業務就是謹慎了。
就問題8。大家測過?大概比裸機慢多少?
閆國旗:這個不是慢的問題,是隔離的問題。IO隔離,IOPS或IO帶寬的SLA。
陳飛:另外應用的時候,版本號選擇也很是重要。像咱們就遇到docker1.5和1.6版本號在CentOS 6.5上,致使Kernel Panic的問題。
現在有什麼比較好用的Docker管理工具?
閆國旗:Swarm/Compose都算是Docker管理工具。固然Orca更無缺一點。
想問下田大師和國旗。此次交流。國外同行對Docker將來發展趨勢怎麼看。還有哪些機會?
閆國旗:從交流的結果上來看,國外的公司使用Docker不少其它是爲了減小「部分流程」上的成本。正是出發點如此,因此纔會有那麼多的Startup參與進來。
對於容器技術,咱們也可以理解爲是一種虛擬化技術。
所以很是多公司也但願本身的產品能向這個方向有所延伸。
田琪:我認爲廠商跟Docker仍是關心的不太同樣的。
感謝劉世傑@獵聘網的記錄與整理,臧秀濤@infoq的校對與公佈。其它多位編輯組志願者對本文亦有貢獻。讀者可以經過搜索「ArchNotes」或長按如下圖片,關注「高可用架構」公衆號,查看不少其它架構方面內容,獲取通往架構師之路的寶貴經驗。轉載請註明來自「高可用架構(ArchNotes)」公衆號。