天雲軟體技術沙龍 帶你了解Docker等技術
2023-12-01 01:21:28 2
在數據爆炸的今天，企業對網際網路應用的要求一方面是速度，要求可以快速迭代，適應市場需求變化；另一方面是穩定性，在面對用戶量不斷增長以及軟體應用不斷更新的情況下，可以依然保持業務持續不中斷。這也是雲計算發展的一個方向，用戶可以不必自己部署、安裝基層應用，因為可以直接交給雲平臺實現。而在這方面，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默認共享內存太小，普通權限無法更改。我們給了最高權限。現在新版本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、統一命名。看起來沒有技術含量，但是在做自動化部署和自動化測試時是非常關鍵的。
