為多云平臺(tái)選擇云配置管理工具
多云模型面臨著獨(dú)特的配置管理挑戰(zhàn)。當(dāng)選擇一個(gè)工具時(shí)，企業(yè)應(yīng)該仔細(xì)對(duì)比云本地和第三方的選項(xiàng)。
當(dāng)企業(yè)選擇向云計(jì)算遷移時(shí)，配置管理并沒有消失。事實(shí)上，配置管理在云中變得更加重要——尤其是當(dāng)企業(yè)使用多云提供商時(shí)，因?yàn)樗鼛椭櫜⒖刂频能浖淖兓?/p>
與他們使用本地工具一樣，組織使用云配置管理工具來確保對(duì)所需交付服務(wù)的資源的適當(dāng)控制。這些工具還可以提供一些信息，關(guān)于如何更好地配置資源 ，以及資源之間的關(guān)系的信息。
但企業(yè)面臨著一個(gè)重要選擇：在公有云中使用本地配置服務(wù)，還是使用第三方工具，如Ansible 和CFengine。這一選擇并不簡單。本地云配置管理工具使得企業(yè)變得更加依賴于它的公有云提供商，增加了廠商鎖定的風(fēng)險(xiǎn)。例如，當(dāng)企業(yè)使用現(xiàn)兩個(gè)或更多的公有云時(shí)，如AWS和人體中，本地配置工具在這兩具平臺(tái)上的表現(xiàn)可能不會(huì)很好。
配置管理選項(xiàng)
來自于第三方和云提供的一些最為常見的云盞管理工具：
第三方：
- Chef
- Puppet
- Terraform
- SmartFrog
- Ansible
提供商自有：
- AWS Config
- Microsoft System Center Configuration Manager
- Google Cloud Platform's autoscaler
- Google Cloud Platform instance groups and managed instance groups
第三方配置工具，無論是否基于云，都可以與多云提供商合作，提供抽象層來移除某些配置復(fù)雜性。然而，這些第三方工具在公有云中獲得一些能力時(shí)，他們也可能會(huì)失去一些能力。為了采用最小公分母方法，第三方云配置管理工具要放棄一些本地工具所提供的能力。例如，許多本地工具提供一種功能來實(shí)時(shí)更新庫——存儲(chǔ)跟蹤資源相關(guān)的數(shù)據(jù)的系統(tǒng)。
第三方工具經(jīng)常需要你手動(dòng)執(zhí)行這類任務(wù)，這將浪費(fèi)時(shí)間，并且增加的錯(cuò)誤的機(jī)率，然而他們可以跨不同的云平臺(tái)工作。企業(yè)需要折衷一下，來平衡本地云服務(wù)的工作能力，如AWS中的功能，與從多云本地服務(wù)抽象工具的能力。
例如，AWS OpsWorks是使用了Chef的云配置管理服務(wù)。Chef提供了一個(gè)自動(dòng)化的平臺(tái)，把服務(wù)配置作為代碼看待。組織可以部署這一技術(shù)來動(dòng)態(tài)更改他們的軟件配置。這一行為通過程序代碼完成，不是通過GUI完成的。這允許開發(fā)人員根據(jù)意愿變更配置，使用API從程序中直接更改。AWS OpsWorks能夠自然地與Amazon Elastic Compute Cloud實(shí)例合作，但卻不能確保與其它提供商，如谷歌或微軟 Azure的正常運(yùn)行。
云配置管理需要跨所有相關(guān)平臺(tái)的高效運(yùn)行。雖然組織可以使用第三方工具跨不同的云服務(wù)，但這些工具不能為每個(gè)平臺(tái)做所有的事，所以有一些需要人工流程琮完成?，F(xiàn)在，是好的選擇是使用多云配置管理工具，即它成本更高，更復(fù)雜。
