概述

當下Docker容器化的架構備受歡迎，越來越多的企業開始利用容器來構建自己的基礎架構。通常是自己建立了Docker注冊表，部署在服務器上安裝Docker，安裝Jenkins通過Docker插件Jenkins CI管道管理Docker容器。更大一點規模的則會使用K8S或者Swarm編排集群。對一個企業而言有開始嘗試使用容器到逐漸深入，擴大規模要經歷一系列的問題和踩坑的過程，那么如何規范化、安全的實施容器化，如何盡量避免踩坑呢?本文蟲蟲給列出企業嘗試容器化架構需要考慮的各方各面問題，希望可以對大家有所幫助。

[[276637]]

鏡像問題

容器注冊表

Docker服務都需要一個注冊表(可不是我們常說的windows注冊表)，Docker注冊表是Docker鏡像的存儲和在線(Web)版本倉庫(類似于代碼的github倉庫)。有很多公有云自有容器注冊表服務，比如Docker官方的Docker Hub，很多公有云都提供自己Docker注冊表服務：

除了這些公開的注冊表，基于安全、網絡訪問速度、規范化等考慮企業維護一個自建的Docker注冊表(Docker私服)也是必須的。構建Docker私服可以使用Docker官方的Distribution，它是Docker官方推出的Docker Registry 2開源產品，使用Golang開發，極大提高了安全和性能。

知名的Git服務器端Gitlab也提供了Gitlab 容器注冊表，部署Gitlab企業可以直接考慮使用這個組件，實現統一管理和集成。當然除了開源的，也可以使用商用的產品的比如Vmware開源的Harbor：

企業選擇容器注冊表需要考慮以下問題：

• 注冊表是否能集成到企業內部的身份統一系統(比如LDAP，Kerberos等)?
• 是否支持基于角色的訪問控制(RBAC)?
• 統一身份認證和授權對企業來說是一個大問題。雖然快速便宜的開放的注冊解決方案可以足夠開發環境的構建。但是對企業線上環境，必須要考慮安全性、RBAC標準等。
• 是否有加速鏡像的方法?
• 鏡像是要有區別對待的。有些是快速、功能全，但是可能雜亂的的開發環境鏡像，他們不需要首要考慮正確性;而線上的鏡像則是要注重安全和性能和正確防護。企業要對這些鏡像分類，并且在注冊表中通過實例管理流程或用標簽強制執行。
• 是否與其他Artefact包管理架構保持良好的一致性?

企業可能已經有包文件庫，內部的Artefact存儲等(比如maven，npm，Gitlab等)。在理想的架構中，容器注冊表應該是它的一個功能。如果架構上是分開的，那么久要考慮兩者的集成和管理開銷。

鏡像掃描

這是很重要的部分。當鏡像上傳到自建容器注冊表時，需要檢查它們是否符合標準。例如，檢查諸如此類的問題：

• bash版本是否存在破殼漏洞?
• ssl庫是不是過時了?
• 該鏡像是否基于一個不安全或不可接受的基本鏡像(Base Image)?
• 是否存在有漏洞的或者過時庫(Strus 2)和工具?
• 等等

可以通過靜態鏡像分析來檢查這些問題。我們需要注意的是，這些掃描可能不是十全十美的，可能會錯過一些非常明顯漏洞，所以它也不是解決一切安全問題的靈丹妙藥，而是一種必要的手段，特別非常適合用解決：

• 防止惡意攻擊者注入木馬?
• 在企業范圍了，統一規范標準?
• 快速發現和修補已知的和標準CVE漏洞?

這些問題是組成了鏡像掃描評估的基礎，當然也需要考慮集成的成本。常見的鏡像掃描工具有Clair，Anchore，OpenSCAP，Dockerscan等。

鏡像構建

如何構建鏡像?企業要支持哪些構建方法?如何將這些方組合在一起?

Dockerfiles最常用標準的方法之一，也可以使用S2I，Docker +Chef/Puppet/Ansible，甚至是手工方法構建。

使用那種CM(配置管理，如果已經使用的話)工具管理。

是否可以重復使用標準治理流程來和配置管理交互?

任何人都可以構建鏡像嗎?

[[276638]]

業界的經驗表明Dockerfile方法是一個使用廣泛而且通用的方法，而且具有大量的社區文檔和問題反饋支持。嘗試更復雜的CM工具用來符合VM的公司標準的則通常有一定實施門檻。通過S2I或Chef/Puppet/Ansible方法則更加便捷，也能很好的實現代碼(playbook)重用。

鏡像完整

需要確保系統上運行的鏡像在從構建到運行之間沒有被篡改過。

是否可以使用安全密鑰來對鏡像進行簽名?

是否有可以重復使用的密鑰庫?

密鑰庫可以與選擇的工具集成嗎?

即使Docker流行了很多年，鏡像的完整性仍然是一個新興領域。很多的供應商的對此還持觀望態度。 Docker 公司在這方面做了一些有益的工作，比如Notary(Docker開源簽名解決方案,已經轉到CNCF基金會下)在Docker企業數據中心產品之外部署。

第三方鏡像

[[276639]]

如果希望使用一鍵部署，那么供應商的鏡像則可以直接使用。

是否擁有驗證供應商鏡像的管理流程?

我們不光需要知道鏡像是否安全，還需要知道誰可以在必要時更新鏡像?

這些鏡像可被其他鏡像重用么?

這里有潛在的許可問題。是否有辦法阻止其他項目/團隊重用鏡像?

是否強制要求運行于特定的環境(例如DMZ)?

Docker是否可以在這些環境中使用?

例如許多網絡級應用程序運行在網絡設備類似環境，并且需要認證，所以，它必須與其他容器或項目工作環境隔離。是否有可能在這些環境中運行鏡像，需要考慮。

SDLC

如果企業已經實施了軟件開發生命周期(SDLC)流程，那么就要考慮Doc​​ker和它適應的問題：

• 如何處理補丁?
• 如何識別哪些鏡像需要更新?
• 如何更新它們?
• 如何通知團隊更新?
• 如果他們不及時更新，如何強制他們更新?

該問題與上面已經提到的鏡像掃描方案密切相關。可能需要在某些時候考慮將其與現有SDLC流程集成。

密碼管理

在實施中數據庫密碼等信息需要傳遞到容器中。可以通過構建時(不建議)或運行時來完成該項工作。

如何在容器內管理密碼?

是否對密碼信息的使用進行了審核/跟蹤并確保安全?

[[276640]]

和鏡像簽名一樣，密碼管理也是一個仍在快速變化的新興領域。業界有OpenShift/Origin與Hashicorp Vault等現有集成解決方案。Docker Swarm等核心組件中也有對密碼管理的支持，Kubernetes 1.7加強了其密碼安全功能。

基礎鏡像

如果在企業中運行Docker，則可能需要在公司范圍內強制使用基礎鏡像：

• 該基本鏡像應該包含哪些內容?
• 應該使用哪種標準工具?
• 誰負責管理集成鏡像?
• 需要提前準備好很多關于基本鏡像的問題。另外開發人員非常注重鏡像的精簡。

安全和審計

root權限

默認情況下，訪問docker命令(特別是訪問Docker UNIX套接字)需要機器root權限。對于生產環境中的來說，這是不可能接受的。需要回答以下問題：

• 誰(組)有權能夠運行docker命令?
• 怎么管理這些有運行權限的人員?
• 如何控制可運行的內容?

這些都有解決方案，但它們相對較新，通常是其他更大解決方案的一部分。

例如，OpenShift具有強大的RBAC控制功能，但需要購買整個平臺。Twistlock和Aquasec這樣的容器安全工具提供了一種管理這些工具的方法，可以考慮集成他們。

[[276641]]

運行時監控

企業可能希望能夠確定線上容器運行情況。

如何知道線上運行了哪些容器?

這些運行中的容器，怎樣容器注冊表?怎么關聯的，怎么在容器注冊表中管理的?

啟動以后，容器都更改過哪些關鍵性的文件?

同樣，這還有其他一些問題，這些構成Docker基礎運行策略。在這方面另一個經常被供應商提起的功能是異常檢測。安全解決方案提供了諸如花哨的機器學習的解決方案，聲稱可以通過學習容器該做什么，并對可能的異常活動發出告警。例如連接到與應用程序無關的外部應用程序的端口。雖然聽起來不錯，但是需要考慮一下如何運維他們。一般來說可能會有大量的誤報，需要大量調整和回歸驗證的，是否有人力和資金來維持運維，是問題的關鍵。

審計

當發生問題后，我們需要知道發生了什么。在物理和虛擬機的架構體系中，有很多安全措施來協助故障調查。而Docker容器的體系下，有可能是一個沒有"黑匣子記錄"的。

能馬上查詢出誰在運行容器嗎?

能馬上查詢出誰構建了了容器嗎?

要刪除容器時，能快速確定該容器的作用嗎?

要刪除容器時，能確定改容器可能做了什么嗎?

在這個問題上，我們可能希望強制使用特定的日志系統解決方案，以確保有關系統活動的信息在容器實例中保持不變。Sysdig的Falco(目前已經轉到CNCF基金會下)是容器安全監控和審計領域一個有趣，很有前途的工具。

運維

日志

應用程序日志記錄是企業關注的問題之一：

• 容器是否記錄了操作所需的內容?
• 日志是否遵循企業日志標準?
• 日志記錄在什么地方?

容器的日志可能與傳統機器部署有著非常不同的模式。日志存儲空間可能要支持橫向擴展，可能需要增加存儲等。

容器編排

為了讓容器可以迅速隨著業務擴展和變更迭代，就需要編排系統來統一管理。

選擇的編排架構是否和Docker基礎架構的其他部分可以很好的適應?

是想使用一個與主流架構相悖的編排架構，還是追隨主流呢?

Kubernetes目前看來是贏得編排系統的市場。選擇非Kubenetes的架構可能需要找出充分的理由。

操作系統

企業線上操作系統遠落后于最新的版本和最通用的版本。

線上的標準操作系統是否能夠支持Docker所有最新功能?

例如，一些編排系統和Docker本身需要的內核版本或軟件包可能比所能支持的新很多，這可能是一個非常棘手的問題。

系統軟件包管理默認支持的Docker版本是多少?

Docker版本之間可能會存在明顯差異(比如，1.10是一個很大的差異)，我們需要關注這些差異的細節。發行版提供的Docker(或者說'Moby'版本)之間也存在差異，這個影響很大。比如，RedHat的二進制docker包請求的順序RedHat的注冊表排在Docker Hub之前。

開發

開發環境

開發人員往往會要求系統管理權限。如何控制他們權限?

一個比較好的做法是可以為開發人員提供一個VM，讓他們在本地進行Docker構建，或者只運行docker客戶端，而將Docker服務端運行在統一服務器上。

他們的客戶端是否與部署環境保持一致?

如果他們的桌面上使用的是docker-compose，他們可能會很反感在UAT和生產中切換到Kubernetes pod。

[[276642]]

CI/CD

Jenkins是最受歡迎的CI工具，但是還有其他流行的替代方案，例如TeamCity，Gitlab CI等

Docker引入很多開發人員渴望使用的插件。其中很多都沒有考慮到安全性，甚至可能與其他插件存在兼容性的問題。

你CI/CD插件的策略是什么?

你準備好開啟一大堆新良莠不齊的插件了嗎?

CI流程是否適合短暫Jenkins實例以及持久的，受支持的實例?

基礎設施

共享存儲

Docker的核心是使用獨立于運行容器的卷，其中存儲持久數據。

共享存儲容易配置嗎?

NFS服務有其局限性，但已經成熟，并且在大型組織中通常得到很好的支持。

共享存儲支持是否可以滿足業務增加的需求?

是否需要跨部署位置提供共享存儲?

你可能擁有多個數據中心和/或云提供商。所有這些地點是否可以互相交互?他們需要交互嗎?

網絡

企業通常擁有自己喜歡的軟件定義網絡(SDN)解決方案，如Nuage，或新的方案比如Calico。

你是否有規定的SDN解決方案?

它如何與你選擇的解決方案相互作用?

SDN交互是否可能會導致出現問題?

aPaaS

擁有像OpenShift或Tutum Cloud這樣的aPaaS可以通過集中化支持Docker運行的上下文來解決上述許多問題。

你是否考慮過使用aPaaS?

云供應商

如果你使用的是亞馬遜或谷歌，阿里云等云提供商：

如何在云供應商上提供鏡像和運行容器?

是否希望將Docker解決方案與云供應商的產品聯系起來，或者讓他們與云供應商無關?

解決方案選擇時要注意的事項

有兩種方法可以選擇。一種方法是使用單個供應商的整體統一架構。還有一種方法是使用多個供應商的各個優勢產品，然后拼湊集成為一個企業方案。

方法一的，好處是：

• 統一管理，統一認證。
• 減少集成工作量和開銷。
• 交付更快。
• 可以享受來自供應商的更大承諾和關注。
• 可能對產品方向的影響
• 更易于管理。

單一供應商解決方案通常要求按照節點付款，可能導致成本費用很高，而且后續更換需要承受巨大損失，也會限制內部的架構。

拼湊集成方案的好處有：

• 可以更具企業需求，用不同的速率提供更靈活的解決方案
• 集眾家之長，可以讓你少踩坑，少犯錯誤，有問題可以隨時調整更換工具。
• 從從長遠來看更加批恩一便宜，而且不會被 "鎖定"到某家供應商上，不仰人鼻息，被人敲詐，吊死在一棵樹上。

結論

企業Docker架構和部署復雜而多變。制定一個統一的，具有成本效益，安全，完整，靈活的，可以快速交付且無需鎖定的戰略是當下企業容器化臨的挑戰之一。本文列出了企業Docker實施各個方面需要注意的問題總結，供大家參考。