天云軟件技術沙龍，帶你近距離了解Docker等容器技術！
原創在數據爆炸的今天，企業對互聯網應用的要求一方面是速度，要求可以快速迭代，適應市場需求變化;另一方面是穩定性，在面對用戶量不斷增長以及軟件應用不斷更新的情況下，可以依然保持業務持續不中斷。這也是云計算發展的一個方向，用戶可以不必自己部署、安裝基層應用，因為可以直接交給云平臺實現。而在這方面，Docker是一個尤其典型的應用!關于Docker等容器技術，你究竟了解多少?其使用場景都有哪些呢?9月24日，由DockOne社區和天云軟件聯合主辦的容器技術沙龍在北京IC咖啡舉辦，由各位技術大咖帶你近距離了解Docker!
作為一個標準的中間件，Docker相當于云計算的“集裝箱”，承載著后端的各種技術，并且可以保障多個技術同時運行的速度。技術人員只需關注將自己開發好的代碼、技術放在Docker鏡像里面，而運維人員也只需關注讓這種標準化的Docker在平臺上運行起來即可。
首先，中國電信云計算公司研發工程師張其棟給大家帶來“中國電信基于Mesos+Docker的運維自動化在CDN中的實踐”的主題演講。
張其棟首先表示，使用Mesos+Docker的大背景是中國電信云公司的CDN架構。之所以采用這樣的架構，是因為后期的業務范圍比較大，用戶比較廣，后期的設備量會達到幾萬臺，如果用傳統的思路進行運維，對于運維的壓力太大。
張其棟認為容器技術有自動化部署、持續集成、敏捷開發和提高開發效率、彈性調度、資源復用等優勢。他表示，中國電信在選擇了Docker之后，首先是實現業務軟件的容器化。比如直播轉碼業務軟件實現容器化。在實現了業務容器化之后，就需要選擇編排軟件。中國電信最終選擇的是Apache的Mesos。另外，他給出了選擇Mesos的如下幾個原因：一是相對比較成熟;二是數據分析相關軟件跟Mesos結合起來更容易。
當然在Docker落地過程中也遇到了一些問題，張其棟表示中國電信在落地Docker的過程中確實也遇到過一些坑，當然他也給出了自己的解決建議：
1、Docker默認共享內存太小，普通權限無法更改。我們給了***權限?，F在新版本Docker已經支持更改共享內存了，在測試環境里可以用新命令去更改。后期會把***權限去掉，使用命令行進行共享內存的更改。
2、Docker***權限會把容器107G存儲給寫滿，寫滿之后，再生成一個容器可以成功，但是運行不起來。有兩個方法，一個是更改107G存儲，變成2T或者4T的大硬盤，不能從根源上解決問題。還有一個辦法，從業務軟件上避免這個問題，把日志盡量往小寫，另外把日志映射出來。
3、直播轉碼和切片無法獲取CP方給的組播流。解決方案是給容器HOST模式，性能上沒有損失，但用網絡比較多。
4、修改防火墻后，Docker網絡環境不通。修改防火墻后重啟防火墻，之前運行起來的鏡像，再次運行時網絡是不通的。現在的解決方案是規避它，在使用鏡像的時候，先把防火墻所有的配置參數調好，不要重啟防火墻。
北京天云融創軟件技術有限公司研發總監劉春陽主要負責公司容器化以及平臺化產品的規劃和設計。他給大家帶來主題為“企業應用容器化的痛點、坑和解決之道”的演講。主要分享了針對企業級的平臺性的產品設計過程當中，可能會面臨什么樣的需求，面臨什么樣的問題，包括天云軟件本身所采取的一些技術選型。
他認為，在電信領域，Docker有著自己的特殊性。首先電信行業里面有運營商企業，然后是應用提供商，然后是資源提供商，這三個是分離的。管理方對于資源提供方，應用提供方都有要求，因此要求業務要能敏捷，要能快，盡快適應他們的需求。其次是業務要穩定;***是高效率。而容器技術給以上三方帶來了改變，利用容器，可以利用行程中的程序邏輯，可以用標準的協議交付第三方，使彼此之間角色沒有重疊現象資源提供者可以無差別的對待資源。其次，利用容器技術，可以在Docker放貨柜混合編排，混合部署，促進平臺的統一性。另外，通過利用標準化的容器技術，促進研發流程的自動化和應用模式化。
劉春陽認為，容器現在面臨的挑戰主要有以下兩個：
1、標準不統一。至少目前來說，容器的標準相對統一，但是容器平臺管理的標準至少有三家在，標準不統一，導致大家在使用過程當中，技術選型的時候會有挑戰。
2、容器的技術涉及到資源，涉及到應用內部，所以它具有一定的輕量性，不是交付虛機就可以。因此容器要解決個問題，否則就沒有辦法做模式化，而不做模式化的話，平臺的很多東西都無法構建。
當當網個性化推薦組項目負責人肖驍主要為大家分享了關于當當網個性化推薦組應用Docker進行應用部署以及小團隊試水Docker的的若干經驗，分享主要包括：現有應用Docker化的過程和結合Jenkins的自動化構建。他的演講主題是 “當當網Docker應用實踐”。
肖驍告訴我們，要是把程序放在容器里，程序至少是無狀態的，不能依賴于宿主機的一切環境和目錄等。Docker以后，代碼流水線管理，提高開發效率。
而用Docker把現有的程序Docker化，需要注意哪些東西呢?
1、鏡像構建。一定要從Dockerfile生成，如果不從Dockerfile生成，以后更新、回滾是很麻煩的。
2、避免依賴過深。不要在基礎鏡像上加太多產生其他的鏡像，最多是三四層。一層是base鏡像，再往上是工具，再往上一層就是自己的程序，再多就比較亂。
3、發布。使用Docker可以用很標準的過程做上線、回滾或者是升級。
4、日志管理。如果把日志放在容器里，容器銷毀了，日志就沒有了。要把日志實時保留，有一種辦法是把日志放在宿主機，完全不依賴宿主機的任何環境。肖驍建議放一些日志收集等。
5、環境變量。指定里面的環境變量，應用再去環境變量。這是Docker啟動的時候用這個，如果上集群的話，這個稍微麻煩一點。
6、配置中心。用數據庫，把配置放在里面都可以。用Docker的話，在里面改配置文件，再啟動的時候，配置文件就沒有了，有個簡單的方法就是配置文件，給每一個版本配置文件都打一個容器。
7、網絡管理。 現在主要是用Host，網絡性能***用Bridge，現在如果用自定義的話，可以建多個像Docker0這樣的網絡，可以為容器之間連接和隔離。
他說，如果自己團隊想用Docker的話，運行環境、內核版本、操作系統的發行版本，這些都是有要求的。
1、鏡像載荷要求。一個現有的比較成熟的架構應用，要放到Docker里要考慮是不是依賴宿主機的環境，包括本地的IP和本地目錄等。
2、數據中心過大。 數據中心過大時采用折中的方法，先往上扔一個空數據，后臺***次啟動的時候，如果容器里面沒有數據的話，自己就下了，這可能也是一個折中的辦法。
3、鏡像管理、版本控制。如果提交一個鏡像，包括版本號等，必須要有比較嚴格的規定，格式和定義必須要仔細規定一下，要不然就會亂。
相信不少人都想知道，在異構技術棧、5種語言、500+個微服務(包括Task)、網狀調用關系狀況下，如何做到一鍵構建測試環境，并同時支持50個Feature獨立測試卻互不影響? 折800的架構師劉凱以 “用Docker&K8s構建自動化測試環境”為主題的演講為大家做了妙答：用Docker + Kubernetes實現一鍵構建測試環境。按需拉起容器，按需部署，按照關聯計算，拉起關聯的服務。
但是，在使用Docker + Kubernetes過程中需要解決如下問題：
1、變異構為同質。不同的語言部署方式是不一樣的， 必須用一個方式，代碼上傳的時候，自帶環境、版本和庫。那么用什么樣的部署方式把異構的語言變成同步呢? 提供一個統一的接口可以構建、傳輸、部署。
2、配置管理。要自動化部署，一鍵拉起幾百個服務和幾十個服務，要知道相互的關系，要連什么服務，要怎么配置，必須做到自動化配置。要加一個存儲，要加一個ES，必須在ES上建索引等。
3、服務管理。如何做服務注冊、服務發現、如何做負載均衡。不同類型的服務，啟動以后，位置是不一樣的，HTDP服務要對外掛IP，要注冊到外面的負載均衡里面，應用層面的服務是不需要這樣做的。
4、監控。如果測試時，測不通，報告異常、超時，必須能在豎狀結構里面知道哪個節點報錯，如果從最前端一層一層向下排查，將會非常耗時。失敗了用紅點標出來，然后告訴失敗原因是什么。請求發不過去，是什么原因，圖形數據怎么來?采用更加激進的做法：整個測試環境，把所有包抓下來，知道源IP以及調度內容是成功還是失敗，從而分析所有容器節點的調度關系是成功還是失敗，這些數據配合服務依賴關系，完全可以把數據貫到監控數據上，這樣一來就知道哪個節點進來了，有什么錯，有多長時間。
5、兼容性。Docker化以后，怎么把之前沒有Docker化的服務和流程融入到里面，Docker研發流程要做相應的改造。接口和數據庫要兼容。
6、編排部署。上線、開發時先更新哪個服務，再更新哪個服務，加一個配置，然后改數據庫等等。這么復雜的事情，如果沒有合理的編排是很難做到自動化的。用DAG的方式去描述部署計劃，通過拖拽的方式表達要干什么。
7、隔離。一鍵拉起測試環境同時還要做到按需拉取，要對服務之間的調度關系做隔離。在隔離區里面，每個來源IP不一樣，***個隔離區的來源IP，把請求轉到相應的隔離區里面。
8、依賴關系。服務之間調度鏈很深，如果不對調度鏈關系進行管理，很難知道被拉起的是什么服務。向上找依賴分析，把依賴的服務一起部署。把500個服務的依賴關系都清算出來，放在一個服務庫里面，能看到相互依賴關系。
9、統一命名。看起來沒有技術含量，但是在做自動化部署和自動化測試時是非常關鍵的。
