作為一組概念，DevOps 融合了幾個突出的主題，包括持續(xù)軟件交付、自動化和配置管理 (CM)。這些不可或缺的部分通常構(gòu)成組織 DevOps 工作的支柱，即使其他更大的部分（如總體最佳實(shí)踐和指南）仍在嘗試和測試中。由于 DevOps 是一種相對較新的范式 - 運(yùn)動 - 方法論 - [在此處插入您自己的標(biāo)簽]，圍繞它的標(biāo)準(zhǔn)尚未被編纂并一成不變。組織需要確定最適合其用例的工具和方法，并且會根據(jù)其成功程度對它們發(fā)誓或貶低它們。
就 CM 而言，一種特定的方法可能適用于一家公司，但不適用于另一家公司，這是一個假設(shè)。然而，很少有不同的方法會像 CM 的聲明式和命令式模型那樣產(chǎn)生如此多的異議。關(guān)于誰更勝一籌的反復(fù)辯論已經(jīng)贏得了雙方的堅(jiān)定支持者，值得仔細(xì)研究。
定義聲明式和命令式模型
聲明式和命令式模型之間的差異可以用一句話來概括：命令式側(cè)重于如何，而聲明式側(cè)重于什么。在軟件工程上下文中，聲明式編程意味著編寫代碼來描述程序應(yīng)該做什么，而不是它應(yīng)該如何做。一個描述需要發(fā)生的事情；讓它如此的細(xì)節(jié)留給系統(tǒng)。相比之下，命令式編程涉及編寫遵循明確步驟來解決問題、完成任務(wù)或達(dá)到預(yù)期結(jié)果的代碼。它具體告訴系統(tǒng)如何做某事，以期達(dá)到預(yù)期的結(jié)果。
命令式/聲明式構(gòu)造也延續(xù)到 IT 領(lǐng)域，例如 CM。事實(shí)上，一個特定的 CM 工具的方法很大程度上受其構(gòu)建的基礎(chǔ)語言的影響（反過來，它本質(zhì)上是命令式的或聲明式的）。
例如，Puppet 是聲明性的：系統(tǒng)管理員描述了所需的最終狀態(tài)，并且工具會嘗試達(dá)到它。它的領(lǐng)域特定語言 (DSL) 用于創(chuàng)建所需服務(wù)器狀態(tài)的高級描述，而不是要執(zhí)行的指令和操作。清單——包含配置信息的 Puppet 文件——可以多次使用以達(dá)到相同的結(jié)果。如果已達(dá)到所需的最終狀態(tài)，Puppet 會簡單地忽略相關(guān)項(xiàng)目。用戶只需擔(dān)心要配置的系統(tǒng)所需的最終狀態(tài)，而不是到達(dá)那里所需的步驟順序。
該條目描述了一個結(jié)束狀態(tài)，其中包含一個名為 /tmp/test123 的文件，其內(nèi)容為“這是一個測試”。如果在目標(biāo)系統(tǒng)上找到匹配的文件（和內(nèi)容），Puppet 假定已經(jīng)達(dá)到所需的結(jié)束狀態(tài)。隨后，無需擔(dān)心 Manifest 會多次執(zhí)行此部分。
相比之下，Chef（Puppet 的宿敵）勢在必行。用戶在稱為食譜的配置指令中定義命令及其執(zhí)行順序，這些指令又可以組織成食譜，以便于管理。
此配方檢查目標(biāo)節(jié)點(diǎn)上的 JDK 7——如果存在，Chef 將安裝 OpenJDK 7。如果不存在，則會發(fā)出警告。請注意，Chef Recipes 的結(jié)構(gòu)是順序的命令列表，而不是 Puppet Manifests，后者僅包含對所需最終狀態(tài)的描述。
CM 供應(yīng)商的一個增長趨勢是讓他們的產(chǎn)品對任一模型開放，從而贏得兩個陣營的心。即使是像 Chef 這樣本質(zhì)上必不可少的工具也可以以聲明方式設(shè)置。
與前面的示例相比，上述配方描述了所需的結(jié)束狀態(tài)，而不是列出要執(zhí)行的一系列命令。
那么哪個型號更適合CM呢？要解決這個問題，需要有資格獲得誰和什么。此外，考慮到 DevOps 的當(dāng)前流行程度和采用率，專家們的復(fù)雜程度不斷提高也就不足為奇了：圍繞 DevOps 的對話已經(jīng)從它是什么發(fā)展到如何去做。怎么做取決于你問的是誰。
因此，讓我們從三個角度分析這場爭論：程序員、系統(tǒng)管理員和全棧開發(fā)人員。
熱衷于編寫高效、結(jié)構(gòu)化和易于理解的代碼的程序員并不是采用笨拙抽象的聲明性模型的最大粉絲。他習(xí)慣于用 for 循環(huán)、條件語句、變量等來規(guī)定事情應(yīng)該如何發(fā)生。他所從事的軟件的業(yè)務(wù)邏輯本質(zhì)上是必不可少的。
最適合：像 Chef 這樣的命令式 CM 工具
系統(tǒng)管理員 喜歡經(jīng)營一家緊湊的商店，這是有充分理由的：如果基礎(chǔ)設(shè)施出現(xiàn)故障，公司就會急剎車。他是一個 Bash 向?qū)?，精?Python 和 Perl，并且更喜歡使用它們而不是學(xué)習(xí)像 Ruby 這樣的新語言。他更喜歡聲明式而不是命令式模型，但他意識到前者在管理動態(tài)云基礎(chǔ)架構(gòu)方面所面臨的挑戰(zhàn)。
最適合： 混合 CM 工具，如 Ansible 或 SaltStack
全棧開發(fā)人員 可以輕松地遍歷堆棧，并且喜歡將基礎(chǔ)架構(gòu)抽象為代碼的想法。Ruby/RoR 忍者，她是 Chef 和 Puppet 的粉絲。她可以欣賞每個模型的優(yōu)點(diǎn)；對她來說，任何一種工具都可以讓她更快、更高效、更不容易出錯地持續(xù)構(gòu)建和發(fā)布高質(zhì)量的軟件。
最適合：任一型號。Puppet、Chef 和 SaltStack 是可行的選擇。
請注意，我們的程序員很可能是 Python 專業(yè)人士，因此非常精通 Ansible（其模塊是用 Python 編寫的）。無論如何，將組織的 IT 技能構(gòu)成與適當(dāng)?shù)哪Ｐ?工具相匹配是確定哪個更合適的實(shí)用方法。如果一家公司從事由程序員掌舵的傳統(tǒng)軟件開發(fā)，那么命令式工具可能是最合適的。一個按計(jì)劃持續(xù)推出的快速發(fā)展的 SaaS 將欣賞一個實(shí)施良好的聲明式 CM 解決方案的靈活性和可擴(kuò)展性。一個對 Ruby 發(fā)誓并擁有專業(yè)知識的商店可能會選擇使用某些工具“烹飪”，從而完全推翻模型辯論。
要記住的關(guān)鍵點(diǎn)是聲明式和命令式模型都是易錯的：前者需要相信已達(dá)到所需狀態(tài)（幾乎沒有驗(yàn)證手段），而后者則需要在出現(xiàn)問題時進(jìn)行復(fù)雜的故障排除。在某些邊緣場景中，這兩種模型都可能存在問題；隨后，無論采用哪種方法，都不應(yīng)將單個工具實(shí)施為 CM 的全部和最終目標(biāo)。所選擇的解決方案應(yīng)該只包含 CM 工具鏈的一部分，而另一個將其作為監(jiān)督工具，確保所有 CM 和自動化工具都按預(yù)期執(zhí)行。
服務(wù)于這個目的：通過強(qiáng)大的掃描、監(jiān)控和比較功能提供全面的系統(tǒng)可見性，我們的平臺彌合了期望您的系統(tǒng)/環(huán)境以某種方式與實(shí)際驗(yàn)證它是否滿足這些期望之間的關(guān)鍵差距。
簡而言之，爭奪思想和市場份額的競爭供應(yīng)商將熱情地?fù)碜o(hù)他們的產(chǎn)品各自的方法。盡管圍繞聲明式/命令式模型的辯論在商業(yè) CM 領(lǐng)域呈現(xiàn)出新的強(qiáng)度和熱情，但事實(shí)是，許多工具兼具兩者的品質(zhì)——盡管它們可能更多地基于一種模式。因此，將聲明式和命令式模型視為一系列可能性，各自的解決方案更接近任一端，這可能更有用。
