容器技術(shù)讓應(yīng)用封裝變得非常簡單，容器將會(huì)成為未來最主流的部署方式。據(jù)權(quán)威咨詢機(jī)構(gòu)Gartner預(yù)測，到2022年全球超過75%的企業(yè)組織將在容器中運(yùn)行應(yīng)用程序，這與目前不到30%的比例相比有了顯著的增長。

單從數(shù)據(jù)來看，近年來容器和Kubernetes在傳統(tǒng)數(shù)據(jù)中心和云原生應(yīng)用中得到很好運(yùn)用，但是當(dāng)前容器的生態(tài)系統(tǒng)并不完善，缺乏足夠成熟的操作實(shí)踐案例。容器集成、網(wǎng)絡(luò)以及自動(dòng)化部署仍然是非常棘手的問題。此外，由于云原生應(yīng)用需要一個(gè)高度自動(dòng)化基礎(chǔ)設(shè)施環(huán)境以及專業(yè)的運(yùn)維技能，導(dǎo)致容器在企業(yè)中應(yīng)用仍然受到一定限制。

在生產(chǎn)環(huán)境部署容器的注意事項(xiàng)

因此，在具體生產(chǎn)環(huán)境中運(yùn)行容器仍然需要一個(gè)長期的學(xué)習(xí)過程。企業(yè)在生產(chǎn)環(huán)境中部署容器之前，一定要認(rèn)真思考以下六個(gè)問題：

• DevOps：是否擁有DevOps團(tuán)隊(duì)來做開發(fā)運(yùn)維，能夠啟用敏捷開發(fā)和部署模型?
• 工作負(fù)載：是否確定了專人來負(fù)責(zé)容器化的工作負(fù)載?
• 快速集成：是否了解如何集成IT基礎(chǔ)架構(gòu)，以及擁有跨平臺的集成能力?
• 付費(fèi)模型：是否了解使用哪種運(yùn)行和編排引擎，以及他們的付費(fèi)模式?
• 培訓(xùn)技能：是否了解應(yīng)學(xué)習(xí)哪種新技能以及采用哪種規(guī)則能確保容器部署成功?
• ROI：投資回報(bào)率如何?

但是，很多企業(yè)組織經(jīng)常會(huì)低估在生產(chǎn)環(huán)境中運(yùn)行容器所需的工作量，想要讓容器在企業(yè)中正常運(yùn)作，要盡量避免下述六個(gè)錯(cuò)誤的行為。

• 在沒有成熟DevOps實(shí)踐經(jīng)驗(yàn)的情況下就開始部署容器。
• 選擇了那些帶有專有組件的容器導(dǎo)致被鎖定。
• 沒有在企業(yè)組織中實(shí)施通用的工具和合規(guī)要求。
• 沒有為開發(fā)和運(yùn)維人員提供前沿的技術(shù)培訓(xùn)服務(wù)。
• 在選擇工具的時(shí)候沒有考慮開發(fā)者和運(yùn)維者的需求。
• 選擇了依賴性、相關(guān)性非常大的復(fù)雜工作負(fù)載。

容器實(shí)踐需要重點(diǎn)管理六個(gè)方面

企業(yè)在生產(chǎn)環(huán)境部署容器后，就應(yīng)該格外重視容器本身的安全。例如Docker宿

安全合規(guī)

安全不能總是事后諸葛亮。它需要嵌入到DevOps過程中。企業(yè)組織需要考慮跨容器全生命周期安全問題，包括應(yīng)用程序的構(gòu)建、開發(fā)、部署和運(yùn)行等不同階段。

1. 將鏡像掃描集成到企業(yè)的CI/CD中，及時(shí)發(fā)現(xiàn)漏洞。在軟件開發(fā)生命周期的構(gòu)建和運(yùn)行階段對應(yīng)用程序進(jìn)行掃描。重點(diǎn)是掃描和驗(yàn)證開源組件、庫和框架。
2. 根據(jù)CIS基線檢查安全配置。
3. 建立強(qiáng)制性訪問控制，針對ssl密鑰或數(shù)據(jù)庫憑據(jù)等敏感信息進(jìn)行加密管理，只在運(yùn)行時(shí)提供。
4. 通過策略管理避免特權(quán)容器，以減少潛在攻擊的影響。
5. 部署提供白名單、行為監(jiān)控和異常檢測的安全產(chǎn)品，以防止惡意活動(dòng)。

持續(xù)監(jiān)控

開發(fā)人員主要關(guān)注容器在功能方面的應(yīng)用，而不會(huì)去監(jiān)控它們的運(yùn)行情況。傳統(tǒng)監(jiān)控工具主要關(guān)注主機(jī)級指標(biāo)，如CPU利用率、內(nèi)存利用率、I/O、延遲和網(wǎng)絡(luò)帶寬。但這遠(yuǎn)遠(yuǎn)不夠，還缺少容器或工作負(fù)載級別指標(biāo)數(shù)據(jù)。

1. 安全人員要將監(jiān)控重點(diǎn)放在容器和服務(wù)級別上，實(shí)現(xiàn)細(xì)粒度監(jiān)控“應(yīng)用程序”，而不僅僅是物理主機(jī)。
2. 優(yōu)先考慮提供與容器編排(尤其是Kubernetes)深度集成的工具和供應(yīng)商。
3. 使用那些能夠提供細(xì)粒度日志記錄、提供自動(dòng)服務(wù)發(fā)現(xiàn)、實(shí)時(shí)操作建議的工具。

容器存儲

隨著對有狀態(tài)工作負(fù)載容器使用的增加，客戶需要考慮物理主機(jī)之外數(shù)據(jù)的持久性，保護(hù)這些數(shù)據(jù)安全。即便容器不在了，數(shù)據(jù)必須還在。如果企業(yè)對容器的主要使用場景，是轉(zhuǎn)移老舊應(yīng)用程序或無狀態(tài)用例，對存儲的安全需求不會(huì)發(fā)生大變化。但是，如果要對應(yīng)用程序進(jìn)行重構(gòu)，或提供一個(gè)新的、面向微服務(wù)的有狀態(tài)應(yīng)用程序，那么安全人員就需要一個(gè)存儲平臺，能夠大限度地提高工作負(fù)載的可用性、靈活性和性能。例如，為了更好的支持容器遷移和數(shù)據(jù)共享，Docker推出了Volume plugin接口機(jī)制，讓第三方的存儲廠商來支持Docker Volume并且在此基礎(chǔ)上進(jìn)行功能拓展。

1. 選擇與微服務(wù)體系結(jié)構(gòu)原則一致的存儲解決方案，要能滿足支持API驅(qū)動(dòng)、具有分布式架構(gòu)、支持本地和公有云部署的服務(wù)。
2. 避免使用專有插件和接口。相反，優(yōu)先考慮與Kubernetes緊密集成的供應(yīng)商，并支持標(biāo)準(zhǔn)接口，如容器存儲接口(CSIs)。

容器網(wǎng)絡(luò)

開發(fā)人員最關(guān)心就是軟件開發(fā)的敏捷性和可移植性，希望應(yīng)用程序能夠跨軟件開發(fā)生命周期進(jìn)行移植。雖然在傳統(tǒng)的企業(yè)網(wǎng)絡(luò)模型中，IT人員為每個(gè)項(xiàng)目的開發(fā)、測試和生產(chǎn)等創(chuàng)建網(wǎng)絡(luò)環(huán)境，即便如此仍然不一定能夠與業(yè)務(wù)流保持很好一致性。在容器業(yè)務(wù)環(huán)境中，容器網(wǎng)絡(luò)問題就更加復(fù)雜。例如，容器網(wǎng)絡(luò)跨越多個(gè)層，如果直接在主機(jī)端口上開放服務(wù)雖然可行，但是部署多個(gè)應(yīng)用的時(shí)會(huì)遇到端口沖突，加大擴(kuò)展集群和更換主機(jī)的難度。

因此網(wǎng)絡(luò)解決方案需要與Kubernetes原語和策略引擎緊密集成。安全和運(yùn)維人員需要努力實(shí)現(xiàn)高度的網(wǎng)絡(luò)自動(dòng)化，并為開發(fā)人員提供適當(dāng)?shù)墓ぞ吆妥銐虻撵`活性。

1. 分析現(xiàn)有的容器即服務(wù)(CaaS)或軟件定義網(wǎng)絡(luò)(SDN)解決方案是否支持Kubernetes網(wǎng)絡(luò)。如果沒有，可以選擇通過容器網(wǎng)絡(luò)接口(CNI)來集成應(yīng)用層網(wǎng)絡(luò)和策略引擎。
2. 確保所選擇的CaaS、PaaS工具能為主機(jī)集群提供負(fù)載均衡方面控制，或者選擇第三方代理服務(wù)器。
3. 培訓(xùn)網(wǎng)絡(luò)工程師對Linux網(wǎng)絡(luò)、自動(dòng)化網(wǎng)絡(luò)工具的使用，彌補(bǔ)技能差距。

容器生命周期管理

對于高度自動(dòng)化和無縫的應(yīng)用交付管道，企業(yè)組織需要使用其他自動(dòng)化工具來補(bǔ)充容器編排，例如Chef, Puppet, Ansible and Terraform等配置管理工具和應(yīng)用發(fā)布自動(dòng)化工具。盡管這些工具和CaaS產(chǎn)品之間有重疊之處，但是互補(bǔ)性遠(yuǎn)大于重合部分。

1. 為容器基礎(chǔ)鏡像建立標(biāo)準(zhǔn)，考慮鏡像大小、開發(fā)人員添加組件的靈活性和許可。
2. 使用容器感知配置管理系統(tǒng)來管理容器鏡像的生命周期，系統(tǒng)一旦感知到規(guī)則限定下的新版本鏡像被推入倉庫，則會(huì)立刻觸發(fā)自動(dòng)部署功能，來使用新鏡像更新指定的容器。
3. 將CaaS平臺與應(yīng)用程序自動(dòng)化工具集成在一起，這樣可以自動(dòng)化整個(gè)應(yīng)用程序工作流。

容器編排

因?yàn)槿萜骶幣殴ぞ吖芾碇休d各類服務(wù)的容器集群。無論是 Kubernetes 社區(qū)還是第三方安全機(jī)構(gòu)均針對 Kubernetes 中組件和資源的安全進(jìn)行了相應(yīng)改善和安全加固，包括計(jì)算資源安全、集群安全及相關(guān)組件安全等。這塊需要重點(diǎn)考慮是隱私管理、授權(quán)管理、身份防控制、編排控制面、網(wǎng)絡(luò)證書等都需要全面考慮。

其中，容器部署的關(guān)鍵是提供編排和調(diào)度能力。編排層與應(yīng)用程序進(jìn)行接口，使容器保持在所需的狀態(tài)下運(yùn)行。而容器調(diào)度系統(tǒng)按照編排層的要求將容器放在集群中最優(yōu)的主機(jī)上。例如通過Apache Mesos提供調(diào)度，Marathon提供編排或使用單個(gè)工具Kubernetes或Docker Swarm提供編排和調(diào)度。客戶在編排引擎之間或跨Kubernetes發(fā)行版之間進(jìn)行決策時(shí)，需要重點(diǎn)考慮以下幾個(gè)方面：

• 支持OS和容器運(yùn)行時(shí)的深度和廣度;
• 整體產(chǎn)品的運(yùn)行時(shí)穩(wěn)定性;
• 可擴(kuò)展性;
• 對有狀態(tài)應(yīng)用程序的支持程度;
• 操作的簡單性和供應(yīng)商支持的質(zhì)量;
• 對開源的支持和開發(fā);
• 部署難易度及License費(fèi)用;
• 支持混合多云。

容器技術(shù)與DevOps

容器和DevOps的關(guān)系就像是咖啡伴侶。容器能夠快速發(fā)展，也得益于DevOps實(shí)踐經(jīng)驗(yàn)。在傳統(tǒng)的開發(fā)環(huán)境，開發(fā)團(tuán)隊(duì)編寫代碼，QA團(tuán)隊(duì)測試軟件應(yīng)用程序，并將它們移交給運(yùn)維團(tuán)隊(duì)進(jìn)行日常管理。為了解決傳統(tǒng)開發(fā)模式中的問題，很多企業(yè)都采用了“DevOps流程+微服務(wù)理論+使用容器和容器編排工具”。事實(shí)上，DevOps前身就是CI/CD，現(xiàn)在只不過是再加上一些發(fā)布、部署等標(biāo)準(zhǔn)和管理就構(gòu)成了DevOps。

在云原生環(huán)境中，不僅軟件開發(fā)和發(fā)布速度很快，而且平臺本身也需要被當(dāng)作一個(gè)產(chǎn)品來對待，因?yàn)樗莿?dòng)態(tài)的，并且在功能和規(guī)模方面不斷發(fā)展。平臺運(yùn)營團(tuán)隊(duì)的目標(biāo)是自動(dòng)化、可伸縮和有彈性的標(biāo)準(zhǔn)化平臺。平臺運(yùn)營團(tuán)隊(duì)的職責(zé)包括CaaS、PaaS產(chǎn)品的部署、操作、定制，標(biāo)準(zhǔn)化中間件的開發(fā)、操作，以及IaaS供應(yīng)的自動(dòng)化、部署、安全的啟用等等。企業(yè)組織需要?jiǎng)?chuàng)建一個(gè)DevOps團(tuán)隊(duì)來運(yùn)營容器，而不是一個(gè)個(gè)孤立的IT運(yùn)營團(tuán)隊(duì)。

以容器安全為例，企業(yè)需要一個(gè)可集成至DevOps流程，又不會(huì)拖慢軟件開發(fā)的方案。目前國內(nèi)外有一些安全廠商已經(jīng)在這方面做出好成績，例如青藤容器安全解決方案，就可以提供對容器鏡像掃描、入侵檢測和合規(guī)基線實(shí)施情況等產(chǎn)品服務(wù)，化解容器所帶來的安全挑戰(zhàn)。這是一個(gè)以應(yīng)用為中心、輕量級、保障容器靜態(tài)資源及運(yùn)行時(shí)安全的分布式解決方案，能夠針對應(yīng)用漏洞、不安全配置、入侵攻擊、網(wǎng)絡(luò)行為，并結(jié)合安全策略，提供覆蓋容器全生命周期的、持續(xù)性安全防護(hù)。

分享標(biāo)題：在生產(chǎn)環(huán)境中運(yùn)行容器的“六要、六不要和六管理”
文章出自：http://jinyejixie.com/news24/99774.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供虛擬主機(jī)、全網(wǎng)營銷推廣、企業(yè)網(wǎng)站制作、App開發(fā)、小程序開發(fā)、定制網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)