在生產環境中運行容器的“六要、六不要和六管理”
容器技術讓應用封裝變得非常簡單，容器將會成為未來最主流的部署方式。據權威咨詢機構Gartner預測，到2022年全球超過75%的企業組織將在容器中運行應用程序，這與目前不到30%的比例相比有了顯著的增長。
單從數據來看，近年來容器和Kubernetes在傳統數據中心和云原生應用中得到很好運用，但是當前容器的生態系統并不完善，缺乏足夠成熟的操作實踐案例。容器集成、網絡以及自動化部署仍然是非常棘手的問題。此外，由于云原生應用需要一個高度自動化基礎設施環境以及專業的運維技能，導致容器在企業中應用仍然受到一定限制。
在生產環境部署容器的注意事項
因此，在具體生產環境中運行容器仍然需要一個長期的學習過程。企業在生產環境中部署容器之前，一定要認真思考以下六個問題：
- DevOps：是否擁有DevOps團隊來做開發運維，能夠啟用敏捷開發和部署模型?
- 工作負載：是否確定了專人來負責容器化的工作負載?
- 快速集成：是否了解如何集成IT基礎架構，以及擁有跨平臺的集成能力?
- 付費模型：是否了解使用哪種運行和編排引擎，以及他們的付費模式?
- 培訓技能：是否了解應學習哪種新技能以及采用哪種規則能確保容器部署成功?
- ROI：投資回報率如何?
但是，很多企業組織經常會低估在生產環境中運行容器所需的工作量，想要讓容器在企業中正常運作，要盡量避免下述六個錯誤的行為。
- 在沒有成熟DevOps實踐經驗的情況下就開始部署容器。
- 選擇了那些帶有專有組件的容器導致被鎖定。
- 沒有在企業組織中實施通用的工具和合規要求。
- 沒有為開發和運維人員提供前沿的技術培訓服務。
- 在選擇工具的時候沒有考慮開發者和運維者的需求。
- 選擇了依賴性、相關性非常大的復雜工作負載。
容器實踐需要重點管理六個方面
企業在生產環境部署容器后，就應該格外重視容器本身的安全。例如Docker宿主機安全、Docker鏡像安全、運行環境安全、編排安全等問題，這都意味著保護容器安全將是一項持續的挑戰。在生產環境中部署容器，需要重點考慮安全合規、持續監控、數據持久性、網絡安全問題、全生命周期管理、容器編排等問題。
安全合規
安全不能總是事后諸葛亮。它需要嵌入到DevOps過程中。企業組織需要考慮跨容器全生命周期安全問題，包括應用程序的構建、開發、部署和運行等不同階段。
- 將鏡像掃描集成到企業的CI/CD中，及時發現漏洞。在軟件開發生命周期的構建和運行階段對應用程序進行掃描。重點是掃描和驗證開源組件、庫和框架。
- 根據CIS基線檢查安全配置。
- 建立強制性訪問控制，針對SSL密鑰或數據庫憑據等敏感信息進行加密管理，只在運行時提供。
- 通過策略管理避免特權容器，以減少潛在攻擊的影響。
- 部署提供白名單、行為監控和異常檢測的安全產品，以防止惡意活動。
持續監控
開發人員主要關注容器在功能方面的應用，而不會去監控它們的運行情況。傳統監控工具主要關注主機級指標，如CPU利用率、內存利用率、I/O、延遲和網絡帶寬。但這遠遠不夠，還缺少容器或工作負載級別指標數據。
- 安全人員要將監控重點放在容器和服務級別上，實現細粒度監控“應用程序”，而不僅僅是物理主機。
- 優先考慮提供與容器編排(尤其是Kubernetes)深度集成的工具和供應商。
- 使用那些能夠提供細粒度日志記錄、提供自動服務發現、實時操作建議的工具。
容器存儲
隨著對有狀態工作負載容器使用的增加，客戶需要考慮物理主機之外數據的持久性，保護這些數據安全。即便容器不在了，數據必須還在。如果企業對容器的主要使用場景，是轉移老舊應用程序或無狀態用例，對存儲的安全需求不會發生大變化。但是，如果要對應用程序進行重構，或提供一個新的、面向微服務的有狀態應用程序，那么安全人員就需要一個存儲平臺，能夠最大限度地提高工作負載的可用性、靈活性和性能。例如，為了更好的支持容器遷移和數據共享，Docker推出了Volume plugin接口機制，讓第三方的存儲廠商來支持Docker Volume并且在此基礎上進行功能拓展。
- 選擇與微服務體系結構原則一致的存儲解決方案，要能滿足支持API驅動、具有分布式架構、支持本地和公有云部署的服務。
- 避免使用專有插件和接口。相反，優先考慮與Kubernetes緊密集成的供應商，并支持標準接口，如容器存儲接口(CSIs)。
容器網絡
開發人員最關心就是軟件開發的敏捷性和可移植性，希望應用程序能夠跨軟件開發生命周期進行移植。雖然在傳統的企業網絡模型中，IT人員為每個項目的開發、測試和生產等創建網絡環境，即便如此仍然不一定能夠與業務流保持很好一致性。在容器業務環境中，容器網絡問題就更加復雜。例如，容器網絡跨越多個層，如果直接在主機端口上開放服務雖然可行，但是部署多個應用的時會遇到端口沖突，加大擴展集群和更換主機的難度。
因此網絡解決方案需要與Kubernetes原語和策略引擎緊密集成。安全和運維人員需要努力實現高度的網絡自動化，并為開發人員提供適當的工具和足夠的靈活性。
- 分析現有的容器即服務(CaaS)或軟件定義網絡(SDN)解決方案是否支持Kubernetes網絡。如果沒有，可以選擇通過容器網絡接口(CNI)來集成應用層網絡和策略引擎。
- 確保所選擇的CaaS、PaaS工具能為主機集群提供負載均衡方面控制，或者選擇第三方代理服務器。
- 培訓網絡工程師對Linux網絡、自動化網絡工具的使用，彌補技能差距。
容器生命周期管理
對于高度自動化和無縫的應用交付管道，企業組織需要使用其他自動化工具來補充容器編排，例如Chef, Puppet, Ansible and Terraform等配置管理工具和應用發布自動化工具。盡管這些工具和CaaS產品之間有重疊之處，但是互補性遠大于重合部分。
- 為容器基礎鏡像建立標準，考慮鏡像大小、開發人員添加組件的靈活性和許可。
- 使用容器感知配置管理系統來管理容器鏡像的生命周期，系統一旦感知到規則限定下的新版本鏡像被推入倉庫，則會立刻觸發自動部署功能，來使用新鏡像更新指定的容器。
- 將CaaS平臺與應用程序自動化工具集成在一起，這樣可以自動化整個應用程序工作流。
容器編排
因為容器編排工具管理著承載各類服務的容器集群。無論是 Kubernetes 社區還是第三方安全機構均針對 Kubernetes 中組件和資源的安全進行了相應改善和安全加固，包括計算資源安全、集群安全及相關組件安全等。這塊需要重點考慮是隱私管理、授權管理、身份防控制、編排控制面、網絡證書等都需要全面考慮。
其中，容器部署的關鍵是提供編排和調度能力。編排層與應用程序進行接口，使容器保持在所需的狀態下運行。而容器調度系統按照編排層的要求將容器放在集群中最優的主機上。例如通過Apache Mesos提供調度，Marathon提供編排或使用單個工具Kubernetes或Docker Swarm提供編排和調度。客戶在編排引擎之間或跨Kubernetes發行版之間進行決策時，需要重點考慮以下幾個方面：
- 支持OS和容器運行時的深度和廣度;
- 整體產品的運行時穩定性;
- 可擴展性;
- 對有狀態應用程序的支持程度;
- 操作的簡單性和供應商支持的質量;
- 對開源的支持和開發;
- 部署難易度及License費用;
- 支持混合多云。
容器技術與DevOps
容器和DevOps的關系就像是咖啡伴侶。容器能夠快速發展，也得益于DevOps實踐經驗。在傳統的開發環境，開發團隊編寫代碼，QA團隊測試軟件應用程序，并將它們移交給運維團隊進行日常管理。為了解決傳統開發模式中的問題，很多企業都采用了“DevOps流程+微服務理論+使用容器和容器編排工具”。事實上，DevOps前身就是CI/CD，現在只不過是再加上一些發布、部署等標準和管理就構成了DevOps。
在云原生環境中，不僅軟件開發和發布速度很快，而且平臺本身也需要被當作一個產品來對待，因為它是動態的，并且在功能和規模方面不斷發展。平臺運營團隊的目標是自動化、可伸縮和有彈性的標準化平臺。平臺運營團隊的職責包括CaaS、PaaS產品的部署、操作、定制，標準化中間件的開發、操作，以及IaaS供應的自動化、部署、安全的啟用等等。企業組織需要創建一個DevOps團隊來運營容器，而不是一個個孤立的IT運營團隊。
以容器安全為例，企業需要一個可集成至DevOps流程，又不會拖慢軟件開發的方案。目前國內外有一些安全廠商已經在這方面做出好成績，例如青藤容器安全解決方案，就可以提供對容器鏡像掃描、入侵檢測和合規基線實施情況等產品服務，化解容器所帶來的安全挑戰。這是一個以應用為中心、輕量級、保障容器靜態資源及運行時安全的分布式解決方案，能夠針對應用漏洞、不安全配置、入侵攻擊、網絡行為，并結合安全策略，提供覆蓋容器全生命周期的、持續性安全防護。
