對于任何一個力，都存在著一個與其大小相等方向相反的反作用力。這個物理學(xué)上的牛頓第三定律也同樣適用于IaC：雖然這一服務(wù)是有優(yōu)勢的，但它也帶來了一些問題。

本文是針對混合云和多個云管理使用基礎(chǔ)設(shè)施即代碼系列中的第二部分?？牲c(diǎn)擊閱讀第一部分。

基礎(chǔ)設(shè)施即代碼是一個強(qiáng)大的工具，它可以幫助簡化混合云和多個云的管理工作，因?yàn)樗軌驅(qū)崿F(xiàn)服務(wù)器、容器以及虛擬機(jī)的部署與配置操作的自動化。但是，它也可能會導(dǎo)致出現(xiàn)低效過程、部署錯誤以及常見混亂等問題。那么，用戶應(yīng)當(dāng)如何解決實(shí)施能夠確定成功與否的基礎(chǔ)設(shè)施即代碼所帶來的挑戰(zhàn)呢?

在實(shí)施基礎(chǔ)設(shè)施即代碼過程中，大多數(shù)企業(yè)所遇到的第一個挑戰(zhàn)就是在開發(fā)人員和運(yùn)營團(tuán)隊(duì)之間創(chuàng)建一個和諧融洽的平穩(wěn)關(guān)系。在過去，開發(fā)人員在為應(yīng)用程序設(shè)置托管平臺時幾乎很難有所作為。這就會帶來問題，尤其是在從應(yīng)用程序測試到實(shí)際生產(chǎn)的過渡過程中更是如此。在大型企業(yè)中最常用的開發(fā)運(yùn)營工具能夠有助于推動開發(fā)團(tuán)隊(duì)和運(yùn)營團(tuán)隊(duì)之間的協(xié)作。但是，對于那些缺乏開發(fā)運(yùn)營理念與工具以及相關(guān)企業(yè)文化的公司來說，實(shí)施一個混合云或多個云可能是第一次需要這樣一種合作。

如果企業(yè)用戶在開發(fā)初期就將應(yīng)用與特定平臺相互關(guān)聯(lián)，然后讓這些平臺需求推動基礎(chǔ)設(shè)施策略貫穿整個應(yīng)用程序生命周期管理直至最后生產(chǎn)，那么實(shí)施一次基礎(chǔ)設(shè)施即代碼還較為容易完成的。此外，當(dāng)虛擬平臺數(shù)量是可管理時，這一目標(biāo)也是較為容易實(shí)現(xiàn)的。這些虛擬平臺是應(yīng)用開發(fā)的目標(biāo)，它們可用于在所有云中或者數(shù)據(jù)中心資源(應(yīng)用就是在數(shù)據(jù)中心資源上運(yùn)行的)上部署應(yīng)用。仔細(xì)定義這些虛擬平臺并讓開發(fā)團(tuán)隊(duì)和運(yùn)營團(tuán)隊(duì)使用它們作為各自工作的重點(diǎn)。

不要模糊不同角色之間的界限

第二個挑戰(zhàn)就是確?；A(chǔ)設(shè)施即代碼和開發(fā)運(yùn)營團(tuán)隊(duì)在混合云和多個云管理策略中各司其職，正常發(fā)揮合適的作用。開發(fā)運(yùn)營主要關(guān)注應(yīng)用程序部署，而基礎(chǔ)設(shè)施即代碼則主要負(fù)責(zé)資源配置管理。亞馬遜網(wǎng)絡(luò)服務(wù)(AWS)提供了開發(fā)運(yùn)營工具Chef作為其云服務(wù)的部署管理工具，這一事實(shí)表明兩者之間的界限有可能會發(fā)生模糊。事實(shí)上，最常見的基礎(chǔ)設(shè)施即代碼工具是開發(fā)運(yùn)營的一部分。這一狀況可能會造成開發(fā)團(tuán)隊(duì)和運(yùn)營團(tuán)隊(duì)之間的持續(xù)混亂。

除非用戶純粹出于服務(wù)器整合的目的來使用云服務(wù)，希望還需要開發(fā)運(yùn)營來實(shí)現(xiàn)部署自定義和應(yīng)用程序生命周期管理的簡化。對于企業(yè)用戶來說，如果沒有正確好用的工具集，那么部署多層次、多組件應(yīng)用程序并保持一致地正確協(xié)調(diào)應(yīng)用程序響應(yīng)云計(jì)算或數(shù)據(jù)中心故障將是一項(xiàng)非常困難的任務(wù)。即便用戶并不立即需要所有的開發(fā)運(yùn)營能力 ，那么也可以選擇一個開發(fā)運(yùn)營工具，例如Chef、Puppet、Ansible或Salt等，然后采用其基礎(chǔ)設(shè)施即代碼方法。

不要千篇一律地對待所有的云服務(wù)供應(yīng)商

當(dāng)使用基礎(chǔ)設(shè)施即代碼來簡化混合云和多個云管理時，第三個挑戰(zhàn)就是解決不同云托管環(huán)境之間的差異性問題。大多數(shù)用戶最終將使用一個混合云計(jì)算模式或多個云模式，而其中很多人已經(jīng)這樣做了。每一家公共云供應(yīng)商都有一個不同的管理框架，他們報(bào)告問題的方式也不一樣，如果發(fā)生錯誤所需要采取的補(bǔ)救措施也不相同。管理這些問題將讓開發(fā)運(yùn)營所部屬的和基礎(chǔ)設(shè)施即代碼所控制配置的應(yīng)用程序之間的界限變得模糊起來。

按照用戶開發(fā)運(yùn)營工具供應(yīng)商的建議來區(qū)分定義，何種情況由基礎(chǔ)設(shè)施即代碼層來處理，何種情況在開發(fā)運(yùn)營層作為 事件 上報(bào)。確定用戶所計(jì)劃做出的任何變更是否會影響如何部署虛擬平臺，或者如何部署應(yīng)用程序本身。在第一種情況下，可考慮重新部署資源，例如虛擬機(jī)或容器;而在第二種情況下，可考慮重新部署應(yīng)用組件。例如，如果用戶必須擴(kuò)展應(yīng)用程序中一個組件，那么相關(guān)變更必須發(fā)生在開發(fā)運(yùn)營層，但如果用戶必須更換故障組件，那么有可能應(yīng)在基礎(chǔ)設(shè)施即代碼層實(shí)施這一操作。

云供應(yīng)商有不同的網(wǎng)絡(luò)服務(wù)，這一事實(shí)就帶來了下一個挑戰(zhàn)?；A(chǔ)設(shè)施即服務(wù)和基本容器服務(wù)在應(yīng)用鏡像外提供了最小的中間件。但是一些供應(yīng)商(例如AWS和微軟Azure)提供的網(wǎng)絡(luò)服務(wù)從本質(zhì)上說就是云托管的中間件。云供應(yīng)商提供這些網(wǎng)絡(luò)服務(wù)的形式各有不同，或者在某些情況下，他們甚至都完全不提供這些網(wǎng)絡(luò)服務(wù)。

由于不同的托管環(huán)境無法提供相同的功能，所以應(yīng)用無法具備跨不同托管環(huán)境的可移植性。如果不可能在多家云計(jì)算供應(yīng)商之間實(shí)現(xiàn)網(wǎng)絡(luò)服務(wù)的一致性，那么應(yīng)當(dāng)明確命名虛擬平臺以表明它們是不可移植的。如果用戶所使用的所有平臺上必要的網(wǎng)絡(luò)服務(wù)可用，但需要不同的部署配置，那么用戶可以使用基礎(chǔ)設(shè)施即代碼腳本程序來為用戶虛擬平臺定義多個托管選項(xiàng)。

不要碎片化實(shí)施基礎(chǔ)設(shè)施即代碼

實(shí)施基礎(chǔ)設(shè)施即代碼的最后一個挑戰(zhàn)就是配置外部的小修小補(bǔ)。讓基礎(chǔ)設(shè)施即代碼在斷開連接的碎片環(huán)境中正常運(yùn)行是非常困難的，同樣讓企業(yè)在缺乏基礎(chǔ)設(shè)施即代碼工具或腳本程序的情況下做出某些配置變更也是非常不容易的。例如，運(yùn)營團(tuán)隊(duì)經(jīng)常會在不更改基礎(chǔ)設(shè)施即代碼腳本程序或模式的情況下做出一些配置變更以適應(yīng)新的軟件版本。這就意味著這些腳本程序?qū)⒉辉俨渴鹜泄芘渲玫恼_版本。

解決這個問題需要執(zhí)行嚴(yán)格的運(yùn)行紀(jì)律。如果沒有通過正式的變更管理系統(tǒng)將這個變更記錄在冊，那么運(yùn)營團(tuán)隊(duì)就絕不應(yīng)當(dāng)對系統(tǒng)或云配置做出這樣一個變更操作。當(dāng)他們確實(shí)需要做出變更時，他們應(yīng)當(dāng)修改基礎(chǔ)設(shè)施即代碼腳本程序并按要求重新配置，然后將相關(guān)變更登記在冊。無論何時運(yùn)營團(tuán)隊(duì)修改了基礎(chǔ)設(shè)施即代碼的腳本程序，他們都必須將這個變更反饋給開發(fā)團(tuán)隊(duì)以便針對應(yīng)用程序需要驗(yàn)證該變更。

基礎(chǔ)設(shè)施即代碼是基于配置管理和開發(fā)運(yùn)營的一種發(fā)展，但他也是一個新興的范例。為基礎(chǔ)設(shè)施即代碼的未來做好規(guī)劃是非常重要的，否則用戶將面臨無法發(fā)揮混合云和多個云管理部署全部潛力的風(fēng)險(xiǎn)。

文章編輯：CobiNet(寧波)，本公司專注于電訊配件,銅纜綜合布線系列領(lǐng)域產(chǎn)品研發(fā)生產(chǎn)超五類，六類,七類屏蔽網(wǎng)線/屏蔽模塊及相關(guān)模塊配件,歡迎來電咨詢0574 88168918,網(wǎng)址www.10166888.com

我們是萬兆屏蔽模塊，10G屏蔽模塊，屏蔽線生產(chǎn)廠家。