基礎(chǔ)設(shè)施即代碼讓混合多云管理更為復雜

作者：佚名 2016-08-30 10:20:57
云計算 基礎(chǔ)設(shè)施即代碼是一個強大的工具，它可以幫助簡化混合云和多個云的管理工作，因為它能夠?qū)崿F(xiàn)服務器、容器以及虛擬機的部署與配置操作的自動化。但是，它也可能會導致出現(xiàn)低效過程、部署錯誤以及常見混亂等問題。那么，用戶應當如何解決實施能夠確定成功與否的基礎(chǔ)設(shè)施即代碼所帶來的挑戰(zhàn)呢?

創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供邕寧網(wǎng)站建設(shè)、邕寧做網(wǎng)站、邕寧網(wǎng)站設(shè)計、邕寧網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、邕寧企業(yè)網(wǎng)站模板建站服務，十余年邕寧做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務。

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

　　本文是針對混合云和多個云管理使用基礎(chǔ)設(shè)施即代碼系列中的一部分。

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

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

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

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

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

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

　　不要千篇一律地對待所有的云服務供應商

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

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

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

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

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

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

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

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

網(wǎng)頁標題：基礎(chǔ)設(shè)施即代碼讓混合多云管理更為復雜
本文路徑：http://m.5511xx.com/article/djjcsei.html